我有一个包含我们用户数据的大型复杂遗留关系数据库。我想构建一个应用程序，按照各种标准对用户群进行细分（告诉我每个体重超过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的各种方法，面向文档的DB似乎最适合我。随意提出一个更好的方法。
加分问题 _ 文档数据库的好处是否证明了将新技术引入数据中心的开销是合理的？ _
我的意思是，我很可能满足我们现有的关系型数据库的性能要求得很好，但我很感兴趣沾我的脚趾在NoSQL的水域，因为我有其他的应用下了线，其中一个面向文档的数据库倒很现付我想先用一个简单的应用程序弄湿我的脚。
答案 0 :(得分：4)
我们最近开始将NoSQL混入我们的技术堆栈中，但我开始使用Mongo的封顶集合进行简单的日志记录，以了解技术并确保其稳健，重要的是确保应用程序代码在以后使用NoSQL作为持久性时是有意义的。数据和对象如何持久化将随着此移动而改变，这也需要考虑在内。
使用传统方法无法做到的事情很少，而且你会确信它会像你期望的那样工作。风险很低。但我也想在未来的另一个项目中使用它，所以我把脚趾拉进去。
使用任何新技术，直到它在您的语言领域得到证明，并且直到您可以证明您对此感到满意为止，我建议您采取“小步骤”并开始实施您所描述的规模的项目。
我的方式，您是否考虑过使用索引视图来“规范化”您的数据并从中进行选择？只是一个想法。
我希望有所帮助！