JR/T 0203-2020Distributed database technology financial application specification Technical architecture (English PDF)

6.1 Overview of the technical framework

The technical architecture of distributed transaction database includes three parts. management module, computing module and storage module. The main functions and logic of each part are the relationship between the series is shown in Figure 1.

Figure 1 Distributed transaction database technology architecture

6.2 Physical resource layer

The physical resource layer refers to the basic hardware facilities and equipment of the distributed transaction database, which provides for the distributed transaction database and upper-level business system.

Provides the basic support environment, including physical infrastructure such as power supply for the physical computer room, computing equipment and storage equipment, and network equipment. The physical resource layer should Use safe and controllable hardware with an open architecture for construction to ensure safety, availability and reliability. The specific requirements are as follows.

a) It should support computing acceleration capabilities such as processor multi-channel interconnection technology, compression and decompression.

b) The network topology of each network element should be dynamically monitored to achieve reliability, scalability, and easy maintenance.

c) It should support more than two processor architecture systems, and the processor has trusted computing capabilities.

d) A dynamically configured blacklist mechanism or firewall mechanism should be provided to prevent network paralysis caused by malicious nodes.

6.3 Calculation module

The computing module is responsible for parsing application query requests, generating query plans, and automatically assigning query plans to each computing node for parallel execution.

Row. Use technologies such as distributed transaction processing to ensure data correctness, and use technologies such as concurrency control and dynamic resource allocation to improve distributed transactions the calculation efficiency of the database in complex business scenarios, the specific requirements are as follows.

a) It should meet the computing power requirements of distributed transaction databases.

b) Should support operation in a trusted virtualization or cloud computing environment.

6.4 Storage module

The storage module is responsible for executing the data operation request of the computing layer, and realizes the persistent storage of the data at the hardware level to ensure that the data is not lost.

The storage layer stores data in multiple copies in shards to ensure data reliability. Distributed transaction database should have application access transparency, including Including, but not limited to, fragmentation transparency, copy transparency, and location transparency. Changes in data fragmentation mode and copy location will not affect the application program, the specific requirements are as follows.

a) It should support efficient, safe and stable provision of data writing and query services.

b) Should support the persistence of written data.

c) It should support the segmentation of different physical copies of the same data to different physical nodes according to the node identification.

d) It should support fast self-check and recovery after data storage node failure.

e) It should support local or global encryption of data.

f) It is advisable to support the function of quick data recovery for misoperation.

g) Should support compression storage technology.

6.5 Management Module

The management module is responsible for coordinating distributed clocks and maintaining metadata, and providing database parameter configuration and operation monitoring interfaces. The specific requirements are as follows under.

a) Load balancing and resource isolation functions should be provided to ensure that the distributed transaction database provides stable services.

b) Should have role authority management, encryption protection mechanism and auditing capabilities.

c) Should have the ability of database node selection, global transaction management, and data migration between nodes.

d) Cluster status monitoring such as parameter configuration, running status monitoring, performance data collection, etc. of distributed transaction database cluster nodes should be provided and configuration function.

7.1 Overview of Functional Architecture

Distributed transaction database should adopt the technical architecture of separation of computing and storage, distributed computing and distributed storage, and use general-purpose software and hardware as the the basic platform realizes functions such as data security, high system availability, data slicing storage, data capacity and performance level scalability, transaction consistency, etc.

can. The functional framework of distributed transaction database applied in the financial field is shown in Figure 2.

Figure 2 Schematic diagram of distributed transaction database functions

7.2 Basic functions

7.2.1 Deployment flexibility

There should be flexible deployment methods, and at least one of the local deployment and cloud deployment methods should be supported.

a) Local deployment. Distributed transaction database deployment uses multiple physical machines to act as management nodes, computing nodes, and data storage nodes.

The following requirements should be met during the deployment process.

--Should have the ability to initiate database deployment on multiple servers automatically from a single node.

--Should provide a unified visual installation management wizard for software components.

--Should record the installation log, and provide installation records and troubleshooting methods.

b) Cloud deployment. Building and deploying a distributed transaction database based on the cloud platform. The cloud platform will automatically allocate storage and computing based on user needs.

For computing resources, self-deployed distributed transaction databases on the cloud should meet the following requirements.

--Should have the ability to deploy flexibly on the cloud, perform automatic installation and deployment, or support bare metal servers provided on the cloud platform, Install and deploy on the virtual machine.

--Should provide a unified visual installation management wizard for software components.

--Should have an installation log, provide installation records and troubleshooting methods.

7.2.2 SQL capabilities

Distributed transaction databases used in the financial field should have SQL capabilities. The specific requirements are as follows.

a) Distributed transactions shall be supported and ACID characteristics shall be met.

b) Should support numeric types such as long integer and decimal, string type, binary string type, date/time type, it should support Interval type, Boolean type, large object type, custom type, enumeration, collection and other data types.

c) Operators such as numerical operations, logical operations, comparison operations, and string splicing (type coercion) shall be supported.

d) Should support commonly used numeric type functions, character functions, date/time functions, aggregate functions, type conversion functions, and null value processing Function, it should support common functions such as regular expressions, security functions, and window analysis functions.

e) It should support comparison conditions, logical conditions, null conditions, conformity conditions, pattern matching conditions, interval conditions, suitable conditions, and storage conditions.

Commonly used conditional expressions in conditions, etc.

f) Should support key value constraints such as primary key and global uniqueness.

g) Table partitioning should be supported; partitioned local indexes should be supported, and partitioned global indexes and distributed global indexes should be supported.

h) Should support query views.

i) It should support UTF-8, GB K encoding, and other character set encodings such as GB 18030 and UTF8MB4 should be supported.

j) The auto-increment sequence should be supported, and the globally unique auto-increment sequence should be supported.

k) Should support the display function of the execution plan.

l) Complex SQL queries such as join queries, subqueries, and aggregate queries across multiple storage nodes should be supported.

m) Should support the definition of the logical storage structure of the database, such as table space definitions, etc.

n) Should support data paging query.

o) The specific requirements that should support stored procedures are as follows.

-Should support the creation, modification and deletion of stored procedures.

-Should support the definition of stored procedure variables.

--Should support stored procedure flow control statements.

-It is advisable to support the conditional judgment statement of the stored procedure.

-Should support the stored procedure loop statement.

p) Should support functional index.

q) Mode management should be supported.

r) It should support quick recovery of accidentally deleted and accidentally modified data.

s) Materialized views should be supported.

t) Should support dynamic system views.

u) The specific requirements for supporting custom functions are as follows.

--It should support JAVA,...