实时分析需要SQL和复杂查询_Sql Server

今天的数据驱动型企业不仅需要针对实时数据作出快速响应要，而且还必须执行复杂的查询以解决复杂的业务问题。

实时分析需要SQL和复杂查询

例如，客户个性化系统需要将历史数据集与实时数据流结合起来，以便立即向客户提供最相关的产品建议。提供关键任务的实时业务观察能力的运营分析系统也必须如此，例如，在线支付供应商需要监测其全球范围内的交易，以发现可能预示金融欺诈的异常情况。

或者想象一个网上学习平台需要为学区客户和内部客户团队提供关于学生和教师使用情况的最新洞察力。或者是一个市场新闻供应商，需要监测并确保其金融客户在狭窄的窗口内获得准确的、相关的更新，以实现盈利的交易。

NoSQL的局限性

SQL支持复杂的查询，因为它是一种非常具有表现力的。是成熟的语言。复杂的SQL查询在商业智能（BI）中早已司空见惯。而当Hadoop和Hive这样的系统出现时，它首次将复杂的查询与大数据结合起来。Hive在Hadoop的本地MapReduce编程范式上实现了一个SQL层。这些第一代基于SQL的大数据系统的代价是，它们以更高的查询延迟为代价，提高了数据处理的吞吐量。因此，这些使用案例仍然是运行在批处理模式中。

当NoSQL数据库（如键值和文档存储）出现时，情况发生了变化。设计目标是低延迟和规模。现在，公司可以把一个庞大的数据集，组织成简单的键值或文档对，并立即执行查找和其他简单的查询。这些大规模、可扩展的键值存储或文档数据库的设计者决定，只有当查询性质简单时，规模和速度才有可能。在键值存储中查找一个值，可以做到快如闪电。相比之下，SQL查询，由于过滤器、排序和聚合的固有复杂性，在技术上太有挑战性，无法在大量数据上快速执行。

不要注意那个幕后的人

不幸的是，由于上述原因，当查询复杂、嵌套且必须返回精确答案时，NoSQL数据库往往会遇到问题。这故意不是他们的强项。他们的查询语言，无论是类似SQL的变体，如 CQL (Cassandra)和Druid SQL等类似SQL的变体，还是MQL（MongoDB）等完全自定义的语言，都不支持连接和其他复杂的查询命令。

NoSQL数据库的供应商就像绿野仙踪一样，用烟雾和镜子分散你的注意力，高谈阔论狭义的速度定义，这样你就不会注意到NoSQL数据库在实时分析方面的实际弱点。使用NoSQL数据库的开发人员最终被迫将Join和其他数据逻辑嵌入到他们自己的应用程序代码中--从单独的表中获取数据到进行连接优化和其他分析工作的一切。

虽然走NoSQL的道路是可能的，但它是繁琐和缓慢的。以一个申请抵押贷款的人为例。为了分析他们的信用度，你会创建一个数据应用来计算数据，比如这个人的信用历史、未偿贷款和还款历史。要做到这一点，你需要结合几个数据表格，其中一些可能是归一化的，哪些数据是真实的，哪些是不真实的。你还可能分析当前和历史上的抵押贷款利率，以确定提供什么利率。

使用SQL，你可以简单地将信用记录和贷款支付表连接在一起，并聚合大规模的历史数据集，如每日抵押贷款利率。然而，使用像Python或Java这样的东西来手动重新创建连接和聚合，与SQL相比，你的应用程序中的代码行数会增加几十甚至一百。

更多的应用程序代码不仅需要更多的时间来创建，而且几乎总是导致更慢的查询。如果不能使用基于SQL的查询优化器，加速查询是很困难和费时的，因为应用程序中的业务逻辑和应用程序使用的基于查询的数据访问路径之间没有分界。像一个普通的东西 join table一样的东西，SQL可以有效而优雅地处理，但在其他语言中却可能成为一个臃肿的内存占用者。

最后，用应用程序代码编写的查询也是比较脆弱的，需要不断的维护和测试，如果数据量发生变化，还可能需要重写。而大多数开发人员缺乏时间和专业知识来进行这种持续的维护。

只有一个NoSQL系统我认为可以合理地胜任复杂的查询。GraphQL。GraphQL系统可以将数据类型与特定的数据字段联系起来，并提供函数来检索文档的选定字段。它的查询API支持复杂的操作，例如根据一组匹配字段过滤文档，并有选择地从匹配的文档中返回字段的子集。GraphQL的主要分析缺陷是它缺乏表达能力，无法根据两个不同的数据集中特定字段的值来连接这两个数据集。大多数分析性查询需要这种能力，以便在查询时连接多个数据源。