You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by me...@apache.org on 2021/10/25 22:44:41 UTC
[shardingsphere] branch master updated: Update picture of sharding
index (#13270)
This is an automated email from the ASF dual-hosted git repository.
menghaoran 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 9f32e2d Update picture of sharding index (#13270)
9f32e2d is described below
commit 9f32e2d1e63626bb9af18354e99eb1ad9b774740
Author: Liang Zhang <te...@163.com>
AuthorDate: Tue Oct 26 06:43:49 2021 +0800
Update picture of sharding index (#13270)
* Update index of apache shardingspjhere's feature document
* Update picture of sharding index
---
docs/document/content/features/_index.cn.md | 1 +
docs/document/content/features/_index.en.md | 1 +
.../content/features/sharding/_index.cn.md | 19 ++++++++++++-------
.../content/features/sharding/_index.en.md | 2 +-
.../static/img/sharding/horizontal_sharding.png | Bin 90527 -> 104230 bytes
.../static/img/sharding/vertical_sharding.png | Bin 68326 -> 95962 bytes
6 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/docs/document/content/features/_index.cn.md b/docs/document/content/features/_index.cn.md
index 4033877..812db47 100644
--- a/docs/document/content/features/_index.cn.md
+++ b/docs/document/content/features/_index.cn.md
@@ -6,4 +6,5 @@ chapter = true
+++
Apache ShardingSphere 提供了多样化的功能，涵盖范围从数据库内核、数据库分布式到贴近数据库上层的应用，为用户提供了大量的功能池。
+
功能并无边界，只要满足数据库服务和生态的共性需求即可，期待更多的开源工程师参与 Apache ShardingSphere 社区，提供新颖思路和令人兴奋的功能。
diff --git a/docs/document/content/features/_index.en.md b/docs/document/content/features/_index.en.md
index 94833f4..e339978 100644
--- a/docs/document/content/features/_index.en.md
+++ b/docs/document/content/features/_index.en.md
@@ -6,4 +6,5 @@ chapter = true
+++
Apache ShardingSphere provides a variety of features, from database kernel and database distributed solution to applications closed features.
+
There is no boundary for these features, warmly welcome more open source engineers to join the community and provide exciting ideas and features.
diff --git a/docs/document/content/features/sharding/_index.cn.md b/docs/document/content/features/sharding/_index.cn.md
index 1f045f5..24dc4f3 100644
--- a/docs/document/content/features/sharding/_index.cn.md
+++ b/docs/document/content/features/sharding/_index.cn.md
@@ -7,13 +7,16 @@ chapter = true
## 背景
-传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。
+传统的将数据集中存储至单一节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足海量数据的场景。
-从性能方面来说，由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
+从性能方面来说，由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；
+同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
-从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。
+从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。
+而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。
-从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在 1TB 之内，是比较合理的范围。
+从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。
+数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在 1TB 之内，是比较合理的范围。
在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的 NoSQL 的尝试越来越多。
但 NoSQL 对 SQL 的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动。
@@ -45,15 +48,17 @@ chapter = true
-水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。
+水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是数据分片的标准解决方案。
## 挑战
虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但分布式的架构在获得了收益的同时，也引入了新的问题。
-面对如此散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道数据需要从哪个具体的数据库的分表中获取。
+面对如此散乱的分片之后的数据，应用开发工程师和数据库管理员对数据库的操作变得异常繁重就是其中的重要挑战之一。
+他们需要知道数据需要从哪个具体的数据库的子表中获取。
-另一个挑战则是，能够正确的运行在单节点数据库中的 SQL，在分片之后的数据库中并不一定能够正确运行。例如，分表导致表名称的修改，或者分页、排序、聚合分组等操作的不正确处理。
+另一个挑战则是，能够正确的运行在单节点数据库中的 SQL，在分片之后的数据库中并不一定能够正确运行。
+例如，分表导致表名称的修改，或者分页、排序、聚合分组等操作的不正确处理。
跨库事务也是分布式的数据库集群要面对的棘手事情。
合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。
diff --git a/docs/document/content/features/sharding/_index.en.md b/docs/document/content/features/sharding/_index.en.md
index e970728..526bfbf 100644
--- a/docs/document/content/features/sharding/_index.en.md
+++ b/docs/document/content/features/sharding/_index.en.md
@@ -7,7 +7,7 @@ chapter = true
## Background
-The traditional solution that stores all the data in one concentrated node has hardly satisfied the requirement of massive Internet data scenario in three aspects, performance, availability and operation cost.
+The traditional solution that stores all the data in one concentrated node has hardly satisfied the requirement of massive data scenario in three aspects, performance, availability and operation cost.
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.
diff --git a/docs/document/static/img/sharding/horizontal_sharding.png b/docs/document/static/img/sharding/horizontal_sharding.png
index 8112769..2af5fce 100644
Binary files a/docs/document/static/img/sharding/horizontal_sharding.png and b/docs/document/static/img/sharding/horizontal_sharding.png differ
diff --git a/docs/document/static/img/sharding/vertical_sharding.png b/docs/document/static/img/sharding/vertical_sharding.png
index 1a3dd26..73131ed 100644
Binary files a/docs/document/static/img/sharding/vertical_sharding.png and b/docs/document/static/img/sharding/vertical_sharding.png differ