NoSQL products are getting increasingly popular. NoSQL products are generally developed with high performance and high performance.ScalabilityHigh Fault Tolerance is everyone's praise. When we ask why NoSQL becomes popular, we may ask why these features become so important.
- We're re dealing with much more data. although advances in storage capacity and CPU speed have allowed the databases to keep pace, we're in a new era where size itself is an important part of the problem, and any significant database needs to be distributed.
- As the number of datasets to be processed increases, the storage capacity of these datasets far exceeds the capacity of a single machine, and the data processing needs far exceed the computing capacity of the single machine CPU. So we needDistributed.
- We require sub-second responses to queries. in the '80s, most database queries cocould run overnight as batch jobs. that's no longer acceptable. while some analytic functions can still run as overnight batch jobs, we 've seen the web evolve from static files to complex database-backed sites, and that requires sub-second response times for most queries.
- We have higher and higher requirements on data delivery speed. In 1980s, many operations may need to run all night. However, this kind of thing becomes unacceptable now. We can tolerate complicated statistical analysis, but quick response is essential for website applications.
- We want applications to be up 24/7. Setting up redundant servers for static HTML files is easy, but a database replication in a complex database-backed application is another.
- We need to provide 7 × 24 services. If your website has only one static page, it is estimated that the problem is not big. You just need to make the WebServer fault tolerance. If you are a dynamic website with databases and caches, you must perform fault tolerance and automatic failover at the data layer.
- We're re seeing processing applications in which the database has to soak up data as fast (or even much faster) than it processes queries: in a logging application, or a distributed sensor application, writes can be much more frequent than reads. batch-oriented ETL (extract, transform, and load) hasn't disappeared, and won't, but capturing high-speed data flows is increasingly important.
- Many application scenarios require the data layer to provide higher Write Performance and data throughput. For example, for log-type applications, the write performance requirements may be very high. When the write performance becomes a bottleneck, it is usually difficult for us to upgrade the standalone configuration. Therefore, distributed requirements become important here.
- We're re frequently dealing with changing data or with unstructured data. the data we collect, and how we use it, grows over time in unpredictable ways. unstructured data isn' t a special new feature of the data landscape, since unstructured data has always existed, but we're re increasingly unwilling to force a structure on data a priority.
- Our demand for storage and processing of unstructured data is increasing. In this changing world, applications in the Internet field may become increasingly difficult to predefine data structures like software development.
- We're re willing to sacriice our sacred cows. we know that consistency and isolation and other properties are very valuable, of course. but so are some other things, like latency and availability and not losing data even if our primary server goes down. the challenges of modern applications make us realize that sometimes we might need to weaken one of these constraints in order to achieve another.
- Our application scenarios may have lower requirements for consistency, isolation, and other transaction features. On the contrary, we may have higher requirements for performance and scalability. Therefore, under the new requirements, we must make a choice, give up some excellent features we are used to, and obtain some new features we need.
