Distributed mysql sub-database sub-table middleware, a one-stop solution in the field of sharding. With rich and flexible routing algorithm support, it is convenient for DBAs to realize the horizontal expansion of the library and reduce the cost of data migration. Shark adopts an application integration architecture, giving up generality in exchange for better execution performance and reducing the risk of downtime of peripheral systems in a distributed environment. At present, shark provides hundreds of millions of SQL read/write services for different enterprises and businesses every day.
Advantages of Shark
Complete technical documentation support;
Seamless switching of dynamic data sources;
Rich and flexible distributed routing algorithm support;
Non-proxy architecture, the application is directly connected to the database, reducing the risk of downtime caused by the dependence of peripheral systems;
Zero business intrusion and simple configuration;
Standing on the shoulders of giants (springjdbc, sqlparser based on druid completes sql parsing tasks), the execution performance is efficient and stable;
Provide API support for multi-machine sequenceid to solve the problem of multi-machine sequenceid;
The default support is based on zookeeper, redis3.x cluster as a centralized resource configuration center;
Rendering content based on velocity template engine, supporting independent configuration and dynamic splicing of SQL statements, and decoupling from business logic code;
Provide a built-in verification page to facilitate development, testing and operation and maintenance personnel to verify the executed SQL;
Provide API support for automatically generating configuration files to reduce configuration error rates;
Shark's overall architecture
Shark adopts an application integration architecture, and its domain model is located between the persistence layer (JdbcTemplate) and JDBC, that is, the distributed data layer.
Comparison of Shark and other Sharding middleware functions
| Function | Cobar | Mycat | Heisenberg | Shark | TDDL | Sharding-JDBC |
| Is it open source | open source | open source | open source | open source | Partially open source | open source |
| Architecture model | Proxy Architecture | Proxy Architecture | Proxy Architecture | Application Integration Architecture | Application Integration Architecture | Application Integration Architecture |
| Database support | MySQL | any | any | MySQL | any | MySQL |
| peripheral dependency | without | without | without | without | Diamond | without |
| use complexity | generally | generally | generally | Simple | complex | generally |
| Technical Documentation Support | less | pay | less | rich | without | generally |
Notes on the use of Shark
Distributed transactions with strong consistency are not supported. It is recommended to rely on MQ at the business layer to ensure final data consistency;
It is not recommended and does not support multi-table query. All multi-table query sql must be broken up into a single sql and executed one by one;
The first parameter of the sql statement must be the shard key;
The shard key must be an integer type;