[Post] Three things that cannot be put into the database

 

Original article: http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/

Translator: cxhuan

like what I said in some speeches, the best way to improve system performance is to never do anything silly ". I am not saying that you or your developers are dummies, but that people are easy to ignore the invisible problems of these decisions and are not aware of the maintainability of some problems. As a consulting consultant, I have seen many such cases and I have never seen anyone who can solve this problem well.

Image, file, and byte data
Your Database supports large-capacity binary data, so you think you should put your files in, right? This is not the case at all. In this way, it is not even convenient to bind multiple database languages. There are several problems in storing files in the database:
Reading/writing data to the database is always slower than the File System
Database Backup is massive and time-consuming
When accessing files, you must use the application layer and database layer.
The last two are the real evils. Put the thumbnail into the database? Good, but now you cannot use proxies or other lightweight Web servers to support them.
Save your effort, store a relative path on your hard disk file to the database, or replace it with something similar to S3 or CDN.

Temporary data
Statistical metric data, GPS location information, session data, any data that only uses short time or frequently changed data is temporary data. If you find that you spend a lot of time deleting tables that only use one hour, one day, or one week, you will use the wrong tool. Use Redis , Statsd / Graphite , Riak Or any more Work with appropriate tools. This method also applies to aggregated temporary data. Instead of waiting for the excavator to arrive at you to dig a pitfall tomato, it is better to dig the shovel in the garage. Select appropriate tools for doing things.

Logs
On the surface, this log seems like it can be put into the database, and the comment "I may need to use complex query statements to query them in the future" seems more impressive. It is not terrible to store logs into the database. What is terrible is to put the logs into the same database as other products. You may be conservative about logs. Generally, each Web request is put in the same log line. In this way, an insert record will still be generated for each action of the website to compete for resources. Set your log level to redundancy or debugging to replace a simple file system such as splunk, logugly, or the old one, Do not put it into the product database. You need to check them occasionally. Sometimes you even need to write a short section.CodeLooking for data is easier than placing fixed resources in your system.
You are an independent individual, and your problems are different, so it doesn't matter if you do one of them.No, this is not the case.Believe me.