当然，目前 StoneDB 的社区建设还正处于初启阶段，我们坚信，开源项目的成长，最终还是要靠社区用户一起来共创，因此，StoneDB 开源社区非常重视社区用户的声音，在 7 月份，我们从各个渠道里收集到了用户的反馈，这里做一个汇总，同步给各位关注 StoneDB 的开发者们，无论您是在校学生还是公司后端研发人员，亦或是某数据库厂商的研发人员，相信本期的社区解答会让您对 StoneDB 有一个更深入的了解。

Q：StoneDB 是基于 MySQL 做的怎么还能叫自主可控呢？你们后面能跟上 MySQL 的生态么？

A: 我们还是要区分“自主”、“可控”、“原创”三个词的准确含义，这样能更好地理解 StoneDB 的数据库定位。我们基于 MySQL 的根本原因，是因为目前 MySQL 客户装机量足够多（截至 2022 年它在整个数据库行业的市场占有率达到了 43.04%，来源：Slintel网站），而使用 MySQL 的客户对 AP 能力的需求也在不断增长，我们要做的是一个具有庞大增量的市场，而不是就只盯着 MySQL 生态玩了，不要误会我们只能做 MySQL，以我们对一体化 HTAP的理解，基于 PostgreSQL 再做一套也是可以的，所以现在的 StoneDB 准确的说法是叫 StoneDB for MySQL。很多人现在被一些极端情绪所影响了，并没有客观的看待“原创”这个事儿，开源世界里，“原创”从来不是最重要的，如果有谁觉得自己做得更好就是可以 Fork 出去做他自己的分支版本，且不说现在有多少优秀的数据库是基于 MySQL 和 PG 做的，很多优秀的操作系统也是基于开源的 Linux 做发行版的，这个无论国内国外，都很常见，也无可厚非。说到底，一个开源项目到底能不能把控研发方向、解决实际落地问题、对用户有没有实用价值才是最重要的。而且，我们用了 MySQL 就大大方方承认，不藏着掖着，也绝对不是简单的拿来主义，稍微优化魔改一下就放出去的。我们底层确实用了 MySQL 社区版的代码，但是我们的自主原创的代码量也足够庞大，为了提高综合性能，我们还对原本的 MySQL 社区版源码进行了大量的修改和优化。必须强调的是，我们的 HTAP 内核引擎Tianmu（中文名：天目）完全自主研发，经过了足够时间的测试和打磨，才开源出来给大家使用，这才是我们强调的自主性。

另外，我们内核研发团队对 MySQL 的各个版本代码的熟悉程度一点儿也不亚于 MySQL 原厂团队，我们有超过 10 年内核研发经验的数据库老兵，有超过七年近 200 万行内核代码的积累，更重要的是，我们对 MySQL 和 HTAP 的理解不单是从工业界上的应用实践，还有学术上的深刻认知，我们对数据库学术界的最新理论保持高度的关注，基本上所有经典的 HTAP 学术论文、国际顶会和期刊，从原始概念的提出到目前最新的研究进展，我们的架构师都深入研究过并从中选择最优可实现的方案落地到我们 StoneDB 的内核设计上——可以说，工业界的丰富实践和学术上的与时俱进就是我们可控性的来源。

现在我们是在做 5.6 和 5.7 的版本，8.0 也在计划中，不用担心我们跟不上，发行版跟上 Upstream 是我们的基本素养。只不过，我们要做的，是连 Oracle 自己都舍不得开源的发行版，这才叫真的玩开源，我们不是那种随便魔改一下开源项目就拿出来说自己自主创新了，我们的自主创新是实实在在的，是会对全球几百万依赖 MySQL 生态且有 AP 需求的中小企业产生巨大实用价值的。当然，未来我们还会有云原生架构，这都是必须会有的，数据库上云是大势所趋，我们只会顺势而为。可以明确的是，一个成熟的、真正的 HTAP 数据库应该有的功能和架构，StoneDB 都会有。

Q：StoneDB 和 TiDB 比怎么样？对硬件条件要求高吗？最早了解的是 TiDB，对外也称 HTAP 数据库，但是生产要求固态硬盘，带宽万兆，普通机械硬盘性能很差。

**A: **StoneDB 与 TiDB 采用了完全不同的技术架构，TiDB 使用松耦合系统架构，StoneDB 采用单系统双引擎架构，单系统架构集成性更高，实时性更强，对用户更加友好，用户完全无需关注和维护类似 Tikv/Tiflash/TiDB 这么多的底层组件。

从硬件要求方面，单系统架构所需的硬件更少、要求也更低，TiDB 最少需要 3~5 个节点才能完成最小化部署，StoneDB 仅需单节点即可，不像 TiDB 那样对硬件配置有严苛要求，在正常情况下采用“与运行MySQL 相同的硬件配置”就可以感受到 StoneDB 飞一般的性能体验，当然配置越高，性能越好。除此以外StoneDB是完全兼容MySQL的（准确的说，我们不需要 Compatible，因为我们就是 Native），可实现对 MySQL 的无缝切换，业务侧无需做一行代码修改。

另外，TiDB 的开源社区做的确实不错，值得我们学习，不过我们从技术理念上一直不太认可 TiDB 属于 HTAP，他们并不符合真正的 HTAP 数据库定义，还是有一定距离的，或许叫分布式数据库是对的。当然，想必他们也知道自己不是真正的 HTAP，因为他们肯定也对 HTAP 的定义有过研究，只不过可能当年做底层架构时工程实现上没有很好的思路，觉得一体化的路线实现太难了，才做了这么一个杂糅架构的伪HTAP数据库出来。我们知道现在出来打破一些人的认知还是要耗费些精力的，毕竟让他们意识到在国内最早推广 HTAP 概念的团队自己做的却是不符合真实 HTAP 定义的数据库，多少会有些打击到他们，也希望相关同学可以看看我们对真正 HTAP 标准的思考。

Q：StoneDB 比 StarRocks 有哪些优势？

**A: **StoneDB 与 StarRocks 产品定位不同，StarRocks 定位 OLAP 数据仓库，进行数据分析时需要从 TP 类数据库通过 ETL 导入数据。StoneDB 定位 HTAP 数据库，可以同时支持 OLTP 和 OLAP 。如果非要一较高下的话，那就是 StarRocks 不支持 OLTP。

Q：StoneDB 性能比 MySQL 如何？

**A: **在 TP 能力方面，StoneDB 目前与 MySQL 持平。在 AP 能力方面，StoneDB 最高可实现 100 倍性能的提升，StoneDB 产品设计的初衷就是解决 MySQL 本身不具备分析能力的问题。

Q：StoneDB 支持 MySQL8.0 的新特性吗？

**A: **StoneDB V2.0会支持 MySQL8.0 的新特性，新版本的具体时间以社区正式发文为准。

Q：StoneDB 向量化是后面的工作吗？

**A: **是的，向量化相关内容规划在后续 Roadmap，具体时间以官方正式发布为准。

Q：StoneDB 支持 K8S 部署不？

**A: **支持，但是在生产环境不建议采用 K8S 部署方式。K8S 其他服务会抢占磁盘 IO，带来性能下降。

Q：大多数列式存储数据库对多表 join 不支持，或者性能差得很，StoneDB 对多表 join 支持如何？

A: StoneDB 是行列混合架构，不是单纯的列式存储。StoneDB 支持多表关联，其优化器采用了知识网格技术，在进行多表关联时，两个列之间的等值映射关系会被自动创建。

Q：StoneDB 只开源单机版吗？集群版本开源吗？

**A: **StoneDB集群版仍在开发过程中，开发完成后会进行开源，具体时间以官方正式发布为准。

Q：如何在进行不确定的 OLAP 的查询情况下，保证 OLTP 的稳定性？业务数据库最基本增删改还是不能出问题的。

**A: **我们推荐使用主从架构：主节点使用 InnoDB 引擎，可读写，支持 OLTP 业务负载；从节点使用 StoneDB 引擎，只读，支持 OLAP 查询负载。

Q：StoneDB 有独立的 Realtime API吗？

**A: **暂时还没有。