You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by pa...@apache.org on 2021/10/19 04:47:01 UTC
[shardingsphere] branch master updated: Use readwrite-splitting
instead of replica query (#13122)
This is an automated email from the ASF dual-hosted git repository.
panjuan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git
The following commit(s) were added to refs/heads/master by this push:
new 6ce2654 Use readwrite-splitting instead of replica query (#13122)
6ce2654 is described below
commit 6ce26548f28fd824e37efeba8064555bcabf4a77
Author: Haoran Meng <me...@gmail.com>
AuthorDate: Tue Oct 19 12:46:20 2021 +0800
Use readwrite-splitting instead of replica query (#13122)
---
docs/document/content/concepts/pluggable/_index.en.md | 2 +-
.../features/governance/management/registry-center.en.md | 2 +-
.../document/content/features/readwrite-splitting/_index.cn.md | 2 +-
.../document/content/features/readwrite-splitting/_index.en.md | 10 +++++-----
.../content/features/readwrite-splitting/concept.en.md | 2 +-
.../content/features/readwrite-splitting/use-norms.en.md | 6 +++---
docs/document/content/features/sharding/_index.en.md | 4 ++--
.../content/features/sharding/concept/configuration.en.md | 2 +-
.../document/content/features/sharding/principle/execute.en.md | 2 +-
.../content/features/test-engine/integration-test.en.md | 2 +-
.../content/features/test-engine/performance-test.en.md | 8 ++++----
.../user-manual/shardingsphere-jdbc/configuration/_index.en.md | 2 +-
.../shardingsphere-jdbc/configuration/yaml/_index.en.md | 2 +-
.../shardingsphere-jdbc/usage/sharding/_index.en.md | 2 +-
.../shardingsphere-proxy/configuration/_index.en.md | 2 +-
.../user-manual/shardingsphere-proxy/usage/startup.en.md | 2 +-
16 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/docs/document/content/concepts/pluggable/_index.en.md b/docs/document/content/concepts/pluggable/_index.en.md
index c95ea73..a1f43fa 100644
--- a/docs/document/content/concepts/pluggable/_index.en.md
+++ b/docs/document/content/concepts/pluggable/_index.en.md
@@ -17,7 +17,7 @@ It needs to make each module decouple to independent and imperceptible to each o
Design an architecture to completely isolate each function, not only can stimulate the enthusiasm of the open source community, but also can guarantee the quality of the project.
Apache ShardingSphere begin to focus on pluggable architecture from version 5.x, features can be embedded into project flexibility.
-Currently, the features such as data sharding, replica query, data encrypt, shadow database,
+Currently, the features such as data sharding, readwrite-splitting, data encrypt, shadow database,
and SQL dialects / database protocols such as MySQL, PostgreSQL, SQLServer, Oracle supported are all weaved by plugins.
Developers can customize their own ShardingSphere just like building lego blocks.
There are lots of SPI extensions for Apache ShardingSphere now and increase continuously.
diff --git a/docs/document/content/features/governance/management/registry-center.en.md b/docs/document/content/features/governance/management/registry-center.en.md
index ebe2824..734a5f9 100644
--- a/docs/document/content/features/governance/management/registry-center.en.md
+++ b/docs/document/content/features/governance/management/registry-center.en.md
@@ -176,7 +176,7 @@ Zookeeper command is as follows:
### Disable Replica Database
-Under replica query scenarios, users can write `DISABLED` (case insensitive) to sub-nodes of data source name to disable replica database sources. Delete `DISABLED` or the node to enable it.
+Under readwrite-splitting scenarios, users can write `DISABLED` (case insensitive) to sub-nodes of data source name to disable replica database sources. Delete `DISABLED` or the node to enable it.
Zookeeper command is as follows:
diff --git a/docs/document/content/features/readwrite-splitting/_index.cn.md b/docs/document/content/features/readwrite-splitting/_index.cn.md
index c7365d4..590ca62 100644
--- a/docs/document/content/features/readwrite-splitting/_index.cn.md
+++ b/docs/document/content/features/readwrite-splitting/_index.cn.md
@@ -30,4 +30,4 @@ chapter = true
## 目标
-**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是ShardingSphere读写分离模块的主要设计目标。**
+**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是 ShardingSphere 读写分离模块的主要设计目标。**
diff --git a/docs/document/content/features/readwrite-splitting/_index.en.md b/docs/document/content/features/readwrite-splitting/_index.en.md
index 3b848c3..39ee86a 100644
--- a/docs/document/content/features/readwrite-splitting/_index.en.md
+++ b/docs/document/content/features/readwrite-splitting/_index.en.md
@@ -1,6 +1,6 @@
+++
pre = "<b>4.3. </b>"
-title = "Replica query"
+title = "Readwrite-splitting"
weight = 3
chapter = true
+++
@@ -11,18 +11,18 @@ With increasing system TPS, database capacity has faced great bottleneck effect.
One primary database with multiple replica databases can further enhance system processing capacity by distributing queries evenly into multiple data replicas. Multiple primary databases with multiple replica databases can enhance not only system throughput but also system availability. Therefore, the system can still function normally, even though any database is down or physical disk is destroyed.
-Different from the horizontal sharding that separates data to all nodes according to sharding keys, replica query routes read operations and write operations separately to the primary database and the replica database according to SQL meaning analysis.
+Different from the horizontal sharding that separates data to all nodes according to sharding keys, readwrite-splitting routes read operations and write operations separately to the primary database and the replica database according to SQL meaning analysis.
-Data in replica query split nodes is consistent, whereas that in horizontal shards is not. The combined use of horizontal sharding and replica query will effectively enhance the system performance.
+Data in readwrite-splitting nodes is consistent, whereas that in horizontal shards is not. The combined use of horizontal sharding and readwrite-splitting will effectively enhance the system performance.
## Challenges
-Though replica query can enhance system throughput and availability, it also brings inconsistent data, including that between multiple primary databases and between primary databases and replica databases. What's more, it also brings the same problem as data sharding, complicating app developer and operator's maintenance and operation. The following picture has shown the complex topological relations between applications and database groups when sharding table and database used together [...]
+Though readwrite-splitting can enhance system throughput and availability, it also brings inconsistent data, including that between multiple primary databases and between primary databases and replica databases. What's more, it also brings the same problem as data sharding, complicating app developer and operator's maintenance and operation. The following picture has shown the complex topological relations between applications and database groups when sharding table and database used tog [...]
## Goal
-**The main design goal of the replica query modular of ShardingSphere is to try to reduce the influence of replica query, in order to let users use replica query database group like one database.**
\ No newline at end of file
+**The main design goal of the readwrite-splitting modular of ShardingSphere is to try to reduce the influence of readwrite-splitting, in order to let users use primary-replica database group like one database.**
\ No newline at end of file
diff --git a/docs/document/content/features/readwrite-splitting/concept.en.md b/docs/document/content/features/readwrite-splitting/concept.en.md
index bd22f62..59cee54 100644
--- a/docs/document/content/features/readwrite-splitting/concept.en.md
+++ b/docs/document/content/features/readwrite-splitting/concept.en.md
@@ -15,7 +15,7 @@ It refers to the database used in data query. It supports multiple replica datab
## Primary Replica Replication
It refers to the operation to asynchronously replicate data from the primary database to the replica database.
-Because of replica query asynchronization, there may be short-time data inconsistency between them.
+Because of the asynchrony of primary-replica synchronization, there may be short-time data inconsistency between them.
## Load Balance Strategy
diff --git a/docs/document/content/features/readwrite-splitting/use-norms.en.md b/docs/document/content/features/readwrite-splitting/use-norms.en.md
index b98ae2d..6fbc87f 100644
--- a/docs/document/content/features/readwrite-splitting/use-norms.en.md
+++ b/docs/document/content/features/readwrite-splitting/use-norms.en.md
@@ -6,8 +6,8 @@ weight = 2
## Supported Items
-* Provide the replica query configuration of one primary database with multiple replica databases, which can be used alone or with sharding table and database;
-* Support SQL pass-through in independent use of replica query;
+* Provide the readwrite-splitting configuration of one primary database with multiple replica databases, which can be used alone or with sharding table and database;
+* Support SQL pass-through in independent use of readwrite-splitting;
* Forcible primary database route based on SQL Hint;
## Unsupported Items
@@ -16,7 +16,7 @@ weight = 2
* Data inconsistency caused by replication delay between databases;
* Double or multiple primary databases to provide write operation;
* The data for transaction across primary and replica nodes are inconsistent.
-In the replica query model, the primary nodes need to be used for both reading and writing in the transaction.
+In the readwrite-splitting model, the primary nodes need to be used for both reading and writing in the transaction.
## Optional Items
diff --git a/docs/document/content/features/sharding/_index.en.md b/docs/document/content/features/sharding/_index.en.md
index 12ff21b..e970728 100644
--- a/docs/document/content/features/sharding/_index.en.md
+++ b/docs/document/content/features/sharding/_index.en.md
@@ -11,13 +11,13 @@ The traditional solution that stores all the data in one concentrated node has h
In performance, the relational database mostly uses B+ tree index. When the data amount exceeds the threshold, deeper index will increase the disk IO access number, and thereby, weaken the performance of query. In the same time, high concurrency requests also make the centralized database to be the greatest limitation of the system.
-In availability, capacity can be expanded at a relatively low cost and any extent with stateless service, which can make all the pressure, at last, fall on the database. But the single data node or simple replica query structure has been harder and harder to take these pressures. Therefore, database availability has become the key to the whole system.
+In availability, capacity can be expanded at a relatively low cost and any extent with stateless service, which can make all the pressure, at last, fall on the database. But the single data node or simple primary-replica structure has been harder and harder to take these pressures. Therefore, database availability has become the key to the whole system.
From the aspect of operation costs, when the data in a database instance has reached above the threshold, DBA’s operation pressure will also increase. The time cost of data backup and data recovery will be more uncontrollable with increasing amount of data. Generally, it is a relatively reasonable range for the data in single database case to be within 1TB.
Under the circumstance that traditional relational databases cannot satisfy the requirement of the Internet, there are more and more attempts to store the data in native distributed NoSQL. But its incompatibility with SQL and imperfection in ecosystem block it from defeating the relational database in the competition, so the relational database still holds an unshakable position.
-Sharding refers to splitting the data in one database and storing them in multiple tables and databases according to some certain standard, so that the performance and availability can be improved. Both methods can effectively avoid the query limitation caused by data exceeding affordable threshold. What’s more, database sharding can also effectively disperse TPS. Table sharding, though cannot ease the database pressure, can provide possibilities to transfer distributed transactions to l [...]
+Sharding refers to splitting the data in one database and storing them in multiple tables and databases according to some certain standard, so that the performance and availability can be improved. Both methods can effectively avoid the query limitation caused by data exceeding affordable threshold. What’s more, database sharding can also effectively disperse TPS. Table sharding, though cannot ease the database pressure, can provide possibilities to transfer distributed transactions to l [...]
Splitting data through database sharding and table sharding is an effective method to deal with high TPS and mass amount data system, because it can keep the data amount lower than the threshold and evacuate the traffic.
Sharding method can be divided into vertical sharding and horizontal sharding.
diff --git a/docs/document/content/features/sharding/concept/configuration.en.md b/docs/document/content/features/sharding/concept/configuration.en.md
index 906ec53..afa6929 100644
--- a/docs/document/content/features/sharding/concept/configuration.en.md
+++ b/docs/document/content/features/sharding/concept/configuration.en.md
@@ -5,7 +5,7 @@ weight = 3
## Sharding Rule
-The main entrance for Sharding rules includes the configurations of data source, tables, binding tables and replica query.
+The main entrance for Sharding rules includes the configurations of data source, tables, binding tables and readwrite-splitting.
## Data Sources Configuration
diff --git a/docs/document/content/features/sharding/principle/execute.en.md b/docs/document/content/features/sharding/principle/execute.en.md
index 7ba9a8c..a7e5090 100644
--- a/docs/document/content/features/sharding/principle/execute.en.md
+++ b/docs/document/content/features/sharding/principle/execute.en.md
@@ -70,7 +70,7 @@ For example, suppose one query needs to acquire two database connections from a
To avoid the deadlock, ShardingSphere will go through synchronous processing when acquiring database connection. When creating execution units, it acquires all the database connections that this SQL requires for once with atomic method and reduces the possibility of acquiring only part of the resources. Due to the high operation frequency, locking the connection each time when acquiring it can decrease ShardingSphere's concurrency. Therefore, it has improved two aspects here:
1. Avoid the setting that locking only takes one database connection each time. Because under this kind of circumstance, two requests waiting for each other will not happen, so there is no need for locking.
-Most OLTP operations use sharding keys to route to the only data node, which will make the system in a totally unlocked state, thereby improve the concurrency efficiency further. In addition to routing to a single shard, replica query also belongs to this category.
+Most OLTP operations use sharding keys to route to the only data node, which will make the system in a totally unlocked state, thereby improve the concurrency efficiency further. In addition to routing to a single shard, readwrite-splitting also belongs to this category.
2. Only aim at MEMORY_STRICTLY mode to lock resources. When using CONNECTION_STRICTLY mode, all the query result sets will release database connection resources after loading them to the memory, so deadlock wait will not appear.
diff --git a/docs/document/content/features/test-engine/integration-test.en.md b/docs/document/content/features/test-engine/integration-test.en.md
index 58c4f92..50f48c1 100644
--- a/docs/document/content/features/test-engine/integration-test.en.md
+++ b/docs/document/content/features/test-engine/integration-test.en.md
@@ -5,7 +5,7 @@ weight = 1
+++
The SQL parsing unit test covers both SQL placeholder and literal dimension.
-Integration test can be further divided into two dimensions of strategy and JDBC; the former one includes strategies as Sharding, table Sharding, database Sharding, and replica query while the latter one includes `Statement` and `PreparedStatement`.
+Integration test can be further divided into two dimensions of strategy and JDBC; the former one includes strategies as Sharding, table Sharding, database Sharding, and readwrite-splitting while the latter one includes `Statement` and `PreparedStatement`.
Therefore, one SQL can drive 5 kinds of database parsing * 2 kinds of parameter transmission modes + 5 kinds of databases * 5 kinds of Sharding strategies * 2 kinds of JDBC operation modes = 60 test cases, to enable ShardingSphere to achieve the pursuit of high quality.
diff --git a/docs/document/content/features/test-engine/performance-test.en.md b/docs/document/content/features/test-engine/performance-test.en.md
index df66387..68a9377 100644
--- a/docs/document/content/features/test-engine/performance-test.en.md
+++ b/docs/document/content/features/test-engine/performance-test.en.md
@@ -6,7 +6,7 @@ weight = 4
## Target
-The performance of ShardingSphere-JDBC, ShardingSphere-Proxy and MySQL would be compared here. INSERT & UPDATE & DELETE which regarded as a set of associated operation and SELECT which focus on sharding optimization are used to evaluate performance for the basic scenarios (single route, replica query & encrypt & sharding, full route). While another set of associated operation, INSERT & SELECT & DELETE, is used to evaluate performance for replica query.
+The performance of ShardingSphere-JDBC, ShardingSphere-Proxy and MySQL would be compared here. INSERT & UPDATE & DELETE which regarded as a set of associated operation and SELECT which focus on sharding optimization are used to evaluate performance for the basic scenarios (single route, readwrite-splitting & encrypt & sharding, full route). While another set of associated operation, INSERT & SELECT & DELETE, is used to evaluate performance for readwrite-splitting.
To achieve the result better, these tests are performed with jmeter which based on a certain amount of data with 20 concurrent threads for 30 minutes, and one MySQL has been deployed on one machine, while the scenario of MySQL used for comparison is deployed on one machine with one instance.
## Test Scenarios
@@ -16,12 +16,12 @@ To achieve the result better, these tests are performed with jmeter which based
On the basis of one thousand data volume, four databases that are deployed on the same machine and each contains 1024 tables with `id` used for database sharding and `k` used for table sharding are designed for this scenario, single route select sql statement is chosen here.
While as a comparison, MySQL runs with INSERT & UPDATE & DELETE statement and single route select sql statement on the basis of one thousand data volume.
-### Replica Query
+### Readwrite-splitting
One primary database and one replica database, which are deployed on different machines, are designed for this scenario based on ten thousand data volume.
While as a comparison, MySQL runs with INSERT & SELECT & DELETE sql statement on the basis of ten thousand data volume.
-### Replica Query & Encrypt & Sharding
+### Readwrite-splitting & Encrypt & Sharding
On the basis of one thousand data volume, four databases that are deployed on different machines and each contains 1024 tables with `id` used for database sharding, `k` used for table sharding, `c` encrypted with aes and `pad` encrypted with md5 are designed for this scenario, single route select sql statement is chosen here.
While as a comparison, MySQL runs with INSERT & UPDATE & DELETE statement and single route select sql statement on the basis of one thousand data volume.
@@ -155,7 +155,7 @@ rules:
- replica_ds_0
```
-#### Replica Query & Encrypt & Sharding Configuration
+#### Readwrite-splitting & Encrypt & Sharding Configuration
```yaml
schemaName: sharding_db
diff --git a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
index 27fe0bb..ad709de 100644
--- a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
+++ b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
@@ -11,7 +11,7 @@ through which developers can quickly and clearly understand the functions provid
This chapter is a configuration manual for ShardingSphere-JDBC, which can also be referred to as a dictionary if necessary.
ShardingSphere-JDBC has provided 4 kinds of configuration methods for different situations.
-By configuration, application developers can flexibly use data sharding, replica query, data encryption, shadow database or the combination of them.
+By configuration, application developers can flexibly use data sharding, readwrite-splitting, data encryption, shadow database or the combination of them.
Mixed rule configurations are very similar to single rule configuration, except for the differences from single rule to multiple rules.
diff --git a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
index a8909fa..1b12384 100644
--- a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
+++ b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
@@ -74,7 +74,7 @@ schemaName: sharding_db
### Data Source Configuration
It is divided into single data source configuration and multi data source configuration.
-Single data source configuration used for data encryption rules; and multi data source configuration used for fragmentation, replica query and other rules.
+Single data source configuration used for data encryption rules; and multi data source configuration used for fragmentation, readwrite-splitting and other rules.
If features such as encryption and sharding are used in combination, a multi data source configuration should be used.
#### Single Data Source Configuration
diff --git a/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md b/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
index 759483f..bde5cee 100644
--- a/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
+++ b/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
@@ -6,7 +6,7 @@ chapter = true
Data sharding is the basic capability of Apache ShardingSphere.
This section uses data sharding as an example.
-The usage of functions such as replica query, data encryption, shadow database is completely consistent with data sharding, as long as the corresponding rules are configured.
+The usage of functions such as readwrite-splitting, data encryption, shadow database is completely consistent with data sharding, as long as the corresponding rules are configured.
Multiple rules can be appended.
Please refer to [Configuration Manual](/en/user-manual/shardingsphere-jdbc/configuration/) for more details.
diff --git a/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md b/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
index eab4018..4118661 100644
--- a/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
+++ b/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
@@ -10,6 +10,6 @@ through which developer can quickly and clearly understand the functions provide
This chapter is a configuration manual for ShardingSphere-Proxy, which can also be referred to as a dictionary if necessary.
ShardingSphere-Proxy only provided YAML configuration.
-By configuration, application developers can flexibly use data sharding, replica query, data encryption, shadow database or the combination of them.
+By configuration, application developers can flexibly use data sharding, readwrite-splitting, data encryption, shadow database or the combination of them.
Rule configuration keeps consist with YAML configuration of ShardingSphere-JDBC.
diff --git a/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md b/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
index c262676..48066ef 100644
--- a/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
+++ b/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
@@ -7,7 +7,7 @@ weight = 1
1. Download the latest version of ShardingSphere-Proxy.
1. If users use docker, they can execute `docker pull shardingsphere/shardingsphere-proxy` to get the image. Please refer to [Docker Image](/en/user-manual/shardingsphere-proxy/docker/) for more details.
-1. After the decompression, revise `conf/server.yaml` and documents begin with `config-` prefix, `conf/config-xxx.yaml` for example, to configure sharding rules and replica query rules. Please refer to [Configuration Manual](/en/user-manual/shardingsphere-proxy/configuration/) for the configuration method.
+1. After the decompression, revise `conf/server.yaml` and documents begin with `config-` prefix, `conf/config-xxx.yaml` for example, to configure sharding rules and readwrite-splitting rules. Please refer to [Configuration Manual](/en/user-manual/shardingsphere-proxy/configuration/) for the configuration method.
1. Please run `bin/start.sh` for Linux operating system; run `bin/start.bat` for Windows operating system to start ShardingSphere-Proxy. To configure start port and document location, please refer to [Quick Start](/en/quick-start/shardingsphere-proxy-quick-start/).
## Using PostgreSQL