将 NoSQL 数据库用于关系目的
非关系数据库日益引起越来越多的关注。主要的限制是当今复杂的数据确实是相互关联的。连接数据库是不是就像我们在RDBMS中连接表一样方便呢？当然，我只是指简单的情况。想象一下三个表，分别是文章、标签和关系。在像Mysql这样的RDBMS中，我们可以运行三个查询，而
1. Find ID of a given tag
2. Find Articles connected with the captured Tag ID
3. Fetch the contents of Articles tagged with the term
不是三个查询，我们通过JOIN执行单个查询。我认为像 BerkeleyDB 这样的键/值数据库中的三个查询比 Mysql 中的 JOIN 查询更快。
这个想法实用吗？还是涉及到其他问题而忽略这种方法？
Non-relational databases are attracting more attention day by day. The main limitation is that today's complicated data are indeed connected. Isn't it convenient to connect databases as we connect tables in RDBMS? Of course, I just mean simple cases. Imagine three tables of Articles, Tags, Relationships. In a RDBMS like Mysql, we can run three queries to
1. Find ID of a given tag
2. Find Articles connected with the captured Tag ID
3. Fetch the contents of Articles tagged with the term
Instead of three queries, we perform a single query by JOIN. I think three queries in a key/value database like BerkeleyDB is faster than a JOIN query in Mysql.
Is this idea practical? Or other issues are involved to ignore this approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
NoSQL 数据库可以很好地支持关系数据模型。您只需在应用程序中自己实现关系映射即可，而且这项工作通常并非微不足道。
在某些应用中，这种额外的努力是值得的。也许您只有少量的表，并且您需要的联接非常简单。或者，您可能已经在传统关系 DBMS 和 NoSQL 替代方案之间进行了一些性能评估，并发现 NoSQL 选项出于多种原因（性能、可扩展性、灵活性等）更适合您的需求。
但是，您应该记住一件事。典型的 SQL DBMS 基本上是一个 NoSQL DB，前面有一个优化的、构建良好的关系引擎。有些数据库甚至可以让您绕过关系层并处理他们的系统就像一个纯粹的 NoSQL DB。
因此，当您开始 构建自己的在 NoSQL DB 之上的关系映射和连接，您应该问自己，“不是有人已经为我构建了这个吗？”答案很可能是“是”，解决方案可能是使用传统的 SQL DBMS。
具体回答你的问题的“3查询”部分，答案是“也许”。您当然可以使这样的查询在 NoSQL DB 中比在 RDBMS 中运行得更快，但您需要记住，这里需要考虑的不仅仅是查询的原始速度：
您可能会查看该列表并对自己说，“没什么大不了的” ，我正在运行一个简单的应用程序，只有几千个数据库条目，我将自己维护它”。如果是这样，那就让自己崩溃吧——伯克利（和其他 NoSQL 选项）会很好。我曾多次使用伯克利来处理此类应用程序。但是，如果您正在为一个规模相当大的 SaaS 产品构建后端，并且该产品可能很快就会拥有数百万用户和非常复杂的查询，那么您可能会有不同的答案。
不幸的是，我们无法给出一刀切的答案。您必须根据应用程序和组织的需求自行做出判断。
NoSQL databases can support relational data models just fine. You're just left to implement the relational mapping yourself in your application, and that effort is typically not insignificant.
In some applications this extra effort will be worthwhile. Perhaps you only have a small number of tables and the joins you need are very simple. Or perhaps you've done some performance evaluation between a traditional relational DBMS and a NoSQL alternative and found that the NoSQL option is more appropriate for your needs for any number of reasons (performance, scalability, flexibility, whatever).
You should keep one thing in mind, however. A typical SQL DBMS is basically a NoSQL DB with an optimized, well-built relational engine in front of it. Some databases even let you bypass the relational layer and treat their system like a pure NoSQL DB.
Therefore, the moment you start to build your own relational mappings and joins on top of a NoSQL DB you should ask yourself, "Didn't someone build this for me already?" The answer may well be "yes", and the solution might be to go with a traditional SQL DBMS.
To answer the "3 query" part of your question specifically, the answer is "maybe". You certainly might be able to make such a query run faster in a NoSQL DB than in an RDBMS, but you need to keep in mind that there are more things to consider here than just the raw speed of your query:
You might review that list and say to yourself, "No big deal, I'm running a simple app with only a few thousand DB entries and I'll maintain it myself". If so, knock yourself out - Berkeley (and other NoSQL options) would work fine. I've used Berkeley many times for those kinds of applications. But you may have a different answer if you are building the back-end for a significantly-sized SaaS product which might soon have millions of users and very complex queries.
We can't give a one-size-fits-all answer, unfortunately. You'll have to make the judgement call yourself based on the needs of you application and organization.
当然，在任一解决方案中，单个记录联接都相当快，但这并不是联接的最大优势。当您将许多行与许多其他行连接时，连接非常有用。想象一下，在您的示例中，您想对 100 个不同的标签执行此操作。如果没有联接，您将需要对 SQL 的查询执行 300 个查询。
Sure, a single record join is pretty speedy in either solution, but that's not the big advantage of joins. Joins are useful when you're joining many, many rows with many, many other rows. Imagine if, in your example, you wanted to do that for 100 different tags. Without joins, you're talking 300 queries to SQL's one.
noSql 系统上的另一个解决方案是 playOrm。它确实进行连接，但仅在分区中进行连接，因此表可以是无限大小，但分区必须与 RDBMS 表的大小相同。它也通过所有相关注释为您完成所有花哨的休眠功能，尽管它有一些差异，并且将添加嵌入式以供您非规范化时使用。它让事情变得更加容易。通常，处理 nosql 是一种痛苦，因为您必须执行所有转换逻辑，以及所有手动索引、更新和从索引中删除....playOrm 会为您完成所有这些工作。
Another solution on noSql systems is playOrm. It does Joins BUT only in partitions so the table can be infinite size, but the partitions have to be on par with the size of RDBMS tables. It does all the fancy hibernate stuff as well for you with all the related annotations though it has some differences and will be adding Embedded for use when you denormalize. It makes things much easier. Typically dealing with nosql is kind of a pain in all the translation logic you have to do and all the manual indexing and updates and removes from the index....playOrm does all this for you instead.