You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by du...@apache.org on 2023/02/24 02:39:07 UTC

[shardingsphere] branch master updated: Update Articles (#24252)

This is an automated email from the ASF dual-hosted git repository.

duanzhengqiang 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 e7b1b04f597 Update Articles (#24252)
e7b1b04f597 is described below

commit e7b1b04f5974849f1d959a7f5b70d20b8c1f6238
Author: FPokerFace <11...@users.noreply.github.com>
AuthorDate: Fri Feb 24 10:38:58 2023 +0800

    Update Articles (#24252)
    
    Update 2 articles from medium.com
---
 ...342\200\235_is_Published_Internationally.en.md" |   7 +-
 ...etup_on_Massive_Data_Management_Practices.en.md |  55 +++++
 ...ere_Enterprise_User_Case_-_Energy_Monster.en.md | 225 +++++++++++++++++++++
 ...eetup_on_Massive_Data_Management_Practices1.png | Bin 0 -> 454930 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster1.png | Bin 0 -> 84119 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster10.png | Bin 0 -> 78784 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster11.png | Bin 0 -> 24747 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster12.png | Bin 0 -> 28842 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster13.png | Bin 0 -> 46571 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster14.png | Bin 0 -> 39327 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster15.png | Bin 0 -> 14247 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster16.png | Bin 0 -> 8355 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster17.png | Bin 0 -> 50716 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster18.png | Bin 0 -> 38102 bytes
 ...ere_Enterprise_User_Case_-_Energy_Monster19.png | Bin 0 -> 22991 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster2.png | Bin 0 -> 90591 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster3.png | Bin 0 -> 41418 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster4.png | Bin 0 -> 15936 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster5.png | Bin 0 -> 86168 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster6.png | Bin 0 -> 40934 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster7.png | Bin 0 -> 106415 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster8.png | Bin 0 -> 28130 bytes
 ...here_Enterprise_User_Case_-_Energy_Monster9.png | Bin 0 -> 54368 bytes
 23 files changed, 283 insertions(+), 4 deletions(-)

diff --git "a/docs/blog/content/material/2022_08_02_Book_Release_\342\200\234A_Definitive_Guide_to_Apache_ShardingSphere\342\200\235_is_Published_Internationally.en.md" "b/docs/blog/content/material/2022_08_02_Book_Release_\342\200\234A_Definitive_Guide_to_Apache_ShardingSphere\342\200\235_is_Published_Internationally.en.md"
index d236f5589aa..feed534ac6d 100644
--- "a/docs/blog/content/material/2022_08_02_Book_Release_\342\200\234A_Definitive_Guide_to_Apache_ShardingSphere\342\200\235_is_Published_Internationally.en.md"
+++ "b/docs/blog/content/material/2022_08_02_Book_Release_\342\200\234A_Definitive_Guide_to_Apache_ShardingSphere\342\200\235_is_Published_Internationally.en.md"
@@ -1,6 +1,6 @@
 +++
 title = "Book Release: “A Definitive Guide to Apache ShardingSphere” is Published Internationally"
-weight = 70
+weight = 71
 chapter = true 
 +++
 
@@ -23,7 +23,6 @@ This is a technical book written for the ShardingSphere community users as well
 - Use ShardingSphere pluggable architecture to build custom solutions.
 
 # Why did we write a professional book about ShardingSphere?
-
 > ***To introduce the strengths of ShardingSphere’s kernel, features, and architecture to more programmers.\***
 >
 > *— By Zhang Liang, Apache ShardingSphere PMC Chair*
@@ -54,7 +53,7 @@ To give back to the community users, ShardingSphere also launched a free book gi
 
 **LinkedIn:** https://www.linkedin.com/feed/update/urn:li:activity:6955445327667548160
 
-## **👉Free Chapter**
+## 👉Free Chapter
 
 A free copy of chapter one is available [**here**](https://www.amazon.com/Definitive-Guide-Apache-ShardingSphere-multi-model-dp-1803239425/dp/1803239425/ref=mt_other?_encoding=UTF8&me=&qid=1655188637&asin=1803239425&revisionId=&format=4&depth=1) for download.
 
@@ -102,6 +101,6 @@ Please note that the discount is only available on the publisher’s website thr
 
 [ShardingSphere Slack](https://join.slack.com/t/apacheshardingsphere/shared_invite/zt-sbdde7ie-SjDqo9~I4rYcR18bq0SYTg)
 
-[Contributor Guide](https://shardingsphere.apache.org/community/cn/contribute/)
+[Contributor Guide](https://shardingsphere.apache.org/community/en/involved/contribute/contributor/)
 
 [GitHub Issues](https://github.com/apache/shardingsphere/issues)
diff --git a/docs/blog/content/material/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices.en.md b/docs/blog/content/material/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices.en.md
new file mode 100644
index 00000000000..8f9c48ea8ca
--- /dev/null
+++ b/docs/blog/content/material/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices.en.md
@@ -0,0 +1,55 @@
++++
+title = "First Look at ShardingSphere 5.2.0 & In-Person Meetup on Massive Data Management Practices"
+weight = 72
+chapter = true 
++++
+
+**One more day before ShardingSphere's first in-person meetup in Beijing on September 3, 2022.**
+
+**Join us to learn about the best practices and technical highlights of Apache ShardingSphere's latest release - version** `5.2.0`**.**
+
+On Saturday, the first in-person Meetup of the ShardingSphere Community will be held in Beijing on Sep 3, 2022. Four technology experts from the developers’ community are invited to give you a detailed analysis of the following:
+
+*   How ShardingSphere can rapidly improve the data application ability of ordinary users driven by cloud scenarios.
+*   Comparison of data management effect between traditional data processing methods and ShardingSphere.
+*   Experience the ShardingSphere’s ecosystem simple operation in response to diverse e-commerce scenarios.
+
+The community will reveal and demo Apache ShardingSphere v5.2.0 at this meetup. The latest version has taken a giant leap forward in terms of its features, performance, testing, documentation, examples, etc.
+
+**Time:** September 3, 2022 **·** 2PM-5PM CST
+
+**Location:** Multi-function Hall, 1st Floor, Intelligent Manufacturing Innovation Center, №32 Zhongguancun Street, Haidian District, Beijing
+
+**![img](https://shardingsphere.apache.org/blog/img/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices1.png)**
+======================================
+
+
+
+**First Look at ShardingSphere 5.2.0**
+======================================
+
+New Features
+------------
+
+The `5.2.0` release brings the following new features:
+
+*   Data sharding and SQL audit.
+*   MySQL `SHOW PROCESSLIST` & `KILL` features.
+*   Specific DistSQL for data migration & heterogeneous migration.
+
+Best Practices
+--------------
+
+**1\. Enhance user’s ability to manage ShardingSphere**
+
+Newly added features, including data sharding, SQL audit, and MySQL `SHOW PROCESSLIST` & `KILL`, can enhance users’ capability to manage ShardingSphere.
+
+**2\. Add heterogeneous database migration for users**
+
+Specific DistSQL for data migration and heterogeneous migration is added. Data can be migrated from Oracle to PostgreSQL.
+
+**3\. Provide enhanced and complete cloud solutions**
+
+Version 5.2.0 transfers Helm Charts from ShardingSphere repository to the shardingsphere-on-cloud sub-project, to provide more complete cloud solutions for ShardingSphere.
+
+Thanks to the practices and testing of the open source community and internal and external business systems, ShardingSphere can achieve stable and constant iterations. We will continue to help developers participate in building an open source ecosystem and apply cutting-edge technologies in the database field.
diff --git a/docs/blog/content/material/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster.en.md b/docs/blog/content/material/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster.en.md
new file mode 100644
index 00000000000..8f3cc4433d1
--- /dev/null
+++ b/docs/blog/content/material/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster.en.md
@@ -0,0 +1,225 @@
++++
+title = "Apache ShardingSphere Enterprise User Case - Energy Monster"
+weight = 73
+chapter = true 
++++
+
+[Energy Monster](https://ir.enmonster.com/)’s application of [ShardingSphere-JDBC](https://shardingsphere.apache.org/document/current/en/overview/#shardingsphere-jdbc)
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+[Energy Monster](https://ir.enmonster.com/) is a consumer tech company with the mission to energize everyday life. The company is the largest provider of mobile device charging services in Asia.
+
+As the company’s business concurrency volume is getting larger, the amount of data generated (users, orders, activities, etc.) increases each day. The traditional relational database has proven to be inadequate in supporting millions or tens of millions of data volumes in a single database or table.
+
+Performance has been unable to meet the benchmark requirements of business development. Under these circumstances, data sharding is an effective way to solve the problem.
+
+Technology selection
+--------------------
+
+Under the [Database Plus](https://shardingsphere.apache.org/) concept, ShardingSphere is designed to build an ecosystem on top of heterogeneous databases. The goal is to provide globally scalable and enhanced computing capabilities while maximizing the original database computing capabilities.
+
+The interaction between applications and databases becomes oriented towards the Database Plus standard, therefore minimizing the impact of database fragmentation on upper-layer services.
+
+Within the ShardingSphere ecosystem, [ShardingSphere-JDBC](https://shardingsphere.apache.org/document/current/en/overview/#shardingsphere-jdbc) is positioned as a lightweight Java framework, providing additional services in Java’s JDBC layer.
+
+It uses the client to directly connect to the database and provide services in the form of a `jar` package, without additional deployment and dependence. It can be understood as an enhanced version of the JDBC driver, which is fully compatible with JDBC and various ORM frameworks.
+
+ShardingSphere-JDBC enables developers to focus only on the work outside the data layer by coordinating the data read and write under the data sharding, instead of using business code to manually select databases and tables.
+
+Business case
+-------------
+
+UCS is Energy Monster’s user-centric service providing basic functionality for users on the Server side. In 2018, it was stripped from [PHP](https://www.php.net/) Server and moved to the Java technology stack to implement microservitization.
+
+It involves the design of new databases and tables and data cleaning and migration. The whole switchover process was expected to ensure the following functions:
+
+*   Stability: smooth release in a short time without halting.
+
+• Accuracy: ensure accurate cleaning of tens of millions of data volumes.
+
+• Scalability: solve the performance problems caused by increasing data volume and ensure scalability.
+
+> **_Solutions to data cleansing and migration_**
+
+*   Initial data synchronization.
+*   The application’s server cuts off the entry (users).
+*   Data synchronization (updates and new users since the last time point).
+*   Data cleaning.
+*   User center release.
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster1.png)
+
+> **_Data sharding strategy_**
+
+The database adopts a database shards design, divided into 16 databases. The default shard key is `user_id` and the default sharding strategy `user_id` is mod 16, such as `${user_id % 16}` for the user table. For SQL that does not carry shard keys, broadcast routing is used.
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster2.png)
+
+`user_id` is used as the shard key because `user_id` can cover most business scenarios, and other fields possibly can be empty. In the local test, the query of shard key strategy (openId,mobile) took 50ms to 200ms.
+
+> **_Using the sharding algorithm_**
+
+There are currently three sharding algorithms available.
+
+* Standard sharding algorithm. It corresponds to `StandardShardingAlgorithm`, used for scenarios that use a single key as the shard key, such as =, IN, BETWEEN AND, >, <, > =, < =.
+
+* Complex sharding algorithm. It corresponds to `ComplexKeysShardingAlgorithm`, used for scenarios that use multi-key as the shard key. The logic with multiple shard keys is complex and requires developers to handle it by themselves.
+
+* Hint sharding algorithm. It corresponds to `HintShardingAlgorithm`, used for scenarios where the Hint row is used for sharding.
+
+  ![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster3.png)
+
+Upgrading ShardingSphere-JDBC
+-----------------------------
+
+ShardingSphere-JDBC is used in multiple business scenarios, such as order, inventory, and finance. By 2021, the R&D groups or teams were using different versions of ShardingSphere-JDBC, ranging from 1.X to 4.X, which is difficult to achieve unified maintenance in the later stage.
+
+Additionally, there are some potential bugs and missing functions in the earlier version. Based on requirements for unified management and availability, we implemented a project to unify the ShardingSphere-JDBC’s versions used by the company and upgrade them to a 4.1.1 stable version in April 2021.
+
+**The following problems were encountered during the upgrade:**
+
+**1. It takes a long time to start the service after the upgrade.**
+
+ShardingSphere-JDBC checks the metadata consistency of sub-tables when the service is started. The configuration item `max.connections.size.per.quer` (maximum number of connections that can be opened per query) is 1 by default. With a large number of tables, the loading process would be slow. You need to refer to the connection pool configuration to improve the loading speed.
+
+**2. There is no response when there is no shard key in the sub-table query.**
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster4.png)
+
+Logical SQL query does not specify shard keys and it queries all the tables according to the whole database tables router in broadcasting routing.
+
+The configuration items have 108 pieces of real tables in a database. According to the configuration of `maxConnectionsizeperquery=50`, ShardingSphere-JDBC uses the connection limit mode, divides the query requests into three groups, and merges the results with in-memory. As a result, 36 database connections are required for one query. But the `maxActive` configured by the [druid](https://druid.apache.org/) thread pool is set to 20, resulting in a deadlock.
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster5.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster6.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster7.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster8.png)
+
+**Solutions:**
+
+*   Combine `check.table.metadata.enabled=true`(check the metadata consistency in sub-tables when started)and properly configure `maxConnectionSizePerQuery`(maximum number of connections that can be opened by each query).
+*   `maxConnectionSizePerQuery` should be less than the maximum number of active threads configured by the druid thread pool.
+
+**3. After upgrading from 1.X, an error message “Cannot update Sharding key” is displayed in SQL execution, and the actual shard key value is not updated.**
+
+To avoid data query failure caused by changing the shard key value, shard key detection is added to the `SQL update` in the 4.X version. The error can be rectified in the following ways:
+
+*   remove the shard key when updating.
+*   the shard key is added to the `where` statement synchronously.
+
+**4. A start failure is caused when using `druid-spring-boot-starter`, which is incompatible with `Sharding-datasource`.**
+
+The druid data connection pool starter will load and create a default data source. This will cause conflicts when ShardingSphere-JDBC creates data sources.
+
+**5. `**inline strategy**` reports an error in range query.**
+
+The `inline strategy` doesn't support range query by default and the `standard strategy` is advised. Add the following configuration if the `inline strategy` is needed for the range query.
+
+`spring.shardingsphere.props.allow.range.query.with.inline.sharding: true`
+
+**Note:** Here all the `inline strategy` range queries will query each sub-table in broadcasting.
+
+**6. The “Cannot find owner from table” error is reported.**
+
+SQL (simplified):
+
+`select id from` (select id from x) as a group by a.id
+
+The 4.X version supports limited sub-queries. This problem is caused by the name of the intermediate table. Remove the table alias of `select` or `group order` or other fields.
+
+> [_https://github.com/apache/shardingsphere/issues/4810_](https://github.com/apache/shardingsphere/issues/4810)
+
+**7. The table’s primary key conflicts with the primary key generated by the [SNOWFLAKE](https://programming.vip/docs/overview-of-snowflake-algorithm.html) algorithm.**
+
+ShardingSphere provides flexible ways to configure distributed primary key generation strategies. In the sharding rule configuration module, you can configure the primary key generation strategy for each table.
+
+By default, the [snowflake](https://programming.vip/docs/overview-of-snowflake-algorithm.html) algorithm is used to generate long integer data of 64bit. The snowflake generator needs to be configured with:
+
+`spring.shardingsphere.sharding.tables.x.key-generator.props.worker.id = ${dcc.node.id}`
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster9.png)
+
+The company uses the [apollo](https://www.apolloconfig.com/#/) configuration center to deliver the node id of the service instance. The service uses multi-data sources. If you use the YAML file to load sharding configuration, the `workId` cannot be automatically loaded into sharding configuration items.
+
+**Solutions:**
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster10.png)
+
+Use the custom generator type based on the built-in `SnowflakeShardingKeyGenerator`.
+
+If the primary key is used as a shard key, configure `max.vibration.offset` based on the data sharding value to increase the vibration range.
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster11.png)
+
+**8. The 3.X version reports an error when `CASE WHEN` statement is executed.**
+
+First, the 3.X and 4.X versions don’t support the `case when` statement.
+
+The 3.X and 4.X versions have different logics when parsing the shard keys of `case when`'s `update` statement. The 4.X `parserEngine.parse` method will ignore the `case when` parsing parameters, resulting in inconsistency with the external parameter list and an error when 3.X executes the normal SQL.
+
+The 3.X version works correctly because the first parameter of `case when` is intentionally set to the shard key when the SQL is written, and the `case when` statement comes first.
+
+> [_https://github.com/apache/shardingsphere/issues/13233_](https://github.com/apache/shardingsphere/issues/13233)
+
+**Solutions:**
+
+*   It is suggested to rewrite SQL as the `case when` is not supported.
+*   According to the shard key parsing logic in version 4.1.1, `case when` is placed at the end, and the shard key remains the first parameter of `case when`.
+
+**9. The logical table `actualDataNodes` is configured and no default value error is reported for the primary key.**
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster12.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster13.png)
+
+The `check.table.metadata.enabled=true` is not configured for service, and the metadata consistency of sub-tables is not checked by default.
+
+The first table of `actualDataNodes` configured by services does not exist, resulting in an empty `GenerateKeyContenxt`.
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster14.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster15.png)
+
+**Solutions:**
+
+*   Configure `check.table.metadata.enabled=true`. A non-existent table is detected when started and an error is reported.
+*   Rewrite the `actualDataNodes inline` expression to make sure that the first table exists.
+
+**10. In version 3.0, there is a deadlock under the high concurrency of the full database and table router.**
+
+ShardingSphere-JDBC uses local transactions by default. In local transactions, the database connection is obtained asynchronously. Under high concurrency, it is possible that all database connections cannot be obtained, resulting in a deadlock.
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster16.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster17.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster18.png)
+
+![img](https://shardingsphere.apache.org/blog/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster19.png)
+
+Conclusion
+==========
+
+As a [ShardingSphere](https://shardingsphere.apache.org/) core user, [Energy Monster](https://ir.enmonster.com/)’s upgrade process also reflects some problems that community users may encounter in the application of ShardingSphere.
+
+Currently, Apache ShardingSphere’s stable version has been updated to 5.1.2 and has been optimized in terms of its functions, performance, testing, documentation, and examples.
+
+You can refer to [Apache ShardingSphere’s official website](https://shardingsphere.apache.org/) for more information. If you have any questions or suggestions, you are also welcome to give feedback on [Github](https://github.com/apache/shardingsphere). The community will actively respond and discuss.
+
+Project Links:
+==============
+
+[ShardingSphere Github](https://github.com/apache/shardingsphere/issues?page=1&q=is%3Aopen+is%3Aissue+label%3A%22project%3A+OpenForce+2022%22)
+
+[ShardingSphere Twitter](https://twitter.com/ShardingSphere)
+
+[ShardingSphere Slack](https://join.slack.com/t/apacheshardingsphere/shared_invite/zt-sbdde7ie-SjDqo9~I4rYcR18bq0SYTg)
+
+[Contributor Guide](https://shardingsphere.apache.org/community/cn/involved/contribute/contributor/)
+
+[GitHub Issues](https://github.com/apache/shardingsphere/issues)
+
+[Contributor Guide](https://shardingsphere.apache.org/community/en/involved/contribute/contributor/)
diff --git a/docs/blog/static/img/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices1.png b/docs/blog/static/img/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices1.png
new file mode 100644
index 00000000000..2e87a7144ae
Binary files /dev/null and b/docs/blog/static/img/2022_09_02_First_Look_at_ShardingSphere_5.2.0_&_In-Person_Meetup_on_Massive_Data_Management_Practices1.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster1.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster1.png
new file mode 100644
index 00000000000..23063e17600
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster1.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster10.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster10.png
new file mode 100644
index 00000000000..e01a829ab6d
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster10.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster11.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster11.png
new file mode 100644
index 00000000000..455aac00537
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster11.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster12.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster12.png
new file mode 100644
index 00000000000..0868aa1fd0c
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster12.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster13.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster13.png
new file mode 100644
index 00000000000..9ab7e34a5ae
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster13.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster14.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster14.png
new file mode 100644
index 00000000000..818267e0809
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster14.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster15.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster15.png
new file mode 100644
index 00000000000..bc4c221c88c
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster15.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster16.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster16.png
new file mode 100644
index 00000000000..c3c24696286
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster16.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster17.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster17.png
new file mode 100644
index 00000000000..f3e34a53048
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster17.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster18.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster18.png
new file mode 100644
index 00000000000..8fcc89d6393
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster18.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster19.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster19.png
new file mode 100644
index 00000000000..da851325551
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster19.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster2.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster2.png
new file mode 100644
index 00000000000..9d38d5c5ce0
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster2.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster3.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster3.png
new file mode 100644
index 00000000000..bc169cc7e00
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster3.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster4.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster4.png
new file mode 100644
index 00000000000..51cdb81e7f2
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster4.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster5.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster5.png
new file mode 100644
index 00000000000..57fa4cda753
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster5.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster6.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster6.png
new file mode 100644
index 00000000000..dd738fe70d4
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster6.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster7.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster7.png
new file mode 100644
index 00000000000..56b0a05b869
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster7.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster8.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster8.png
new file mode 100644
index 00000000000..a522e29e6b8
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster8.png differ
diff --git a/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster9.png b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster9.png
new file mode 100644
index 00000000000..f4056fc0a1c
Binary files /dev/null and b/docs/blog/static/img/2022_09_06_Apache_ShardingSphere_Enterprise_User_Case_-_Energy_Monster9.png differ