什么数据库这么猛？5.6 版本刚开源一个半月，8.0 版本竟然就要启动了？| StoneDB 社区答疑第二期

2022 年 8 月 22 日
浙江
本文字数：3963 字
阅读完需：约 13 分钟

好吧，或许你觉得这是在标题党，但就是这么猛，你没想到吧，小编我也没想到。

这是真的，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 级别的数据？

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 存储引擎的特性。

好了，本期的社区答疑就到这里，希望对您有所帮助，如果您对 StoneDB 的整体架构走向比较感兴趣，也想知道在 StoneDB 团队是怎么理解真正的 HTAP 的，上周六下午我们联合白玉兰开源研究院，与几大知名开源数据库厂商合作了一场线上 Meetup，欢迎大家观看回顾：

最后，小编想说，我们走的是开源道路，我们期待有更多数据库行业的志士能人参与到 StoneDB 的开源社区里来，参与研发、运营和产品的建设工作，与我们共同见证一款伟大的 HTAP 数据库的诞生，要知道，这不单是为了做一款数据库产品而已，做任何一款产品的根本目的和最终使命都应该是为了解决实际的社会问题，对经济社会产生价值，而 StoneDB 的使命就是**让数百万对数据有分析需求的中小企业以最低的成本获得最佳的 AP 能力解决方案****——**我们相信，这个使命，值得追求，而 StoneDB 这个产品，也绝对承担得起。