大家好，StoneDB 自開源以來，收獲到了諸多數(shù)據(jù)庫開發(fā)者的關(guān)注。開源當(dāng)周，StoneDB 一度沖上了 GitHub 上 C++ 項(xiàng)目趨勢排行榜全球第?3 名，Star 數(shù)也在一直維持增長：

還獲得了很多國際友人的關(guān)注：

當(dāng)然，目前 StoneDB 的社區(qū)建設(shè)還正處于初啟階段，我們堅(jiān)信，開源項(xiàng)目的成長，最終還是要靠社區(qū)用戶一起來共創(chuàng)，因此，StoneDB 開源社區(qū)非常重視社區(qū)用戶的聲音，在 7 月份，我們從各個(gè)渠道里收集到了用戶的反饋，這里做一個(gè)匯總，同步給各位關(guān)注 StoneDB 的開發(fā)者們，無論您是在校學(xué)生還是公司后端研發(fā)人員，亦或是某數(shù)據(jù)庫廠商的研發(fā)人員，相信本期的社區(qū)解答會(huì)讓您對 StoneDB 有一個(gè)更深入的了解。

Q：StoneDB 是基于 MySQL 做的怎么還能叫自主可控呢？你們后面能跟上 MySQL 的生態(tài)么？

A：我們還是要區(qū)分“自主”、“可控”、“原創(chuàng)”三個(gè)詞的準(zhǔn)確含義，這樣能更好地理解 StoneDB 的數(shù)據(jù)庫定位。我們基于 MySQL 的根本原因，是因?yàn)槟壳?MySQL 客戶裝機(jī)量足夠多（截至 2022 年它在整個(gè)數(shù)據(jù)庫行業(yè)的市場占有率達(dá)到了 43.04%，來源：Slintel網(wǎng)站），而使用 MySQL 的客戶對 AP 能力的需求也在不斷增長，我們要做的是一個(gè)具有龐大增量的市場，而不是就只盯著 MySQL 生態(tài)玩了，不要誤會(huì)我們只能做 MySQL，以我們對一體化 HTAP（也即真正的HTAP）的理解，基于 PostgreSQL 再做一套也是可以的，所以現(xiàn)在的 StoneDB 準(zhǔn)確的說法是叫 StoneDB for MySQL。很多人現(xiàn)在被一些極端情緒所影響了，并沒有客觀的看待“原創(chuàng)”這個(gè)事兒，開源世界里，“原創(chuàng)”從來不是最重要的，如果有誰覺得自己做得更好就是可以 Fork 出去做他自己的分支版本，且不說現(xiàn)在有多少優(yōu)秀的數(shù)據(jù)庫是基于 MySQL 和 PG 做的，很多優(yōu)秀的操作系統(tǒng)也是基于開源的 Linux 做發(fā)行版的，這個(gè)無論國內(nèi)國外，都很常見，也無可厚非。說到底，一個(gè)開源項(xiàng)目到底能不能把控研發(fā)方向、解決實(shí)際落地問題、對用戶有沒有實(shí)用價(jià)值才是最重要的。而且，我們用了 MySQL 就大大方方承認(rèn)，不藏著掖著，也絕對不是簡單的拿來主義，稍微優(yōu)化魔改一下就放出去的。我們底層確實(shí)用了 MySQL 社區(qū)版的代碼，但是我們的自主原創(chuàng)的代碼量也足夠龐大，為了提高綜合性能，我們還對原本的 MySQL 社區(qū)版源碼進(jìn)行了大量的修改和優(yōu)化。必須強(qiáng)調(diào)的是，我們的 HTAP 內(nèi)核引擎Tianmu（中文名：天目）完全自主研發(fā)，經(jīng)過了足夠時(shí)間的測試和打磨，才開源出來給大家使用，這才是我們強(qiáng)調(diào)的自主性。

另外，我們內(nèi)核研發(fā)團(tuán)隊(duì)對 MySQL 的各個(gè)版本代碼的熟悉程度一點(diǎn)兒也不亞于 MySQL 原廠團(tuán)隊(duì)，我們有超過 10 年內(nèi)核研發(fā)經(jīng)驗(yàn)的數(shù)據(jù)庫老兵，有超過七年近 200 萬行內(nèi)核代碼的積累，更重要的是，我們對 MySQL 和 HTAP 的理解不單是從工業(yè)界上的應(yīng)用實(shí)踐，還有學(xué)術(shù)上的深刻認(rèn)知，我們對數(shù)據(jù)庫學(xué)術(shù)界的最新理論保持高度的關(guān)注，基本上所有經(jīng)典的?HTAP 學(xué)術(shù)論文、國際頂會(huì)和期刊，從原始概念的提出到目前最新的研究進(jìn)展，我們的架構(gòu)師都深入研究過并從中選擇最優(yōu)可實(shí)現(xiàn)的方案落地到我們?StoneDB 的內(nèi)核設(shè)計(jì)上——可以說，工業(yè)界的豐富實(shí)踐和學(xué)術(shù)上的與時(shí)俱進(jìn)就是我們可控性的來源。

現(xiàn)在我們是在做 5.6 和 5.7 的版本，8.0 也在計(jì)劃中，不用擔(dān)心我們跟不上，發(fā)行版跟上 Upstream 是我們的基本素養(yǎng)。只不過，我們要做的，是連 Oracle 自己都舍不得開源的發(fā)行版，這才叫真的玩開源，我們不是那種隨便魔改一下開源項(xiàng)目就拿出來說自己自主創(chuàng)新了，我們的自主創(chuàng)新是實(shí)實(shí)在在的，是會(huì)對全球幾百萬依賴 MySQL 生態(tài)且有 AP 需求的中小企業(yè)產(chǎn)生巨大實(shí)用價(jià)值的。當(dāng)然，未來我們還會(huì)有云原生架構(gòu)，這都是必須會(huì)有的，數(shù)據(jù)庫上云是大勢所趨，我們只會(huì)順勢而為。可以明確的是，一個(gè)成熟的、真正的 HTAP 數(shù)據(jù)庫應(yīng)該有的功能和架構(gòu)，StoneDB 都會(huì)有。

Q：StoneDB 和 TiDB 比怎么樣？對硬件條件要求高嗎？最早了解的是 TiDB，對外也稱 HTAP 數(shù)據(jù)庫，但是生產(chǎn)要求固態(tài)硬盤，帶寬萬兆，普通機(jī)械硬盤性能很差。

A：StoneDB 與 TiDB 采用了完全不同的技術(shù)架構(gòu)，TiDB 使用松耦合系統(tǒng)架構(gòu)，StoneDB 采用單系統(tǒng)雙引擎架構(gòu)，單系統(tǒng)架構(gòu)集成性更高，實(shí)時(shí)性更強(qiáng)，對用戶更加友好，用戶完全無需關(guān)注和維護(hù)類似 Tikv/Tiflash/TiDB 這么多的底層組件。

從硬件要求方面，單系統(tǒng)架構(gòu)所需的硬件更少、要求也更低，TiDB 最少需要 3~5 個(gè)節(jié)點(diǎn)才能完成最小化部署，StoneDB 僅需單節(jié)點(diǎn)即可，不像 TiDB 那樣對硬件配置有嚴(yán)苛要求，在正常情況下采用“與運(yùn)行MySQL 相同的硬件配置”就可以感受到 StoneDB 飛一般的性能體驗(yàn)，當(dāng)然配置越高，性能越好。除此以外StoneDB是完全兼容MySQL的（準(zhǔn)確的說，我們不需要 Compatible，因?yàn)槲覀兙褪?Native），可實(shí)現(xiàn)對 MySQL 的無縫切換，業(yè)務(wù)側(cè)無需做一行代碼修改。

另外，TiDB 的開源社區(qū)做的確實(shí)不錯(cuò)，值得我們學(xué)習(xí)，不過我們從技術(shù)理念上一直不太認(rèn)可 TiDB 屬于 HTAP，他們并不符合真正的 HTAP 數(shù)據(jù)庫定義，還是有一定距離的，或許叫分布式數(shù)據(jù)庫是對的。當(dāng)然，想必他們也知道自己不是真正的 HTAP，因?yàn)樗麄兛隙ㄒ矊?HTAP 的定義有過研究，只不過可能當(dāng)年做底層架構(gòu)時(shí)工程實(shí)現(xiàn)上沒有很好的思路，覺得一體化的路線實(shí)現(xiàn)太難了，才做了這么一個(gè)雜糅架構(gòu)的偽HTAP數(shù)據(jù)庫出來。我們知道現(xiàn)在出來打破一些人的認(rèn)知還是要耗費(fèi)些精力的，畢竟讓他們意識(shí)到在國內(nèi)最早推廣 HTAP 概念的團(tuán)隊(duì)自己做的卻是不符合真實(shí) HTAP 定義的數(shù)據(jù)庫，多少會(huì)有些打擊到他們，也希望相關(guān)同學(xué)可以看看我們對真正 HTAP 標(biāo)準(zhǔn)的思考。

Q：StoneDB 比 StarRocks 有哪些優(yōu)勢？

A:：StoneDB 與 StarRocks 產(chǎn)品定位不同，StarRocks 定位 OLAP 數(shù)據(jù)倉庫，進(jìn)行數(shù)據(jù)分析時(shí)需要從 TP 類數(shù)據(jù)庫通過 ETL 導(dǎo)入數(shù)據(jù)。StoneDB 定位 HTAP 數(shù)據(jù)庫，可以同時(shí)支持 OLTP 和 OLAP 。如果非要一較高下的話，那就是 StarRocks 不支持 OLTP。

Q：StoneDB 性能比 MySQL 如何？

A:：在 TP 能力方面，StoneDB 目前與 MySQL 持平。在 AP 能力方面，StoneDB 最高可實(shí)現(xiàn) 100 倍性能的提升，StoneDB 產(chǎn)品設(shè)計(jì)的初衷就是解決 MySQL 本身不具備分析能力的問題。

Q：StoneDB 支持 MySQL8.0 的新特性嗎？

A：StoneDB V2.0會(huì)支持 MySQL8.0 的新特性，新版本的具體時(shí)間以社區(qū)正式發(fā)文為準(zhǔn)。

Q：StoneDB 向量化是后面的工作嗎？

A：?是的，向量化相關(guān)內(nèi)容規(guī)劃在后續(xù) Roadmap，具體時(shí)間以官方正式發(fā)布為準(zhǔn)。

Q：StoneDB 支持 K8S 部署不？

A：?支持，但是在生產(chǎn)環(huán)境不建議采用 K8S 部署方式。K8S 其他服務(wù)會(huì)搶占磁盤 IO，帶來性能下降。

Q：大多數(shù)列式存儲(chǔ)數(shù)據(jù)庫對多表 join 不支持，或者性能差得很，StoneDB?對多表 join 支持如何？

A：StoneDB 是行列混合架構(gòu)，不是單純的列式存儲(chǔ)。StoneDB 支持多表關(guān)聯(lián)，其優(yōu)化器采用了知識(shí)網(wǎng)格技術(shù)，在進(jìn)行多表關(guān)聯(lián)時(shí)，兩個(gè)列之間的等值映射關(guān)系會(huì)被自動(dòng)創(chuàng)建。

Q：StoneDB?只開源單機(jī)版嗎？集群版本開源嗎？

A：StoneDB集群版仍在開發(fā)過程中，開發(fā)完成后會(huì)進(jìn)行開源，具體時(shí)間以官方正式發(fā)布為準(zhǔn)。

Q：如何在進(jìn)行不確定的 OLAP 的查詢情況下，保證 OLTP 的穩(wěn)定性？業(yè)務(wù)數(shù)據(jù)庫最基本增刪改還是不能出問題的。

A：我們推薦使用主從架構(gòu)：主節(jié)點(diǎn)使用 InnoDB 引擎，可讀寫，支持 OLTP 業(yè)務(wù)負(fù)載；從節(jié)點(diǎn)使用 StoneDB 引擎，只讀，支持 OLAP 查詢負(fù)載。

Q：StoneDB 有獨(dú)立的 Realtime API嗎？

A:：暫時(shí)還沒有。

如果您對 StoneDB 感興趣，可以通過下方鏈接查看 StoneDB 源碼、閱讀文檔，期待您的貢獻(xiàn)！

StoneDB 開源倉庫

https://github.com/stoneatom/stonedb

END