Database For The Mobile App Backend

In the app back-end Development, the database is critical, Should we choose MySQL? Redis? MongoDB?

Storing your data: Redis, MongoDB, and MySQL  – Chinese SEO Marketing

Data involves the two issues of reading and writing. For performance considerations, the faster the read and write speeds, the better.

In a computer, data is generally stored in memory or hard disk. As we all know, the read and write speed of the memory is much faster than that of the hard disk. Therefore, in order to obtain faster reading and writing speed, the data should be placed in memory as much as possible.

However, memory capacity is very limited. For example, on a cloud server, you can only have up to 64G of memory, while a single hard disk on a cloud server can be as high as 1000G.

Redis data is stored in the memory of the server. When the memory is full, Redis will not serve anymore. Of course, in order to prevent data loss, you can use the configuration file to make a backup of the data on the hard disk.

MongoDB is mainly stored in memory. If MongoDB finds that the memory is full and the data can no longer fit, MongoDB will store the new data on the hard disk. If it is a distributed architecture, there is basically no need to consider that the data will be stored on the hard disk.

MySQL data is placed on the hard disk. Although MySQL also has a cache, MySQL caches the results of the query, not the data.

Looking Up Your Data: Redis, MongoDB, and MySQL – Top App Developer in Vancouver

If you want to find a specific unit in the building, but you don’t know the unit number of the room, the only solution is to check every single unit. However, if you know the unit number, searching for the specific unit will become much more simple.

Redis data is stored based on “key-value pairs”, “key” is equivalent to unit number, and “value” is equivalent to room. Redis searches for data and goes straight to the target every time. That makes the reading and writing speed fast.

In MongoDB and MySQL, each group of data has an id (or an index can be built for each group of data), and this id or index is equivalent to the unit number.

There are two modes for searching data in MongoDB and MySQL, know the id or index, and don’t know the id or index. Knowing the id or index is equivalent to knowing the unit number, then just go straight to the goal, which is very efficient. If you don’t know the id or index to find the data, it is equivalent to looking for each room one by one on each floor, which is very inefficient.

Redis, MongoDB, and mysql application:

Redis applicable scenarios:

Data read and write speed is fast, but because Redis data is only stored in the memory of the server; so storage is very limited.

At the same time, the data stored in Redis must be in the form of key-value pairs, the key must be known when reading and writing redis data, which needs to be considered.

Therefore, in the app backend, we use Redis to handle the busiest data. For example, in social apps, many operations need to verify the user’s login information – Redis can apply in this situation.

After the user logs in, the server will return a token string to the user. Assuming that the token string is “abcdsdf”, the token string has been registered in the server, and the token string is associated with the user’s information. This token string can query the user’s information.

When it encounters the user’s login information that needs to be verified, it passes the token string to the server, and the server searches for the user’s information based on the token’s information.

In social apps like Facebook, when you need to verify your ID, Redis was applied. 

MongoDB application:

• Website data: mongo is very suitable for real-time insertion, update, and query, and has the replication and high scalability required for real-time data storage of the website.
• Caching: Due to its high performance, mongo is also suitable as a caching layer for information infrastructure. After the system restarts, the persistent cache built by mongo can avoid overloading the underlying data sources.
• Large-size, low-value data: It may be more expensive to store some data using traditional relational databases. Before that, many programmers often chose traditional files for storage.
• Highly scalable scenarios: mongo is very suitable for databases composed of dozens or hundreds of servers.
• Store the data of geographic coordinates. Mongo supports very powerful geographic coordinate queries, for example, users who can be within a certain rectangular range. Very suitable for the application of LBS.

What MongoDB is not suitable:

• Highly transactional systems: such as banking or accounting systems. Traditional relational databases are currently more suitable for applications that require a large number of atomic and complex transactions. For example, for operations involving money, suppose you want to transfer money, you must deduct money from one account, and then transfer money to another account. This operation must ensure that either both are completed, or neither is done, not just one. Unfortunately, since MongoDB does not support transactions, there is no guarantee.
• Traditional business intelligence applications: BI database for specific problems will produce highly optimized query methods. For such applications, a data warehouse may be a more suitable choice.
• Questions that require SQL. Although MongoDB supports query methods similar to SQL, its query still has a certain gap compared with MySQL.

MySQL applicable scenarios:

　　a. Transactional system. For example, the transfer example in MongoDB
　　b. Issues that require complex SQL.