PolarDB-X前身是淘寶內部使用的分庫分表中間件TDDL（2007年，Java庫的形態），早期以DRDS（2012年開始研發，2014年上線，分庫分表中間件+MySQL Proxy的形態）的品牌在阿里云上提供服務，后來（2019年）正式轉型為分布式數據庫PolarDB-X（正式成為了PolarDB品牌的一員）。從中間件到分布式數據庫，我們在以MySQL為存儲構建分布式數據庫這條路上走了10余年，這中間積累了大量的技術，也走了一些彎路，未來我們也會堅定的走下去。

PolarDB-X的發展過程主要分成了中間件（DRDS）和數據庫（PolarDB-X）兩個階段，這兩個階段存在著巨大的差異。筆者參與PolarDB-X的開發恰好剛滿十年，全程經歷了整個發展過程。今天就和大家嘮一嘮PolarDB-X發展與轉型過程中的一些有意思的事情。

中間件時代（2012～2019）

DRDS時期的發展思路其實很簡單，滿足用戶的幾個主要訴求：

阿里云上提供的RDS MySQL單實例最大存儲空間有限制（例如早期只有2T）；

Share Storage的數據庫可以解決磁盤容量問題，但依然受到單機CPU\內存的限制，無法解決寫擴展性的問題；

使用開源中間件能解決上述問題，但做擴容等運維操作十分的麻煩復雜。

在這樣的背景下，我們在中間件TDDL之上增加了一個MySQL Proxy（實際上是Cobar的網絡層），部署在了阿里云上，便成為了最早的DRDS。

上云的開始--使用云，也服務云

值得一提的是，DRDS上云的方式放到現在看，也是非常時髦的。

像阿里云的普通用戶一樣，它也擁有一個阿里云的賬號（只不過這個賬號有上萬億的授信額度），使用這個賬號的AK/SK，調用阿里云各個產品的Open API來進行各種操作。

例如，創建實例時，會購買ECS來進行部署DRDS節點；會購買SLB搭在前面來做負載均衡；會購買SLS服務用來存儲該實例的SQL審計；會打通DRDS節點到用戶RDS的網絡等等。

這種形式的管控架構目前被廣泛地運用，充分地利用了云的優勢。DRDS幾乎不需要關注資源問題，也不需要自己維護庫存；像機器宕機這種問題，ECS也能自動地進行遷移（連IP都不會發生變化），非常的便利。讓DRDS的研發團隊可以將更多的精力放在提升產品本身的能力上。

DRDS一方面為阿里云上的用戶提供服務，另一方面也作為阿里云的一個“普通用戶”，享受著云技術帶來的好處，還是非常有趣的。

在DRDS時期，我們在內核側重點積累了以下技術能力：

SQL語義上與MySQL的兼容性

TDDL僅服務于內部用戶，而淘寶的研發規范相對是比較嚴格的，應用使用的SQL都是比較簡單的類型，所以對SQL的處理是非常少的，簡單說，它甚至不需要理解SQL的語義，僅做轉發即可。但云上用戶的需求五花八門，又存在大量遷移上云的存量應用，對SQL兼容性要求變高了很多。這就要求我們要提供一個完整的SQL引擎。

DRDS相對于TDDL以及市面上一眾的分庫分表中間件，多了兩個關鍵組件：具備完整的算子體系的查詢優化器與執行器。它的目標是無論SQL有多復雜，都要能夠正確理解其語義，并執行出正確的結果。

這里有非常多需要長期積累的工作。舉幾個例子：

• 任何一個MySQL支持的內建函數，都有可能是基于一個不能下推的結果進行計算的，這就要求DRDS需要支持所有MySQL的內建函數，并且目標與MySQL的行為一致。我們在DRDS內實現了幾乎所有的這些函數（https://github.com/ApsaraDB/galaxysql/tree/main/polardbx-optimizer/src/main/java/com/alibaba/polardbx/optimizer/core/function）。早期我們有兩位同學花了數年時間來做這件事情，并且打磨至今。
• MySQL中支持大量的charset與collation，不同的組合會帶來不同的排序結果。如果我們要使用歸并排序的算子對MySQL層已經局部有序的結果進行歸并，則需要確保DRDS使用與MySQL一致的排序行為。實際上這里要求DRDS支持與MySQL行為一致的charset與collation系統，例如我們實現的utf8mb4_general_ci：https://github.com/ApsaraDB/galaxysql/blob/main/polardbx-common/src/main/java/com/alibaba/polardbx/common/collation/Utf8mb4GeneralCiCollationHandler.java。

類似這樣的工作還有很多，例如類型系統（https://zhuanlan.zhihu.com/p/374130246）、sql_mode、時區系統、默認值等等，繁瑣但必要。這些工作都很好地延續到了PolarDB-X中。

極致的下推優化

將計算下推到與數據最近的地方，這是保證性能的一個最樸素的原則。

將MySQL作為一個分布式數據庫的存儲引擎，它實際上本身也具備很強的計算能力。特別相對于目前很多使用KV來作為存儲引擎的分布式數據庫，它們大多只能做到Filter、函數的下推執行。但MySQL卻支持完整的SQL執行，將分片級的JOIN、子查詢、聚合等操作盡可能多地下推到MySQL上，是DRDS保證高性能的一個關鍵。

下表簡單對比業界產品的一些優化選擇，信息來自公開文檔：

推多了會導致結果錯誤，推少了會達不到最佳性能。DRDS的優化器積累了大量下推優化策略。這些優化策略大多是沒有辦法憑空想象出來的，只有通過實際的場景案例，才能得到積累。詳見：https://zhuanlan.zhihu.com/p/366312701

物理算子的豐富與MPP的執行引擎

物理算子也就是指執行器的各種算法，例如對于Join，我們支持HybridHashJoin、LookupJoin、NestedLoopJoin、SortMergeJoin、MaterializedSemiJoin等等算法。

DRDS最初僅支持單線程去執行SQL，但這種執行對復雜的SQL是不夠用的。我們先做了單機并行引擎（SMP），又發展到了現在的MPP引擎，https://zhuanlan.zhihu.com/p/346320114

同時，執行引擎還支持spill out（中間結果落盤的能力），即使只有15M內存，也能跑通TPCH 1G的測試，詳見：https://zhuanlan.zhihu.com/p/363435372

這些能力的積累與突破，極大地提升了PolarDB-X在面對復雜的SQL的計算能力。

坎坷的分布式事務

分布式事務，是繞不開的一個問題。

對于中間件類型的產品來說，我們有一個很基本的假設：使用標準的MySQL，避免對MySQL做侵入性的修改；即使修改，也應該是插件化的。

不修改MySQL，這導致我們很長一段時間都沒有很好地實現分布式事務。

我們前前后后走過的一些彎路：

• 像傳統中間件一樣，禁止分布式事務。但這個對應用的改造成本太高了；
• 使用柔性事務，很長一段時間我們使用GTS（原名TXC）這樣的第三方組件來實現分布式事務。這種方案需要對不同的SQL根據語義來實現回滾語句，SQL兼容性很差；
• 使用GTM的方案。GTM本質是一個單點，并且GTM與Coordinator之間要做大量的數據交互，性能太差，不可能作為一個默認使用的事務策略。所以我們看使用GTM方案的“數據庫”，它一定有很嚴苛的使用條件（例如要求應用盡量避免分布式事務、默認關閉強一致等）；
• XA事務，早期的MySQL對XA支持的很弱，BUG很多（實際上現在的MySQL對于XA的BUG依然很多），例如宕機恢復流程很容易因為XA掛掉。并且XA事務無法解決讀的可見性問題，與單機事務的行為不兼容。

事務系統是一個與存儲層密切相關的事情，從PolarDB-X的探索來看，不對MySQL做深度修改，是不可能做出性能、功能都符合要求的分布式事務的。這是所有中間件類產品都無法解決的問題，也是中間件與數據庫根本性的差異。

繞不開的分區鍵

從DRDS的第一個用戶開始，就一直要回答一個問題，我的表怎么選分區鍵？

從做“高吞吐”、“高并發”的業務系統角度來看，要求表和SQL帶上有業務特征的分區鍵是非常合理的一件事情。全部下推到存儲層，避免產生跨機的查詢、事務，做到這些才能保證做到最佳的性能，這是性能的天花板。

問題是，雖然這樣做上限很高（高到淘寶雙十一0點的業務高峰也可以很絲滑），但：

• 這種改造成本是非常高的，很多時候分區鍵是很難選的。例如很多電商系統的訂單表會有兩個查詢維度，賣家和買家，選哪個當分區鍵；
• 不是所有的業務系統（或者說不是所有的表和SQL）都值得花這么大的代價去改造的，只有核心系統中的核心邏輯才需要做這種細致的改造；
• 拆分鍵選錯了，會導致下限極低。對于數據庫來說，提供比較高的上限和提供不太低的下限同樣重要。

自然，我們想知道，什么樣的技術，才能讓你“忘掉”分區鍵這個東西呢？

數據庫時代（2019～）

透明分布式之路

是否需要強制應用在意分區鍵的概念，是中間件與數據庫的關鍵性區別之一。

1）分區鍵與全局索引

廣義的“分區鍵”的概念，其實并不是分布式數據庫特有的。

我們在單機數據庫中，例如MySQL中，數據存儲成了一棵一棵B樹。如果一個表只有主鍵，那它只有一棵B樹，例如：

CREATE TABLE t1(
    id INT,
    name CHAR(32),
    addr TEXT,
    PRIMARY KEY (id)
)

這個表唯一的B樹是按照主鍵（id）進行排序的。如果我們的查詢條件中帶了id的等值條件例如where id=14，那么就可以在這棵樹上快速的定位到這個id對應的記錄在哪里；反之，則要進行全表掃描。

B樹用于排序的Key，通過二分查找可以定位到一個葉子節點；分區鍵通過哈希或者Range上的二分查找，可以定位到一個分片。可以看出它們都是為了能快速地定位到數據。

如果我們要對上面的表做where name='Megan'來查詢，在MySQL中，我們并不需要將name設為主鍵。更加自然的方式是，在name上創建一個二級索引：

CREATE INDEX idx ON t1(name)

每個二級索引在MySQL中都是一棵獨立的B Tree，其用于排序的Key就是二級索引的列。

也就是說，當前t1這張表，有兩顆B Tree了，主鍵一棵，idx一棵，分別是：

id->name,addr
name->id

當使用where name='Megan'進行查詢時，會先訪問idx這顆B樹，根據name='Megan'定位到葉子節點，獲取到id的值，再使用id的值到主鍵那顆B樹上，找到完整的記錄。

二級索引實際上是通過冗余數據，使用空間與提升寫入的成本，換取了查詢的性能。

同時，二級索引的維護代價并不是非常的高，一般情況下可以放心地在一個表上創建若干個二級索引。

同理，在分布式數據庫中，想讓你“忘掉”分區鍵這個東西，唯一的方法就是使用分布式二級索引，也稱為全局索引（Global Index）。并且這個全局索引需要做到高效、廉價、與傳統二級索引的兼容度高。

全局二級索引同樣也是一種數據冗余。例如，當執行一條SQL：

INSERT INTO t1 (id,name,addr) VALUES (1,"meng","hz");

如果orders表上有seller_id這個全局二級索引，可以簡單理解為，我們會分別往主鍵與seller_id兩個全局索引中執行這個insert，一共寫入兩條記錄：

INSERT INTO t1 (id,name,addr) VALUES (1,"meng","hz");
INSERT INTO idx (id,name) VALUES (1,"meng");

其中t1主鍵索引的分區鍵是id，idx的分區鍵是name。

同時，由于這兩條記錄大概率不會在一個DN上，為了保證這兩條記錄的一致性，我們需要把這兩次寫入封裝到一個分布式事務內（這與單機數據庫中，二級索引通過單機事務來寫入是類似的）。

當我們所有的DML操作都通過分布式事務來對全局索引進行維護，二級索引和主鍵索引就能夠一直保持一致的狀態了。

好像全局索引聽起來也很簡單？實則不然。

2）全局索引與分布式事務

索引一定要是強一致的，例如：

• 不能寫索引表失敗了，但是寫主表成功了，導致索引表中缺數據；
• 同一時刻去讀索引表與主表，看到的記錄應該是一樣的，不能讀到一邊已提交，一邊未提交的結果。
• ...

這里對索引的一致性要求，實際上就是對分布式事務的要求。

由于全局索引的引入，100%的事務都會是分布式事務，對分布式事務的要求和“強依賴分區鍵類型的分布式數據庫”完全不同了，要求變得更高：

• 至少需要做到SNAPSHOT ISOLATION以上的隔離級別，不然行為和單機MySQL差異會很大，會有非常大的數據一致性風險。目前常見的方案是HLC、TrueTime、TSO、GTM方案，如果某數據庫沒有使用這些技術，則需要仔細甄別；
• 100%的分布式事務相比TPCC模型10%的分布式事務，對性能的要求更高，HLC、TSO、TrueTime方案都能做到比較大的事務容量，相對而言，GTM由于更重，其上限要遠遠低于同為單點方案的TSO（TSO雖然是單點，但由于有Grouping的優化，容量可以做的很大）；
• 即使用了TSO/HLC等方案，優化也要到位，例如典型的1PC、Async Commit等優化。不然維護索引增加的響應時間會很難接受。

3）與單機索引的兼容性

此外，單機數據庫中，索引有一些看起來非常自然的行為，也是需要去兼容的。

例如：

• 能通過DDL語句直接創建索引，而不是需要各種各樣的周邊工具來完成。
• 前綴查詢，單機數據庫中，索引是可以很好地支持前綴查詢的，全局索引應該如何去解這類問題？
• 熱點問題（Big Key問題），單機數據庫中，如果一個索引選擇度不高（例如在性別上創建了索引），除了稍微有些浪費資源外，不會有什么太嚴重的問題；但是對于分布式數據庫，這個選擇度低的索引會變成一個熱點，導致整個集群的部分熱點節點成為整個系統的瓶頸。全局索引需要有相應的方法去解決此類問題。

索引的創建速度，索引回表的性能，索引的功能上的限制，聚簇索引，索引的存儲成本等等，其實也都極大的影響了全局索引的使用體驗，這里鑒于篇幅原因，就不繼續展開了。

4）索引的數量

對全局索引的這些要求，本質來源于全局索引的數量。

透明性做得好的數據庫，所有索引都會是全局索引，其全局索引的數量會非常的多（正如單機數據庫中一個表一個庫的二級索引數量一樣）。數量多了，要求才會變高。

而，這些沒有全做好的分布式數據庫，即使有全局索引，你會發現它們給出的用法依然會是強依賴分區鍵的用法。

它們會讓創建全局索引這件事，變成一個可選的、特別的事情。這樣業務在使用全局索引的時候會變得非常慎重。自然，全局索引的數量會變得非常有限。

當全局索引的數量與使用場景被嚴格限制之后，上述做的不好的缺點也就變得沒那么重要了。

5）面向索引選擇的查詢優化器

我們知道，數據庫的優化器核心工作機制在于：

• 枚舉可能的執行計劃
• 找到這些執行計劃中代價最低的

例如一個SQL中涉及三張表，在只考慮左深樹的情況下：

• 在沒有全局索引的時候，可以簡單理解為，執行計劃的空間主要體現在這三張表的JOIN的順序，其空間大小大致為3x2x1=6。執行計劃的空間相對是較小的，優化器判斷這6個執行計劃的代價也會容易很多。（當然優化器還有很多工作，例如分區裁剪等等，這些優化有沒有索引都要做，就不多說了）。
• 在有全局索引的時候，情況就復雜多了。假設每個表都有3個全局索引，那執行計劃空間的大小大致會變成(3x3)x(2x3)x(1x3)=162，這個復雜度會急劇的上升。相應的，對優化器的要求就會高得多。優化器需要考慮更多的統計信息，才能選擇出更優的執行計劃；需要做更多的剪枝，才能在更短的時間內完成查詢優化。

所以我們可以看到，在沒有全局索引的“分布式數據庫”或者一些中間件產品中，其優化器是很羸弱的，大多是RBO的，它們根本就不需要一個強大的優化器，更多的優化內容實際上被單機優化器給替代了。

PolarDB-X提供了使用代價模型的優化器：https://zhuanlan.zhihu.com/p/370372242

在MySQL上實現強一致、高性能的分布式事務

為了做一個透明的分布式數據庫，最關鍵的就是全局索引以及全局索引依賴的分布式事務了。中間件時代的探索已經告訴我們，要做強一致、高性能的分布式事務，一定要對存儲（MySQL）做深度的修改。

我們選擇的是使用全局MVCC（TSO）+2PC（XA）的方案。

MySQL的單機MVCC中包含了start_timestamp（也就是MySQL中的trx_id），為了實現全局MVCC，需要做幾件核心的事情：

• 提供一個全局的時間戳生成器TSO，https://zhuanlan.zhihu.com/p/360160666
• 使用TSO生成的全局時間戳替換掉單機生成的trx_id
• 引入commit_timestamp（同樣由TSO生成），使用strat_timestamp與commit_timestamp來進行可見性的判斷，非常的高效

https://zhuanlan.zhihu.com/p/355413022。不使用在節點之間交換活躍事物鏈表或者GTM這種代價非常大的方案。

PolarDB-X中的事務流程：

InnoDB中的記錄格式的修改，我們稱之為Lizard事務系統，詳見：https://developer.aliyun.com/article/795058

我們還有其他一些文章來介紹PolarDB-X分布式事務的實現：

• PolarDB-X 強一致分布式事務原理

（https://zhuanlan.zhihu.com/p/329978215）

• PolarDB-X 分布式事務的實現（一）

（https://zhuanlan.zhihu.com/p/338535541）

有了分布式事務與全局索引后，PolarDB-X正式從中間件轉型成了一個分布式數據庫。

PolarDB-X的透明分布式

PolarDB-X實現了非常優秀的分布式事務與全局索引，滿足上文提到了對全局索引的要求，做到了透明分布式。

在透明分布式模式下（CREATE DATABASE中指定mode='auto'），所有的索引都是全局索引，應用無需關心分區鍵的概念。

例如，我們的建表語句，與單機MySQL完全一致，并不需要指定分區鍵：

create table orders (
   id bigint, 
   buyer_id varchar(128) comment '買家', 
   seller_id varchar(128) comment '賣家',
   primary key(id),
   index sdx(seller_id),
   index bdx(buyer_id)
)

創建全局索引也與單機MySQL創建二級索引的體驗一致，全程是Online的：

CREATE INDEX idx_seller_id ON orders (seller_id);

PolarDB-X的全局索引是強一致的，其數據一致性體驗與單機MySQL沒有明顯差異，提供了符合MySQL語義的RC與RR的隔離級別。

同時，PolarDB-X在索引的維護、優化器上也做了大量的工作，確保索引能高效的創建、維護，優化器能正確地生成使用索引的執行計劃。

PolarDB-X的分區算法，也能很好地處理索引中產生的熱點、數據傾斜等問題，參考：https://zhuanlan.zhihu.com/p/424174858

自動（透明）決定下限，手動決定上限

按透明與手動來劃分市面上常見的分布式數據庫：

• 透明的分布式數據庫的典型代表：TiDB、CockroachDB。
• 手動的分布式數據庫典型代表：OceanBase、YugabyteDB。

是否透明的分布式數據一定比手動的要好呢？

對于只提供透明用法的數據庫，遷移成本會比較低，初步體驗會比較好。但進入深水區后，由于不可避免的會大量的使用分布式事務，在核心場景中，性能往往是達不到要求的（或者同樣的性能需要更高的成本），并且缺少消除分布式事務、更充分的計算下推等優化手段。

對于只提供手動用法的數據庫，雖然設計良好的分區鍵使得理論上能夠做到性能最優，但使用門檻會大幅增加（10%核心表設計分區鍵也就算了，剩下的90%非核心表也要設計分區鍵）。

我們認為，無論是純透明還是純手動的分布式數據庫，都無法很好地滿足業務對試用成本和性能兼顧的要求。

PolarDB-X除了提供了透明模式，也完整的支持了分區表的語法，并提供了Join Group/Table Group、分區在線變更等工具，讓應用在需要極致性能的情況下，能將事務、計算更多的下推到存儲節點。

PolarDB-X是市面上唯一能夠做到同時提供透明與手動兩種模式的分布式數據庫，我們推薦大多場景使用透明模式，之后對核心業務場景進行壓測，并使用分區表語法對這些場景做手動的優化，以達到最高的性能。

使用Paxos協議做到RPO=0

中間件對接的MySQL普遍使用主備架構，這種方式最大的問題就是會丟數據，甚至時間長了是一個必然的事情。（常在河邊走，哪能不濕鞋呢？）

經過數據庫圈子這幾年的科普，基本大家都知道了需要使用一些一致性協議，例如Paxos和Raft才能做到不丟數據。這些協議實際上并不是什么秘密了，甚至數據庫圈子都有一個段子：“現在校招的學生都要能手擼Paxos了”。

門檻并不在協議本身上，而在于如何與MySQL結合后的穩定性與性能。穩定性，只有經過大規模的驗證，踩過足夠多的坑，才能獲得。

PolarDB-X所使用的的Paxos協議是源于阿里內部的X-Paxos，可以這樣說，阿里內部的MySQL數據庫，已經不存在主備模式了，100%的使用X-Paxos。這代表它經歷了上萬個MySQL集群以及各種大促的驗證，具備極高的可靠性。

我們有幾篇文章想寫介紹X-Paxos：

• PolarDB-X 一致性共識協議 —— X-Paxos：https://zhuanlan.zhihu.com/p/302845832
• PolarDB-X 存儲架構之“基于Paxos的最佳生產實踐”：https://zhuanlan.zhihu.com/p/315596644

完全兼容MySQL的Binlog協議

要利用MySQL生態的資源，非常重要的一點是能夠使用MySQL生態的工具，將數據流向下游。業內常見的方案里：

• 中間件類產品，需要用戶去訂閱每個MySQL的Binlog，由用戶自行解決這中間的各種運維問題（例如DDL問題，不同的分表名要做合并等），非常的繁瑣；
• 分布式數據庫類產品，這些大多提供自己的CDC能力，例如OceanBase、TiDB，但他們的格式并非MySQL的Binlog格式，無法直接使用MySQL生態。

PolarDB-X是市面上唯一一個提供完全兼容MySQL Binlog協議的分布式數據庫，用戶可以使用任何開源的MySQL Binlog訂閱、解析工具（例如Canal）來對接PolarDB-X的Binlog。

這極大地提升了PolarDB-X的易用性。詳見：

PolarDB-X 如何兼容MySQL Binlog 協議和參數，https://zhuanlan.zhihu.com/p/512114589

PolarDB-X 全局 Binlog 解讀，https://zhuanlan.zhihu.com/p/369115822

下一個五年

我們對未來的PolarDB-X充滿想象，希望她能變成一個更好的數據庫。雖然有很多的不確定性，不過有一些事情是我們會持續去做的。

最重要的，我們會堅持在MySQL生態上，并且堅持在基于MySQL作為存儲節點構建分布式數據庫這條技術路線上。我們認為這是我們相對于其他分布式數據庫的一個非常關鍵的差異。與MySQL的兼容其實分為功能兼容與性能兼容，使用分布式KV等技術方案，也許能在功能上兼容MySQL，但是很難做到與MySQL性能上的兼容。MySQL是一個具備全功能的存儲，將大量的事務與計算下推到存儲節點，是分布式數據庫做到高性能的關鍵。

業內提供全局索引的分布式數據庫，全局索引的性能（寫入和查詢）與單機數據庫中索引的性能和行為普遍都有一定的差距，縮小這個差距，便能提升分布式數據庫的下限。對于PolarDB-X來說，這個差距主要來自于CN與DN（MySQL）之間的交互鏈路過長，有很多冗余的操作（MySQL Server層的線程連接模型、MySQL優化器、Parser等）。我們會通過使用RPC協議與MySQL進行交互、做薄MySQL Server層等方式來進一步提升PolarDB-X全局索引的性能。

自動的負載均衡能夠極大的降低分布式數據庫的使用門檻，PolarDB-X的一些特性（手動與自動兼顧、Join能夠下推等），使得這件事情相對于不支持這些特性的數據庫有一些額外的難度（一把淚，但我們可以解決），這塊還需要一些時間進行打磨。

降本增效是這兩年比較火的一個話題，PolarDB-X即將OSS歸檔的能力，能夠自動的將歷史數據轉儲到OSS上，并能通過和在線數據一樣的SQL接口進行訪問，也支持使用Spark等開源大數據工具對轉儲的OSS文件直接進行分析等操作。詳見：https://zhuanlan.zhihu.com/p/477664175

HTAP是分布式數據庫領域比較熱門的主題，各數據庫廠商提出了各種各樣的方案。但從現有的HTAP實現來看，性能、隔離性、成本三者處于一種比較矛盾的狀態（有些數據庫會使用列存副本，性能OK，但很貴；有些數據庫在HA使用的備節點來做分析，性能和隔離性就會差一些），離理想中的HTAP差距甚遠。我們也會在這個領域做持續性的投入，希望能探索出一種能滿足大多數業務場景的HTAP的形態出來。

提供異地多活（全球化等概念）在數據庫層面更原生的支持。支持淘寶的異地多活使我們團隊在這個領域積累了大量的經驗（相信沒有人比我們懂的更多）。實際上PolarDB-X是國內少有的落地大型異地多活項目的數據庫（其中一個還是民生級的系統），我們希望能把這些經驗變成數據庫的原生能力，減少異地多活系統對外部組件的依賴，將它變得更為普世。