You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by wu...@apache.org on 2021/10/31 15:57:59 UTC
[shardingsphere] branch master updated: Update Readwrite-splitting
index (#13373)
This is an automated email from the ASF dual-hosted git repository.
wuweijie 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 0ca0e2e Update Readwrite-splitting index (#13373)
0ca0e2e is described below
commit 0ca0e2eef64224917136df80c18eb0861914cc8b
Author: Liang Zhang <te...@163.com>
AuthorDate: Sun Oct 31 23:57:06 2021 +0800
Update Readwrite-splitting index (#13373)
* Update Readwrite-splitting index
* Update diagrams
---
.../features/readwrite-splitting/_index.cn.md | 8 +++----
.../features/readwrite-splitting/_index.en.md | 24 ++++++++++++++-------
.../static/img/readwrite-splitting/background.png | Bin 0 -> 107932 bytes
.../static/img/readwrite-splitting/challenges.png | Bin 0 -> 133627 bytes
.../readwrite-splitting-standalone.png | Bin 81064 -> 0 bytes
.../sharding-and-readwrite-splitting.png | Bin 122039 -> 0 bytes
6 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/docs/document/content/features/readwrite-splitting/_index.cn.md b/docs/document/content/features/readwrite-splitting/_index.cn.md
index 10a8877..fd6645e 100644
--- a/docs/document/content/features/readwrite-splitting/_index.cn.md
+++ b/docs/document/content/features/readwrite-splitting/_index.cn.md
@@ -15,7 +15,7 @@ chapter = true
与将数据根据分片键打散至各个数据节点的水平分片不同，读写分离则是根据SQL语义的分析，将读操作和写操作分别路由至主库与从库。
-
+
读写分离的数据节点中的数据内容是一致的，而水平分片的每个数据节点的数据内容却并不相同。将水平分片和读写分离联合使用，能够更加有效的提升系统性能。
@@ -24,10 +24,10 @@ chapter = true
读写分离虽然可以提升系统的吞吐量和可用性，但同时也带来了数据不一致的问题。
这包括多个主库之间的数据一致性，以及主库与从库之间的数据一致性的问题。
并且，读写分离也带来了与数据分片同样的问题，它同样会使得应用开发和运维人员对数据库的操作和运维变得更加复杂。
-下图展现了将分库分表与读写分离一同使用时，应用程序与数据库集群之间的复杂拓扑关系。
+下图展现了将数据分片与读写分离一同使用时，应用程序与数据库集群之间的复杂拓扑关系。
-
+
## 目标
-**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是 ShardingSphere 读写分离模块的主要设计目标。**
+**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是 Apache ShardingSphere 读写分离模块的主要设计目标。**
diff --git a/docs/document/content/features/readwrite-splitting/_index.en.md b/docs/document/content/features/readwrite-splitting/_index.en.md
index ce1713c..d5d7c7b 100644
--- a/docs/document/content/features/readwrite-splitting/_index.en.md
+++ b/docs/document/content/features/readwrite-splitting/_index.en.md
@@ -7,22 +7,30 @@ chapter = true
## Background
-With increasing system TPS, database capacity has faced great bottleneck effect. For the application system with massive concurrence read operations but less write operations in the same time, we can divide the database into a primary database and a replica database. The primary database is responsible for the addition, deletion and modification of transactions, while the replica database is responsible for queries. It can significantly improve the query performance of the whole system b [...]
+Database throughput has faced the bottleneck with increasing TPS.
+For the application with massive concurrence read but less write in the same time, we can divide the database into a primary database and a replica database.
+The primary database is responsible for the insert, delete and update of transactions, while the replica database is responsible for queries.
+It can significantly improve the query performance of the whole system by effectively avoiding row locks.
-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.
+One primary database with multiple replica databases can further enhance processing capacity by distributing queries evenly into multiple data replicas.
+Multiple primary databases with multiple replica databases can enhance not only throughput but also availability.
+Therefore, the system can still run normally, even though any database is down or physical disk destroyed.
-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.
+Different from the sharding that separates data to all nodes according to sharding keys, readwrite-splitting routes read and write separately to primary database and replica databases according SQL analysis.
-
+
-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.
+Data in readwrite-splitting nodes are consistent, whereas that in shards is not.
+The combined use of sharding and readwrite-splitting will effectively enhance the system performance.
## Challenges
-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 [...]
+Though readwrite-splitting can enhance system throughput and availability, it also brings inconsistent data, including that among multiple primary databases and among primary databases and replica databases.
+What's more, it also brings the same problem as data sharding, complicating developer and operator's maintenance and operation.
+The following diagram has shown the complex topological relations between applications and database groups when sharding used together with readwrite-splitting.
-
+
## Goal
-**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
+**The main design goal of readwrite-splitting of Apache ShardingSphere is to try to reduce the influence of readwrite-splitting, in order to let users use primary-replica database group like one database.**
diff --git a/docs/document/static/img/readwrite-splitting/background.png b/docs/document/static/img/readwrite-splitting/background.png
new file mode 100644
index 0000000..b67ebb4
Binary files /dev/null and b/docs/document/static/img/readwrite-splitting/background.png differ
diff --git a/docs/document/static/img/readwrite-splitting/challenges.png b/docs/document/static/img/readwrite-splitting/challenges.png
new file mode 100644
index 0000000..84ef3fb
Binary files /dev/null and b/docs/document/static/img/readwrite-splitting/challenges.png differ
diff --git a/docs/document/static/img/readwrite-splitting/readwrite-splitting-standalone.png b/docs/document/static/img/readwrite-splitting/readwrite-splitting-standalone.png
deleted file mode 100644
index 39b432c..0000000
Binary files a/docs/document/static/img/readwrite-splitting/readwrite-splitting-standalone.png and /dev/null differ
diff --git a/docs/document/static/img/readwrite-splitting/sharding-and-readwrite-splitting.png b/docs/document/static/img/readwrite-splitting/sharding-and-readwrite-splitting.png
deleted file mode 100644
index 3b18bea..0000000
Binary files a/docs/document/static/img/readwrite-splitting/sharding-and-readwrite-splitting.png and /dev/null differ