证券行业核心交易数据库信创选型思考和POC测试经验分享

加快证券行业信息技术应用创新（简称“信创”）是落实国家安全战略，增强我国资本市场全球竞争力的必然要求。中国证监会相继发布的《证券期货业科技发展“十四五”规划》《证券期货业网络和信息安全管理办法》等相关文件明确了信创建设路径，鼓励、引导证券期货公司加强网络和信息安全技术创新与应用。

一、证券行业核心交易系统数据库的特点及现状

证券行业的核心交易系统数据库具有以下几个显著特点：

• 高并发性：证券交易系统需要支持大量交易并发操作，因此数据库需要具备高并发处理能力。

• 低延迟性：交易系统对延迟要求极高，数据库需要提供快速的数据读写能力，以确保交易操作的及时响应。

• 高可靠性：证券交易涉及大量资金，数据库系统需要具备高可靠性和容错性，确保交易数据不丢失和不篡改。

• 数据一致性：证券交易系统要求数据的一致性和准确性，数据库需要提供强大的事务支持，保证交易数据的完整性。

• 扩展性：随着证券市场的发展，交易系统的业务规模不断扩大，数据库需要具备良好的扩展性，能够支持系统的持续增长。

目前，许多证券公司的核心交易系统依赖于传统商业数据库，如Oracle、DB2等， 因为 Oracle 和 DB2 都是成熟的商业级数据库管理系统，在数据库的可靠性和稳定性方面表现出色。它们具有强大的数据恢复和容错能力，能够保证交易系统的高可用性和持续稳定运行，从而保障交易系统的正常运行和业务持续发展。它们采用先进的数据库架构和优化技术，能够支持大规模数据处理和高并发访问，保证交易系统在高负载和大规模交易情况下的稳定运行。同时，它们也具备良好的扩展性，能够根据业务需求灵活扩展数据库规模和性能，满足交易系统的持续增长需求。而且都拥有庞大的生态系统和丰富的技术支持资源。用户可以获得来自厂商官方的技术支持、培训和咨询服务，解决数据库运维和性能优化等问题。此外，社区和第三方开发者也提供了大量的技术资源和解决方案，帮助用户更好地利用和优化数据库系统。

国产数据库的发展起步较晚，并在最近几年，国产数据库在技术创新和市场应用方面取得了一定的成就，在技术创新方面取得了长足进步。一些国内数据库企业不断加大对核心技术的研发投入，推出了一系列具有自主知识产权的创新产品。这些产品在数据库内核、性能优化、分布式架构、云原生等方面都取得了一定的突破，部分产品的性能和功能已经能够与国际知名数据库相媲美。并随着国内科技创新和数字化转型的推进，越来越多的企业和机构开始选择国产数据库作为其关键业务系统的基础架构。国产数据库在政府、金融、电信、互联网等行业的应用逐渐增多，逐步取代了部分传统的商业数据库，成为行业的重要选择，如Oceanbase、TiDB、TDSQL、GoldenDB、GaussDB等等。

二、证券行业核心数据库的信创替换难点

在进行数据库信创替换时，证券行业面临着诸多难点：

1、数据兼容性：

目前国产数据库大多基于开源的MySQL或者PostgreSQL开发，很多券商选择重构新的交易系统，若国产数据库替换的性能达不到要求，中间会再套一层内存数据库，所以数据兼容性方面是需要考虑的方面，但不是最重要的。

2、数据迁移风险：

证券行业的核心交易系统通常已经建立在 Oracle 或 DB2 等成熟的数据库平台上，并且已经运行了很长时间，积累了大量的业务数据和逻辑。在替换为国产数据库时，需要确保新数据库与现有系统的技术兼容性，以及数据迁移的稳定性和准确性。由于数据库平台之间存在一些技术差异，可能需要重新设计和优化部分系统架构和代码，增加了迁移风险和实施成本。

3、系统稳定性：

证券行业的核心交易系统对系统稳定性和性能要求极高，任何系统变更都可能对系统的稳定性和性能产生影响。在替换数据库时，需要充分评估新数据库的性能和稳定性，确保新系统能够满足交易系统的实时性和高并发访问要求。同时，还需要进行充分的测试和评估，确保新系统在生产环境中的稳定运行。

4、经验储备和技术支持：

国产数据库相对于 Oracle 和 DB2 来说，可能在证券行业的应用经验和技术支持方面还存在一定的不足。证券行业的核心交易系统对数据库的稳定性和性能要求非常高，需要有丰富的应用经验和专业的技术支持来保障系统的正常运行。因此，在替换数据库时，需要评估国产数据库厂商的技术实力和服务能力，确保数据库厂商有足够的技术支持能力和本地售后服务能力，能够及时响应和解决系统运行中遇到的问题，这也是各券商考虑的重要因素之一。

5、成本控制：

目前国产数据库及服务器的成本较高，数据库替换涉及到较高的成本投入，包括硬件设备、软件许可和人力资源等方面，需要合理评估成本，并制定有效的控制措施。

三、数据库POC测试经验分享

POC测试是选择合适数据库的重要步骤。以下是一些经验分享：

1、确定测试目标和范围：

在开始POC测试之前，首先需要明确测试的目标和范围。确定测试目标可以帮助明确测试重点和方向，例如性能测试、功能测试、可用性测试等。同时，也需要确定测试的时间周期和资源投入。

2、设计测试方案和用例：

根据测试目标，设计合理的测试方案和测试用例是关键步骤。测试方案应包括测试环境的搭建、测试数据的准备、测试指标的定义等内容。测试用例应覆盖数据库的各项功能和性能指标，同时也需要考虑实际业务场景和数据特点。

3、搭建测试环境：

进行POC测试之前，需要搭建合适的测试环境。测试环境应尽可能模拟真实生产环境，包括硬件设备、网络环境、数据库配置等方面。确保测试环境的稳定性和可靠性对于测试结果的准确性至关重要。

4、执行测试计划：

在执行测试计划时，需要按照预先设计的测试方案逐步进行。根据不同的测试项和测试用例，记录测试数据和测试结果，并及时反馈问题和异常情况。在测试过程中，需要注意监控系统的性能和资源使用情况，确保系统运行稳定。

5、分析测试结果：

在测试完成后，需要对测试结果进行分析和评估。评估数据库在功能、性能、可用性、安全性等方面的表现，比较不同数据库之间的优劣势，为最终选型提供参考依据。同时，也需要分析测试过程中遇到的问题和挑战，总结经验教训，为后续工作提供指导和改进方向。

6、形成报告并进行总结：

最后，根据测试结果和分析，撰写POC测试报告并进行总结。报告应包括测试目的、测试方案、测试环境、测试结果、问题反馈、优缺点评估等内容。同时，还可以提出建议和改进建议，为最终选型提供参考意见。

以下是个人及公司在数据库POC测试时的一些指标分类（主要采用Jmeter工具），供大家参考：

功能性指标：可用性（高并发、高可用、长稳运行）、易用性（部署升级、管理运维、可监测性）、可扩展性（水平扩展、垂直扩展）、兼容性（硬件及操作系统、应用和开发工具、主流数据库兼容（包括数据类型、存储过程、触发器等））、成本和生态（总体成本、同行业案例、数据库生态和技术支持能力）；

性能指标：业务性能（模拟资金、订单、账户、清算和查询等各项业务场景下的QPS和CPU利用率对比），复杂查询能力（模拟单表和多表联合查询）、内存和磁盘管理（各业务场景下的内存和磁盘使用情况）。

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发或点击在看，让更多同行看到