Optimize MySQL, or use cache?

Today I want to compare the various performance optimization strategies that can be used on a Greenfield project. In other words, the project does not have the constraints imposed on it by previous decisions, and it has not yet been optimized.

Specifically, the two optimization strategies I want to compare are optimizing mysql and caching. Point out in advance that these optimizations are orthogonal and the only thing that makes you choose one over the other is that they both cost resources, i.e. development time.

Optimizing MySQL

When optimizing MySQL, you generally check the query statement sent to MySQL first, and then run the explain command. After a little scrutiny it is common to add indexes or make some adjustments to the schema.

Advantage

1. An optimized query is fast for all users of the application. Because the index retrieves data at a logarithmic complexity speed (aka fractional scale, just as you search a phone book, gradually narrowing down the search) and maintains good performance as the amount of data grows. Caching the results of an unindexed query can sometimes perform worse as the data grows. As the data grows, users who miss the cache may get a bad experience, and such applications are not available.

2. To optimize MySQL, you do not need to worry about cache invalidation or cache data expiration.

3. Optimizing MySQL can simplify the technical architecture, and it will be easier to replicate and work in the development environment.

Disadvantages

1. Some queries cannot be improved in performance only by indexing, and the schema may also need to be changed, which may be troublesome for some applications in some cases.

2. Some schema changes may be used for denormalization (data backup). Although this is a common technique for DBAs, it requires either ownership to ensure that all places are updated by the application, or triggers to be installed to guarantee such changes.

3. Some optimization methods may be unique to MySQL. That is, if the underlying software is ported to multiple working on the database , it is difficult to ensure that some more complex optimization techniques other than adding indexes can be generalized.

Using caches

This optimization requires someone to analyze the actual situation of the application, and then strip the expensive part of the processing from MySQL and replace it with a third-party cache, such as memcached or redis .

Advantages

1. The cache works well for some queries that MySql itself is difficult to optimize, such as large-scale aggregation or grouping queries.

2. Cache may be a good solution for improving system throughput. For example, when multiple people access the application at the same time, the response speed is very slow.

3. The cache may be easier to build on top of another application. For example: your application may be the front end of another package that uses MySQL to store data, and it is very difficult to make any database changes to this package.

Disadvantage

1. If data is provided in multiple access paradigms (eg, displayed in different forms on different pages), it may be difficult to expire or update the cache, and/or it may be necessary to tolerate expired data. A feasible alternative is to design a more elaborate caching mechanism, but of course it also has the disadvantage that fetching the cache multiple times will increase the latency.

2. Caching an expensive object may have a potential performance difference for users who miss the cache (see Optimizing MySQL Advantage #1). Some good performance practices suggest that you should try to minimize variance between users, not just average (caches tend to do this).

3. Naive cache implementations are incapable of dealing with subtle vulnerabilities such as avalanche effects. Just last week I helped a guy whose database server was overwhelmed by multiple user requests trying to regenerate the same cached content at the same time. The correct strategy is to introduce some level of locking to serialize requests for cache regeneration.

Original link: http://www.kubiji.cn/juhe-id5534.html