共计 3062 个字符，预计需要花费 8 分钟才能阅读完成。
当然，目前 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: 临时还没有。
