comprehensive discussion on StackOverflow and Linkin, as well as my personal work experience:Redis Scenario (Memcache can be replaced with Redis in most scenarios, so not discussed separately)
- High performance requirements for on-line business, read and write
- Non-massive data (single GB level)
- Multi-machine sharing operation, such as session
- Support transactions (but not as well as imagined, logically prone to problems)
- Excellent native data structure
- Small atomic operations (e.g. counters)
- Not suitable for n-tier structure data processing, or can be used for storage but it is best not to update, in the case of hash, including the Redis instance (an instance is also equal to the Key-value dictionary) itself, only two layers of structure, no more can not use atomic Operation command, Content can only be stored as JSON and other structures, not easy to modify.
Traditional database application scenarios such as MySQL
- Relatively small amount of data (relatively, tens above data can be processed but not recommended)
- Insert/update/select cannot be very frequent at the same time (basically only read and write less is more acceptable application range)
- Business with high reliability requirements
- A single business operation requires complexity and frequent changes, but the frequency of operation is not high. (such as operations management platform, etc.)
- BI business, requires a highly optimized query, ES and the like may get the same results, but the efficiency is not able to do this
Hadoop Application Scenario
- Large amount of data (applicable when single machine and common cluster cannot be processed)
- High scalability
- Data can best be organized into a row of comparative rules
- There are more Join/group class operations/collection operations, or more complex computing requirements (compared to search queries such as ES, the script can be very complex).
- Low immediacy, primarily for offline analysis and processing
- Building and managing relative hassles (such as Redis and MySQL can be easily built and maintained by regular technicians)
Elasticsearch Application Scenarios
- It is first a search engine rather than a data store (which can actually be used as storage, but not as good as a lot of dedicated storage, but probably enough for small businesses)
- is an efficient data analysis engine that comes with analytic syntax and is more powerful than other tools
- Not an all-in-one data analysis tool, such as join query support is not good
- The primary goal of the analysis is data columns
- Large data volume, variable column, all columns may have query requirements (different from MANGODB)
- Large number of new data inserts, large number of search, a small number of update (frequent update will cause the index to change frequently, IO, etc. will be greatly affected)
- With historical snapshot versions, you can find old data that has been deleted (and, of course, takes up more space).
MongoDB Application Scenario
- Key-value Document storage view
- Does not require the same column (similar to ES)
- The primary goal of the analyzed operation is the data row
- Data with a large storage capacity but lower value
- Storing JSON-and object-type data
- A small number of indexes with memory and performance bottlenecks if there are too many indexes
- A large number of high performance-demanding online services are not suitable
Application scenarios for various data processing scenarios (Sql,nosql, others)
