MatrixOne Meetup回顾 | 深圳站

活动开场，矩阵起源产品总监邓楠为大家讲解了云原生时代下的新一代数据趋势。邓楠指出，在应用层，当前 K8S 与容器的统一平台已成为必然趋势。而在数据层 K8S+S3+Serverless 正在成为数据架构的新范式，数据处理需求也正在向统一融合和多模发展，大模型工具链与数据处理能力也更紧密地进行结合。在新的技术发展趋势下，用户需要一个什么样的数据库呢？在邓楠看来，目前用户需要的是能够进行极简数据开发的、云原生 Serverless 化的、超融合 All-in-One 的数据库，而 MatrixOne 正是顺应时代发展、满足用户需求的此类产品。

随后，矩阵起源产品资深云原生研发工程师吴叶磊对 MatrixOne 如何基于 K8S 和 S3 构建 HTAP 数据库进行了阐述，说明了 MatrixOne 是怎么实现 Serverless 与超融合能力的。他从技术人员角度出发，全方位讲解了 MatrixOne 云计算资源、存储系统、各层架构的设计理念。表达了当前数据库上云已经不再新鲜，但充分发挥云的潜力需要面向云的设计。而 K8S 的统一 API，让云无处不在。当前应用云原生已经成熟，数据系统也不再例外。

在短暂的茶歇后，矩阵起源产品经理李松，分享了 MatrixOne 应用场景与 Demo 演示，展示了 MatrixOne 和 MatrixOne Cloud 目前的研发成果。；李松展示了车联网场景下 MatrixOne 应用 Demo 与弹性扩缩容相关 Demo。MatrixOne Cloud 具有按 SQL 计费的极高性价比与资源隔离的能力，并在资源隔离的基础上实现了弹性扩缩容的灵活扩展。李松指出，MatrixOne 当前在 HTAP、SaaS 和时序+实时数仓场景中，能够有效优化用户使用数据库的痛点，为用户带来高性能与高性价比的极致体验，帮助用户降本增效。

最后，此次 Meetup 邀请了来自深圳素问智能的创始人王巍，以妙趣横生的土耳其、达特茅斯、大预言模型和产业链+大模型的四个故事，循序渐进、由浅入深地讲述了目前产业大数据中的大模型应用。

MatrixOne Cloud 是否达到业内安全标准；产品的安全隔离是怎么做的？

MatrixOne Cloud 设计上达到业内安全标准，各类第三方认证正在进行中。安全隔离上，MO Cloud 借助云供应商的存储加密确保数据 encryption at rest, 并考虑未来支持不同租户使用自己的 key 加密数据，提供更高的安全隔离性。

如果大量写的时候开启了某个事务，是否会造成很多中间状态，造成冲突，导致被压垮，其他用户写不进去？

MatrixOne 做 Snapshot Read，对于每个事务 CN 只需要等待内存中的数据时间戳 > 事务时间戳就可以开始处理事务，中间状态都在 CN 本地的工作区，最后才向 TN commit，并不会压垮 TN 或 LogService。

Serverless 自动扩容会不会有 CN 冷启动的状态？

有，每个新的 CN 都需要将 SQL 要读的对象存储数据和 LogTail 数据加载到内存中之后才能进行计算，LogTail 数据量小，冷启动时间主要取决于需要读取多大的 S3 数据。要读取的数据越少（比如大部分数据命中了 CN 的 Local Cache）冷启动时间越短。

高并发备案，是否有溢出的告警？

瞬时的大量新增计算资源需求对于私有云而言很难即时满足，但可以通过公有云资源进行补充，这也是云边协同的场景之一。我们也提供了溢出告警。

社区版跟云上版有很大的区别吗？社区版能否热数据放到本地，冷数据放到S3？

社区版没有云平台的 Serverless 自动控制 CN 资源的能力，需要自己指定部署多少个多大的 CN；社区版可以热数据放到本地，冷数据放到 S3，只要本地和 S3 或其他对象存储有稳定的网络通信，就能在本地部署 MO 的同时使用云上的对象存储。

多租户隔离在云上会限制 CPU 或存储的使用吗?

对于计算资源，付费实例会使用独立的 CN 组，每个 CN 组中的单个 CN 实例会使用容器限制 CPU/Memory，而 CN 组的上限（近乎）无限扩展。存储没有限制，按空间付费。

多租户是共同计算节点吗？

策略可配置，以 MatrixOne Cloud 为例，不同付费实例之间（即使是同一个租户的）都会使用独立的计算节点（CN），免费实例会使用一组共享的计算节点（CN）。

一个节点会调动多个 Pod 吗？

目前策略是一个节点调度一个 MatrixOne Pod。

可以实时读取 MatrixOne 吗？CDC 的能力有吗？

MatrixOne 支持通过发布订阅功能实现实例间的数据实时共享；不过暂时还不支持将数据通过 CDC 的方式同步到下游。

现有的 query 扩容还是下一个 query 扩容？

MatrixOne Cloud Serverless 现在的自动扩容策略比较保守，系统会观察当前实例的资源使用状况决定扩容量，已满足后续的 query 需求。

一个 CN 会接入多个租户的 Connection 吗？

在 MatrixOne Cloud 上免费的实例会共享 CN Pod，但付费实例会独享一个 CN Group，这个付费实例的链接会被均衡的分摊到各个 CN Pod 上。

一个 CN 对应的 CPU 是一样的还是不一样的？

当前是一样的，相同的规格更容易维护和扩缩容。但我们也正在规划不同规格的 CN 用于业务在不同负载下的使用，做到精准和平滑。

CN 的个数和性能是线性的吗？网络是否要收费？

很难做到绝对的线性扩展，因为分布式系统会有数据交换的任务开销，不过从 MatrixOne 当前的测试效果来看，线性度还是挺高的；CN 之间的网络是不单独收费的，CU 的计费只会考虑对象存储的 I/O 请求。

最后再次感谢所有到场的嘉宾和朋友，期待 MatrixOne Meetup 北京站再会👋！

“

关于MatrixOrigin