需要有关数据存储选择的建议

Question

要求

必须有

水平可扩展。
二级索引快速排序。
对一组文档进行原子更新（或者通过模拟原子更新 table 级别的版本控制）。非常重要的是，一群文档（来自过滤器）被最终用户视为已更新一起。
应该很容易维护很多 tables。每个 table 都会存储一个类别的项目，每个类别都有一个单独的架构。
添加复合索引应该很容易。过滤条件可以随时更改（过滤器查询未预先定义）。更好的是如果数据存储允许对所有可能的组合进行快速过滤列（默认情况下带有所有可能的复合索引）。过滤器可以等于或范围查询。

可选

在上面提到的对一组文档进行原子更新时，我们通常只会更新两列或三列。如果数据存储支持部分文档更新而无需重新索引整个文档，那就太好了。

不需要

高可用性
强一致性（最终一致性有效）
高写入吞吐量或低写入延迟

查询模式

{
  "item_id": "1234",
  "brand": "adidas",
  "average_price": 123,
  "rate_of_sale": 123,
  "visual information": {
    "img_url": "http://imgsdsd",
    "color": "red"
  }
}

获取价格在 100 到 200 之间的所有阿迪达斯品牌商品并进行排序筛选设置基于 rate_of_sales。
根据第二天更新所有项目rate_of_sales 在 csv 上。它应该是一个原子更新或者它应该创建一个 new table，用new ros复制数据并删除旧的table和使应用程序指向新的 table.

Answer 1

由于您需要水平可伸缩性，因此 Mysql 等事务性存储不起作用。

既然要复合索引，那么Redis、Aerospike等键值存储和HBase、Cassandra等扩展键值存储就可以去掉了。

如果你有很多复合索引，MongodB效率低下。

Elastic search 或 Solr 支持所有用例（原子批量更新除外），尽管如果您要更新整个索引，这可以通过使用别名来解决。

Solr 通常可以多次更新文档。

如果复合索引数量不多，也可以考虑使用Mysql，做应用层分片

https://db-engines.com/en/ranking 是比较数据存储的好网站。

需要有关数据存储选择的建议

Need advice on datastore selection

architecture

datastore

system-design