As an efficient and stable open source distributed database, TiDB is widely used in banking, securities, insurance, online payment and fintech industries at home and abroad, and supports users’ critical computing in about 20 different financial business scenarios. This article will introduce the practice of distributed relational database TiDB in the key application areas of the financial industry.

Financial critical business scenarios

The business system of the bank is very complex, including the core account, accounting, settlement and other businesses to the periphery of all kinds of deposit, loan, bill, exchange and Internet scene of all kinds of financial business.

With the development of science and technology, the core transaction system of the whole bank is evolving from the traditional centralized application structure to the service-oriented and distributed system. In China, several leading banking institutions in science and technology have started the transformation of the core and introduced many distributed technologies into their core transaction applications and the data processing layer behind them to support the development of their business. In the future, the whole development direction will be more unit and service oriented, and some application supporting frameworks, such as cloud, micro-service and future serverless, will gradually be introduced to core transactions.

Distributed core system architecture has the following specific requirements for the entire database:

  • Safety, stability and reliability;

  • Provide distributed computing and distributed data management and online elastic expansion capabilities;

  • Provide high concurrency, low latency, high throughput database processing capabilities;

  • Support online trading and batch (day/final) batch mixed load;

  • Support core reporting and data reporting business load;

  • Providing reliable and high-performance distributed online transactions;

  • At least two-center, three-center, and multi-center disaster recovery capabilities must be supported.

  • RPO = 0, RTO should meet the high availability requirements of the core system of the regulatory and banking technology departments;

  • Low difficulty in core business application development/transformation;

  • Perfect and convenient operation and maintenance management ability.

Existing architecture pain points

At present, the core system database schemes adopted by many banks are mainly the traditional centralized database architecture and the mysql-based distributed database architecture. However, there are some problems in both the centralized database architecture and the mysql-based distributed database architecture. Centralized database architecture has the following problems:

  • Heavy reliance on proprietary high-end hardware;

  • Unable to extend horizontally flexibly;

  • Low matching degree with the new generation of distributed service-oriented core application architecture;

  • High construction and maintenance costs;

  • DB2 / Oracle database technology locking;

  • Unable to take advantage of the development of cloud computing systems.

The distributed database architecture based on MySQL also has the following problems:

  • The maturity and reliability of database distributed middleware still need to be tested.

  • The degree of application intrusion is high and the transformation complexity is large.

  • Applying model and data model locking at the expense of flexibility;

  • Batch load processing capacity limitation;

  • The distributed transaction capability is low, which requires the application development side and the planning side to avoid deeply.

  • Risk of strong consistency assurance;

  • Lack of flexible expansion ability and the ability to automatically balance online expansion;

  • Risks of MySQL high availability technology;

  • Two – three – center city live complexity.

Bank core database solution based on TiDB HTAP architecture

Scheme 1: TiDB core trading system support architecture

The first is a more straightforward solution, using TiDB as the main repository for the core transaction repository.

In this way, the whole TiDB is similar to the access mode of traditional single-machine centralized database and business application development mode, and the access to applications is transparent. At the same time, whether the application model, data model or the whole transaction model, there is no need for human behavior segmentation. Because in the development of the core transaction application, we will use the user view as well as the account view, so simply finding the user’s account shard to do the shard is actually sacrificing the flexibility of the whole core transaction.

In addition, TiDB is used as the main library, and the built-in multi-center and multi-active Dr Mechanism simplifies the complexity of deployment, management, and cost. And fully distributed online transaction support, without application intervention and early locking transaction processing planning, users basically do online transactions on TiDB in the process, with the use of standalone database is the same; In addition, TiDB provides a dynamic scheduling mechanism in the background, so the online node expansion will not affect the business at all. Both the background data balance and the automatic allocation of load balance between internal engines are done by the engine itself, and users do not need to pay much attention to the application side.

Taking TiDB as the main library of the core transaction database has the following values:

  • In the core system database side distributed transformation greatly reduce the difficulty and risk of transformation;

  • Business models and data models do not need to be retrofitted to the database schema;

  • Transparent computing and data management distributed, reducing maintenance complexity and cost;

  • Throughput and performance can scale transparently with online horizontal scaling;

  • Standard SQL, distributed transactions, multi-table complex association computing, online and batch mixed load processing capabilities, ensure business flexibility and suitable for distributed core applications;

  • Kernel supports strong consistent data part mechanism and high availability mechanism (RPO=0,RTO <30s);

  • The kernel supports the multi-center, multi-active Dr Mechanism.

Changliang core trading system test

We have made a relatively complete connection with the system of city commercial bank level, including Changliang Technology. We have fully adapted its core transaction system, including account, accounting, loan, card issuing, cash management, asset load and other core modules.

We have fully adapted and optimized the functions, correctness and performance of transactions, and completed functional tests of more than 2000 core transactions, including nearly 200 batch tests in full. Next, we are planning to carry out docking test of V8 version with Changliang Technology and test based on ARM localized platform.

Scheme 2: core transaction MySQL + TiDB post-library scheme

The second scheme is to use TiDB as the post-storage scheme of the whole core transaction.

The structure is shown in the figure above. The application side of the whole core transaction is split according to the application logic, which is also the evolution trend of the new generation of core application structure.

Users use MySQL + middleware to assume the pre-library of online transactions in the core online transaction library, complete the most basic online transactions on it, and then perform quasi-real-time synchronization through the CDC synchronization tool provided by TiDB to parse the binlog of MySQL fragment pairs. And by means of automatic library convergence to TiDB’s distributed cluster.

Some of the limitations originally imposed by a single MySQL Sharding solution can be overcome on a TiDB distributed cluster, such as the previously mentioned complex computation, complex real-time query services, which can be completed offline from the online transaction main library to the TiDB back-end library. This can be said to be the advantages and circumvent the disadvantages, in the whole scheme can be the whole transaction online part, batch part, real-time query part and complex report forms part to make a distinction.

Scheme 3: Core transaction MySQL(business unit) + TiDB post-library scheme

The third solution is similar to the second solution, but with the development of core transaction technology and architecture route, many solutions will carry out the transformation of application dimension of micro service or unit in the application side of core transaction.

In the whole core transaction, the customer center, product center and accounting center, which are all used in the transaction link, are separated from the whole transaction, and these parts are carried out separately. For online transactions and accounts, such as deposit system and loan system, through business logic segmentation, they are divided into independent units, which can be understood as virtual branch system, through this way in the application of the business layer to achieve horizontal expansion; At the same time, the whole transaction link, such as the public service center, can be extracted by micro-service mode and used as the public service area of invocation through the standard interface between different modules.

After such a structure is generated, there will be many databases corresponding to the online transaction library. As the back-end database behind the core transaction online database under the business unit architecture, TiDB can also use CDC to carry out one-for-one warehousing of the unified global dimension libraries such as customer center, product center and accounting center. At the same time, in the application layer is not rely on MySQL depots table, but by the application layer for cutting the vertical depots, can directly by the CDC tools in TiDB layer converge into a global summary library, we can finish on this summary libraries across service unit data background batch operations, including complex queries and reports of business; At the same time, it can also ensure that in the whole business, the original shared service library is still in the form of logical single library in the large cluster of TiDB, providing services to the business.

Webank’s new generation core system architecture

Webank has adopted this scheme as its core system architecture. Small Banks in terms of domestic core trading unitized has its own innovation, in the process of the past three or four years of development, the core of their overall trade adopted distributed extensible framework of DCN, extensibility in the application layer, at the same time in the database layer data processing interface and guarantee the very good simplicity.

DCN is a logical area concept, which can be equivalent to an independent branch, such as a branch or branch of a bank. Business expansion can be solved by horizontal expansion of DCN. They also adopted the MySQL sub-database sub-table as the background of the online library, and the transaction and accounting separation, through the distributed database NewSQL technology, the batch and accounting through the way of post-library moved to the distributed cluster.

Value of TiDB as a core post-transaction repository

The value of TiDB as a core post-transaction database is mainly as follows:

  • Solve the challenge of data summary processing in MySQL distributed solution.

  • Standard SQL, distributed transactions, multi-table complex association computing capabilities provide high-performance batch processing of massive data across nodes.

  • The HTAP architecture provides column and column hybrid computing capability, high performance real-time computing of massive data.

  • Provide a complete tool to achieve full synchronization of online library cluster data, at any time as an alternative to the online library cluster switch guarantee.

  • Throughput and performance can scale transparently with online horizontal scaling.

  • The kernel supports strong consistent data part mechanism and high availability mechanism (RPO=0,RTO <30s).

  • The kernel supports the multi-center, multi-active Dr Mechanism.

Potential value of TiDB to core trading scenarios

TiDB also brings some potential value to core trading scenarios.

First of all, we firmly believe that cloud must be the future. TiDB cloud native architecture and product capabilities (K8s container cluster) are ready, providing the technical foundation for the upper cloud (private cloud). At the same time, we have recently completed the docking and adaptation of commercial cloud basic platforms (open source OpenShift, open source Rancher), and TiDB is based on the scheduling mechanism of cloud resources and database itself, which can better realize the support capability of multi-tenant database in the cloud.

In the kernel, TiDB HTAP column and column hybrid architecture can support more online new business scenarios in the future, and broaden the scope of business application; At the same time, our product team is also working with the team including Flink to complete the solution adaptation including stream processing to power the real-time processing business.

In addition, we have preliminarily completed the scheduling capability across data centers to realize data awareness scheduling among multiple centers. Under the multi-center architecture, the distributed scheduling mechanism and row-level data scheduling capability of TiDB are used to dynamically associate data with the central site, and associate data tables (row sets) based on geographical location, so as to reduce cross-regional access, reduce query delay and improve the overall performance of applications. At the same time, using such a core means, we can schedule the hot and cold data flexibly, and separate the hot and cold data.

Advantage analysis of the solution

For the core online transaction, from the traditional scheme to the distributed scheme of MySQL, and then to the scheme with TiDB as the main library or as a post-library scheme, TiDB has significant advantages in terms of transaction performance, throughput, summary and expansion. Moreover, compared with the traditional structure, the introduction of TiDB has obvious advantages in the overall hardware and software, including the cost of the entire operation and maintenance deployment.

To be continued……