One of the frequently asked questions in the development of app backend is: where is the data placed? Mysql? Redis Mongodb?
Now that there are so many good open source database products, how to choose the right data according to the business scenario?
What are the advantages and disadvantages of common database products?
By reading this article, you will be able to solve the above doubts and make your thinking clearer when you encounter data storage selection problems.
1. Redis,mongodb,mysql the difference between stored data
Data, it involves both the reading and writing of these two issues. For performance reasons, of course, the faster you read and write, the better.
Computer, the data is generally placed in memory or hard disk, it is known that the memory read and write faster than the hard disk. Therefore, in order to get faster read and write speeds, the data is placed in memory as much as possible.
However, the capacity of the memory is very limited, for example, on Ucloud server, can only have up to 16G of memory, and Ucloud on the server of a single hard disk, up to 1000G.
Redis data is placed in the server's memory, when the memory is full, Redis is not broken (now only a third-party distributed solution, the official distributed solution will be in the 3.0 version only.) ）。 Of course, in order to prevent data loss, you can make a backup of the data on the hard disk through the configuration file.
MongoDB data is mainly in memory, if MongoDB found that the memory is full, the data can no longer be put down, MongoDB put the new data on the hard disk. If you are using a distributed architecture, it is essential that the data is placed on the hard disk.
The MySQL data is placed on the hard drive. Although MySQL also has a cache, MySQL caches the results of the query rather than caching the data.
2. Redis,mongodb,mysql the difference between finding data
If you want to find a room in a building, but you do not know the room number, only remember this room door is very special, that the only way to find this room only each floor room to find once, until found this room.
If you know the number of the room, it is very simple, just straight to the floor.
Redis data is based on "key-value pairs" storage, "key" equivalent to house number, "value" equivalent to room. Redis looks for data, and every time it goes straight to the target, the reading speed is certainly high.
In MongoDB and MySQL, each set of data has an ID (or can be indexed for each set of data), which is equivalent to the house number.
MongoDB and MySQL find data, there are two modes, know ID or index, and do not know ID or index. Know the ID or index, it is equivalent to know the number, then go straight to the target, the efficiency is high. If you do not know the ID or index of the case to find data, it is equivalent to each floor of the room to find, efficiency is very low.
3. Redis,mongodb,mysql Application Scenario
Redis Application Scenarios:
Data reads and writes fast, but because Redis data resides only in the memory of one server (and now only a third-party distributed solution, the official distributed solution will be available in version 3.0), storage data is limited.
At the same time, because the data stored by Redis must be in the form of a key-value pair (key-value), you must know the key when reading and writing Redis data, which needs to be considered.
Therefore, in the app backend, the most read-write efficiency, the most frequent reading of the data will generally be placed in the Redis (of course, this part of the data also exists in MySQL or MongoDB, redis data is a redundancy, when the data update, both parts are updated).
For example, in social apps, a lot of operations need to verify the user's login information, how do you generally do?
After the user logs in, the server returns a token string to the user, assuming that the token is "ABCDSDF", the token is already registered in the server, and the Tokentoken string is associated with the user's information. The user's information can be queried by this token string.
When encountering the need to verify the user's login information, the token string to the server, the server based on the token information, the server to find the user's information.
In social apps, most operations require this verification, which can be seen as a very frequent operation, and this operation needs to be done in a very short period of time.
Then, the token string and the user's information, it is suitable for the Redis, the token string as a key (key), the user's information as a value, find it very convenient and efficient.
Of course, verifying the user's login information also requires a lot of security measures, here only one of the simplest model, in the future of the "app Communication Security" article will say the perfect security measures.
MongoDB Application Scenario:
A. Website data: MONGO is ideal for real-time inserts, updates and queries, as well as the replication and high scalability required for real-time data storage on the site.
B. Caching: Because of its high performance, MONGO is also suitable as a caching layer for the information infrastructure. After the system restarts, the persistent cache built by MONGO can avoid overloading the underlying data sources.
C. Large-size, low-value data: It may be expensive to store some data using a traditional relational database, before which many programmers often choose to store traditional files.
D. Highly scalable scenario: The MONGO is ideal for databases consisting of dozens of or hundreds of servers.
E. Storing data for geographic coordinates. MONGO supports very powerful queries for geographic coordinates, such as users that can be within a rectangular range. Ideal for lbs applications.
MongoDB does not fit the scene:
A. A highly functional system: such as a bank or accounting system. The traditional relational database is still more suitable for applications that require a large number of atomic complex transactions.
For example, if you want to transfer money, you must deduct money from one account and then transfer money to another account. This operation must be guaranteed to be either two complete, or two do not do, not just one. Unfortunately, MongoDB does not support transactions, so there is no guarantee.
B. Traditional business intelligence applications: a BI database for a specific problem will produce highly optimized query methods. For such applications, the Data warehouse may be a more appropriate choice.
C. A problem that requires SQL. Although MongoDB supports SQL-like queries, its query is still a gap from MySQL.
MySQL application scenario:
A. A system of things. Example of a transfer example in MongoDB
B. A problem that requires complex SQL.
Simply put, after considering the data is not suitable for Redis and MongoDB, then put the data in MySQL bar ^ ^
--------------------------------------------------------------------------------------------------------------- ------------
Open the total list of articles in the Link app backend series to see all the original "app backend" articles I've published.
"Author" Zeng Jiansen
"QQ" 190678908
"QQ Group" 254659220
"public number" Appbackend
"Sina Weibo" @newjueqi
"blog" Http://blog.csdn.net/newjueqi
12.app backend How to select the right database product
