好吧，或許你覺(jué)得這是在標(biāo)題黨，但就是這么猛，你沒(méi)想到吧，小編我也沒(méi)想到。

這是真的，8.0 is coming~

先說(shuō)一下標(biāo)題，StoneDB for MySQL在6月底開(kāi)源出來(lái)的，確實(shí)是5.6版本，但在開(kāi)源的同時(shí)，我們就同步開(kāi)啟了5.7版本的研發(fā)，并且發(fā)布了今年的版本計(jì)劃，5.7版本將在8月31號(hào)正式與大家見(jiàn)面，所以實(shí)際上現(xiàn)在5.7版本我們已經(jīng)完成的差不多了（而且是ALL in Github，如果您對(duì)我們的開(kāi)發(fā)進(jìn)展感興趣，可以隨時(shí)到Gihub倉(cāng)庫(kù)上查看我們的研發(fā)狀況），于是乎，在這個(gè)時(shí)間節(jié)點(diǎn)，我們決定啟動(dòng)8.0版本的開(kāi)發(fā)。

為什么？這樣做不著急么？

坦白講，對(duì)開(kāi)發(fā)來(lái)說(shuō)，是有一定挑戰(zhàn)的，但對(duì)大形勢(shì)來(lái)講，我們認(rèn)為，這個(gè)動(dòng)作是必須的。

我們?cè)谏弦黄诖鹨衫锞鸵呀?jīng)回答過(guò)了，無(wú)論是基于MySQL還是基于PostgreSQL，跟上Upstream的版本進(jìn)度一定是眾多做發(fā)行版廠商的基本素養(yǎng)，這個(gè)基本素養(yǎng)如果沒(méi)準(zhǔn)備好，我們也不會(huì)冒然挺進(jìn)。面對(duì)MySQL 8.0的快速上升趨勢(shì)的客觀事實(shí)，我們不可能坐視不管。

另外，值得一提的是，StoneDB的自研引擎從5.7版本開(kāi)始已經(jīng)正式改名為Tianmu了，這個(gè)名稱的討論我們也在Github上做了一次投票，每個(gè)備選名稱我們都說(shuō)明了理由：

當(dāng)然，其實(shí)也不會(huì)有社區(qū)以外的用戶關(guān)注這個(gè)，只是，公開(kāi)透明是我們做開(kāi)源社區(qū)的基本原則

好了，對(duì)標(biāo)題的解釋就到這里，如果你被小編忽悠看到了這里，不妨繼續(xù)看下去吧，下面是干貨時(shí)間，我們又把近期的一些社區(qū)熱點(diǎn)問(wèn)題做了一次匯總，同步給所有關(guān)注StoneDB的同學(xué)們~

提問(wèn)

Qustions

&

解答

Answers

Q

現(xiàn)在StoneDB單機(jī)什么硬件規(guī)格部署能分析100TB級(jí)別的數(shù)據(jù)？

A

像這么大的存儲(chǔ)量，系統(tǒng)一般是分析類的，存儲(chǔ)可以是單塊盤容量是7.6TB的SSD，CPU核數(shù)和主頻越高越好。

Q

StoneDB什么時(shí)候支持delete功能？

A

StoneDB預(yù)計(jì)在10月20號(hào)會(huì)發(fā)布StoneDB_5.7_V1.0.1版本，屆時(shí)會(huì)支持delete功能，目前只是暫時(shí)不支持，主要是為了優(yōu)化性能，給用戶更好的使用體驗(yàn)。

Q

當(dāng)前StoneDB支持哪些客戶端管理軟件嗎？類似MySQL下的Navicat客戶端。

A

StoneDB支持Navicat、DBeaver、SQLyog等客戶端，同時(shí)對(duì)應(yīng)標(biāo)準(zhǔn)的JDBC，ODBC等方式也是支持的。

Q

1、創(chuàng)建表時(shí)，可以選擇engine = innodb 或 tianmu 嗎？engine = innodb 的表會(huì)更新到 tianmu 去嗎？

2、如果沒(méi)指定引擎，表默認(rèn)引擎是什么？

A

1、StoneDB 支持在創(chuàng)建表時(shí)顯式指定表的存儲(chǔ)引擎類型。另外，StoneDB支持將engine=innodb的表自動(dòng)更新到 engine=tianmu 的表中，在主從架構(gòu)下，將主節(jié)點(diǎn)默認(rèn)的存儲(chǔ)引擎設(shè)置為innodb，從節(jié)點(diǎn)默認(rèn)的存儲(chǔ)引擎設(shè)置為tianmu，則數(shù)據(jù)在主從同步過(guò)程中自動(dòng)完成行列轉(zhuǎn)換。

2、如果創(chuàng)建表沒(méi)有指定存儲(chǔ)引擎，表的存儲(chǔ)引擎取決于參數(shù)default_storage_engine的值。建議TP端的參數(shù)設(shè)置為default_storage_engine=innodb，AP端的參數(shù)設(shè)置為default_storage_engine=tianmu。

Q

一份數(shù)據(jù)在主節(jié)點(diǎn)可以同時(shí) 行存&列存，以兩種形態(tài)存放嗎？如果數(shù)據(jù)同時(shí)以兩種形態(tài)存放， 則任何數(shù)據(jù)修改需要維護(hù)兩個(gè) copy , ?如果只以一種形態(tài)存放， 那如何兼顧TP/AP 兩種業(yè)務(wù)操作?

A

現(xiàn)階段StoneDB HTAP是通過(guò)MySQL主從架構(gòu)來(lái)實(shí)現(xiàn)的（這只是1.0的架構(gòu)，未來(lái)在2.0的架構(gòu)中會(huì)有完全不同的實(shí)現(xiàn)），采用binlog同步數(shù)據(jù)：主節(jié)點(diǎn)使用InnoDB引擎，可讀寫，提供OLTP場(chǎng)景的讀寫業(yè)務(wù)；從節(jié)點(diǎn)使用StoneDB引擎，只讀，OLAP查詢節(jié)點(diǎn)，實(shí)現(xiàn)了OLAP 的多種重要特性，滿足數(shù)據(jù)實(shí)時(shí)查詢及高并發(fā)復(fù)雜查詢場(chǎng)景。

Q

對(duì)于主節(jié)點(diǎn)是innodb,slave是stoneDB應(yīng)對(duì)TP和AP的場(chǎng)景，,對(duì)目前你們不支持的DDL和DML，比如修改字段長(zhǎng)度、創(chuàng)建、刪除索引、delete等這些你們是如何處理的,到slave會(huì)忽略？

A

遇到不支持的DDL和DML可以通過(guò)以下辦法解決。如果主從之間沒(méi)有開(kāi)啟GTID模式，主庫(kù)在變更前可以關(guān)閉當(dāng)前線程的binlog（set sql_log_bin=off），這樣就不會(huì)同步到從庫(kù)；如果主從之間開(kāi)啟GTID模式，主庫(kù)在變更前可以設(shè)置GTID的值，從庫(kù)可以執(zhí)行這個(gè)GTID值的空事務(wù)。

Q

因?yàn)镸ySQl適合OLTP場(chǎng)景下的事務(wù)處理，那每次進(jìn)行新增、修改、刪除，這部分?jǐn)?shù)據(jù)是如何同步到StoneDB里的呢？

因?yàn)镾toneDB的限制，有些DDL不支持，比如修改字段長(zhǎng)度、類型、重命名字段等，如果這部分在我們實(shí)際開(kāi)發(fā)和應(yīng)用中對(duì)MySQL進(jìn)行了操作會(huì)影響MySQL和StoneDB之間的數(shù)據(jù)保持一致性嗎？

A

如果StoneDB為從庫(kù)，那么主庫(kù)做的DML會(huì)通過(guò)binlog同步到從庫(kù)，delete目前不支持，TP端可以用邏輯刪除標(biāo)記為這一行為刪除狀態(tài)。例如新增一個(gè)字段，這個(gè)字段用于標(biāo)識(shí)這一行是否是刪除狀態(tài)，1表示刪除，0表示未刪除，這種方法在TP端使用update代替了delete。原生delete支持將在10月20號(hào)的StoneDB_5.7_v1.0.1版本中支持，詳細(xì)的可以看看我們的Roadmap。

Q

你們文檔中列舉的使用限制是針對(duì)存儲(chǔ)引擎是Tianmu的吧?

A

是的，文檔中列舉的使用限制是針對(duì)存儲(chǔ)引擎為Tianmu的情形，如果存儲(chǔ)引擎為 InnoDB ,與使用 MySQL 無(wú)任何差異。

Q

我們現(xiàn)在的業(yè)務(wù)數(shù)據(jù)表都是基于行式存儲(chǔ)引擎InnoDB創(chuàng)建的，如果要用StoneDB，這部分業(yè)務(wù)數(shù)據(jù)需要遷移？同步？需要用什么工具嗎？

A

InnoDB遷移到StoneDB，常用的mysqldump，mysqldumper、gravity都可以支持。停機(jī)遷移可以考慮使用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基本支持當(dāng)前市面上MySQL熱遷移工具，例如Mydumper+otter(mysqldump也可以，mydumper支持多線程全量備份，大數(shù)據(jù)量建議使用mydumper多線程備份)，gravity等。

Mydumper+otter可以參考這個(gè)方案操作，從mydumper備份文件 metadata 中找到binlog位點(diǎn)填入otter位點(diǎn)配置，就可以做到全量數(shù)據(jù)同步后進(jìn)行增量數(shù)據(jù)同步，

mydumper 可以參考上面提供的鏈接，otter可以參考o(jì)tter 項(xiàng)目文檔：https://github.com/alibaba/otter

gravity可以參考我們的官方文檔：https://stonedb.io/zh/docs/data-migration-to-stonedb/use-gravity-to-migrate

Q

集群方案是基于什么算法？需要引入zk這樣的額外組件嗎

A

目前集群采用的是HA架構(gòu)，搭建和MySQL高可用架構(gòu)一樣，再引入keepalive或者ProxySQL之類的流量分?jǐn)偨M件即可，不需要使用zk組件。

Q

1、我們現(xiàn)在業(yè)務(wù)系統(tǒng)通過(guò)JAVA生態(tài)體系技術(shù)開(kāi)發(fā)，如果用InnoDB的話，我們現(xiàn)有持久層對(duì)MySQL的操作需要進(jìn)行哪些改造？

A

無(wú)需改造。

Q

關(guān)于檢索的需求，目前的數(shù)據(jù)量使用MySQL不能很好的支持全文檢索，我們了解到其他友商的解決方案也是要配合ES。StoneDB的介紹上有寫可以取代ES集群支持檢索業(yè)務(wù)，這塊StoneDB的能力大概是怎樣的？

A

目前StoneDB在行存引擎支持了全文檢索，列存引擎尚未支持。如果有任何一位用戶提供給我們對(duì)全文檢索的具體需求和使用場(chǎng)景做詳細(xì)描述，我們會(huì)派相關(guān)技術(shù)人員展開(kāi)深入交流，共同探討解決方案。

Q

1、將來(lái)有沒(méi)有可能支持CEP？

2、支持prewhere這樣的功能么？

3、支持物化視圖么？

4、是個(gè)單機(jī)數(shù)據(jù)庫(kù)么？

A

1、會(huì)支持CEP的。

2、不支持prewhere。

3、不支持物化視圖，MySQL也不支持物化視圖，理論上可以結(jié)合觸發(fā)器達(dá)到物化視圖的功能。

4、目前是單機(jī)，將來(lái)會(huì)實(shí)現(xiàn)集群。

Q

StoneDB知識(shí)節(jié)點(diǎn)（KN）里存儲(chǔ)的是什么數(shù)據(jù)？

知識(shí)節(jié)點(diǎn)和元數(shù)據(jù)節(jié)點(diǎn)有啥不同呢？

A

基本的元數(shù)據(jù)（如列定義，約束條件等），數(shù)據(jù)特征及更深度的數(shù)據(jù)統(tǒng)計(jì)信息（如記錄值范圍段的標(biāo)識(shí)BitMap， 統(tǒng)計(jì)當(dāng)前Column中各記錄的值分布信息等）。

數(shù)據(jù)元信息節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)是一一對(duì)應(yīng)的，記錄對(duì)應(yīng)數(shù)據(jù)塊中聚合函數(shù)值（min,max, sum,avg ...)，record count，null 記錄標(biāo)記等信息。

Q

1、假設(shè)我在TP中創(chuàng)建了一個(gè)表testA，并指明engine=innodb，在進(jìn)行一些業(yè)務(wù)寫入操作后，這張表是否會(huì)同步到AP中？（相當(dāng)于在TP中的表在AP中也有一份）

2、如果我要對(duì)testA進(jìn)行分析，是不是需要等TP同步之后才能進(jìn)行分析？

A

如果在TP端創(chuàng)建表時(shí)指定了存儲(chǔ)引擎engine=innodb，那么這張表會(huì)同步到AP端，但在AP端它的存儲(chǔ)引擎還是innodb。

如果繼續(xù)對(duì)這張表做analyze操作，不需要等AP端同步完，在TP端的analyze也會(huì)同步到AP端。但因?yàn)檫@張表在AP端還是innodb引擎，所以就沒(méi)有Tianmu存儲(chǔ)引擎的特性。

好了，本期的社區(qū)答疑就到這里，希望對(duì)您有所幫助。

最后，小編想說(shuō)，我們走的是開(kāi)源道路，我們期待有更多數(shù)據(jù)庫(kù)行業(yè)的志士能人參與到StoneDB的開(kāi)源社區(qū)里來(lái)，參與研發(fā)、運(yùn)營(yíng)和產(chǎn)品的建設(shè)工作，與我們共同見(jiàn)證一款偉大的HTAP數(shù)據(jù)庫(kù)的誕生，要知道，這不單是為了做一款數(shù)據(jù)庫(kù)產(chǎn)品而已，做任何一款產(chǎn)品的根本目的和最終使命都應(yīng)該是為了解決實(shí)際的社會(huì)問(wèn)題，對(duì)經(jīng)濟(jì)社會(huì)產(chǎn)生價(jià)值，而StoneDB的使命就是讓數(shù)百萬(wàn)對(duì)數(shù)據(jù)有分析需求的中小企業(yè)以最低的成本獲得最佳的AP能力解決方案——我們相信，這個(gè)使命，值得追求，而StoneDB這個(gè)產(chǎn)品，也絕對(duì)承擔(dān)得起。

和優(yōu)秀的人，做有挑戰(zhàn)的事兒，更要做有價(jià)值的事兒，讓天下中小企業(yè)沒(méi)有難做的數(shù)據(jù)分析，StoneDB開(kāi)源社區(qū)，期待你的加入~