1. 参考一楼回复，详细可以回看直播 2. 使用openGemini产品时，可以提供相关培训和技术支持，前提是加入社区，成为社区的共建伙伴 3. openGemini后续会在可观测性和IoT领域发力。和AI结合的场景，可以有，希望可以和伙伴一起孵化该能力。

1. 跨地域复制和同步还没有解决方案，目前可以使用数据订阅来做。openGemini不支持地理空间查询 2. 参考3楼回复 3. openGemini生命周期管理主要有Retention Policy来决定的。预聚合数据更新是在写入和compaction时候完成的 4. 业务该怎么查就怎么查，剩下的交给数据库就可以了。 5. 多表的数据隔离是物理隔离，每个表都有单独的数据目录。不支持数据联邦查询和异构数据集查询。

通常是一边写入一边做预聚合计算，另外就是在Compaction时做

1. 技术方面，业务需求日新月异，需要不断提高产品技术创新和成熟度。 2. 生态建设任重道远，需要鼓励不同厂商、开发者和用户之间的合作，共同推动分布式数据库技术的发展和应用。 3. 行业应用方面，需要进行大量的业务改造和系统集成工作。这不仅涉及到技术层面的挑战，还包括对现有业务流程的理解和重构。

同4楼

openGemini有两种技术方案来保证数据一致性。一是通过计算副本，数据存多份。另一种是采用存算分离架构，数据一致性交给底层的分布式文件系统来保证。目前二者都在开发者。考虑到这种长周期数据存储的成本，openGemini未来还将考虑支持对象存储，以降低存储成本。

1. openGemini在大规模数据集上，首先是相同时间线数据是存放在一起，避免了多次分散查询。其次，数据按时间分区，根据查询给定的时间范围就可以确定数据所在的分区，从时间上可以进一步过滤不必要的数据集。第三，检视相关时间线数据时，使用了布隆过滤器，能快速判断文件是否包含对应时间线的数据。最后，数据批量读取，向量化方式计算，加速计算速度。 2. openGemini在数据隐私和安全方面的保护措施有：支持用户验证和授权机制，支持https数据加密传输，支持证书过期检测，支持弱密码检测，用户密码加密存储等。

openGemini集群支持组件独立水平扩展，理论上支持100+节点没问题，目前openGemini在实际应用中搭建的集群规模有70个节点。

问题1和2，我集中回复您，首先，搭建好openGemini的监控面板；其次，开始压测，根据监控指标确定性能瓶颈，比如写时延比较大，可以看看WAL写时延是否也很大，如果WAL时延比较大，则可以给WAL目录分配独立的磁盘。这些都在我的直播中有讲到。 总的来说，性能调优是一个循环过程，解决了一个性能瓶颈，压力可能给到了另一个地方，需要继续解决，直到满足要求为止。 关于问题3 如何平衡读写性能，主要看业务的容忍程序和硬件成本了，比如有的业务对写要求很高，必须在规定时间内要完成，但是查询可以接收秒级的响应，这时就可以把资源多分配给写流程，比如说内存、磁盘带宽。如果是读写要求都很高，那最好是做纵向扩展，升级机器规格，使用大内存和高性能磁盘等。

您好，我叫向宇，主要负责openGemini开源社区相关工作，包括合作，技术支持等。我来回答您这个问题。 部署openGemini，规划集群时，主要考虑三个因素： 1. 时间线规模（不是点位），比如 region=“shanghai”，service=“mysql” cpu=0.4，mem=0.6，这是一条时间线，带两个点位数据。时间线规模对应节点规格参考：https://docs.opengemini.org/zh/guide/reference/specification.html 2. 大致确定了规格之后，接下来要确定集群需要几台服务器，openGemini集群推荐最小规模是3个节点，部署ts-meta(3x),ts-sql(1-3x),ts-store(2-3)。具体组件数量，需要根据业务负载来看。最终选择几台服务器，要结合写入和查询来看，目前单节点（32U128G）可以30万时间线，一条数据包含10个标签和10个点位数据这种数据模型，写入性能是近40万条/秒，换算成点位是400万点位/s，如果业务数据负载是1000万点位/s，可以简单计算 3*400*0.8 = 960万点位/s，也就差不多3-4台服务器即可满足。 3. 再看查询场景，如果有分组聚合查询的场景，且分组数量偏大，比如一次查询产生几十万甚至上百万个分组，那么建议cpu和内存规格要大一点。 什么场景下内存需要配置高一些？ 我的建议是 a. 复杂查询比较多的场景，比如分组聚合，大量分组数据都将缓存在内存做计算（ts-store的内存要大一些）。 b. 要做降采样，包括流式降采样，以及历史数据降采样（流式降采样，ts-sql内存大一些） c. 要使用数据订阅功能（ts-sql内存要求大一些） d. ts-meta主要用于元数据管理，一般4U8G基本够用。