商业上的驱动力
当前市场上对于数据的处理方式越加的注重多种类型的负载混合进行，即对于用户或者业务端来说，有一个统一的处理逻辑或者架构。如对于广告计算，用户画像，分控，物流，地理信息等商业场景下，原有的处理方式为在海量的历史数据中通过 AP（分析型处理）数据库或者自建的大数据平台，完成对于历史数据的计算，然后将 AP 计算的结果作为 TP（事务型处理）的输入结构，完成对于实时计算需求。
因此，在原有的架构环境下，对于此类的应用需要部署两套环境分别应对 AP 和 TP 两类负载，从而造成整个架构变得复杂，中间涉及到的组件较多，无法及时将 TP 数据实时更新到 AP 系统中，从而影响 BI 等应用的时效性。
上图：异构架构模式
上图：一体化HTAP架构
产生 HTAP 用户侧的需求或者诉求如下：
- 事务数据及历史数据的集成；
- 理解用户需求的超维度数据分析的需要；全局视角来看数据，方能看清事物的本质；（例如：从手机的位置信息，用户的填表所获得信息，社交媒体所获得富媒体信息。）
- 企业运行所需的商业分析的实时性需求；
矛盾点：
OLTP 和 OLAP 从不同维度之间的对比关系如下所示：
| 对比维度 | OLTP | OLAP |
|---|---|---|
| 一句话特征 | 小事务众多的场景 | 使用复杂查询来处理较大数据量的场景 |
| ACID | 强 | 弱 |
| 面向用户 | 数据库操作人员 | 决策人员、高级管理人员，数据库科学家、业务分析师和知识工作者 |
| 使用场景 | 金融（如银行、股票）、电商、旅行预订等 | 商业智能（BI）、数据挖掘和气压决策支持应用程序 |
| 基本操作 | 主要为：insert, update, delete为主 | 主要为聚合操作，窗口操作等为主 |
| 操作数据范围 | 通常读写数据量较小（数十条记录） | 通常读写数据量大（数百万条记录） |
| 主要衡量指标 | 事务吞吐量（TPS） | 查询响应速度（QPS） |
| 响应时间要求 | 实时性要求高，通常毫秒级 | 实时性要求低，依赖于所处理的数据量，时间范围由小时，分钟秒级，亚秒级等 |
| 数据源 | 业务系统实时事务数据 | 业务系统中的历史数据，事务型数据 |
| 数据库表设计规范 | 通常需要满足三范式（3NF） | 不作规范 |
| 数据量/磁盘空间 | 较小，MB~TB级 | 较大，GB~PB级 |
| 并发量 | 需要支持大并发环境 | 对并发量要求不高 |
| 稳定性 | 要求高 | 要求高 |
| 可用性（备份，恢复） | 完整的备份，恢复能力（全量，增量） | 主要按时间点进行备份/恢复，备份/恢复要求不高 |
| 数据完整性要求 | 强一致性要求 | 数据完整性要求不高 |
| 系统吞吐量，IOPS | 低 | 高 |
| 挑战 | 1.高吞吐量，保证数据完整性，可靠性等；2.完整的生态工具，不同异构产品间协调使用难度； | 1.海量数据高效，低成本的数据存储；2.复杂查询高效处理； |
| 可靠性要求 | 通常要求高可靠性：主备、同城灾备、异地灾备 | 可靠性要求相对低，一般同城灾备 |
| 读特性 | 简单查询为主、每次查询只返回少量数据 | 复杂查询为主、对大量数据进行汇总 |
| 写特性 | 1.随机、低延迟、小数据量；2.数据更新、删除频繁 | 1.很少有更新、删除操作；2.大数据量批量、并行导入 |
| 数据模型 | ER（实体、关系） | 星型或者雪花、星座 |
| 数据粒度 | 行级 record | 多表 |
| 数据结构 | 高度结构化、复杂，适合操作计算 | 简单、适合分析 |
| 数据字段 | 动态变化，按字段更新 | 静态、很少直接更新，定时添加、刷新 |
| 数据返回值 | 一般为记录本身或该记录的多个列 | 一般为聚合计算结果 |
HTAP系统诞生的初衷，是要打破事务处理和分析处理的界限，使企业能通过HTAP系统更好地发现市场反馈，获得更好的创新。
但如何让OLTP和OLAP在系统运行的过程中相互干扰最小，却成了HTAP系统面临的难题。
总体来看，HTAP系统架构的实践可以分成两类：一类是改革，另一类是改良。
前者采用One size fits all的策略，用一个大而全的系统同时满足OLTP和OLAP的需求，
后者采用One size doesn’t fit all模型，将OLTP和OLAP两种系统组合起来，通过CDC的方式把OLTP上产生的数据以增量的方式导入到数仓进行分析。
本期DB · 洞见，将由腾讯云数据库专家工程师朱阅岸来为大家重点分享HTAP系统的技术实现相关路线。
以下是分享实录：
1、HTAP的定义与挑战
我们先来解释HTAP的定义与挑战是什么。下图是经典的数据处理框架，我们在里面划分出两种数据库系统：一种是事务型的系统，这是数据源头产生的地方；另一种是分析型的系统，是我们的数仓。数据会定期从交易型数据库中借助ETL的方式流入到数仓. 然后在数据仓库做分析处理，产生相应的报表和报告。企业的经营决策者能够通过分析报告和决策报表去观察企业的经营行为，从而观察到未来的发展趋势。这是数据宝贵之处的体现之一。不少公司都在数据基础设施上投入人力物力，期待在数据变现上获得更好的回报。
下图右上角是部分研究机构做的调查。研究表明，这些样本公司在每13美金的投入中就有1美金投入到数据分析里，有74%的公司想成为一个数据驱动型的公司，如果一个公司采用更为先进的数据分析手段，那它超越竞争对手的可能性将达到两倍。
数据分析具备巨大的商业价值。但在目前的数据处理框架中，OLTP和OLAP两类系统是割裂开的，主要是通过ETL把数据从交易型数据库导入到分析型数据库，而ETL的时延比较大，可以达到数十分钟到几小时，甚至是几天。上图右下角的图片显示，数据的商业价值会随着时间的流逝而下降。数据产生再经过ETL导入到数仓，在数仓里进行分析，然后做决策，执行相应的动作。在这时，数据的商业价值就会大打折扣。
因此最理想的情况是在数据产生后就能迅速对其进行分析。为了解决这个问题， HTAP系统应运而生，它的初衷就是要打破事务处理和分析处理的界限，使企业能够通过HTAP系统更好地发现市场反馈，获得更好的创新。这么先进的数据处理技术，为什么近年来才引起人们的关注呢？我个人认为，这主要得益于现代列存储技术的发展，HTAP系统的出现才成为了可能。
以前客户用SQL Server做查询分析处理，需要十多个小时以上。在这种技术能力下是无法达到实现HTAP系统要求的。后来SQL Server采用列存储技术，耗时十几个小时的分析可以降到几分钟，甚至可以在秒级时间内把结果运行出来。列存储技术及背后的向量查询引擎的发展，使得HTAP登上了历史舞台。
HTAP能让数据产生后马上就可以进入分析场景。但它面临最大的问题是如何把OLTP和OLAP两类工作负载更好放在一个系统上运行，毕竟这两类工作负载本质上是互斥的。
交易型的事务是短事务，以写为主；分析型的事务是长事务，以读为主，经常需要做全表扫描，在扫描的基础上做统计、聚合等操作。这种情况下，OLAP的事务经常需要独占系统资源，使交易型的事务吞吐量下降。
有研究表明，把OLTP和OLAP放在一个系统里调度，OLTP的吞吐量可能会下降到原本的1/3到1/5。所以如何让OLTP和OLAP在系统运行的过程中相互干扰最小，就成为HTAP系统设计的难题。
从过去十多年的发展来看，主要有两种实现HTAP的方案：
1.第一种是改良的方式，在现有业务系统上延伸扩展，打造一个HTAP的系统来满足业务的需要；
2.第二种是从头开始设计一个具有颠覆性的系统. 当然第二种方式会产生更多有价值的技术，也会涉及到比较多技术难题，包含技术突破、业务适配等。
从现在来看很难说哪种更好，分享着也没有明确指出哪一条路线更好，我们会在这两条路线上挑选典型的具有鲜明技术特色的系统，来和大家分享，同时会在最后给出最近十年来HTAP系统技术的演变过程和发展趋势。
2、HTAP系统的架构实践
2.1 HTAP系统的类别
总体来看，HTAP系统架构的实践可以分成两类：一类是改革，另一类是改良。
前者采用One size fits all的策略，用一个大而全的系统同时满足OLTP和OLAP的需求，
后者采用One size doesn’t fit all模型，将OLTP和OLAP两种系统组合起来，通过CDC的方式把OLTP上产生的数据以增量的方式导入到数仓进行分析。
第一类下又分为两个子类：
1.第一个子类是单系统单拷贝系统，在一个系统里用一种数据格式满足两种业务需求，通常是采用PAX存储。系统整体来看是采用行存储，但是当它把数据打包存储到某个页面时转换成列存储的形式；
2.另一种是单系统双拷贝系统，一个系统里同时存在行存储和列存储，行存储上的更新会定期导入到列存储里转换成列存储格式。在列存储上进行分析，行存储上执行更新。这在某种程度上降低了它们的竞争。
第二类可以分为共享存储和独立存储两个子类。
下图右上角就是这四种类型的系统实现HTAP特征时的比较，可以从两个维度来刻画，一是数据新鲜度，二是工作负载干扰程度。
One size fits all 策略把OLTP和OLAP两种工作负载放在一个系统上，如图1左上角，就干扰程度而言，OLTP和OLAP相互干扰最强，而单系统单拷贝方式尤为明显，其次就是单系统双拷贝的方式。这两种实现方式的缺点是OLTP/OLAP的干扰比较大会导致事务工作负载的吞吐严重下降，但优点是数据可见度高，因为不需要做数据的同步导入导出或数据转换。
One size doesn’t fit all 即松耦合模型也有两种类别，橙色椭圆代表共享存储下的松耦合系统，目前还没有有商业化的产品，只有IBM出了一个DEMO；另一种是采用类似proxy方式把TP与AP两种独立系统组合起来的松耦合系统。这两类系统中，OLTP和OLAP分别在两个独立的系统上进行，可以把干扰降到最小，但数据需要同步，交易型数据库更新的数据要通过CDC的方式同步到分析型系统上，数据的延迟会比较大。
上图右上角也列出了几个典型的HTAP工作负载对时延的需求。系统监控的延迟在20毫秒，在线游戏、个性化广告推荐、商品价格监控，则是在100-200之间。
2.2 单系统单拷贝之Hyper
接下来我们从四类系统实践中挑选部分代表性的系统来看HTAP技术如何具体实现。首先是Hyper。Hyper是很典型的系统，它原本是德国慕尼黑工业大学的 Thomas Neumann教授团队开发的原型产品，但是性能与创新性实在太好，后来被美国tableau公司收购，从学术型的产品变成了商业化的产品，不论从技术与经历都具有较高的代表性。
Hyper的查询执行模式很有考究。OLTP是串行执行，不需要加锁。这是因典型OLTP数据库把大部分时间都消耗在加锁、缓冲区管理、日志管理上，这些操作消耗了系统80%左右的资源。在Hyper中没有这些开销，事务串行执行，去除维护事务隔离性等开销。一个事务串行执行的耗时只有微秒级别，这个是可以接受的。VoltDB是类似的一个系统，事务执行同样不需要加锁，串行地执行（通过分片达到并行执行的效果）。OLAP则通过fork产生子进程在事务一致性的拷贝上运行查询。更新时再把相关的数据页拷贝出来，让交易型事务在不同的数据页上进行更新（Copy-on-Write）。
此外通过区分冷热数据的方式，把数据分成热数据、冷数据和温数据。上图右下角就是通过硬件的方式即MMU的内存管理单元去区分数据的访问热度。热数据放在正常页面即小页面上，冷数据是压缩存储，放在4M的大页面上。这种做法的好处是更新代价比较小，同时在做OLAP查询的时候，在大页面上会有比较好的性能。
Hyper的查询引擎也是相当优秀的，它利用向量化的查询引擎，用LLVM生成可执行的机器码。这个技术非常具有代表性，连著名的Spark也参考了它的代码生成技术。
2.3 单系统单拷贝之SAP HANA
HANA也是采用单系统单拷贝实现HTAP。它不太像一个数据库系统，反而像是一个支持多引擎多工作负载类型的统一数据管理平台。HANA系统的分层结构做得很好，总体来看可以分为编译层和执行层，上层又可以分为查询的解析，生成抽象语法树AST，再映射到计算图模型，接着对计算图模型进行物理优化。此后由分布式执行框架去构建实际的数据流，将具体的物理执行算子分发到特定的引擎执行。因为HANA支持多个工作引擎，比如数据仓的查询引擎、文本、图等，它向上提供了针对这些特定引擎的物理算子，比如关系操作算子、图计算的算子等。
执行引擎下又有统一的表模型。它向上提供一个统一的接口，类似于MySQL下的handler接口，下面的存储引擎负责实现具体的存储，上面的查询执行器只要实现handler接口就可以对接到系统里去。
里面的存储分成三级：
- 首先是L1-delta，对应的是热数据和无压缩的行存储；
- 其次是L2-delta，对应的是轻量级压缩的列存储，比如字典压缩；
- 最后是L3-main store，对应的是重度压缩列存储。
更新发生在L1-delta，数据会定量地导入到Main store里。Main store是读友好的实现方式，满足AP类型的查询，而L1-delta是写优化的实现。通过这种方式来满足HTAP的需求。
它会定期地执行合并操作，把数据定期地合并到Main store里。在合并操作的过程中会生成Main2和Delta2，这时读操作就在Main1、Delta1和Delta2进行。拷贝完成以后Main1和Delta1最终会合并到Main2，最后切换过来，在Main2上进行读操作，写操作发生在Delta2。数据加锁的行为只是发生在缓冲区切换阶段。L1-delta采用redo日志保持持久性，Main store采用影子页技术减少日志的写入，保持一致性与持久性。
2.4 单系统双拷贝之SQL Server
SQL Server是一个双拷贝系统，把数据按行切分成group，定期转变成列存储。具体来说是，每一百万条数据做一个Group，进行切分，然后针对每列转换成列存储，叫做segment。每个列采用单独的压缩算法，比如有些适合用字典压缩，有些适合用数值压缩，因此不同的列采用不同的压缩算法。转换后的列存储附加额外字典表（如有），存储到Blob类型中。外面的directory追踪这些segment的存放位置。
SQL Server也针对列存储提供了批量执行的算法，加速分析操作。
2.5 单系统双拷贝之Oracle
Oracle是另外一个采用双拷贝方式实现HTAP的系统，每个系统里针对有需要的表，会同时存在一份行存储和列存储，在行存储上进行更新，定期同步到列存储里；在列存储上做分析操作。系统可以灵活指定需要采用行存与列存的表，也可以系统运行时更改表特性。Oracle利用RAC集群进行横向拓展。
这里举两个例子，来介绍Oracle是如何利用列存储加速分期操作的。假如我们查找Outlet这个商店类型所有的销售额，首先扫描维表，根据“type把Outlet类型的商店ID拿到，生成一个map”，接着在事实表的对于外键列里把商品ID拿出来在这个map查找，如果找到就可以把Amount累加起来。它通过只扫描某些特定的列，生成相关的map，就可以把要访问的数据找出来，即把关联操作简化成表扫描操作，提升性能。
另外一个比较复杂的是要扫描两个维表，生成两个vectors，在里面再去事实表找相关的外键列，就可以直接定位到相关的vector，如果符合条件，就分类写到相应的临时表里。优点在于可以把表关联操作转换成表扫描操作，只需要访问查询中涉及到的列。
2.6 松耦合共享存储之Wildfire
目前还没有商业化的HTAP产品采用松耦合共享存储架构，但是IBM开发了一个原型，叫 Wildfire。从技术细节来看，它的系统分成两类节点：一类是有状态的节点，一类是无状态的节点。有状态的节点处理事务型的请求，无状态的节点处理OLAP型的请求。OLAP型的请求可以容忍一定的延迟。
OLTP型的数据不会直接写入到共享文件系统里，会写入私有组成的一个集群，按照表分片的模式在这里进行数据的快速写入，再定期导入到共享文件系统里，然后供分析型查询去执行。分析型查询会自己去定制一个引擎，去对接spark executor。这个引擎是无状态的，可以去定制修改，在数据分析领域也是比较强悍的引擎，叫BLU，是IBM自家的分析执行引擎。
总体上看，这个系统分成两个集群：一个是OLTP，一个是OLAP。
国内有部分产品的技术和该架构比较类似，利用spark的能力和生态去做分析型查询，比如利用spark的查询优化器和机器学习能力去构建OLAP能力，OLTP能力则自己构建，这样就把数据和这两套系统在某种程度上做了一定的融合，变成HTAP。
2.7 松耦合独立存储之 F1 Lightning
松耦合独立系统近几年比较流行，有两个典型代表，一个是谷歌的F1 Lightning，另外一个是IBM的IDAA。我们先来介绍F1 Lightning。
F1 Lightning把系统分成三个模块：OLTP数据库、Lightning、查询执行引擎。
Lightning通过Changepump捕获OLTP数据库的更新，以订阅的方式把数据分发到订阅者。Lightning内部还开发了一个适配器，将CDC的模式转换成内部统一的格式。
内部有两级存储：内存存储和磁盘存储。内存存储是以行存储的模式存在，采用B-tree索引，在这里没有转换成列存储，只有在数据写入磁盘时才把行存储转换成列存储。
上层查询通过快照的机制读取可见范围的相关数据。F1 Lightning将捕获的日志分成两层存储,为日志维护系统范围的检查点时间戳以及为适配不同数据库而设计的客户端接口很大程度上借鉴了Databus。这种实现方式带来的问题是查询延迟。从谷歌的测试来看，查询延迟在8-10分钟之间。因为采用CDC方式，要把OLTP数据转换成CDC内部统一的格式，再批量提交，因此延迟会比较大。
2.8 松耦合独立存储之 IDAA
接下来介绍IBM的IDAA。最初IBM也开发了类似松耦合的HTAP架构。下图中左边是Db2，右边是他们的Warehouse，挂载到事务型引擎，事务型引擎将更新定期同步。但IBM系统设计者认为，CDC方案需要花费大量的时间和背景知识来维护额外的进程，且延迟比较大。基于这个原因，他们对此进行了改进，通过轻量级的集成同步方案规避上述问题，将延迟减少180倍。
CDC的方案需要在源端经历6个步骤：读取数据，解密；过滤无关的日志，按照LSN排序；
之后还要对数据进行行列转换；把数据暂存起来，把数据转换成CDC统一内部的格式；再批量等待commit或Rollback，发送之前还要把Rollback数据去除。这种情况对源端的压力是比较大的，延迟也会比较大。
IDAA则建议把这几个步骤都挪到目的端执行。目的端能够原生地识别从Db2里传输过来的数据，当然这个是比较定制化的方案，通用性没那么好，但延迟可大幅降低，只有原来的1/180。现在延迟只有1-2秒左右就能读到最新的数据。
2.9 HTAP技术发展一览
这部分我们来对HTAP近10年来的发展脉络做梳理。图中的直线方向表示后者的技术借鉴前驱或者是从该产品演变过来的。
从图上可以看到，HTAP技术在2015、2016年之前主要是以One size fits all 策略为主，2015、2016年以后则以松偶合架构为主。
这几年如F1 Lightning、IDAA等都是采用松偶合方式来实现HTAP，甚至SAP也是有采用松偶合的技术方案实现HTAP。从One size fits all 的演变趋势来看，大多是从单系统双拷贝转换成单系统单拷贝，从行存储转换成单一的列存储来应对OLTP/OLAP的请求。从原先在磁盘上用列存储，到内存里用行存储，再到现在统一改成列存储。这就是最近10年来HTAP技术的演变趋势。
3、云原生对于HTAP系统启示
这一部分我们来看看云原生架构对HTAP系统实现是否能带来帮助。
下面是三个值得思考的问题：
1.首先是云原生架构即存算分离架构能否为HTAP的设计带来便利？其次是存算分离架构和弹性算力能否缓解资源竞争；
2.因为这两条技术下的系统，在资源竞争和数据可见度上的表现各有优缺点，并不能说哪种产品的表现最优，都是在数据延迟和资源争用上做取舍；
3.此外，云环境下丰富的计算资源池和存储资源池能否针对不同的计算、不同的业务特征进行划分从而降低用户的成本，这也是值得大家去思考的问题。
下图是构想中的愿景图。总体来看，理想的情况是，在一个云原生架构里，Share storage和Query processing 分层，在查询入口处采用多租户设计，这里执行查询解析和查询的优化，然后把查询的执行推到查询执行层。
查询执行层分为有状态和无状态两种，分别处理与OLTP和OLAP相关的请求。共享存储层Share storage针对工作模式和工作负载采取不同的存储设计策略。在OLAP方面可以主打性价比，用对象存储和纠错编码模式降低成本。AWS Redshift团队的调研也表明，OLAP型的用户会更加关注成本，所以在Share storage里OLAP方面可以偏向性价比的权衡。而OLTP数据存储则采用高性能的存储，优化事务提交的关键路径，达到用户最优体验，比如说高性能Nvme(协议是颇为创新的存储技术,如固态硬盘)，加速事务的提交速度，然后定期把数据从OLTP型存储导入到OLAP型的存储。
希望在不久的未来，可以看到相关厂商或数据库开发者实现这样的方案或技术特征。
4、总结
总体来看，HTAP已有的问题是OLTP和OLAP这两种互斥的属性，如何在一个系统里共存而干扰尽可能小，数据可见度延迟尽可能短。
目前存在两种架构实践：
1.一种是One size fits all，用一个数据库系统来满足OLTP和OLAP多样化工作负载的需求；对系统相关的架构革新，针对两种工作负载的特性做更好的适配优化。
2.另外一种是采用松偶合的方式，通过CDC把两类系统黏合起来，在上面架构一个类似于proxy的东西，为用户呈现出一个系统的表象，用户感知不到OLAP型系统的存在。
第二种方案能更好地降低两类工作负载对资源的竞争，但是由于需要跨系统进行数据同步因此延迟较大。而第一种方案虽然资源竞争比较大，但不需要对数据进行跨系统同步，因此延迟比较小，数据能见度、新鲜度高，可以满足紧急型任务的需求。
展望未来，我们认为云原生的弹性算力可能更适合HTAP系统，在云原生上会诞生更优秀的HTAP系统。
5、一体化HTAP数据库 代表作
StoneDB(HTAP数据库)：
StoneDB首页、文档和下载 - 基于 MySQL 的开源实时 HTAP 数据库 - OSCHINA - 中文开源技术交流社区
StoneDB 宣布开源，一体化实时 HTAP 架构为何是当前最优解_StoneDB开源社区的博客-CSDN博客
PolarDB(HTAP数据库)：首次公开！阿里云开源 PolarDB 总体架构和企业级特性
TiDB(伪HTAP数据库,分布式数据库 ): 使用 TiUP 部署 TiDB 集群 | PingCAP Docs
如下补充内容 (此话摘录 https://blog.csdn.net/leizzboy/article/details/126467385)：
Q：StoneDB 和 TiDB 比怎么样？对硬件条件要求高吗？
最早了解的是 TiDB，对外也称 HTAP 数据库，但是生产要求固态硬盘，带宽万兆，普通机械硬盘性能很差。
*A: *StoneDB 与 TiDB 采用了完全不同的技术架构，TiDB 使用松耦合系统架构，StoneDB 采用单系统双引擎架构，单系统架构集成性更高，实时性更强，对用户更加友好，用户完全无需关注和维护类似 Tikv/Tiflash/TiDB 这么多的底层组件。
从硬件要求方面，单系统架构所需的硬件更少、要求也更低，TiDB 最少需要 3~5 个节点才能完成最小化部署，StoneDB 仅需单节点即可，不像 TiDB 那样对硬件配置有严苛要求，在正常情况下采用“与运行MySQL 相同的硬件配置”就可以感受到 StoneDB 飞一般的性能体验，当然配置越高，性能越好。除此以外StoneDB是完全兼容MySQL的（准确的说，我们不需要 Compatible，因为我们就是 Native），可实现对 MySQL 的无缝切换，业务侧无需做一行代码修改。
另外，TiDB 的开源社区做的确实不错，值得我们学习，不过我们从技术理念上一直不太认可 TiDB 属于 HTAP，他们并不符合真正的 HTAP 数据库定义，还是有一定距离的，或许叫分布式数据库是对的。当然，想必他们也知道自己不是真正的 HTAP，因为他们肯定也对 HTAP 的定义有过研究，只不过可能当年做底层架构时工程实现上没有很好的思路，觉得一体化的路线实现太难了，才做了这么一个杂糅架构的伪HTAP数据库出来。我们知道现在出来打破一些人的认知还是要耗费些精力的，毕竟让他们意识到在国内最早推广 HTAP 概念的团队自己做的却是不符合真实 HTAP 定义的数据库，多少会有些打击到他们，也希望相关同学可以看看我们对真正 HTAP 标准的思考。
Q：StoneDB 性能比 MySQL 如何？
A: 在 TP 能力方面，StoneDB 目前与 MySQL 持平。在 AP 能力方面，StoneDB 最高可实现 100 倍性能的提升，StoneDB 产品设计的初衷就是解决 MySQL 本身不具备分析能力的问题。
Q：StoneDB 支持 K8S 部署不？
A: 支持，但是在生产环境不建议采用 K8S 部署方式。K8S 其他服务会抢占磁盘 IO，带来性能下降。
Q：大多数列式存储数据库对多表 join 不支持，或者性能差得很，StoneDB 对多表 join 支持如何？
A: StoneDB 是行列混合架构，不是单纯的列式存储。StoneDB 支持多表关联，其优化器采用了知识网格技术，在进行多表关联时，两个列之间的等值映射关系会被自动创建。
Q：StoneDB 只开源单机版吗？集群版本开源吗？
A: StoneDB集群版仍在开发过程中，开发完成后会进行开源，具体时间以官方正式发布为准。
Q：如何在进行不确定的 OLAP 的查询情况下，保证 OLTP 的稳定性？业务数据库最基本增删改还是不能出问题的。
A: 我们推荐使用主从架构：主节点使用 InnoDB 引擎，可读写，支持 OLTP 业务负载；从节点使用 StoneDB 引擎，只读，支持 OLAP 查询负载。
TiDB
● 入门手册：
● 运维操作：
openGauss
● 入门手册：
● 运维操作：
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
