CA, to the database, to the machine, why also can not expand capacity?

This is a creation in Article, where the information may have evolved or changed.

As the business becomes more complex, the volume of data becomes larger and the concurrency is increasing, the performance of the database becomes lower. Finally find operations to apply for two machines, let the DBA deployed a few instances, want to put some business library split out, but found that can not be broken out, expand the capacity, embarrassment!

Because the database is strongly correlated, it is not possible to increase the capacity of the database instance, which is a typical case of coupling.

Scene restore

There is a public user database Db_user, in which Table_user stores common user Data :

Table_user (uid, name, passwd, ...)

When the data volume is small, the concurrency is small, the business is not so complex, in order to improve resource utilization (programmers do not consider what resource utilization, more is the diagram convenient), business A to the user personalized data is also placed in this library:

Table_a (uid, a business personalization attribute)

Business A has a need to present the user's public properties and to show the business a personalization attributes that programmers often implement:

SELECT * from Table_user, table_a

where Table_user.uid = Table_a.uid

and Table_user.uid = $uid

Initial correlation query without any problems, single record access, hit index, query all data at once, simple and efficient.

How to generate the business data coupling?

The business is implemented through join, which causes the common table table_user and the business table table_a to exist in a DB instance.

If business B does the same, business C will do the same, leading to public service, business A, business B, and business C all must exist in a DB instance .

What potential problems will arise?

If a business line a new function, accidentally performed a full table scan, resulting in database cpu100%, database instance performance degradation, because the instance is common, General Service, business B and business C will be affected.

That is, the sharp decline in database performance of a line of business leads to all business being affected, and this coupling, history is always strikingly similar:

• Business B's Big Boss in the group first to get mad: "The technology is what, how the system hung up "

• Rd for Business B a face of Innocence: " business A is on the line, so we hung up "

Well, the reason, however, seems to be that the big Boss doesn't explain ...

• Business B's Big Boss : " quickly add a few machines, split apart "

• Rd for Business B one face helpless: " add machine Add instance also can't enlarge "

• Business B's Big Boss to the Business 2nd Roar " still want to throw pot, dragged out to Heaven"

...

Alas, add a few machines, add a few instances, however, there is no egg, all coupled in an instance, completely expand the capacity.

So, how to decouple the public database from the business database?

First step: Public data access sinking service

Or the above example, when public user data access is serviced, based on the principle of service:

• The business layer can access data only through the service RPC interface

• The underlying user library belongs to the User Service private

• Any upstream does not allow access to the underlying user library across services

Second step: vertical split , personalized data access floating

Original Business Party:

• Get common data and personalized business data data at once with join

After service + vertical split, it becomes two accesses:

• Get Business data at once (the business can call its own database directly, or it can make its own business service call RPC interface)

• Get common data at once (call generic RPC interface)

Compared to the two methods:

• before the way In fact, the business code may be simpler because it puts the business logic in the SQL statement, but causes the database to be coupled together

• the latter way is that the code of the business will be more complex and will become multiple accesses, turning the logical computations originally made in SQL into logical computations in the business code , but the database is decoupled

Complex business, large data volume, concurrency Boss, the scalability of the higher requirements of the architecture, must be the latter.

At this time each business has its own library, the public has a public library:

• Early : Can be placed in a database instance

• Late : It is easy to split the user library or business a/b/c library by adding a new instance of the database to realize the expansion by increasing the number of instances of the machine .

Personalized Business data access vertical split , common data access service sinking , is only a small optimization point, but for the database decoupling is very effective.

I hope you get a little bit every day so that the architecture will be a little better.

Have you ever seen a library that's coupled with hundreds of of tables? Let's turn it down, please.

Related articles:

Small IP, big coupling, have you ever hurt?

Little Public Library, big coupling, have you ever hurt?