混合数据库系统：用于数据的NoSQL，用于关系的SQL。最佳实践？

我正在构建一个应用程序，其数据库系统将至关重要，并且需要可扩展，因为其所有值都将存储在数据中。混合数据库系统：用于数据的NoSQL，用于关系的SQL。最佳实践？

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

我熟悉SQL和MongoDB，所以它几乎没有决策的因素（虽然我倾向于喜欢MongoDB的结构和JS更加这些时间:)）

但是从一切我读过在网络上，我的决定仍然感到不舒服。

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

具有对象（用户，项目，评论等）
具有关系SQL表（表用户资料NOSQL文档，用户评论等）
复制一个文件NOSQL了投票结果每当有一个投票或以规则的间隔（以获得速度也表决结果的显示器上）

大ADVA我看到的是：

查询文档时（例如，用户显示他的个人资料），我把所有的NoSQL的好处（速度，都在一个地方，模式灵活性等）
在做统计数据（如数量的选票），我把所有的SQL好处
并行化：我可以获取在SQL投票和
快速阅读在异步模式下的文件，写slowish（它不会在我的情况不要紧）
关系的完整性总是保留

我的问题是：

这是否是一个很好的做法？网络似乎很害羞
我是否优化花生，即使是高DB负载？（比较文件获取到完整的SQL和像SELECT * FROM表，其中primary_key = XXX查询）

来源

2013-04-24 Augustin Riedinger

好问题。我一直在使用各种NoSQL技术玩一点同样的想法。一旦我有一点时间真正写出答案，可能会稍后回答。 – 2013-04-24 13:11:11

如果我正确理解这个，你想使用MongoDB就像某种缓存？从你所描述的，我不认为这是一个坏主意，你只需要确保MongoDB在应用层与你的RDBMS保持一致（基本上提高了代码的复杂性） – LMeyer 2013-04-24 16:10:02

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

来源

2013-04-25 10:43:08

缓存复杂的查询，我可能会使用memcached，我也可以有一个临时表，存储我的计算结果。就我而言，我也有兴趣使用Documents来描述我的数据类（例如用户），以保持数据的灵活性，速度和格式化。 – 2013-04-25 12:55:11

我想抛出另一个建议，建模可以扩展的对象和关系。

有些耐人寻味：

正如你所说，模型中的实体/在文档数据库MongoDB的类似物体。
将关系存储在像Titan或Neo4j这样的图形数据库中。在我看来，这些系统更适合存储复杂的关系。您可以轻松遍历许多复杂关系，然后在图中找到目标节点/顶点时，可以从Mongo加载文档。
考虑一下像Riak，它是一个NoSQL文档存储，也有文档（关系）之间的链接。他们建议不要使关系过于复杂，但可以将文档链接在一起而不需要另一个系统。

来源

2013-05-06 14:53:22 ryan1234

“最佳实践”是一个可怕的术语 - 它经常被用来证明直肠的本能，“这是我们一直这样做”或其他偏见。

但是，您所描述的解决方案具有一系列优点（您提到了一些优点），但也存在一些重大缺陷，主要是因为您将问题域的知识分解为两个不兼容的数据存储区，重复的机会 - 但也是不一致的。

例如，一个给定用户由某个标识符标识的知识将在您的NoSQL系统和您的数据库之间共享。如果一个系统删除该用户，则另一个系统处于不一致的状态。一个给定用户的配置文件将被分成两个系统，并且都不会有完整的图片;你需要大量的家务同步代码。

在您的平台上工作的开发人员需要两种技术堆栈的专业知识 - 想象一下，试图调试为什么给定用户的评论数量似乎不正确。

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

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

我不认为利大于弊。

来源

2014-03-18 17:16:25

混合数据库系统：用于数据的NoSQL，用于关系的SQL。最佳实践？

回答

相关问题