好吧，或许你觉得这是在标题党，但就是这么猛，你没想到吧，小编我也没想到。
这是真的，8.0 is coming~
先说一下标题，StoneDB for MySQL在6月底开源出来的，确实是5.6版本，但在开源的同时，我们就同步开启了5.7版本的研发，并且发布了今年的版本计划，5.7版本将在8月31号正式与大家见面，所以实际上现在5.7版本我们已经完成的差不多了（而且是ALL in Github，如果您对我们的开发进展感兴趣，可以随时到Gihub仓库上查看我们的研发状况），于是乎，在这个时间节点，我们决定启动8.0版本的开发。
为什么？这样做不着急么？
坦白讲，对开发来说，是有一定挑战的，但对大形势来讲，我们认为，这个动作是必须的。
我们在上一期答疑里就已经回答过了，无论是基于MySQL还是基于PostgreSQL，跟上Upstream的版本进度一定是众多做发行版厂商的基本素养，这个基本素养如果没准备好，我们也不会冒然挺进。面对MySQL 8.0的快速上升趋势的客观事实，我们不可能坐视不管。
另外，值得一提的是，StoneDB的自研引擎从5.7版本开始已经正式改名为Tianmu了，这个名称的讨论我们也在Github上做了一次投票，每个备选名称我们都说明了理由：
当然，其实也不会有社区以外的用户关注这个，只是，公开透明是我们做开源社区的基本原则
好了，对标题的解释就到这里，如果你被小编忽悠看到了这里，不妨继续看下去吧，下面是干货时间，我们又把近期的一些社区热点问题做了一次汇总，同步给所有关注StoneDB的同学们~
提问
Qustions
&
解答
Answers
Q
现在StoneDB单机什么硬件规格部署能分析100TB级别的数据？
像这么大的存储量，系统一般是分析类的，存储可以是单块盘容量是7.6TB的SSD，CPU核数和主频越高越好。
A
Q
StoneDB什么时候支持delete功能？
StoneDB预计在10月20号会发布StoneDB_5.7_V1.0.1版本，届时会支持delete功能，目前只是暂时不支持，主要是为了优化性能，给用户更好的使用体验。
A
Q
当前StoneDB支持哪些客户端管理软件吗？类似MySQL下的Navicat客户端。
StoneDB支持Navicat、DBeaver、SQLyog等客户端，同时对应标准的JDBC，ODBC等方式也是支持的。
A
Q
1、创建表时，可以选择engine = innodb 或 tianmu 吗？engine = innodb 的表会更新到 tianmu 去吗？
2、如果没指定引擎，表默认引擎是什么？
1、StoneDB 支持在创建表时显式指定表的存储引擎类型。另外，StoneDB支持将engine=innodb的表自动更新到 engine=tianmu 的表中，在主从架构下，将主节点默认的存储引擎设置为innodb，从节点默认的存储引擎设置为tianmu，则数据在主从同步过程中自动完成行列转换。
2、如果创建表没有指定存储引擎，表的存储引擎取决于参数default_storage_engine的值。建议TP端的参数设置为default_storage_engine=innodb，AP端的参数设置为default_storage_engine=tianmu。
A
Q
一份数据在主节点可以同时 行存&列存，以两种形态存放吗？如果数据同时以两种形态存放， 则任何数据修改需要维护两个 copy , 如果只以一种形态存放， 那如何兼顾TP/AP 两种业务操作?
现阶段StoneDB HTAP是通过MySQL主从架构来实现的（这只是1.0的架构，未来在2.0的架构中会有完全不同的实现），采用binlog同步数据：主节点使用InnoDB引擎，可读写，提供OLTP场景的读写业务；从节点使用StoneDB引擎，只读，OLAP查询节点，实现了OLAP 的多种重要特性，满足数据实时查询及高并发复杂查询场景。
A
Q
对于主节点是innodb,slave是stoneDB应对TP和AP的场景，,对目前你们不支持的DDL和DML，比如修改字段长度、创建、删除索引、delete等这些你们是如何处理的,到slave会忽略？
遇到不支持的DDL和DML可以通过以下办法解决。如果主从之间没有开启GTID模式，主库在变更前可以关闭当前线程的binlog（set sql_log_bin=off），这样就不会同步到从库；如果主从之间开启GTID模式，主库在变更前可以设置GTID的值，从库可以执行这个GTID值的空事务。
A
Q
因为MySQl适合OLTP场景下的事务处理，那每次进行新增、修改、删除，这部分数据是如何同步到StoneDB里的呢？
因为StoneDB的限制，有些DDL不支持，比如修改字段长度、类型、重命名字段等，如果这部分在我们实际开发和应用中对MySQL进行了操作会影响MySQL和StoneDB之间的数据保持一致性吗？
如果StoneDB为从库，那么主库做的DML会通过binlog同步到从库，delete目前不支持，TP端可以用逻辑删除标记为这一行为删除状态。例如新增一个字段，这个字段用于标识这一行是否是删除状态，1表示删除，0表示未删除，这种方法在TP端使用update代替了delete。原生delete支持将在10月20号的StoneDB_5.7_v1.0.1版本中支持，详细的可以看看我们的Roadmap。
A
Q
你们文档中列举的使用限制是针对存储引擎是Tianmu的吧?
是的，文档中列举的使用限制是针对存储引擎为Tianmu的情形，如果存储引擎为 InnoDB ,与使用 MySQL 无任何差异。
A
Q
我们现在的业务数据表都是基于行式存储引擎InnoDB创建的，如果要用StoneDB，这部分业务数据需要迁移？同步？需要用什么工具吗？
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
A
Q
集群方案是基于什么算法？需要引入zk这样的额外组件吗
目前集群采用的是HA架构，搭建和MySQL高可用架构一样，再引入keepalive或者ProxySQL之类的流量分摊组件即可，不需要使用zk组件。
A
Q
1、我们现在业务系统通过JAVA生态体系技术开发，如果用InnoDB的话，我们现有持久层对MySQL的操作需要进行哪些改造？
无需改造。
A
Q
关于检索的需求，目前的数据量使用MySQL不能很好的支持全文检索，我们了解到其他友商的解决方案也是要配合ES。StoneDB的介绍上有写可以取代ES集群支持检索业务，这块StoneDB的能力大概是怎样的？
目前StoneDB在行存引擎支持了全文检索，列存引擎尚未支持。如果有任何一位用户提供给我们对全文检索的具体需求和使用场景做详细描述，我们会派相关技术人员展开深入交流，共同探讨解决方案。
A
Q
1、将来有没有可能支持CEP？
2、支持prewhere这样的功能么？
3、支持物化视图么？
4、是个单机数据库么？
1、会支持CEP的。
2、不支持prewhere。
3、不支持物化视图，MySQL也不支持物化视图，理论上可以结合触发器达到物化视图的功能。
4、目前是单机，将来会实现集群。
A
Q
StoneDB知识节点（KN）里存储的是什么数据？
知识节点和元数据节点有啥不同呢？
基本的元数据（如列定义，约束条件等），数据特征及更深度的数据统计信息（如记录值范围段的标识BitMap， 统计当前Column中各记录的值分布信息等）。
数据元信息节点和数据节点是一一对应的，记录对应数据块中聚合函数值（min,max, sum,avg ...)，record count，null 记录标记等信息。
A
Q
1、假设我在TP中创建了一个表testA，并指明engine=innodb，在进行一些业务写入操作后，这张表是否会同步到AP中？（相当于在TP中的表在AP中也有一份）
2、如果我要对testA进行分析，是不是需要等TP同步之后才能进行分析？
如果在TP端创建表时指定了存储引擎engine=innodb，那么这张表会同步到AP端，但在AP端它的存储引擎还是innodb。
如果继续对这张表做analyze操作，不需要等AP端同步完，在TP端的analyze也会同步到AP端。但因为这张表在AP端还是innodb引擎，所以就没有Tianmu存储引擎的特性。
A
好了，本期的社区答疑就到这里，希望对您有所帮助，如果您对StoneDB的整体架构走向比较感兴趣，也想知道在StoneDB团队是怎么理解真正的HTAP的，本周六下午我们联合白玉兰开源研究院，与几大知名开源数据库厂商合作了一场线上Meetup，欢迎大家预约观看：
最后，小编想说，我们走的是开源道路，我们期待有更多数据库行业的志士能人参与到StoneDB的开源社区里来，参与研发、运营和产品的建设工作，与我们共同见证一款伟大的HTAP数据库的诞生，要知道，这不单是为了做一款数据库产品而已，做任何一款产品的根本目的和最终使命都应该是为了解决实际的社会问题，对经济社会产生价值，而StoneDB的使命就是让数百万对数据有分析需求的中小企业以最低的成本获得最佳的AP能力解决方案——我们相信，这个使命，值得追求，而StoneDB这个产品，也绝对承担得起。
和优秀的人，做有挑战的事儿，更要做有价值的事儿，让天下中小企业没有难做的数据分析，StoneDB开源社区，期待你的加入~
StoneDB 已经正式开源，欢迎关注我们
https://github.com/stoneatom/stonedb