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