库存数据的数据库选择

Question

我想知道NoSQL是否适合这种情况：

输入的是来自多个来源的小时库存数据(sku、数量、价格和一些更具体的数据)。旧的版本只会掉下来。所以我们不会超过1百万。数据集在不久的将来，不会有任何商业智能查询，如在数据仓库。但是也会出现聚合，至少对于一组物品的最低价格，如果一个组的最低价格的文章卖光了，就必须更新它。除了这些频繁的大写之外，一篇文章的数量也会减少一次，这在任何时候都可能发生。

数据库将是服务的一部分，该服务需要通过REST快速响应请求。所以需要某种缓存。不需要严格的一致性，但要持久。

进一步的愿望清单：

• 对于不断增长的请求负载，应该进行良好的扩展。
• 在金钱和复杂性方面便宜的技术(没有Oracle集群)
• 没有专有语言(没有PL/SQL)

MongoDB和它的聚合框架看起来很有希望。你能想到备选词吗？(我不坚持NoSQL!)

Answer 1

我从Redis开始，原因如下：

• “需要某种类型的缓存”=>，这就是Redis最擅长的地方。如果出于任何原因，您决定需要“更多”，则可以添加“更多”，但仍然保留在Redis中已经开发的内容作为“更多”的缓存。
• 一条红宝石真快。两个Redises更快。三个Redises是一个比两个更快的单位，等等
• 学习曲线是相当平坦的，有趣的=>因为集合理论真的很有趣。
• 增量/递减/ Min / Max是Redis的母语
• Redis与XYZ的集成(您提到了对REST的需求)遍布google和github。
• Redis是诚实的 <=，实际上是我最喜欢的Redis特性之一。

MongoDB一开始可以工作，其他主要的NoSQL也会工作，但为什么呢？

我将使用Redis，如果您稍后决定需要“更多”，我将首先查看"Redis + SQL (Postgre/MySQL/etc.)“，它将为您提供两个世界的=>”缓存/速度“和”聚合能力“，以防您的聚合需要超出Min/Max/Incr/Decr。

无论谁告诉你PostgreSQL“写得不够快”，他都不知道。

无论谁告诉你MySQL“不够可伸缩”，都不知道(例如Facebook运行在MySQL上)。

=>告诉你MongoDB有“复制集和切分”并不是很好，因为从文档和炒作来看，复制集和切分看起来很性感。一旦您需要reshard / reorg副本集，您就会知道错误的碎片键选择和神奇的块移动的代价..。

=> Redis FTW!

Answer 2

在我看来，MongoDB是最好的选择。

它不仅具有聚合特性，而且还具有用于统计计算的映射/减少查询的可能性。它可以通过replica sets和sharding进行缩放，具有增量的原子更新(递减只是负增量)。

替代办法：

• CouchDB -阅读速度不够快
• Redis -是键/值db。您需要在应用程序级别上对文章逻辑进行编程。
• MySQL -可伸缩性不够
• PostgreSQL --如果使用pgbouncer进行缩放，但编写的速度不够快，这可能是很好的选择。