战略问题:混合关系数据库和非关系数据库？

Question

有很多关于反革命NoSQL数据库的讨论,如Cassandra,CouchDB,Hypertable,MongoDB,Project Voldemort,BigTable等等.就我而言,最强大的优点是可扩展性,性能和简单性.

我正在认真考虑建议在下一个项目中使用一些非关系数据库.然而,一些团队包含一些RDBMS狂热分子,因此在某些情况下仅仅因为情感原因而难以说服硬切换.此外,当谈到复杂的数据模型时,我个人仍然相信RDBMS的强大功能与低级别的协调执行机制.

现在我的问题出现了:我想知道,如果有人可以认真考虑在新项目中同时使用RDBMS 和非关系数据库:复杂但不是性能关键的数据模型仍然可以使用关系模型和数据库实现,而所有性能至关重要,但是,简单模型将使用非关系数据库实现.此外,这种软范式的转变对于一些高度情绪化的团队成员来说要比出现困难的团队成员更容易出售.

有人会推荐这样的方法吗？或者您更愿意推荐黑色或白色,即关系或非关系方法？所有评论都非常欢迎!

---

PS:任何想法,如果这样的混合适用于Spring和Hibernate/JPA？

Answer 1

Rob Conery最近写了一篇关于他使用MongoDB和MySQL 构建他的流行Web应用程序TekPub的经验,强调了两者的优势:

高读取的东西(帐户信息,制作和剧集信息)非常适合像MongoDb这样的"现在"类型的东西."昨天发生了什么"的东西对于关系系统来说是完美的.

在高层次上,Rob将其应用程序数据分为两个范围:运行时数据和历史数据.例如,用户购物车的当前状态非常适合保留在MongoDB中.这是一个不断变异的对象blob.保存进出购物车的历史记录; 发生的时候; 结帐状态非常适合MySQL中的关系表格数据.

他总结道:

它完美地运作.我能不能跟我们建立快乐.这是非常低的维护,我们可以像任何其他解决方案一样备份它,并且我们在需要时拥有所需的数据.

2016年5月更新(6年后)

这在过去的6年中变得更加真实.现在常见的是,NoSQL数据库为事务存储和传统关系数据库提供动力,支持分析数据库.