【DTSE Tech Talk 精选问答】NO.59丨从数据库设计到性能调优，全面掌握openGemini应用开发最佳实践
【摘要】 数据库是一个复杂的系统，如何用好它，让它在实际应用中充分发挥其作用，这对我们每个开发者来说都至关重要。本期直播将围绕openGemini的应用开发流程，并结合具体案例，详细介绍数据库设计、数据写入、数据查询等场景下的最佳实践，共同探索数据库的奥秘！
数据库是一个复杂的系统，如何用好它，让它在实际应用中充分发挥其作用，这对我们每个开发者来说都至关重要。本期直播将围绕openGemini的应用开发流程，并结合具体案例，详细介绍数据库设计、数据写入、数据查询等场景下的最佳实践，共同探索数据库的奥秘！
直播链接：https://bbs.huaweicloud.cn/live/DTT_live/202405291630.html
Q：openGemini如何处理大量并发查询请求？
A:如果大量并发请求是突发的，那么openGemini会采取流控措施，甚至会killQuery，确保系统稳定。如果是设计阶段已知的并发请求，则可以通过横向扩展ts-store，分摊计算压力。另外，处理并发查询请求和客户端的查询场景有关，如果是单设备查询，可以使用hint查询。Q：在遇到性能瓶颈时，OpenGemini提供了哪些诊断工具和日志分析手段帮助开发者定位问题？
A:pprof抓取内核的火焰图，还有就是通过openGemini的监控面板帮助分析。Q：openGemini是否可以支持数据的跨地域复制和同步？
A:跨地域复制和同步可以借助openGemini的数据订阅和数据导出功能。Q：有哪些工具或框架推荐用于OpenGemini的性能测试？
A:tsbs，JmeterQ：能否通过OpenGemini直接实现对数据质量的监控，比如检测数据缺失或异常波动？
A:异常波动可以通过openGemini的监控实现，数据缺失没办法。Q：openGemini数据库如何保证数据的一致性？openGemini有两种技术方案来保证数据一致性。一是通过计算副本，数据存多份。另一种是采用存算分离架构，数据一致性交给底层的分布式文件系统来保证。目前二者都在开发者。
A:openGemini有两种技术方案来保证数据一致性。一是通过计算副本，数据存多份。另一种是采用存算分离架构，数据一致性交给底层的分布式文件系统来保证。目前二者都在开发者。Q：openGemini数据库在预聚合方面的技术如何实现查询加速？
A:采用了预聚合、算子下推、向量化等技术实现查询加速。Q：OpenGemini内置了哪些监控和报警机制？
A:openGemini内置了260余项监控指标，但没有内置告警机制。告警需要借助第三方工具，根据openGemini的监控指标来做。Q：如何使用索引来提高数据库查询性能？有哪些常见的索引优化策略？
A:openGemini在时间线数量不大的情况下，通过倒排索引快速过滤不相关的时间线，并使用布隆过滤器快速过滤不相关的数据文件，以此加速查询。时间线非常大的情况下，建议是用高基数存储引擎，借助稀疏索引加速查询。索引优化方面，主要提供了索引缓存，另外openGemini的索引使用mergeset数据结构，读写性能更高。高基数存储引擎的索引优化，主要是让低基数字段排在前面，高基数字段排后面。Q：openGemini在大规模数据集上如何保证查询响应时间？
A:openGemini在大规模数据集上，首先是相同时间线数据是存放在一起，避免了多次分散查询。其次，数据按时间分区，根据查询给定的时间范围就可以确定数据所在的分区，从时间上可以进一步过滤不必要的数据集。第三，检视相关时间线数据时，使用了布隆过滤器，能快速判断文件是否包含对应时间线的数据。最后，数据批量读取，向量化方式计算，加速计算速度。Q：openGemini数据库在性能优化方面有哪些关键技术和策略？
A:多值模型、LSM存储引擎、时序优化的数据格式、数据压缩技术、向量化等关键技术。Q：分布式数据库服务化（DDS）在生态建设和行业应用方面存在哪些挑战？
A:- 技术方面，业务需求日新月异，需要不断提高产品技术创新和成熟度。
- 生态建设任重道远，需要鼓励不同厂商、开发者和用户之间的合作，共同推动分布式数据库技术的发展和应用。
- 行业应用方面，需要进行大量的业务改造和系统集成工作。这不仅涉及到技术层面的挑战，还包括对现有业务流程的理解和重构。
Q：对于遵守GDPR或其他数据保护法规的企业，OpenGemini提供了哪些特性来帮助达到合规要求？
A:根据GDPR，企业需要确保数据处理的合法性、透明性、目的限制、数据最小化、准确性、存储限制、完整性和保密性、账户转移权以及数据主体的权利等。openGemini提供了访问控制和审计日志功能。
Q：在数据生命周期管理上，OpenGemini提供了哪些工具或策略来实现数据的归档、清理或过期删除？如何自动化此过程以减轻运维负担？
A:openGemini提供了数据过期策略配置，可确保数据到期自动删除。数据归档不支持。Q：openGemini有哪些技术来尽可能减少OOM的概率？有哪些我们客户层面可以感知的对内存控制和优化的手段呢？
A:openGemini会实时检测查询对内存的消耗，超过90%就会kill终止查询请求，这个功能可以配置。客户层面能感知的对内存控制和优化的手段有：对查询的时间线规模做限制，这方面内核有配置。Q：在相对有限的时间线数量下，openGemini如何提供极致的写入与查询性能？
A:批量写入+WAL独立磁盘+加大写缓存 + 高性能磁盘 + 增加下盘带宽。查询方面就是打开索引缓存即可。Q：如何减少open Gemini查询过程中的磁盘读取和数据解码开销？
A:内核自动完成，对客户层面透明。Q：openGemini如何处理预聚合数据的更新和过期问题？
A:预聚合数据的更新，是由数据写入触发更新操作的。Q：对于涉及大量数据的聚合查询，OpenGemini有没有提供缓存机制或预计算功能来加速查询过程？如何有效利用这些特性？
A:部分聚合函数是有预聚合Q：openGemini如何保证数据的容灾和高可用性？
A:通过数据副本保证Q：如何将已有的数据库的数据迁移到openGemini呢？官方提供了什么解决方案呢？
A:如果是InfluxDB数据库迁移openGemini，社区有提供相关的工具。Q：随着数据量的增长，openGemini如何平滑地对OpenGemini的库和表进行扩展？有哪些自动化或手动的扩展策略？
A:创建新表，或者新库、新数据写新表和库，历史数据做迁移。Q：如何识别openGemini的性能瓶颈？如何配置openGemini的参数达到最佳性能？
A:性能瓶颈要看监控面板，配置上没有确切的参数，需要参考监控面板逐步调整。Q：openGemini有哪些监控工具推荐吗？
A:推荐ts-monitor + GrafanaQ：针对事务处理，OpenGemini有哪些机制保证数据一致性的同时，还能保持较高的写入效率？如何合理使用事务来优化性能？
A:openGemini没有事务，事务并不适合时序场景。Q：OpenGemini是否提供了数据压缩功能？如何在客户端层面启用数据压缩来减少网络传输负担？
A:openGemini支持数据压缩。客户端层面可以通过GzipEnabled配置参数启用客户端数据压缩传输。Q：现在物联网场景，很多工业场景下的数据保存周期都要求保存3年或者5年以上，请问openGemini有没有方案来保证数据的可靠性？以及如何降低这种长周期存储的成本呢？
A:openGemini有两种技术方案来保证数据一致性。一是通过计算副本，数据存多份。另一种是采用存算分离架构，数据一致性交给底层的分布式文件系统来保证。目前二者都在开发者。考虑到这种长周期数据存储的成本，openGemini未来还将考虑支持对象存储，以降低存储成本。Q：openGemini高基数引擎相对于业界时序引擎或OLAP分析引擎有哪些优势？ 在时序数据领域，openGemini是不是没有时间线约束了？是否有新增哪些约束？
A:相比业界的OLAP分析引擎，openGemini的高基数存储引擎更贴合时序场景，查询性能更好。在时序数据领域，openGemini的高基数存储引擎在理论上不存在时间线的上限，使用高基数存储引擎，需要开发者熟悉业务场景，设计合理的排序键。数据写入采用Apache Arrow Flight数据协议，对客户端来说，要求单批次数据需要内部时间有序。Q：openGemini多表引擎是如何做数据隔离的？
A:不同的表有自己单独的数据目录Q：对于时间序列数据，OpenGemini如何根据时间粒度、测量频率等因素合理分区和索引？
A:分区主要考虑shard数量不能太多，这和数据保留时长有关系。如果数据保留3个月，可以每周一个shard，如果数据保留7天，可以每天一个shard。至于索引，openGemini默认是在Tag字段上建索引，因此非必要不指定字段为Tag。Q：如何在openGemini中实现数据的生命周期管理？
A:openGemini的数据生命周期管理主要由过期保存策略（Retention Policy）来实现。Q：在多租户环境下，OpenGemini提供了哪些机制来隔离不同用户或应用的数据？
A:不同用户使用不同DB，为每个用户授予DB的读写权限，可以实现物理隔离。如果租户太多的情况下，每用户一个DB不合适，最好是添加用户字段，查询时必须带有用户ID的条件，以此实现逻辑隔离。Q：哪些原因会导致索引膨胀？openGemini在解决索引膨胀问题上有何创新？
A:Tag字段的基数太高。解决索引膨胀问题上，openGemini推出高基数存储引擎，采用稀疏索引降低索引空间占用。Q：如何选择合适的数据类型以优化存储空间和查询性能？
A:尽可能使用Float和Int，一般数据波动很小的数据集，数据压缩效果更好。Q：openGemini在大数据和实时分析场景中有哪些优势？如何对openGemini进行压力测试和性能评估？
A:openGemini是专门处理海量时序数据的数据库，它的优势是高性能、低成本、高扩展。对openGemini做压测，可以用工具tsbs，推荐自己写测试程序，使用自己业务数据做性能测试，数据更可靠。Q：如何根据业务需求，如读写比例、查询复杂度等，决定使用预聚合表还是原始细节表？
A:如果业务主要是查询聚合后的数据，那推荐使用聚合表。否则使用明细表Q：如何在openGemini项目中实施有效的用户认证和授权机制？
A:openGemini支持用户认证和授权机制。推荐一个管理员用户和多个普通用户Q：openGemini支持哪些具体的数据类型？
A:支持5支持5中数据类型，包括字符串、整型、浮点、布尔、时间中数据类型，包括字符串、整型、浮点、布尔、时间Q：openGemini支持哪些开发语言和框架？openGemini是否支持多租户架构？
A:主流开发语言都支持，比如rust，java，python，go，JavaScript等等，支持多租户架构Q： openGenmini如何防止SQL注入攻击？
A:SQL注入建议应用层面做，数据库做不合适Q：针对不同业务场景，openGemini扩展性能怎么样？是否支持组件单独扩展？
A:openGemini支持单独主键横向扩展，理论上支持100+节点没问题，目前最大集群规模是70节点。Q：openGemini如何设置数据库的监控和警报系统？
A:建议使用单独的实例保存数据库的监控数据，以支撑监控告警系统。Q：openGemini支持哪些数据写入方式? 如何优化openGemini的数据写入性能?
A:支持SDK、CLI、Apache Arrow Flight协议数据写入，SDK和CLI的写入本质上是使用HTTP API访问的数据库。优化写性能的方法在直播中有提及，请看直播Q：openGemini是否支持数据的服务化和API 化? 如何在openGemini中实现数据的缓存和热点数据识别?
A:openGemini服务化要自己开发管控。数据库系统通常会利用内存作为数据的快速访问缓存，OpenGemini在内存中缓存频繁访问的数据，以减少对磁盘的I/O操作，从而提高查询性能。Q：openGemini数据库性能调优的最佳实践有哪些？
A:首先，搭建好openGemini的性能监控面板；其次，写入压测时关注openGemini的性能指标，比如写QPS、写时延、WAL时延、CPU利用率、内存利用率、IO利用率等等，发现问题，逐步解决，比如WAL时延高，就为WAL目录更换独立磁盘。最后，解决问题后，再一次压测，看性能数据的改善，如果有新的问题，再继续解决，直到满意。Q：OpenGemini是否支持表的动态列？如果支持，如何有效地利用这一特性来适应不断变化的数据模式？
A:支持动态列（schemaless），动态列意味着可以根据实际业务情况，添加新的列。Q：如何识别和解决数据库性能瓶颈？性能调优应该从哪些方面入手？如何平衡读写性能？
A:首先，搭建好openGemini的监控面板；其次，开始压测，根据监控指标确定性能瓶颈，比如写时延比较大，可以看看WAL写时延是否也很大，如果WAL时延比较大，则可以给WAL目录分配独立的磁盘。这些都在我的直播中有讲到。 总的来说，性能调优是一个循环过程，解决了一个性能瓶颈，压力可能给到了另一个地方，需要继续解决，直到满足要求为止。 关于问题3 如何平衡读写性能，主要看业务的容忍程序和硬件成本了，比如有的业务对写要求很高，必须在规定时间内要完成，但是查询可以接收秒级的响应，这时就可以把资源多分配给写流程，比如说内存、磁盘带宽。如果是读写要求都很高，那最好是做纵向扩展，升级机器规格，使用大内存和高性能磁盘等。Q：openGemini是否提供水平扩展能力？支持多大节点集群规模？
A:openGemini集群支持组件独立水平扩展，理论上支持100+节点没问题，目前openGemini在实际应用中搭建的集群规模有70个节点。Q：openGemini如何支持大规模数据的存储和查询？对数据隐私和安全有什么保护措施？
A:- openGemini在大规模数据集上，首先是相同时间线数据是存放在一起，避免了多次分散查询。其次，数据按时间分区，根据查询给定的时间范围就可以确定数据所在的分区，从时间上可以进一步过滤不必要的数据集。第三，检视相关时间线数据时，使用了布隆过滤器，能快速判断文件是否包含对应时间线的数据。最后，数据批量读取，向量化方式计算，加速计算速度。
- openGemini在数据隐私和安全方面的保护措施有：支持用户验证和授权机制，支持https数据加密传输，支持证书过期检测，支持弱密码检测，用户密码加密存储等。
Q：openGemini数据库如何保证数据的一致性？
A:openGemini有两种技术方案来保证数据一致性。一是通过计算副本，数据存多份。另一种是采用存算分离架构，数据一致性交给底层的分布式文件系统来保证。目前二者都在开发者。考虑到这种长周期数据存储的成本，openGemini未来还将考虑支持对象存储，以降低存储成本。Q：在openGemini应用中，如何根据业务需求设计合理的数据库结构？
A:openGemini有两种技术方案来保证数据一致性。一是通过计算副本，数据存多份。另一种是采用存算分离架构，数据一致性交给底层的分布式文件系统来保证。目前二者都在开发者。考虑到这种长周期数据存储的成本，openGemini未来还将考虑支持对象存储，以降低存储成本。Q：分布式数据库服务化（DDS）在生态建设和行业应用方面存在哪些挑战？
A:- 技术方面，业务需求日新月异，需要不断提高产品技术创新和成熟度。
- 生态建设任重道远，需要鼓励不同厂商、开发者和用户之间的合作，共同推动分布式数据库技术的发展和应用。
- 行业应用方面，需要进行大量的业务改造和系统集成工作。这不仅涉及到技术层面的挑战，还包括对现有业务流程的理解和重构。
Q：如何在openGemini中实现数据的生命周期管理？openGemini如何处理预聚合数据的更新和过期问题？
A:openGemini生命周期管理主要有Retention Policy来决定的。预聚合数据更新是在写入和compaction时候完成的Q：如何设计openGemini的查询策略来适应冷热数据分离的存储架构？如何减少open Gemini查询过程中的磁盘读取和数据解码开销？
A:业务该怎么查就怎么查，剩下的交给数据库就可以了。Q：openGemini多表引擎是如何做数据隔离的？openGemini是否支持数据的联邦查询和异构数据源集成？
A:多表的数据隔离是物理隔离，每个表都有单独的数据目录。不支持数据联邦查询和异构数据集查询。Q：在opengemini调优时有哪些注意事项？
A:首先，搭建好openGemini的监控面板；其次，开始压测，根据监控指标确定性能瓶颈，比如写时延比较大，可以看看WAL写时延是否也很大，如果WAL时延比较大，则可以给WAL目录分配独立的磁盘。这些都在我的直播中有讲到。 总的来说，性能调优是一个循环过程，解决了一个性能瓶颈，压力可能给到了另一个地方，需要继续解决，直到满足要求为止。 关于问题3 如何平衡读写性能，主要看业务的容忍程序和硬件成本了，比如有的业务对写要求很高，必须在规定时间内要完成，但是查询可以接收秒级的响应，这时就可以把资源多分配给写流程，比如说内存、磁盘带宽。如果是读写要求都很高，那最好是做纵向扩展，升级机器规格，使用大内存和高性能磁盘等。Q：随着数据库不断发展，openGemin后续的发展方向是怎么样的，是否会有和AI结合的应用场景？
A:openGemini后续会在可观测性和IoT领域发力。和AI结合的场景，可以有，希望可以和伙伴一起孵化该能力。想要了解更多openGemin组件库相关知识，欢迎观看DTSE Tech Talk 系列技术直播
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）