战略问题：混合关系和非关系数据库？ [英] Strategic issue: Mixing relational and non-relational db?
问题描述
有很多关于革命性的NoSQL数据库的讨论，例如 Cassandra ， CouchDB ， Hypertable ， MongoDB ， Project Voldemort ， BigTable 等等。就我而言，最强的优点是可扩展性，性能和简单性。
我正在认真考虑建议对我们的下一个项目使用一些非关系数据库。然而，一些团队包括一些RDBMS狂热者，所以说服一个硬开关在某些情况下可能是不可能的只是因为情感的原因。此外，当涉及到复杂的数据模型时，我个人仍然相信RDBMS的力量与他们的低级一致性强制机制。
这里有我的问题：我想知道，如果有人可以认真考虑在新项目中使用RDBMS 和非关系数据库：复杂的，但不是性能关键的数据模型仍将使用关系模型和db实现，而所有性能关键的，但简单的模型将使用非关系数据库实现。此外，这种软范式转换比一个困难的团队成员更容易卖给一些高度情绪化的团队成员。
有人会推荐这样的方法吗？或者你宁愿推荐黑色还是白色，即关系或非关系方法？所有评论都非常受欢迎！
PS：任何想法如果这样的混合在Spring和Hibernate / JPA
Rob Conery最近写了关于他构建受欢迎的网络应用程序的经验 TekPub 与MongoDB和MySQL，强调两者的优势：
高读的东西（帐户信息，情节信息）是一个现在像MongoDb的东西的完美。
在高层，Rob将应用程序数据分成两个范围：运行时数据和历史数据。例如，用户的购物车的当前状态对于保存在MongoDB中是很好的。这是一个不断变化的对象blob。保持购物车进出的历史记录;发生的时候;
他总结为：
它工作完美。我可以不是更快乐我们的设置。这是非常低的维护，我们可以支持它像任何其他解决方案，我们有我们需要的数据，当我们需要它。
2016年5月更新（6年后）
更真实的在过去6年。现在很常见的是NoSQL数据库为交易商店和传统的关系数据库提供动力的分析数据库。
There has been a lot of talk about contra-revolutionary NoSQL databases like Cassandra, CouchDB, Hypertable, MongoDB, Project Voldemort, BigTable, and so many more. As far as I am concerned, the strongest pros are scalability, performance and simplicity.
I am seriously considering to suggest using some non-relational db for our next project. However, some teams comprise some RDBMS fanatics, so convincing a hard switch might be impossible in some cases just because of emotional reasons. Also, when it comes to complex data models, I personally still believe in the power of RDBMS with their low-level consistance enforcement mechanisms.
Now here comes my question: I was wondering, if someone could seriously consider using both, RDBMS and non-relational DB in a new project: The complex, but not performance critical data model would still be implemented using a relational model and db, while all performance critical, yet, simple models would be implemented with a non-relational db. Furthermore, such a soft paradigm shift would be much easier to sell to some highly emotionalized team members than a hard one.
Would anyone recommend such an approach? Or would you rather recommend a black or white, i.e. relational or non-relational approach? All comments highly welcome!
P.S.: Any idea if such a mix-up works well with Spring and Hibernate/JPA?
Rob Conery recently wrote about his experience building his popular web application TekPub with both MongoDB and MySQL, highlighting the strengths of both:
The high-read stuff (account info, productions and episode info) is perfect for a "right now" kind of thing like MongoDb. The "what happened yesterday" stuff is perfect for a relational system.
At a high-level, Rob breaks their application data into two scopes: runtime data and historical data. The current state of a user's shopping cart, for example, is great for keeping in MongoDB. It's an object blob that is constantly mutating. To keep a historical record of what went in and out of the shopping cart; when it happened; the state of the checkout are great for relational, tabular data in MySQL.
He summarizes with this:
It works perfectly. I could not be happier with our setup. It's incredibly low maintenance, we can back it up like any other solution, and we have the data we need when we need it.
Update May 2016 (6 years later)
This has only become more true in the last 6 years. It's now common to see NoSQL databases powering transactional stores and traditional relational databases powering analytical databases.
这篇关于战略问题：混合关系和非关系数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
