Many problems don’t have just one solution, which means you can use this technique or that technique. The purpose of learning can be whatever you want, but in a real production environment it is strongly recommended to simplify your complexity and solve problems in the simplest way that you are most familiar with. Think about whether it is really necessary to use 2 databases to solve the same problem.
I was wondering if the song query part would be queried from MongoDB, would it be faster?
Maybe, maybe not. It depends on how much data you have, whether the data model design using MongoDB is reasonable, and... how much hardware resources you plan to invest in it. NoSQL focuses more on horizontal expansion, which means that it can still maintain query speed at a certain level even as the amount of data continues to increase. From personal experience, if there are tens of millions or hundreds of millions of data, MongoDB may really show its advantages. Before the data reaches this level, I don't think there is much need to introduce an additional database if it is just for speed. Compared with the benefits it brings to you and the complexity it causes, it can only be said that it is not cost-effective.
When you add or delete song information in the future, you need to synchronize it with MongoDB at the same time, right?
The issue of data synchronization depends on how high your requirements for "consistency" are. In the case of strong consistency, this is a distributed transaction, which is probably not a good thing for performance and goes against your original intention of speeding up the transaction. If you are considering eventual consistency, you can look at various MySQL to MongoDB ETL tools, such as Pentaho. Of course, it is possible to implement it through code yourself, but it is not easy to consider various fault tolerance issues.
First of all, you need to know clearly that MongoDB is a specific implementation of NoSQL. Unlike Redis, the data structure it stores is document-based.
Secondly, query speed is difficult to make arbitrary decisions based on differences between products or engines. It needs to be weighed based on actual usage. Not only that, what information is stored and how to store it also requires some analysis (if only The process can be simpler with practice).
I only learned MySQL before. Because of the uncertainty or complexity of the structure of some stored data, if I want to use MySQL alone to store it, I have to use many tables and set up foreign keys, so I also learned MongoDB to solve the needs.
What I am doing is a book practice practice, which is somewhat similar to songs from a certain perspective. For example, there may be more than one author of a book. If you use MySQL, the simple method is to use delimiters to store multiple authors in one field. There will be certain problems in later queries (complexity of judgment conditions and even performance), and a A song may also have more than one singer.
My practice is MySQL + MongoDB. Of course, it can also be achieved using only MongoDB, but I think the specific needs should be analyzed accordingly. My comprehensive practice is still going on, and I can communicate at any time, one of the ideas provided above.
I guess you may need functions such as finding songs based on lyrics. The Elasticsearch mentioned above is very good, and there is also sphinx, which is also very good for full-text search.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Many problems don’t have just one solution, which means you can use this technique or that technique. The purpose of learning can be whatever you want, but in a real production environment it is strongly recommended to simplify your complexity and solve problems in the simplest way that you are most familiar with. Think about whether it is really necessary to use 2 databases to solve the same problem.
Maybe, maybe not. It depends on how much data you have, whether the data model design using MongoDB is reasonable, and... how much hardware resources you plan to invest in it. NoSQL focuses more on horizontal expansion, which means that it can still maintain query speed at a certain level even as the amount of data continues to increase. From personal experience, if there are tens of millions or hundreds of millions of data, MongoDB may really show its advantages. Before the data reaches this level, I don't think there is much need to introduce an additional database if it is just for speed. Compared with the benefits it brings to you and the complexity it causes, it can only be said that it is not cost-effective.
The issue of data synchronization depends on how high your requirements for "consistency" are. In the case of strong consistency, this is a distributed transaction, which is probably not a good thing for performance and goes against your original intention of speeding up the transaction. If you are considering eventual consistency, you can look at various MySQL to MongoDB ETL tools, such as Pentaho. Of course, it is possible to implement it through code yourself, but it is not easy to consider various fault tolerance issues.
First of all, you need to know clearly that MongoDB is a specific implementation of NoSQL. Unlike Redis, the data structure it stores is document-based.
Secondly, query speed is difficult to make arbitrary decisions based on differences between products or engines. It needs to be weighed based on actual usage. Not only that, what information is stored and how to store it also requires some analysis (if only The process can be simpler with practice).
I only learned MySQL before. Because of the uncertainty or complexity of the structure of some stored data, if I want to use MySQL alone to store it, I have to use many tables and set up foreign keys, so I also learned MongoDB to solve the needs.
What I am doing is a book practice practice, which is somewhat similar to songs from a certain perspective. For example, there may be more than one author of a book. If you use MySQL, the simple method is to use delimiters to store multiple authors in one field. There will be certain problems in later queries (complexity of judgment conditions and even performance), and a A song may also have more than one singer.
My practice is MySQL + MongoDB. Of course, it can also be achieved using only MongoDB, but I think the specific needs should be analyzed accordingly. My comprehensive practice is still going on, and I can communicate at any time, one of the ideas provided above.
Elasticsearch makes queries faster and does not affect mysql performance
I guess you may need functions such as finding songs based on lyrics. The Elasticsearch mentioned above is very good, and there is also sphinx, which is also very good for full-text search.