Php multi-database supported application design page 1/2

In the past, PHP applications were mostly used to query and update data in a single database. at most, they are also supported by master/slave databases, which is relatively simple to implement. The problem with the master-slave database is that when a session is stored in the database, synchronization may fail, that is, session interruption may occur. Therefore, I think all session-related tables should be specially treated in the master-slave database design. That is, all session data tables can be updated and queried. when a user accesses the site, the user is bound to the specified database. all session access and query operations are performed on the database. The session table is not synchronized, and other non-session updates are also updated from the primary database. In fact, this operation cannot avoid database switching during session update. if you don't want to bother, you can store the session in the text.
The database-based design may improve the performance by several grades. of course, the efficiency of a single execution is not higher than that of a single database. after all, there is a problem with the efficiency of database switching. Database Sharding and combination of master and slave databases can improve the database concurrency bottleneck. Principles: large data volume, Database Sharding, large access volume, master/slave. Most of the time, the two are parallel (this article does not discuss cache ).
I think if you want to implement Database Sharding and master-slave relationships, the number of database servers will be very large. switching to a server in an application at any time will be a headache, is there a lot of variable names? How to find better solutions will be discussed in this article.
First, Database Sharding causes many problems in the database. Under what circumstances is Database Sharding? Maybe some people still don't understand why Database Sharding is required. I will give a brief look at my experience. For example, a blog program is generally designed to store logs in a log table. Assume that a multi-user blog is used, a uid will be associated. if the data volume is small, this design is correct, but when the log volume is large, when there are hundreds of thousands of log entries in a day, and the access volume is also considerable, I don't think every user can access the log list, we can see the efficiency of finding tens of millions of log records from the data table. In this case, we should consider the Database Sharding issue. How to score? There is a simple table sharding method, that is, recording logs in each database based on the uid segment. of course, this distribution still needs to be adjusted based on the previous statistical results, because user logs are not evenly distributed. Set the uid segment, and then create a database object based on the uid index to the specified database configuration. The configuration information may be as follows:

$ Configs ['DB _ info'] ['blog '] [0] = array (
'Db _ host' => '2017. 168.0.1 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [1] = array (
'Db _ host' => '2017. 168.0.2 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [2] = array (
'Db _ host' => '2017. 168.0.2 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
//... There are many more

As for which server to choose, you only need to make a simple match based on the uid.
Next we will talk about the master-slave database. Under what circumstances does the master/slave database work? For example, if a celebrity blog has a very large access volume and there is no way to split its data, you have to consider the master-slave database server and use multiple databases for traffic distribution. In this case, master/slave databases and sub-databases should be applied, and the configuration information above may have to be slightly changed.

$ Configs ['DB _ info'] ['blog '] [0] ['master'] = array (
'Db _ host' => '2017. 168.0.1 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [0] ['Slave'] [0] = array (
'Db _ host' => '2017. 168.0.2 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [0] ['Slave'] [1] = array (
'Db _ host' => '2017. 168.0.3 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [1] ['master'] = array (
'Db _ host' => '2017. 168.0.4 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [1] ['Slave'] [0] = array (
'Db _ host' => '2017. 168.0.5 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['blog '] [1] ['Slave'] [1] = array (
'Db _ host' => '2017. 168.0.6 ',
'Db _ name' => 'blog ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['session '] [0] ['master'] = array (
'Db _ host' => '2017. 168.0.7 ',
'Db _ name' => 'session ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);
$ Configs ['DB _ info'] ['session '] [1] ['master'] = array (
'Db _ host' => '2017. 168.0.8 ',
'Db _ name' => 'session ',
'Db _ user' => 'root ',
'Db _ pass' => '',
);

Here, I think I should know how to split tables and allocate your database. Next, I will talk about how to easily read such configuration information, how to integrate these configurations into your database driver.