SingleStore（前身 MemSQL）是一个为数据密集型应用设计的云原生数据库。它是一个分布式的关系型 SQL 数据库管理系统（RDBMS），具有 ANSI SQL 支持，它以数据摄入、交易处理和查询处理的速度而闻名。SingleStore 主要存储关系型数据，但也可以存储 JSON 数据、图形数据和时间序列数据。它支持混合工作负载，也就是我们常说的 HTAP ，以及更传统的 OLTP 和 OLAP 用例。对于查询，它将结构化查询语言（SQL）编译成机器代码。SingleStore 数据库引擎可以在各种 Linux 环境中运行，包括企业内部安装（on-premises）、公共和私有云供应商、通过 Kubernetes 运营商在容器中运行，或者使用 SingleStore 自有的托管云服务。

今天我们主要来聊一聊数据库独角兽公司 SingleStore 对 HTAP 的认知。

SingleStore，HTAP 界的融资宠儿

说起 SingleStore，一些同学可能不太了解，但是提到 MemSQL，相信研究过HTAP 数据库发展脉络的同学就很熟悉了，也可以回顾一下这篇文章《深度干货！一篇Paper带您读懂HTAP》，我们在第一节中介绍了 HTAP 数据库的发展历史，其中 MemSQL 就是最早的一波提出行列混存+内存计算的数据库，也是在 2014 年要发力 HTAP 的，恰巧和 Gartner 正式提出 HTAP 概念是同一年。不过后来在 2020 年 10 月，MemSQL 正式宣布改名为 SingleStore 了。

关于改名的原因，官方是说是为了更好地描述组织的广泛价值主张。官方表示，尽管 MemSQL 在数据架构师和性能工程师中广为人知，但该公司的旗舰数据管理产品已扩展到包括开发人员功能，所以 MemSQL 已不能再反映他们当前功能和产品愿景的广度和深度。

其进行品牌重塑的目的在于，向外界反映 MemSQL 不仅仅是一个内存数据库，而是一个可以实现企业所有数据的平台。SingleStore 将为交易和分析提供一个数据平台，能够处理结构化、非结构化和半结构化数据。

SingleStore 首席产品官 Jordan Jigani 还透露了团队的新愿景，即计划提供对位于 SingleStore 以外任何地方的数据的访问权限。这项新功能将为跨多云环境的数据提供一个全局命名空间，使 SingleStore 可以提供一个 API，无论数据位于何处，都可以通过该 API 对数据进行操作。用户可以从拥有 SingleStore 计算群集的任何位置访问 SingleStore 数据库，同时遵守访问权限和主权限制。

不得不说，SingleStore 对市场的敏锐度还是很高的，像 HTAP、云原生、分布式、一体化、平台化、实时分析处理、数据库 API 化、DBaas 这些，人家玩得很溜，把这些伟大的愿景抛出去又加上技术确实不错，自然很受资本市场的欢迎，从其融资历史就可以窥知一二：

截止目前，SingleStore 的总融资额达到 4.12 亿美元，估值超过了 13 亿美金，当然，可能一些经常看 VC 圈子的小同学觉得这个估值对于数据库企业来说不算特别高，也不是很明白，为啥有这么多投资机构给它投钱，因为在数据库这个赛道上确实太多卷王了。SingleStore 虽然面临着与 Imply、Oracle、Snowflake 和 MongoDB 等企业的竞争，但要知道，SingleStore 现在只有近 400 名员工，却已经拥有大约 300 名客户，估值还高于 10 亿美元，相信明眼人都能看出来，SingleStore 的潜力无限，正如 CMU 的 Andy Pavlo 教授在去年预测的那样，这家公司离 IPO 不远了。

此外，Gartner 预测，到 2022 年，75% 的数据库将迁移到云服务。一项调查显示，每年在大数据和人工智能计划上投资超过 5000 万美元的公司数量在 2019 年上升至 33.9%。

如果没有 HTAP，机器学习和人工智能都是不切实际的

下面是一篇来自 SingleStore 的博客，推荐给大家阅读。

HTAP，即混合交易/分析处理，将交易（如更新数据库）与分析（如寻找可能的销售线索）相结合。HTAP 数据库在一个数据库中支持这两种工作负载，提供速度和简单性。今天，“云原生 HTAP”的概念很流行，用户希望 HTAP 数据库能够与 Kafka、Spark 和其他技术在云中顺利混合和匹配。使用的场景案例包括预防欺诈、电子商务的推荐引擎、智能电网和人工智能等等。

HTAP 数据库在某种程度上是为集成流数据源(如 Kafka )和用于高级分析、人工智能和机器学习(如 Spark)的消息系统而设计的。它们为多个分析客户端提供服务，从输入SQL查询的业务分析师，到BI工具、应用程序和机器学习模型，这些客户端每秒生成数十个或数千个查询。

HTAP之前–OLTP 和 OLAP 分离

HTAP 将不同类型的数据处理组合成一个连贯的整体。这两种处理方式差别很大。事务处理（OLTP）——在数据库中添加和更新记录——对单个记录操作要求非常高的可靠性，以及准确性和速度。“更新Sandy Brown的当前地址”就是事务性更新的一个例子。

另一方面，分析处理意味着非常快速地在一个或多个数据库表中查找单个记录、多个记录或一种类型的记录的总数。“帮我找到所有住在科罗拉多州并拥有自己房子的订户”就是一个分析请求的例子。

第一批有效的数据库是面向事务的，最初广泛应用于20世纪70年代和80年代。它们被称为在线事务处理(OLTP)系统。OLTP系统经过优化，可以在低功率、硬盘较小的计算机上工作——当然，按照今天的标准。唯一的分析是通过打印的报告，这些报告可能根据不同的关键字段进行分类排序，比如按州或邮政编码。

当后来加入分析时，事务系统已经很忙了，所以数据被复制到另一台运行不同软件的计算机上。这些数据库称为在线分析处理(OLAP)数据库。数据仓库和数据集市是专门的 OLAP 数据库，存放用于分析的非操作数据。

使用多种语言对 OLAP 系统上的数据进行查询，这些语言结合了结构化查询语言(SQL)。一开始，分析查询是由个别分析师直接输入的；最后，使用商业智能(BI)程序来简化查询。到最近，软件应用程序已经可以自己生成查询了，通常以每秒数千个的速度生成。

这创建了名为提取、转换和加载(Extract、Transform和Load, ETL)的整个过程和规程，只是为了将数据从 OLTP 移动到 OLAP。作为ETL过程的一部分，数据所有者可以混合使用他们自己的不同数据库、外部购买的数据、社会信号和其他有用的信息。然而，使用三个不同的筒仓意味着OLAP数据库中的数据总是过时的–往往是一天到一周的数据。

向 HTAP 变迁

OLTP/ETL/OLAP结构今天仍然被广泛使用。然而，随着时间的推移，OLAP和OLTP数据库(速度较慢)都获得了以分布式方式工作的能力。也就是说，单个数据表现在可以分布在多台计算机上。

跨多个服务器分布允许数据表变得更大。分布式数据表可以随时提高性能，只需添加更多的服务器来处理更多的事务或回复更多的查询。一个数据库——一个或多个数据表，在重叠的数据上提供相关功能——现在可以在灵活大小的机器阵列上运行，可以在本地运行，也可以在云中运行。

随着这些功能的增加，在单个数据库中混合 OLTP 和 OLAP 功能的令人兴奋的可能性已经实现。使这成为可能的数据库软件在 2014 年被 Gartner 命名为混合事务和分析处理(HTAP)。

这种能力是如此的新，以至于它有许多名称，包括混合操作分析处理(HOAP)和translytical数据库(它结合了trans_actions和ana_lytical函数)。HTAP、HOAP 和 translytical 数据库也被描述为执行操作分析——“使用SLA的分析”，或者必须提供接近实时响应的分析。Gartner 还提出了增强事务处理(ATP)，它描述了 HTAP 工作负载的一个子集，包括操作 AI 和机器学习。

HTAP 的优势

HTAP有很多好处。HTAP创建了一个更简单的体系结构，因为两种不同类型的数据库以及ETL流程都被单个数据库所取代。而且，数据拷贝也被消除了。数据不是先存储在OLTP数据库中(用于事务)，然后再被复制到 OLAP 中(可能是多次复制，用于分析)，而是作为单一来源数据驻留在HTAP数据库中（A single source of truth resides in the HTAP database）。

这些根本性的改变带来了额外的好处：操作要简单得多，因为只有一个系统在运行，而不是几个。确保单个数据库的安全比在不同系统上进行多个数据拷贝要容易。而且数据可以是新鲜的——一旦数据被处理，它也可以用于分析。不再需要等待数小时或数天（有时更长时间），也不要再让数据通过 OLTP 和 ETL 才能进行分析。

HTAP 可以实现非常大的成本效益，同时还可以增加相关的收入和降低成本。架构和操作的简单性大大节省了成本，更高的性能使现有的创收功能更具生产力，并使新的功能实现成为可能。

物联网（IoT）从HTAP中获益匪浅。如果你正在运行一个智能电网，你需要根据最新的数据快速运行。分析师、仪表盘和应用程序都需要一次性访问相同的、最新的数据。

没有 HTAP，机器学习和人工智能实际上是不切实际的。如果不能从当前和历史数据中学习，那么运行机器学习算法就没有多大意义。没有人想运行一个预测性维护程序——假如这个程序告诉你：你公司的油井可能在一周前需要紧急维护，或者昨天有几个有趣的旅行便宜货。我相信你该明白，这丝毫没有意义。

OK，今天的分享就到这里，欢迎大家关注 StoneDB。

StoneDB 2.0 云原生分布式实时 HTAP 架构详细设计以 RFC 形式持续进行，欢迎大家关注我们最新进展，更欢迎给我们开源协作的模式和方法提出改进意见，一起通过开源的方式共建 StoneDB ~

https://github.com/stoneatom/stonedb/issues/436

• StoneDB 代码已完全在 Github 开源：

https://github.com/stoneatom/stonedb

• StoneDB 官网：

https://stonedb.io/