Kubernetes中文社区
使用NoSQL数据库有众多好处，但也经常面临两个挑战：
- 如何转换RDBMS( Relational Database Management System ) Schema到无Schema文档模型。
- 需要学习新的 API/Query 以访问数据。
NoSQL缩写代表“不仅仅 SQL”，但是经常被误解为“不是SQL”。因此，为了使用NoSQL数据库，组织将不仅需要将他们的关系数据模型转换为文档模型，而且还需要进行NoSQL数据库API的培训。
实际上，NoSQL从未放弃过最流行的数据库数据访问。许多NoSQL供应商仍在使用SQL的变体，例如： Cosmos DB， Cassandra CQL， Elasticsearch SQL， Cockroach Labs。即使使用 MongoDB查询 语言，您仍会发现它基于select-join-project构造，这是SQL中使用的关系代数的基础。
NoSQL领域中的一个数据库公司 Couchbase 及其 N1QL 查询语言，就为NoSQL数据库带来SQL般的查询体验。虽然Couchbase以JSON格式存储数据，但它支持的数据模型可以是关系结构或分层结构，由于其schema灵活性和可扩展性，经常在基于文档的模型中使用。因为Couchbase提供了类似SQL的查询语言-N1QL，它扩展了SQL语言以允许用户操纵文档模型的层次结构。所有这些都是基于具有 key-value APIs 的Couchbase高性能数据服务构建的 。
在当今的NoSQL数据库市场中有很多选择，组织在享受NoSQL带来的优势时，同时也带来许多挑战。
- 对结构化和非结构化数据的支持
- 商业硬件的水平可扩展性
- 易于管理 schema 演变
- 数据库供应商的选择
为了帮助组织做出决定，Altoros（一家致力于帮助公司从旧版IT系统过渡到未来的公司）发布了查询比较报告，以比较当今最受欢迎的数据库中的查询语言。它选择MySQL / SQL，Couchbase N1QL和MongoDB query语言对比。使用以下条件对每种查询语言的实现进行了评估，以满足不同的查询情景。
- Simplicity （简洁性）
- Readability （可读性）
- Expressiveness（表现力）
- Flexibility（灵活性）
- Skills availability（技能专长）
- Line of codes（代码行数）
- The number of application to server trips（应用程序请求服务器的次数）
可以在此 GitHub找到数据库对比的示例，这些示例可以帮助部署和运行此报告中的所有情景。
对比方法
该报告的目的是从传统RDBMS应用程序的角度比较查询语言。为此，它选择了：
活动管理应用程序模型，通常在管理销售，服务和营销活动的大多数CRM系统应用。报告包括用于MySQL的关系模型和用于Couchbase和MongoDB的文档数据库模型。
它还使用了这些系统的大多数用户可以识别的一组查询情景。
| 情境（Scenario） | 描述 |
|---|---|
| 1.客户会议报告 | 为了准备下周要参加的客户会议，我想获得所有参加会议的客户及其联系人的列表。 |
| 2.区域销售地区报告 | 我是C-Suite卖方区域的区域销售经理。我想获取分配给该地区的所有帐户以及团队成员的账号。 |
| 3.客户十大行业 | 根据2018年销售活动，从客户中确定十大行业。 |
| 4.销售组织 | 我想弄清楚19财年第三季度，花了多少时间与团队成员进行交谈。 |
| 5.销售活动报告 | 在2018年的一个月内，与销售相关的任务数量变化趋势。 |
| 6.销售团队技能 | 当前销售组织中的销售团队技能/角色分析 |
| 7.客户互动报告 | 查看我们在19财年第四季度与客户进行的所有演示，并详细说明在每个客户上花费的时间以及会议的有效性。 |
| 8.分析消费者关于酒店的评论 | 调用Google自然语言API对所有评论进行排序 |
| 9.通过文本搜索识别客户会议 | 确定讨论了特定主题的客户帐户及其相关联系人。搜索条件可以部分或全部包括以下信息：会议标题，会议日期范围，客户联系详细信息，销售团队成员详细信息（参与者）和客户名称。 |
对于每种情况，报告均提供以SQL，N1QL和MongoDB查询语言编写的相应解决情景，然后提供每种解决情景的评估。
对比结果
该报告以MySQL-SQL为参考，根据许多标准评估了Couchbase N1QL和MongoDB查询语言。
备注：
- N1QL与SQL非常相似，并且始终给它比MongoDB查询语言更高的评分。
- 情景3的示例代码显示，对于简单查询，这三种查询语言相对相似，并且具有相似的评分。差异出现在JOIN和Aggregations查询场景中。
代码行数
该图表显示了每个查询的代码行数。尽管此度量标准可能并不准确，因为所有查询语言都有自己推荐的格式，但它至少说明了基本差异。
- N1QL查询语言的代码行数与SQL大致相同。
- MongoDB查询语言始终具有更多的代码行。
- 对于场景7，必须为MongoDB查询语言编写347行，而N1QL为21行。这个差异，反映了MongoDB查询在复杂聚合和通用表达式（CTE）方面的局限性，在过去的几十年中，SQL（现在是N1QL）一直是关系数据库技术的主要优势。
请注意，这是Altoros团队提供的MongoDB查询解决方式。与任何实现一样，可能还有其他方式编写Mongo代码。
客户端向服务器的请求数
该图显示了应用程序必须提交给数据库服务器的次数。
备注：
- 在大多数情况下，SQL/N1QL只需要向服务器提交一个查询，而MongoDB需要查询多个部分，因此需要多次访问后端服务器。这是由于SQL/N1QL的表现力所致，其中应用程序开发人员只需要声明所需的输出，由服务器来处理并返回结果。
- 由于缺乏复杂聚合的支持，MongoDB就需要通过多个阶段执行其计算。这类似于标准的SQL子查询方法。此处的区别在于，子查询结果集需要在客户端应用程序中维护，然后再传递给另一个查询。
总结
如图所示，归纳如下：
- SQL/N1QL 是 declarative的，可以自动优化查询结果；Mongo是Procedural的，需要用户自己显示设置。
- SQL/N1QL 是标准SQL，并且可以处理JSON文档；Mongo查询是特有的。
- SQL/N1QL 仅需要请求一次服务器，性能卓越；Mongo查询需要请求多次服务器，耗费更多资源。
- 与SQL/N1QL相比， Mongo查询面对聚合和JOIN查询就会变得复杂。
参考：
- Altoros查询比较报告— https://resources.couchbase.com/c/altoros-database-query-report
- Couchbase N1QL教程— https://query-tutorial.couchbase.com/tutorial
- 索引顾问作为N1QL的服务— https://index-advisor.couchbase.com/indexadvisor
译文链接： https://dzone.com/articles/sql-to-nosql-how-would-you-choose
登录后评论
立即登录 注册