ElasticSearch
Course Recommendation →: "Elasticsearch Full Text Search Practical Combat" (Practical Video)
From the Course "Ten Million Level Data Concurrency Solution (Theoretical Practical Combat)"
Compared with MongoDB and Redis, ES, which was released a year later, may be less well-known, but ES's reputation in the search engine field is definitely resounding. Compared with other high-end database products, ES has a much more humble background.
The founder of ES, Shay Banon, was once an unemployed programmer. He created ES to facilitate his wife’s search for recipes when he had nothing to do (of course, it was not called ES at the time). Unexpectedly, through unintentional intervention, the most popular search engine database was created today. Sure enough, girls are the biggest motivation for programmers to work!
ES has also established its own Elastic company and has received hundreds of millions of dollars in financing. Shay Banon, the loser programmer at that time, has already counterattacked to become CEO and reached the pinnacle of his life. Programmers, after reading this story, have you already begun to imagine the day when you become CEO and marry Bai Fumei?
The characteristic of ES, as its name suggests, is search. Strictly speaking, ES is not a database, but a search engine, and all aspects of ES are designed around search. ES supports full-text search. Here is a brief explanation of what full-text search is: For data such as "I work in an Internet company in Beijing", if you search for keywords such as "Beijing", "Internet" and "work", you can hit this If there is a piece of data, this is full-text search. Baidu and Google that you use every day are full-text searches.
It is worth mentioning that ES’s full-text search also has good support for Chinese (there are many Chinese word segmenters alone), which can definitely meet the full-text search needs of most people in China. In addition to searching, ES will automatically index all fields for you to achieve high-performance complex aggregation queries. Therefore, as long as the data is stored in ES, no matter how complex the aggregation query is, you can get good performance, and You no longer have to worry about how to create various complex indexes.
Having said so many advantages of ES, do you think ES is almost omnipotent?
Unfortunately not, ES also has many shortcomings. The most obvious ones are that field types cannot be modified, low writing performance and high hardware resource consumption. As mentioned earlier, ES will automatically create indexes for you. Although this can bring many benefits to full-text search and aggregate queries and save you the trouble of building indexes, this feature will also bring a lot of problems.
ES needs to establish Mapping in advance before creating fields. Mapping contains type information of each field. ES needs to establish appropriate indexes for fields based on Mapping. Due to the existence of this Mapping, the type of a field in ES cannot be modified once it is created.
(For example, you forgot to add full-text search to a field in the data table you built. You want to add it temporarily, but the table has already been built and has a lot of data. What should you do at this time? No Sorry, you can only delete the entire data table and rebuild it again!)
Therefore, ES is higher than MySQL in data structure flexibility but far inferior to MongoDB. The shortcomings of ES are not limited to these. Automatic index creation also affects the writing performance of ES, which is significantly lower than MongoDB.
For the same data, the storage space occupied by ES is significantly larger than that of MongoDB (can you build so many indexes without taking up space?), and the consumption of hardware resources is also very powerful. A 64G memory SSD is basically used for large amounts of data. It is standard and can be regarded as an aristocratic service in the database. Therefore, if your boss is very stingy, you should be careful when choosing ES!
The full-text search feature of ES makes it a powerful tool for building search engines. In addition, ES supports complex aggregation queries very well. This feature also makes ES very suitable for data analysis.
In fact, ES has also specially made its own ELK suite to provide you with a one-stop service from log collection to data visualization analysis. It is definitely a powerful tool for building a high-end data analysis platform.
However, the shortcomings of ES's high cost and low writing performance also make it unsuitable for use in scenarios where the data value is not high, writing performance is required, the data volume is large, and the cost is limited. .
Redis
Redis is the most popular key-value database now. It was released in 2009 together with MongoDB and is also a masterpiece of databases in the early big data era.
The biggest feature of Redis is of course the simplicity and high performance brought by key-value storage. The so-called key-value storage means that each record only contains a Key for querying data, and the corresponding value for storing data, just like house numbers and residents in real life, without conventional databases such as tables and fields. Complex concepts that are necessary in , all queries rely only on key values.
Therefore, the key-value database can be said to be the simplest data structure in the database. Thanks to this simple structure, and the fact that Redis will load all data into memory, Redis can achieve much higher results. The read and write performance of conventional databases such as MongoDB. Of course, the function of Redis is not just as simple as key-value storage. Compared with its key-value predecessor Memcached, Redis also supports data persistence, various data structures such as list and set, and a series of functions such as master-slave replication and backup. Therefore, Redis is definitely the most comprehensive and easiest-to-use key-value database.
Redis’ key-value storage brings performance advantages, but it also brings many limitations to complex queries. Since important features such as data tables and fields are eliminated, and all queries rely on keys, Redis cannot provide complex query functions such as multi-column queries and section queries that conventional databases have.
At the same time, because Redis needs to store data in memory, this also greatly limits the amount of data that Redis can store, which also determines that Redis is difficult to use in application scenarios with large data scales.
Redis sacrifices functions such as data tables and complex queries in conventional databases in exchange for great performance improvements. It is especially suitable for those who have extremely high requirements for read and write performance and have simple data table structures (key-value , list, set, etc.), the query conditions are also simple application scenarios.
If your data table structure is quite complex and you often need to do some complex query operations, then you'd better stick to MongoDB or SQL.
For more Redis related knowledge, please visit the Redis usage tutorial column!
The above is the detailed content of The difference between es and redis. For more information, please follow other related articles on the PHP Chinese website!