咱们又把近期的一些社区热点问题做了一次汇总，同步给所有关注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存储引擎的个性。