當然，目前 StoneDB 的社區建設還正處于初啟階段，我們堅信，開源專案的成長，最侄訓是要靠社區用戶一起來共創，因此，StoneDB 開源社區非常重視社區用戶的聲音，在 7 月份，我們從各個渠道里收集到了用戶的反饋，這里做一個匯總，同步給各位關注 StoneDB 的開發者們，無論您是在校學生還是公司后端研發人員，亦或是某資料庫廠商的研發人員，相信本期的社區解答會讓您對 StoneDB 有一個更深入的了解，
Q：StoneDB 是基于 MySQL 做的怎么還能叫自主可控呢？你們后面能跟上 MySQL 的生態么？
A: 我們還是要區分“自主”、“可控”、“原創”三個詞的準確含義，這樣能更好地理解 StoneDB 的資料庫定位，我們基于 MySQL 的根本原因，是因為目前 MySQL 客戶裝機量足夠多（截至 2022 年它在整個資料庫行業的市場占有率達到了 43.04%，來源：Slintel網站），而使用 MySQL 的客戶對 AP 能力的需求也在不斷增長，我們要做的是一個具有龐大增量的市場，而不是就只盯著 MySQL 生態玩了，不要誤會我們只能做 MySQL，以我們對一體化 HTAP的理解，基于 PostgreSQL 再做一套也是可以的，所以現在的 StoneDB 準確的說法是叫 StoneDB for MySQL，很多人現在被一些極端情緒所影響了，并沒有客觀的看待“原創”這個事兒，開源世界里，“原創”從來不是最重要的，如果有誰覺得自己做得更好就是可以 Fork 出去做他自己的分支版本，且不說現在有多少優秀的資料庫是基于 MySQL 和 PG 做的，很多優秀的作業系統也是基于開源的 Linux 做發行版的，這個無論國內國外，都很常見，也無可厚非，說到底，一個開源專案到底能不能把控研發方向、解決實際落地問題、對用戶有沒有實用價值才是最重要的，而且，我們用了 MySQL 就大大方方承認，不藏著掖著，也絕對不是簡單的拿來主義，稍微優化魔改一下就放出去的，我們底層確實用了 MySQL 社區版的代碼，但是我們的自主原創的代碼量也足夠龐大，為了提高綜合性能，我們還對原本的 MySQL 社區版原始碼進行了大量的修改和優化，必須強調的是，我們的 HTAP 內核引擎Tianmu（中文名：天目）完全自主研發，經過了足夠時間的測驗和打磨，才開源出來給大家使用，這才是我們強調的自主性，
另外，我們內核研發團隊對 MySQL 的各個版本代碼的熟悉程度一點兒也不亞于 MySQL 原廠團隊，我們有超過 10 年內核研發經驗的資料庫老兵，有超過七年近 200 萬行內核代碼的積累，更重要的是，我們對 MySQL 和 HTAP 的理解不單是從工業界上的應用實踐，還有學術上的深刻認知，我們對資料庫學術界的最新理論保持高度的關注，基本上所有經典的 HTAP 學術論文、國際頂會和期刊，從原始概念的提出到目前最新的研究進展，我們的架構師都深入研究過并從中選擇最優可實作的方案落地到我們 StoneDB 的內核設計上——可以說，工業界的豐富實踐和學術上的與時俱進就是我們可控性的來源，
現在我們是在做 5.6 和 5.7 的版本，8.0 也在計劃中，不用擔心我們跟不上，發行版跟上 Upstream 是我們的基本素養，只不過，我們要做的，是連 Oracle 自己都舍不得開源的發行版，這才叫真的玩開源，我們不是那種隨便魔改一下開源專案就拿出來說自己自主創新了，我們的自主創新是實實在在的，是會對全球幾百萬依賴 MySQL 生態且有 AP 需求的中小企業產生巨大實用價值的，當然，未來我們還會有云原生架構，這都是必須會有的，資料庫上云是大勢所趨，我們只會順勢而為，可以明確的是，一個成熟的、真正的 HTAP 資料庫應該有的功能和架構，StoneDB 都會有，
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 比 StarRocks 有哪些優勢？
**A: **StoneDB 與 StarRocks 產品定位不同，StarRocks 定位 OLAP 資料倉庫，進行資料分析時需要從 TP 類資料庫通過 ETL 匯入資料，StoneDB 定位 HTAP 資料庫，可以同時支持 OLTP 和 OLAP ，如果非要一較高下的話，那就是 StarRocks 不支持 OLTP，
Q：StoneDB 性能比 MySQL 如何？
**A: **在 TP 能力方面，StoneDB 目前與 MySQL 持平，在 AP 能力方面，StoneDB 最高可實作 100 倍性能的提升，StoneDB 產品設計的初衷就是解決 MySQL 本身不具備分析能力的問題，
Q：StoneDB 支持 MySQL8.0 的新特性嗎？
**A: **StoneDB V2.0會支持 MySQL8.0 的新特性，新版本的具體時間以社區正式發文為準，
Q：StoneDB 向量化是后面的作業嗎？
**A: **是的，向量化相關內容規劃在后續 Roadmap，具體時間以官方正式發布為準，
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 查詢負載，
Q：StoneDB 有獨立的 Realtime API嗎？
**A: **暫時還沒有，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/502509.html
標籤：其他