1樓：
就沒人吐槽一下那個「計算節點」麼？「計算節點」使用tokudb儲存引擎儲存全量資料，為了支援複雜查詢。。。如果我乙個分布式系統的資料總量有20T、100T，也用單個「計算節點」儲存全量資料？
而且這個資料同步過程是非同步的，顯然沒法用在OLTP場景。
2樓：靈劍
用Sharding中介軟體冒充NewSQL這件事，讓我想起了青雲當年的「SDN」，其實是iptables。一而再再而三搞這種事情就不好了吧？
3樓：
說一下事務方面，官方宣傳用XA實現了Snapshot Isolation，然而眾所周知XA是無法實現SI的，於是抱著好奇的態度研究了下。
結論大跌眼鏡：
1. 所謂的事務其實只支援單條SQL，BEGIN / SET AUTOCOMMIT=0 都不支援。
（大概是開發者們對事務的理解與眾不同吧。。）
這也算了，重點在下面：
2. 為了達到 SI 隔離級別，在執行使用者 SQL時，會加上乙個 commitLock，防止其他事務提交。但，這個commitLock 只是在記憶體裡而已，也就是說只對當前的 proxy 節點有效。
所以如果你想用SI事務，對不起，最多乙個節點，不能再多了。
（這。。也稱得上分布式資料庫嗎？）
總之大家不要驚慌，就是乙個 MySQL 的 sharding proxy，類似的東西已經有很多了。
最後希望貴司吹牛的時候考慮下使用者的感受，這標題黨有點過分了啊，生氣了 （｀Δ）ゞ
4樓：吳鏑
瀉藥重點看了一下xenon中所謂的Raft+，這個raft看上去是用來對一組mysql(一主多從)進行選主，大家都知道raft選主的邏輯是會選出乙個擁有最多的committed log的成員作為主，那麼對於xenon來說，哪個mysql的GTID最大，就選哪個。部署上，每個mysql機器上部署乙個xenon，類似於mysql agent的角色。xenon和xenon之間進行通訊，xenon可以拿到自己守護的mysqld的所有的狀態，包括GTID。
一組mysql機器內的複製還是通過semi-sync來複製(如果退化成非同步複製怎麼辦?)。可以看出這種方案，一般適用於至少三颱mysql的場景。
之前看介紹文件，還以為xenon接管了mysql機器之間的複製，目前看不是這樣。可以說xenon是乙個解決了HA+一致性的方案.
上層radon是乙個分庫分表的東西，需要設定sharding key，這個和傳統的分庫分表中介軟體比較像了，比傳統的中介軟體nb的是支援了分布式事務，基於mysql xa搞的。並且看文件也支援了join，具體做的有多精細就沒仔細看了。
分布式資料庫，如hadoop cassandra mysql集群，主流是採用什麼儲存技術，DAS NAS還是SAN？
如果簡單的回答題主的問題，那麼答案是DAS。除了MySQL以外，其他的都是經典的分布式系統。這些分布式系統通常假定任何裝置都是不可靠的，演算法上會對資料做冗餘儲存，因此對介質本身的要求相對較低，DAS即可。MySQL相對特殊。一般而言，如果用MySQL，題主要用的是關聯式資料庫，且資料一般是比較重要...
如何評價開源資料庫lealone的分布式事務模型？
題主的假設是 client coordinator 讀到的各個伺服器上的事務id列表是一致的，即無論是多大的群，就是假定了某地存在乙個全域性一致的事件序列。還需要好好斟酌下。 吳鏑 我先給你理理這個設計的思路，然後再來說這個設計的問題。事務有原子性要求，分布式事務可能會涉及到多個機器，原子性如何保證...
分布式資料庫計算引擎對分布式儲存系統底座提出了哪些新的技術挑戰？
lemon wonder 我說一下HTAP情況，對於資料庫，TP主要是事務相關，一般底層儲存引擎使用行存，對於AP是分析性，對事務要求沒那麼高，一般用列存，要處理HTAP，那要做到行列混合儲存就很困難。對於儲存引擎，一種是外掛程式型，向MySQL中，SQL和儲存約定好介面，實現介面並直接使用。但是要...