我想知道 NoSQL 是否适合这种情况:
输入是来自多个来源的每小时库存数据(sku、数量、价格等等)。旧版本将被丢弃。所以我们不会超过1 mio。数据集在不久的将来，不会有像数据仓库那样的任何商业智能查询。但是会有聚合，至少对于一组最低价格的文章，如果一组最低价格的文章售罄，则必须更新。除了这些基于频繁的批量写入之外，随时可能发生的文章数量的单次递减。
数据库将是需要通过 REST 快速响应请求的服务的一部分。所以需要有某种缓存。不需要强烈的一致性，但需要持久性。
更多愿望 list :
- 应该可以很好地扩展以适应不断增长的请求负载
- 在资金和复杂性方面的廉价技术(无 Oracle 集群)
- 无专有语言(无 PL/SQL)
MongoDB 及其 aggregation framework似乎很有希望。你能想到替代方案吗？ (我不坚持 NoSQL!)
最佳答案
我会从 Redis 开始，原因如下:
“需要某种缓存” => 这就是 Redis 最擅长的。如果出于某种原因您决定需要“更多”，您可以添加“更多”，但仍保留您在 Redis 中开发的任何内容作为“更多”的缓存
一个 Redis 很快。两个 Redis 更快。三个 Redises 比两个更快，等等。
学习曲线相当平坦，而且很有趣 => 因为集合论真的很有趣
Increments/Decrements/Min/Max 是 Redis 的原生对话
Redis 与 XYZ 的集成(您提到需要 REST API)遍布 google 和 github
Redis 是诚实的 <=实际上是我最喜欢的 Redis 功能之一
MongoDB 一开始可以工作，其他主要的 NoSQL 也可以，但是为什么!？
我会选择 Redis，如果你以后决定需要“更多”，我会先看看“Redis + SQL db (Postgre/MySQL/etc..)”，它会给你两个世界 = > “缓存/速度”和“聚合能力”，以防您的聚合需要超出 Min/Max/Incr/Decr。
告诉你 PostgreSQL“写起来不够快”的人并不知道。
谁告诉你 MySQL“可扩展性不够”并不知道(例如 Facebook 在 MySQL 上运行)。
因为我已经开始了 :) => 告诉你 MongoDB 有“副本集和分片”的人并不希望你好，因为副本集和分片从文档和炒作中看起来很性感。一旦你需要重新分片/重组副本集，你就会知道错误的分片键选择和魔法 block 移动的代价......
再次 => Redis FTW!
关于mongodb - 股票数据的数据库选择，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9851101/