mongodb - 面向文档的数据库是否适合此用例？

Question

我有一个大型、复杂的遗留关系数据库，其中包含我们的用户数据。我想构建一个应用程序，根据各种标准对用户群体进行分割(显示所有体重超过 200 磅且穿着红色衬衫的人)。查询将由预定义的参数化谓词组成(想想 outlook 或 gmail 中的消息规则 UI)。完全即席的查询将很少见。

由于遗留架构的复杂性，针对源数据构建 SQL 查询是不切实际的。

第一个天真的想法可能是将要用于分割的数据反规范化到 RDBMS 中的一个非常宽的表中:

id  | hat size | shirt color | weight | ....123 | 7        | blue        | 175    | 456 | 6        | red         | 205    | 

但这并不太吸引人，因为数据会很稀疏，而且列会经常变化(每周？)。在我的环境中，架构更改在逻辑上很困难。

我可以进一步将该表规范化为一个简单的键/值表，但在这一点上，NoSQL 变得很有趣。

所以这是我的问题:

像 MongoDB 或 CouchDB 这样的面向文档的数据库是否适合这种用例？

我没有大量数据(在假设的非规范化表中，有数百万行、300 列左右)。写入相当少(每天 10,000 次)。查询每天会发生几次，响应时间需要以秒为单位。

过去几天我一直在阅读 NoSQL 的各种方法，面向文档的数据库似乎最适合我。欢迎提出更好的方法。

奖励问题_文档数据库的好处是否值得将新技术引入我们的数据中心的开销？_

我的意思是，我可能可以用我们现有的关系数据库很好地满足性能要求，但我有兴趣涉足 NoSQL 领域，因为我还有其他应用程序在面向文档的数据库真正支付 -关闭，我想先尝试一个简单的应用程序。

Answer 1

我们最近开始将 NoSQL“混合”到我们的技术堆栈中，但我开始通过 Mongo 使用上限集合进行简单的日志记录，以了解该技术并确保它的健壮性，重要的是，确保以后使用 NoSQL 作为持久性时，应用程序代码才有意义。数据和对象的持久化方式将随着这一举措而改变，这也需要考虑在内。

几乎没有什么是传统方法无法完成的，而且您会确信它也会像您期望的那样工作。这是低风险的。但我也想在未来的其他项目中使用它，所以我试了一下。

对于任何新技术，直到它在您的语言领域得到证实，并且您可以证明自己对它感到满意之前，我建议您采取“婴儿步骤”并逐步完成您所描述规模的项目。

顺便问一下，您是否考虑过使用索引 View 来“规范化”您的数据并从中进行选择？只是一个想法。

希望对您有所帮助!