在本文中，我们检查了比较SQL和NoSQL的七个指标。想要利用NoSQL数据库的众多优势的组织通常会发现他们面临两个挑战：如何转换他们的RDBMS模式以利用无模式文档模型。了解用于访问数据的新API/查询。有些人还发现它与NoSQL名称混淆。首字母缩略词不仅代表“SQL”，还可能被误解为“notoSQL”，因此，为了使用NoSQL数据库，组织不仅需要将其关系数据模型转换为文档模型，还需要获取信息关于NoSQL数据库API培训。事实上，NoSQL数据库行业从未放弃最流行的数据库数据访问。许多NoSQL供应商仍在使用SQL的变体。CosmosDB、CassandraCQL、ElasticsearchSQL、CockroachLabs。即使使用MongoDB查询语言，您仍然会发现它基于select-join-project结构，这是SQL中使用的关系代数的基础。这个NoSQL空间中的一家数据库公司（已经完全解决了这个问题）是Couchbase及其N1QL查询语言。尽管Couchbase以其原生JSON格式存储数据，但它支持的数据模型可以是关系型或分层型，并且由于其模式灵活性和可扩展性，通常用于基于文档的模型。这是可能的，因为Couchbase提供了一种类似SQL的查询语言——N1QL，它扩展了SQL语言以允许用户操作文档模型的层次结构。所有这些都建立在具有键值API的Couchbase高性能数据服务之上。然而，在当今的NoSQL数据库市场上，有许多选择，对于希望确保其数据库技术投资能够利用NoSQL技术当前提供的所有优势的组织而言，结果可能会带来许多挑战。支持结构化和非结构化数据在商品硬件上的水平可伸缩性易于管理模式演变也许最重要的是，除了在过去几十年主导数据库市场的当前RDBMS供应商之外，还有供应商的选择。为了帮助客户做出决定，Altoros（一家致力于帮助企业从遗留IT系统过渡到未来的公司）发布了一份查询比较报告，比较了当今最流行的数据库中的查询语言。它选择专注于MySQL/SQL、CouchbaseN1QL和MongoDB查询语言。使用以下标准评估每种查询语言的实现以满足不同的查询场景。简单性可读性表现力灵活性技能代码行应用程序到服务器的行程所有查询和数据库转储的示例都可以在此GitHub存储库中找到，以帮助部署和运行本报告中的所有场景。AltorosReportMethodology本报告的目的是从传统RDBMS应用程序的角度比较查询语言。为此，它选择了：活动管理应用程序模型，通常在大多数管理销售、服务和营销活动的CRM系统中都能找到。报告设置包括MySQL的关系模型和Couchbase和MongoDB的文档数据库模型。它还使用这些系统的大多数用户都能识别的一组查询方案。对于每个案例，报告都提供了用SQL、N1QL和MongoDB查询语言编写的相应解决方案，然后对每个解决方案进行了评估。评估标准结果下表总结了所有查询场景的所有等级。请参阅报告以了解对每个查询场景的单独评估。该报告以MySQL-SQL为参考，根据多项标准评估了CouchbaseN1QL和MongoDB查询语言。备注：曾与MongoDB、Cassandra和RedisLab合作过的Altoros发现N1QL与SQL非常相似，并且始终给予它比MongoDB查询语言更好的评级。场景三的示例代码表明，对于简单的查询，三种查询语言比较相似，评价标准得分也相近。然而，差异出现在查询场景中，其中文档JOIN和Aggregations图表显示了每个查询的代码行数。尽管由于所有查询语言都有自己的推荐格式，这个指标可能会被错误表述，但它可以提供一个关于复杂性的简单指南。N1QL查询语言的代码行数与SQL大致相同。MongoDB查询语言总是有更多的代码行。对于场景7，Altoros团队必须为MongoDB查询语言编写347行，而为N1QL编写21行。这个异常值反映了MongoDB查询语言在计算复杂聚合和公用表表达式(CTE)方面的局限性，SQL（现在的N1QL）在过去几十年一直是关系数据库技术的主要力量。请注意，这是Altoros团队提供的MongoDB查询解决方案。与任何实现一样，可能还有其他编写Mongo代码的方法，但这是团队想出的方法。客户端服务器行程计数此图显示应用程序必须提交给数据库服务器的行程数。注意：在大多数情况下，SQL/N1QL只需要向服务器提交单个查询，而MongoDB查询可能会导致多个部分，因此需要多次命中后端服务器。这是由于SQL/N1QL的表达能力，应用程序开发人员只需声明所需的输出，并由服务器处理并返回结果。缺乏对复杂聚合的支持需要MongoDB在多个阶段执行其计算。这类似于标准的SQL子查询方法。这里的区别在于，子查询结果集在传递给另一个查询之前需要在客户端应用程序中进行维护。Altoros查询比较报告-主要发现
