追寻终极数据库 - 事务/分析混合处理系统的交付挑战 （1）

追寻终极数据库

---

摇晃的数据库钟摆

IT行业的技术决策就像一只来回摇晃的钟摆。
大约十年前，新型网络公司开始收集比以往任什么时候候都更多的数据，他们迫切须要将数据库系统的扩展性能和处理性能提高到一个新的水平，当时已经出现了能在大规模并行处理(MPP)构架上扩展的关系型数据库管理系统(RDBMS)，例如：

• 适用于联机事务处理（OLTP）或运营工做负载的NonStop SQL/MX。
• 适用于商业智能（BI）/企业数据仓库（EDW）工做负载的Teradata和HP Neoview。
• 适用于分析工做负载的Vertica、Aster Data、Netezza、Greenplum和其余架构。

然而，这些专有数据库存在一些劣势：

• 不管是软件和专门硬件，均价格不菲。
• 没法保证Schema的灵活性，而灵活性对于面临动态变化的成长型公司而言十分重要。
• 没法弹性扩展，所以难以知足容量大和速度快的大数据要求。
• 没法很好地处理半结构化和非结构化数据（是的，您能够将这些数据插入XML、BLOB或CLOB列，但若是不使用复杂语法，您很难轻松处理数据。采用附加功能与供应商绑定，灵活性最小）。
• 用户自定义函数（UDF）仅支持标量函数，所以，用户代码受到限制而没法并发执行，后来Map/Reduce较好地解决了这个问题。
• 须要花费很长时间解决可靠性问题，在某些状况下，平均无端障时间（MTBF）很是长，另外，在亚马逊网络服务（AWS）的大量高端服务器上运行Hadoop更廉价且可靠性更强。到2008年，这一成本差别变得很大。

最重要的是，网络公司的需求十分简单，因此这些数据库系统就显得过于复杂，管理和部署都至关不易。这些公司在使用大数据时，事务支持、链接、预约义列和数据类型的元数据支持、优化访问路径以及RDBMS提供的许多其余功能不是必须的。大部分数据量本质上是过渡性质的，可能有至多几回访问，传统EDW方法存储数据的成本更高。所以，这些公司开始转向NoSQL数据库，以克服RDBMS的局限性，避免专有系统的高价格。

因为人们想经过最佳工具完成任务，所以，在多语言编程和持久性方面也摇摆不定。Hadoop 和NoSQL解决方案发展迅猛。为了操做简单并保持性能，NoSQL解决方案支持避免事务和链接的数据模型，而是采用JSON格式存储相关的数据结构。因为物联网（IOT）和机器产生日志数据等因素，数据的增加量和速度已急剧增长。NoSQL技术以很是高的处理速率容纳数据流。

NoSQL和Hadoop技术的普及使更多应用程序开始转移到这些环境，应用方式也日益多样化。随着网络规模初创公司的成熟，它们的运营工做负载需求加强，传统RDBMS功能变得更加剧要。此外，虽然大型企业未面临与互联网初创公司相同的挑战，但他们也想利用该新技术的优点（但更想使用SQL）。如下是使用SQL的缘由：

• SQL使开发更容易，由于它在企业中被广泛使用。
• 现存的工具和应用生态系统使用SQL语言。
• 在某些状况下，事务支持颇有用（尽管存在开销）。
• 常常须要进行链接，SQL引擎能更有效地实现。
• SQL能完成开发人员必须在应用程序或MapReduce工做中编写的代码。
• 在许多状况下，预约义列的严格性存在优势，数据类型和检查强制性能维护数据质量。
• 它促进统一元数据管理和跨应用程序强制执行。

因而，咱们开始看到SQL、RDBMS和 NoSQL功能从新流行，在两方面提供最好的方案。Not Only SQL（而不是No SQL）和 NewSQL 开始流行。出现了大量的SQL-on-Hadoop新系统，主要用于BI和分析。这方面Hive、Stinger/Tez和Impala是领头羊，还有一些其余的开源和专有解决方案。NoSQL数据库也开始提供相似SQL的功能。在NoSQL或HDFS结构上运行的新型SQL引擎从新具有RDBMS功能，同时还提供了灵活的开发环境，包括图形数据库功能、文档存储、文本搜索、列存储、键值存储和宽列存储。随着2014年Spark 的出现，各大公司开始放弃采用Hadoop，而部署不一样的应用程序开发范型，这些范型混合了编程模型、算法和函数库、流媒体和SQL，在内存中对只读数据进行快速计算。

钟摆又正在摆回原位，多语言趋势正逐渐失去魅力。有不可胜数的语言、接口、API和数据结构待处理，人们花费太多时间整合不一样技术，这须要大量培训和技能来开发和管理这种复杂环境。对同一数据运行运营、报告和分析工做负载会使海量数据从一个结构移动到另外一个结构，这将致使数据的重复和延迟，并提升操做难度。经过多种接口访问数据的工具不多，另外，也没有单一技术能知足全部用例的需求。

在不移动、不改变、不复制或不延迟（处理）数据的状况下，对同一数据进行事务/操做、BI和分析工做负载的需求正在逐渐增长。

各大公司正在寻找一个能知足不一样需求的查询引擎——终极数据库。451 Research中使用“融合”或“融合数据平台”一词，“多模式“或“统一”也可表示这个概念。而IT研究和咨询公司Gartner使用的“混合事务/分析处理“（HTAP）一词，应该是最确切的。

但可否寻找到终极数据库？本报告讨论在研究HTAP系统时所遇到的挑战，例如：

• 同时处理运营和分析工做负载
• 支持多个存储引擎，每一个知足不一样的需求
• 为了提升运营和分析工做负载的性能，使用相同的数据模型
• 提供知足企业运营能力的数据库引擎，用于支持运营和分析应用程序

在咱们讨论这些问题前，让咱们首先了解运营和分析工做负载的区别、查询引擎和存储引擎的区别。有了这个背景知识，咱们将会理解为何构建HTAP数据库是项伟大创举。

HTAP 工做负载：运营与分析

尽管人们对运营与分析工做负载的定义不一样，图1-1所示的特征能知足本报告的分析须要。虽然HTAP指的是事务和分析工做负载，但在本报告中，咱们指的是运营工做负载（包括事务工做负载）以及BI和分析工做负载。

图1-1 运营和分析工做负载的不一样类型和特色

OLTP和运营数据存储（ODS）是运营工做负载。它们具备低延迟、超高容量和高并发工做负载的特色，例如，接收和履行订单、安排发货、客户开票、收取付款等。

另外一方面，BI/EDW和分析工做负载是分析工做负载。相对来讲，它们具备高延迟、低容量和低并发工做负载的特色，经过分析操做、历史和外部（大）数据来提升公司绩效，作出战略决策或采起行动来提升产品质量和客户体验等。

从简单、短事务查询到复杂、长时间运行分析，HTAP查询引擎必须可以服务于全部工做负载的服务级目标。

关于做者

Rohit Jain是Esgyn的联合创始人和首席技术官。Esgyn是一家开源数据库公司，致力于构建融合型分布式大数据平台。2015年，惠普将Apache Trafodion（企业级大数据MPP SQL数据库）捐赠给了Apache软件基金会。在Apache Trafodion的基础上，EsygnDB的愿景是创建一个能处理任何数据、任何大小和任何工做负载的融合型分布式大数据平台。在过去的28年中，做为一个资深数据库专家，Rohit在应用程序和数据库开发领域曾为Tandem、Compaq和Hewlett-Packard工做过。他经验丰富，主要涉及在线事务处理、运营数据存储、数据集市、企业数据仓库、BI和大规模分布式并行系统的高级分析。