Three types of data should not be stored in the database

Program = Data + algorithm. This is the simplest definition of a program. Without a doubt, a program will inevitably store a large amount of data. for data storage, most developers should immediately think of the database, however, not all data is suitable for storing in the database. We will share with you three types of data that are not suitable for storing in the database.

Images, files, and binary data

Since the database supports BLOB-type data, there must be no error in inserting the file into the BLOB field !? Wrong, not like this! In many database languages, it is not easy to process large fields.

There are many problems with storing files in the database:

• The read/write speed of the database will never catch up with the speed of File System Processing
• Database Backup has become huge and time-consuming
• Access to files must go through your application layer and database layer.

The last two are real killers. Store thumbnail images in the database? Well, you can't use nginx or other types of lightweight servers to process them.

Make it easy for yourself. Simply store the relative path of your files on the disk in the database, or use services such as S3 or CDN.

Short-lived data

Usage Statistics, measurement data, GPS positioning data, session data, and any data that is useful or frequently changed for you in a short period of time. If you find that you are using a scheduled task to delete data that is valid for only one hour, one day, or several weeks from a table, it means you have not found the correct method for doing things. Using redis, statsd/graphite, and Riak is a more suitable tool for doing this. This suggestion also applies to the collection of short-lived data.

Of course, it is also feasible to plant potatoes in the back garden with excavators, but instead of taking out a shovel from the storage room, you reserve a excavator and wait for it to rush to your garden to dig holes, this is obviously slower. You need to select a proper tool to handle the tasks at hand.

Log Files

Storing log data in a database seems to be good on the surface, and "I may need to perform complex queries on this data in the future" is quite impressive. This is not a very bad practice, but it is very bad if you store the log data and your product data in a database.

Maybe your logging is quite conservative, and only one log is generated for each web request. For every event on the entire website, this will still produce a large number of database insertion operations, competing for the database resources required by your users. If your log level is set to verbose or debug, check that your database is on fire.

You should use some plain text files such as Splunk logugly to store your log data. It may be inconvenient to view them in this way, but there are not many such cases. Sometimes you need to write some code to analyze the answer you want, but it is worth it in general.

Articles you may be interested in

• Rational use of MySQL database indexes to make the database run efficiently
• In php, we use the curl post method to submit data and the get method to obtain webpage data.
• How to optimize servers, static databases, and load balancing for high-traffic websites
• How to locate, eliminate and avoid MySQL database performance problems
• Php obtains all the files in the directory and saves the results to the array program.
• Mysql Server master-slave Database Synchronization Configuration
• Where is the CMS database configuration file?
• How to modify the character set of a mysql database