混合数据库系统:NoSQL用于数据,SQL用于关系.最佳实践？

Question

我正在构建一个应用程序,其数据库系统将是至关重要的,并且需要可扩展,因为它的所有价值都在数据中.

我正在制作一个实时投票系统.

我对SQL和MongoDB很满意,所以它几乎不是决定因素(虽然我更倾向于喜欢MongoDB结构和JS这些时间:))

但是从我在网上看到的所有内容来看,我仍然对我的决定感到不安.

我想要做的是结合两者的优势:

• 拥有对象的noSQL文档(用户,项目,评论等)
• 拥有关系的SQL表(表User-Items,User-Comments等)
• 每当有投票或定期间隔时,复制投票都会产生一个noSQL文档(为了在投票结果显示时获得速度)

我看到的巨大优势是:

1. 在查询文档(例如,用户显示他的个人资料)时,我拥有NoSQL的所有好处(速度,所有在一个地方,架构灵活性等)
2. 在进行统计(例如投票数)时,我拥有所有SQL优势
3. 并行化:我可以在SQL和ASync模式下获取文件
4. 读得快,写得慢(在我的情况下并不重要)
5. 始终保持关系完整性

我的问题是:

• 这样做是一种好习惯吗？网络似乎很害羞
• 我是否优化了花生,即使是高DB负荷？(将文档提取与完整SQL进行比较,以及查询,例如select*from table,其中primary_key = XXX)

Answer 1

如果您喜欢将 NoSQL 数据库与 RDBMS 一起使用的唯一原因是为了获得速度和灵活性，我建议您改用缓存服务器（例如 Memcache）。您可以使用 sql 语句构建文档/结果，并使用 memcache 中的单个键值将其存储以供以后检索。它比说 MongoDB 更容易实现。但是，这当然取决于您的要求，如果您真的只打算使用密钥进行文档查找或计划对您的文档使用更复杂的查询。

Answer 2

“最佳实践”是一个可怕的术语——它经常被用来证明直觉、“这就是我们一直这样做的方式”或其他偏见。

但是，您描述的解决方案有很多好处（您提到了一些），但也有一些明显的缺点，主要是因为您将问题领域的知识分散到两个不兼容的数据存储中，这为重复提供了很多机会 -但也因为不一致。

例如，给定用户由特定标识符标识的知识将在您的 NoSQL 系统和您的数据库之间共享。如果一个系统删除了那个用户，另一个系统就会处于不一致的状态。给定用户的个人资料将被拆分到两个系统中，并且都没有完整的图片；你需要大量的内务同步代码。

在您的平台上工作的开发人员需要在这两个技术堆栈方面的专业知识 - 想象一下尝试调试给定用户的评论计数似乎不正确的原因。

您现在有两个故障点 - 如果 NoSQL 或 SQL 数据库出现故障，您的整个系统就会崩溃。失败可能并不意味着崩溃——它还可能意味着性能问题、升级问题或备份问题。

软件解决方案拥有多个系统，每个系统都拥有一部分数据的情况并不少见，拆分通常沿着业务领域线（CRM 系统了解您的个人资料，支付系统了解您的信用卡详细信息，电子商务系统了解您订购的商品） ; 沿着技术路线拆分部门将创建一个具有多个故障点的复杂架构。

我认为好处不会超过这些缺点。