某软件公司国产分析型数据库选型方法论

国产数据库选型策略及方法论，是我今年的重点选题之一。这个选题的灵感源于我与朋友的一次深入交谈。

在现今的国际环境下，技术自主可控的重要性日益突显。这一趋势的形成受多重因素推动，包括政治紧张局势、贸易保护主义以及对数据隐私和安全的加强意识。为应对这些挑战，发展和采用国产技术，特别是国产数据库，已经成为确保对关键技术和数据控制权的有效策略，同时，这也有助于提升国内技术和产业的竞争力。

目前，越来越多的企业正在认识到这一点，并积极考虑并实施国产技术替代和国产数据库选型。然而，这个过程并不容易，存在许多潜在的问题和挑战。

因此，如果能系统地总结出各种企业的国产数据库选型策略和方法论，为企业提供一个参考框架，帮助他们根据自身需求和条件选择最适合的国产数据库，那将是极具价值的。其中，理解和分析真实案例是这个过程中的关键步骤。

基于此，老鱼常在各种会议上寻找来自用户企业的相关演讲，这样的机会使老鱼能从多角度理解和总结不同企业的数据库选型策略和方法论。

以下是老鱼对某软件公司凭证引擎国产分析性数据库选型策略及方法论演讲的总结：

凭证引擎是财务核算系统的核心组成部分，负责凭证处理和财务账簿管理。在企业中，各种业务系统产生的数据会通过凭证引擎进行保存和记账，同时落实财务管控规则，并生成各类财务报表。这些报表通过账户查询和接口，可供企业财务的其他外围系统使用，如税务、资金预算等。凭证引擎的性能和稳定性对整个财务核算体系具有重要的影响。

某软件公司在财务系统领域有着二十多年的积累，为支持大型企业的数字化转型，以及满足当前创新趋势的发展需求，在新创项目中开发了新一代的财务总账核心系统。在这个过程中，提出了三项具有挑战性的技术指标：

1. 期望新的凭证引擎能够处理年度凭证数量达到40亿，这是当前处理量的4倍。

2. 期望总账查询报表能在3秒内返回响应。需要注意的是，总账报表并非简单的点查询，它涉及复杂的数据整理过程，包括利润中心统计、会计期间和科目的复杂计算等。当前，财务报表查询速度相对较慢，希望能将其优化到3秒以内。

3. 期望新的凭证引擎能支持每秒处理2000张凭证。这并非指2000行，而是针对不同的客户和场景。对于实时录入凭证的客户，这是一个挑战性的性能需求;而对于需要批量处理的客户，这样的性能可以缩短他们的处理时间窗口。

复杂的凭证数据结构：一个凭证包含至少五张表，每个表字段众多，总计可能达到一千多个字段。这些字段包含用于集团管控的主数据，科目和辅助核算的维度，以及用户和审批人的数据权限控制内容。

严格的数据准入校验：由于凭证是财务核心数据，一旦生成，其财务编号不能更改或删除。进行严格校验，涉及大约120种主数据，主数据项数达到百万项，以满足大型集团细致灵活的管控需求。此外，需要满足约300项的校验规则和数据权限控制需求，可能会面临10万量级的用户组。

凭证编号的连续性需求：凭证编号需要连续递增且不能断号，这对于数据库，特别是分布式数据库的自增ID功能，是一个挑战。需要在应用层面解决这个问题，虽然可以借助一些数据库的能力。

高性能需求：系统需要满足每秒处理2000张凭证的性能要求，这意味着大量的数据入库压力和校验延时。既需要兼容用户的日常实时提交，也需要兼容大容量的数据提交，同时还需要关注用户体验。

适配国产数据库：国产化数据库可能会带来兼容性问题，包括通信协议等。需要在选择新的开发语言和打通数据库时考虑这些问题。此外，该软件公司也希望与国产数据库厂商有更深入的合作，挖掘数据库底层的接口，实现更好的实践。

这些挑战需要在技术层面进行深入的研究和攻关，以实现新一代财务总账核心系统的高性能和高效率目标。

凭证引擎设计：整个设计分为四个模块：

• 凭证网关：处理各种协议介入，将不同格式的凭证转换成内部标准的凭证格式。

• 外围业务：处理凭证的冲销、核销和关联交易单据等业务，利用事务机制进行处理。

• 接口适配：处理同步和异步的接口，完成标准接口转让。

• 凭证校验模块：这是逻辑最复杂且对算力消耗最大的模块。它包含120种主数据，每张凭证需与数据库进行多次网络通信。为降低延时，主数据从数据库拉出，将校验的复杂度从网络访问开销转移到内存。

数据校验：校验包括数据有效性、取值范围、财务管控、集团管控等多个方面。为避免在高性能场景下涉及大表的联表查询，采用位图方式，一次CPU位图处理即可完成校验。

编号发放：为保证凭证编号连续不断，凭证先被写入Kafka进行串行化，然后批量处理，减小数据库压力，提高性能。

事务和状态管理：主数据和校验规则存储在内存中，数据状态管理模块类似于数据库架构。最后，数据写入凭证记账数据库，待记帐数据通过同步机制在两数据库间实时同步。

主数据校验：采用哈希进行查询，为避免对数据库压力过大，采用百万位级的大位图进行数据权限管理。

业务校验规则：支持300项可配置规则，同时为了支持实施和第三方厂方实施，提供了脚本规则开发的功能。

整体上，这个工程设计和方案利用了凭证网关、外围业务、接口适配和凭证校验等多个模块来处理和校验数据，充分考虑了性能和数据准确性，使得数据处理更高效，减小了数据库压力。同时，这个设计也很灵活，提供了可配置规则和脚本规则开发的功能，满足了不同用户的需求。

编程语言选择：在初期，产品主要是用Java开发，但由于需要使用更低级的CPU指令以及对内存和计算的控制，Java无法满足需求。因此，选择了使用Rust语言，它是一种现代编程语言，提供了零成本抽象，支持并发和原编程，可以提供类似C或C++的系统控制能力。

工程师培养问题：Rust工程师在国内相对较少，因此选择从Java团队内部进行转岗。虽然Rust编译器的严格检查可能使编码速度变慢，但它能更早地暴露问题，从而降低整体的开发成本。

编码格式：在高性能处理环境中，数据冗余和文本类型会对网络传输、硬盘I/O和解析产生很大压力。为了解决这个问题，选择了使用Flatbuffer编码，因为它可以高效地进行单个字段的读取，而无需完全解码整个数据。

数据零拷贝和零成本抽象：这是利用Rust对底层系统控制能力的结果，可以更好地利用CPU处理流水线，优化CPU的自身优化。

性能压力测试：在每秒处理2000张凭证时，硬件资源使用情况良好。一个凭证对应24行数据，每秒可以处理48000行入库，字段数量超过1000个。虽然Kafka和数据库占用的CPU资源相对较多，但是整体性能仍然可以达到需求。

总的来说，这个工程设计利用了Rust的优势，克服了新语言带来的挑战，实现了高性能和低延时的数据处理，同时保证了数据的准确性和安全性。

数据库优化：该软件公司计划通过更进一步优化数据库的处理能力以提高性能。尽管已经可以处理每秒2000张凭证，但他们的目标是进一步提升这个数字。其中一个方法是使用文件方式进行入库，如CSV文件，这在初步试验中已经显示出显著的性能提升。

代码优化和数据库接口优化：进一步优化代码和数据库接口能够进一步提高单线程入库的性能。他们的目标是在硬件使用低的情况下，使单个线程入库能达到每秒1450张。

支持快速查询：为了能在3秒内查出凭证，他们计划采用某国产分析型数据库，利用高性能计算来提升统计分析的能力。此外，他们还希望采用预计算的方式降低一次报表查询时的IO和CPU计算力消耗。这将使财务报表的查询更为高效，满足3秒内查出财务报表的挑战。