我們又把近期的一些社區熱點問題做了一次匯總，同步給所有關注StoneDB的同學們~
提問Qustions & 解答Answers
Q：現在StoneDB單機什么硬體規格部署能分析100TB級別的資料？
A：像這么大的存盤量，系統一般是分析類的，存盤可以是單塊盤容量是7.6TB的SSD，CPU核數和主頻越高越好，
Q：StoneDB什么時候支持delete功能？
A：StoneDB預計在10月20號會發布StoneDB_5.7_V1.0.1版本，屆時會支持delete功能，目前只是暫時不支持，主要是為了優化性能，給用戶更好的使用體驗，
Q：當前StoneDB支持哪些客戶端管理軟體嗎？類似MySQL下的Navicat客戶端，
A：StoneDB支持Navicat、DBeaver、SQLyog等客戶端，同時對應標準的JDBC，ODBC等方式也是支持的，
Q：1、創建表時，可以選擇engine = innodb 或 tianmu 嗎？engine = innodb 的表會更新到 tianmu 去嗎？2、如果沒指定引擎，表默認引擎是什么？
A：1、StoneDB 支持在創建表時顯式指定表的存盤引擎型別，另外，StoneDB支持將engine=innodb的表自動更新到 engine=tianmu 的表中，在主從架構下，將主節點默認的存盤引擎設定為innodb，從節點默認的存盤引擎設定為tianmu，則資料在主從同步程序中自動完成行列轉換，
2、如果創建表沒有指定存盤引擎，表的存盤引擎取決于引數default_storage_engine的值，建議TP端的引數設定為default_storage_engine=innodb，AP端的引數設定為default_storage_engine=tianmu，
Q：一份資料在主節點可以同時 行存&列存，以兩種形態存放嗎？如果資料同時以兩種形態存放， 則任何資料修改需要維護兩個 copy , 如果只以一種形態存放， 那如何兼顧TP/AP 兩種業務操作?
A：現階段StoneDB HTAP是通過MySQL主從架構來實作的（這只是1.0的架構，未來在2.0的架構中會有完全不同的實作），采用binlog同步資料：主節點使用InnoDB引擎，可讀寫，提供OLTP場景的讀寫業務；從節點使用StoneDB引擎，只讀，OLAP查詢節點，實作了OLAP 的多種重要特性，滿足資料實時查詢及高并發復雜查詢場景，
Q：對于主節點是innodb,slave是stoneDB應對TP和AP的場景，,對目前你們不支持的DDL和DML，比如修改欄位長度、創建、洗掉索引、delete等這些你們是如何處理的,到slave會忽略？
A：遇到不支持的DDL和DML可以通過以下辦法解決，如果主從之間沒有開啟GTID模式，主庫在變更前可以關閉當前執行緒的binlog（set sql_log_bin=off），這樣就不會同步到從庫；如果主從之間開啟GTID模式，主庫在變更前可以設定GTID的值，從庫可以執行這個GTID值的空事務，
Q：因為MySQl適合OLTP場景下的事務處理，那每次進行新增、修改、洗掉，這部分資料是如何同步到StoneDB里的呢？因為StoneDB的限制，有些DDL不支持，比如修改欄位長度、型別、重命名欄位等，如果這部分在我們實際開發和應用中對MySQL進行了操作會影響MySQL和StoneDB之間的資料保持一致性嗎？
A：如果StoneDB為從庫，那么主庫做的DML會通過binlog同步到從庫，delete目前不支持，TP端可以用邏輯洗掉標記為這一行為洗掉狀態，例如新增一個欄位，這個欄位用于標識這一行是否是洗掉狀態，1表示洗掉，0表示未洗掉，這種方法在TP端使用update代替了delete，原生delete支持將在10月20號的StoneDB_5.7_v1.0.1版本中支持，詳細的可以看看我們的Roadmap，
Q：你們檔案中列舉的使用限制是針對存盤引擎是Tianmu的吧?
A：是的，檔案中列舉的使用限制是針對存盤引擎為Tianmu的情形，如果存盤引擎為 InnoDB ,與使用 MySQL 無任何差異，
Q：我們現在的業務資料表都是基于行式存盤引擎InnoDB創建的，如果要用StoneDB，這部分業務資料需要遷移？同步？需要用什么工具嗎？
A：
InnoDB遷移到StoneDB，常用的mysqldump，mysqldumper、gravity都可以支持，停機遷移可以考慮使用mysqldump 或者mydumper，可以參考
mysqldump：
https://stonedb.io/zh/docs/O&M-Guide/backup-and-recovery/use-mysqldump-backup-and-restore/
mydumper：
https://stonedb.io/zh/docs/O&M-Guide/backup-and-recovery/use-mydumper-full-backup
熱遷移StoneDB基本支持當前市面上MySQL熱遷移工具，例如Mydumper+otter(mysqldump也可以，mydumper支持多執行緒全量備份，大資料量建議使用mydumper多執行緒備份)，gravity等，
Mydumper+otter可以參考這個方案操作，從mydumper備份檔案 metadata 中找到binlog位點填入otter位點配置，就可以做到全量資料同步后進行增量資料同步，
mydumper 可以參考上面提供的鏈接，otter可以參考otter 專案檔案：https://github.com/alibaba/otter
gravity可以參考我們的官方檔案：https://stonedb.io/zh/docs/data-migration-to-stonedb/use-gravity-to-migrate
Q：集群方案是基于什么演算法？需要引入zk這樣的額外組件嗎？
A：目前集群采用的是HA架構，搭建和MySQL高可用架構一樣，再引入keepalive或者ProxySQL之類的流量分攤組件即可，不需要使用zk組件，
Q：我們現在業務系統通過JAVA生態體系技術開發，如果用InnoDB的話，我們現有持久層對MySQL的操作需要進行哪些改造？
A：無需改造，
Q：關于檢索的需求，目前的資料量使用MySQL不能很好的支持全文檢索，我們了解到其他友商的解決方案也是要配合ES，StoneDB的介紹上有寫可以取代ES集群支持檢索業務，這塊StoneDB的能力大概是怎樣的？
A：目前StoneDB在行存引擎支持了全文檢索，列存引擎尚未支持，如果有任何一位用戶提供給我們對全文檢索的具體需求和使用場景做詳細描述，我們會派相關技術人員展開深入交流，共同探討解決方案，
Q：1、將來有沒有可能支持CEP？2、支持prewhere這樣的功能么？3、支持物化視圖么？4、是個單機資料庫么？
A：1、會支持CEP的，
2、不支持prewhere，
3、不支持物化視圖，MySQL也不支持物化視圖，理論上可以結合觸發器達到物化視圖的功能，
4、目前是單機，將來會實作集群，
Q：StoneDB知識節點（KN）里存盤的是什么資料？知識節點和元資料節點有啥不同呢？
基本的元資料（如列定義，約束條件等），資料特征及更深度的資料統計資訊（如記錄值范圍段的標識BitMap， 統計當前Column中各記錄的值分布資訊等），
A：資料元資訊節點和資料節點是一一對應的，記錄對應資料塊中聚合函式值（min,max, sum,avg ...)，record count，null 記錄標記等資訊，
Q：1、假設我在TP中創建了一個表testA，并指明engine=innodb，在進行一些業務寫入操作后，這張表是否會同步到AP中？（相當于在TP中的表在AP中也有一份）2、如果我要對testA進行分析，是不是需要等TP同步之后才能進行分析？
A：如果在TP端創建表時指定了存盤引擎engine=innodb，那么這張表會同步到AP端，但在AP端它的存盤引擎還是innodb，
如果繼續對這張表做analyze操作，不需要等AP端同步完，在TP端的analyze也會同步到AP端，但因為這張表在AP端還是innodb引擎，所以就沒有Tianmu存盤引擎的特性，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/502609.html
標籤：MySQL
上一篇：DECIMAL 資料處理原理淺析