我想知道NoSQL是否适用于这种情况：
输入是来自多个来源的每小时库存数据（sku，数量，价格和更具体的一些）。旧版本只会下降。所以我们不会超过1 mio。在不久的将来，数据集将不会出现像数据仓库那样的商业智能查询。但是会有聚合，至少对于一组的最低价格而言，如果一个组的最低价格的商品售罄，则必须更新。除了频繁写入这些批量写入之外，还可以随时对文章数量进行单一减少。
数据库将成为服务的一部分，需要通过REST快速响应请求。所以需要某种缓存。没有必要坚持一致，但坚持不懈。
进一步的愿望清单：
MongoDB及其aggregation framework似乎很有希望。你能想到替代品吗？ （我不坚持NoSQL！）
答案 0 :(得分：3)
我会从Redis开始，这就是原因：
“需要某种缓存” =＆gt;这就是Redis最擅长的。如果由于任何原因您决定需要“更多”，您可以添加“更多”，但仍然保留您在Redis中已经开发的任何内容作为“更多”的缓存
One Redis很快。两个Redise更快。三个Redise是比两个更快的单位等。
学习曲线相当平坦，乐趣=＆gt;因为集合理论真的很有趣
递增/递减/最小/最大是Redis的本地谈话
Redis与XYZ的集成（您提到需要REST API）遍布google和github
Redis是诚实的＆lt; =实际上我最喜欢的Redis功能之一
MongoDB最初会 ，所以任何其他主要的NoSQL，都会这样，但为什么呢？
我会选择Redis，如果你以后决定需要“更多”，我会先看看“Redis + SQL db（Postgre / MySQL / etc ..）”，它会给你两个世界= ＆GT;如果您的聚合需要超出Min / Max / Incr / Decr，那么“缓存/速度”和“聚合能力”。
无论谁告诉你PostgreSQL“写得不够快”都不知道。
谁告诉你MySQL“不够可扩展”不知道它（例如Facebook在MySQL上运行）。
因为我已经在滚动了:) =＆gt;谁告诉你MongoDB有“副本集和分片”不希望你好，因为副本集和分片只从文档和炒作看起来很性感。一旦你需要reshard / reorg副本集，你就会知道错误的分片键选择和魔术块移动的价格......
再次=＆gt; Redis FTW！
答案 1 :(得分：0)
嗯，在我看来MongoDB是最好的选择。
它不仅具有聚合功能，还具有映射/减少查询的可能性，可用于统计计算。它可以通过replica sets和sharding进行缩放，具有增量的原子更新（减量只是负增量）。
备选方案：
CouchDB - 阅读速度不够快Redis - 是键/值db。您需要在应用程序级别编写文章逻辑MySQL - 不够可扩展PostgreSQL - 如果使用pgbouncer进行缩放，但在写作时速度不够，则可能是不错的选择