股票数据的数据库选择

Question

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

输入是来自多个来源的小时库存数据（sku，数量，价格等）。旧版本将被删除。所以我们不会超过1个mio。数据集在不久的将来，并且不会像数据仓库中那样出现任何商业智能查询。但是将存在汇总，至少对于一组商品的最低价格而言，如果一组最低价格的商品被售罄，则必须进行汇总。除了频繁地进行这些批量写入外，还会随时减少文章数量的单次减少。

该数据库将成为服务的一部分，该服务需要通过REST快速响应请求。因此，需要进行某种缓存。不需要强烈的一致性，但要持久。

进一步的愿望清单：

• 应该很好地适应不断增长的请求负载
• 就金钱和复杂性而言，价格便宜的技术（没有Oracle集群）
• 没有专有语言（没有PL / SQL）

MongoDB及其聚合框架似乎很有希望。你能想到替代品吗？（我不坚持使用NoSQL！）

Answer 1

我会从 Redis 开始，原因如下：

• “需要某种缓存” => 这就是 Redis 最擅长的。如果出于任何原因您决定需要“更多”，您可以添加“更多”，但仍保留您在 Redis 中已经开发的内容作为该“更多”的缓存

• 一个Redis很快。两个 Redis 更快。三个 Redis 是一个比两个更快的单位，等等。

• 学习曲线非常平坦，而且很有趣 => 因为集合论真的很有趣

• Increments / Decrements / Min / Max 是 Redis 的原生对话

• Redis 与 XYZ 的集成（您提到需要 REST API）遍布 google 和 github

• Redis 很诚实<= 实际上是我最喜欢的 Redis 功能之一

MongoDB首先可以工作，任何其他主要的 NoSQL 也可以，但为什么！？

我会选择 Redis，如果您稍后决定需要“更多”，我会首先查看“Redis + SQL db (Postgre/MySQL/etc..)”，它会给您两个世界=>“缓存” /速度”和“聚合功率”，以防聚合需要超出最小/最大/增量/减量。

告诉你 PostgreSQL“写入速度不够快”的人并不知道。

谁告诉你 MySQL“可扩展性不够”，他并不知道（例如 Facebook 就运行在 MySQL 上）。

因为我已经准备好了:) => 无论谁告诉你 MongoDB 有“副本集和分片”，都不希望你好，因为副本集和分片只是从文档和炒作中看起来很性感。一旦您需要重新分片/重组副本集，您就会知道错误的分片键选择和魔法块移动的代价......

再次 => Redis FTW！