As MySQL ShardingSphere-Proxy has become more and more mature and widely adopted, the ShardingSphere team has also been working on PostgreSQL Shardingsphere-Proxy. Compared to alpha and Beta, 5.0.0 has a lot of improvements in PostgreSQL protocol implementation, SQL support, permission control, and other aspects, paving the way for the full integration of PostgreSQL ecosystem. The ecological docking between ShardingSphere-Proxy and PostgreSQL enables users to obtain incremental transparent capabilities such as data sharding, read/write separation, shadow library, data encryption/desensitization, and distributed governance based on the PostgreSQL database.
In addition to PostgreSQL, openGauss, an open-source Chinese database developed by Huawei, continues to gain popularity. OpenGauss has excellent stand-alone performance, combined with the capability and ecology of ShardingSphere, can create a domestic distributed database solution covering more scenes.
ShardingSphere PostgreSQL/openGauss Proxy currently supports data sharding, read/write separation, shadow library, data encryption/desensitization, distributed governance and most of the capabilities in the Apache ShardingSphere ecosystem. Gradually align ShardingSphere MySQL Proxy in the degree of perfection.
This article will introduce shardingSphere-Proxy 5.0.0 on PostgreSQL and the ecological docking with openGauss.
The authors introduce
Benedict goh
Apache ShardingSphere Committer, SphereEx Middleware Engineer. Currently focused on Apache ShardingSphere and its sub-project ElasticJob.
ShardingSphere – Proxy is introduced
Shardingsphere-proxy is an access end in the ShardingSphere ecosystem. It is positioned as a database Proxy transparent to clients. ShardingSphere Proxy is not limited to Java. It implements MySQL and PostgreSQL database protocols, and can connect and manipulate data using various clients compatible with MySQL/PostgreSQL protocols.
ShardingSphere-JDBC | ShardingSphere-Proxy | |
---|---|---|
The database | any | Database based on MySQL/PostgreSQL |
Connection consumption | high | low |
Heterogeneous language | Support for JVM-based languages such as Java | any |
performance | Low loss | Loss is slightly high |
There is no centralized | is | no |
Static entry | There is no | There are |
In the case of sub-database sub-table or other rules, data will be scattered to multiple database instances, which will inevitably have some inconvenience in management. Or developers using non-Java languages who need the capabilities provided by ShardingSphere… These situations are exactly what Shardingsphere-Proxy can do.
Shardingsphere-proxy hides the actual back-end database. For the client, it is just using a database. There is no need to care about how ShardingSphere coordinates the database behind, and it is more friendly to developers or DBAs who use non-Java languages.
In terms of protocol, ShardingSphere PostgreSQL Proxy implements Simple Query and most Extended Query protocols, and supports heterogeneous languages to connect to Proxy through PostgreSQL/openGauss drivers. ShardingSphere openGauss Proxy not only uses the PostgreSQL protocol, but also supports the opengAuss-specific bulk insert protocol.
However, because ShardingSphere-Proxy adds a layer of network interaction compared with ShardingSphere-JDBC, the delay of SQL execution will be increased and the loss will be slightly higher than shardingSphere-JDBC.
Ecological interconnection between ShardingSphere-Proxy and PostgreSQL
Compatible with PostgreSQL Simple Query and Extended Query
Simple Query and Extended Query are the protocols most users use when using PostgreSQL.
For example, when the following command line tool PSQL is used to connect to a PostgreSQL database for CRUD operations, the Simple Query protocol is used to interact with the database.
$ psql -h 127.0. 01. -U postgres
psql (14.0 (Debian 14.0-1.pgdg110+1))
Type "help" for help.
postgres=# select id, name from person where age < 35;
id | name
----+------
1 | Foo
(1 row)
Copy the code
The Simple Query protocol interaction diagram is as follows:
When using a Driver such as the PostgreSQL JDBC Driver, the following code may be PreparedStatement, which by default corresponds to the Extended Query protocol.
String sql = "select id, name from person where age > ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setInt(1.35);
ResultSet resultSet = ps.executeQuery();
Copy the code
Extended Query’s protocol interaction is shown as follows:
Currently, ShardingSphere PostgreSQL Proxy implements Simple Query and most Extended Query protocols. However, since database clients and drivers have encapsulated apis for users to use, The average user doesn’t need to care about the database protocol level.
Shardingsphere-proxy’s compatibility with PostgreSQL’s Simple Query and Extended Query means: Users can use a common PostgreSQL client or driver to connect to ShardingSphere-Proxy for CRUD operations, taking advantage of the incremental capabilities provided by ShardingSphere at the top of the database.
Ecological connection between ShardingSphere-Proxy and openGauss
Supports openGauss JDBC Driver
The openGauss database has a JDBC driver. The JDBC URL prefix is JDBC: openGauss. Although the PostgreSQL JDBC driver can connect to openGauss databases, it does not take full advantage of openGauss ‘unique features such as bulk inserts. ShardingSphere adds openGauss database type and can identify openGauss JDBC Driver. Developers can directly use openGauss JDBC Driver when using ShardingSphere.
Supports openGauss batch insert protocol
As an example, when we prepare an insert statement below
insert into person (id, name, age) values (?, ?, ?)
Copy the code
Using JDBC as an example, we might perform bulk inserts using the following methods:
String sql = "insert into person (id, name, age) values (? ,? ,?) ";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setLong(1.1);
ps.setString(2."Foo");
ps.setInt(3.18);
ps.addBatch();
ps.setLong(1.2);
ps.setString(2."Bar");
ps.setInt(3.36);
ps.addBatch();
ps.setLong(1.3);
ps.setString(2."Tom");
ps.setInt(3.54);
ps.addBatch();
ps.executeBatch();
Copy the code
On the PostgreSQL protocol level, Bind messages can transmit a set of parameters to form a Portal, and Execute can Execute a Portal at a time. Performing bulk inserts can be done by repeatedly executing Bind and Execute. Protocol interaction diagram is as follows:
Batch Bind
This is an openGauss specific message type, compared to the originalBind
.Batch Bind
Can pass multiple groups of parameters at a time, usingBatch Bind
The protocol interaction for performing batch inserts is as follows:
Shardingsphere-proxy openGauss implements support for the Batch Bind protocol, that is,Clients can directly use openGauss clients or drivers to perform bulk inserts to ShardingSphere Proxy.
What shardingSphere-proxy will do next
ShardingSphere PostgreSQL Proxy logical MetaData query is supported
Shardingsphere-proxy serves as a transparent database Proxy, and users do not need to care about how the Proxy coordinates the database behind it.
In the following figure, logical library Sharding_DB and logical table Person are configured in Shardingsphere-proxy. There are actually 4 tables in 2 databases behind Proxy.
Currently executed separately in ShardingSphere MySQL Proxyshow schemas
,show tables
Statement, the result of the query can list the logical library normallysharding_db
And the logical tableperson
.
When PSQL is used to connect to PostgreSQL, you can run the \l and \d commands to query libraries and tables. However, unlike MySQL, show tables is supported by MySQL. In PSQL, \d corresponds to a more complex SQL statement. Currently, the Logical library or logical table cannot be queried using ShardingSphere PostgreSQL Proxy.
Describe Prepared Statement that supports Extended Query
There are two variants of Describe messages for the PostgreSQL protocol, Describe Portal and Describe Prepared Statement. Currently, ShardingSphere Proxy only supports Describe Portal and does not support Describe Prepared Statement.
Obtain MetaData for a result set before the PreparedStatement is executed.
PreparedStatement preparedStatement = connection.prepareStatement("select * from t_order limit ?");
ResultSetMetaData metaData = preparedStatement.getMetaData();
Copy the code
The docking process between The ShardingSphere and the PostgreSQL/openGauss ecosystem is still in progress, and there is still much to be done. If you are interested in what we do, you are welcome to join the ShardingSphere community via GitHub or the mailing list.
Making: github.com/apache/shar…
The resources
- www.postgresql.org/docs/curren…
- Gitee.com/opengauss/o…
Welcome to add community Manager wechat (SS_assistant_1), enter the wechat communication group and communicate with more ShardingSphere enthusiasts