<<
The NoSQL Concept
With the rapid development of web 2.0, non-relational and distributed data storage has seen fast growth. They do not guarantee the ACID properties of relational data. The NoSQL concept was introduced in 2009. The most common interpretation of NoSQL is “non-relational,” while “Not Only SQL” is also widely accepted. (The term “NoSQL” was first used in 1998 as the name of a lightweight relational database.)
The most common use of NoSQL for us is key-value storage, though there are also document-based, column-family, graph, and XML databases. Before the NoSQL concept emerged, these databases were already used in various systems but rarely in web applications, such as cdb, qdbm, and bdb databases.
Bottlenecks of Traditional Relational Databases
Traditional relational databases offer decent performance, high stability, a long history of proven use, ease of use, powerful functionality, and a large number of success stories. In the Internet realm, MySQL has become the absolute king. It is no exaggeration to say that MySQL has made outstanding contributions to the development of the Internet.
In the 1990s, website traffic was generally low, and a single database could easily handle the load. At that time, most sites were static, and dynamic, interactive websites were rare.
Over the last decade, websites began to develop rapidly. Hot forums, blogs, SNS, and microblogs gradually led the trends in the web field. In the early days, forum traffic was actually not very high. If you have been online long enough, you might remember text-file-based forum software, which gives you an idea of the traffic volume back then.
Memcached + MySQL
Later, as traffic increased, almost most websites using a MySQL architecture started experiencing database performance issues. Web programs no longer focused solely on functionality but also began pursuing performance. Developers started extensively using caching technologies to relieve database pressure and optimizing database structures and indexes. Initially, file-based caching became popular to ease database load, but as traffic continued to grow, file caches could not be shared among multiple web servers, and a large number of small cache files also caused high IO pressure. At this point, Memcached naturally became a very fashionable technical product.
As an independent distributed cache server, Memcached provides a shared, high-performance caching service for multiple web servers. On top of the Memcached server, extensions were developed to spread cache across multiple Memcached instances based on hashing algorithms. Then, consistent hashing emerged to solve the problem of mass cache invalidation caused by re-hashing when adding or removing cache servers. Back then, if you went to an interview and mentioned you had Memcached experience, it would definitely be a plus.
MySQL Master-Slave Read/Write Separation
As database write pressure increased, Memcached could only relieve the database’s read pressure. Having both reads and writes concentrated on a single database overwhelmed it. Most websites began using master-slave replication technology to achieve read/write separation, improving read/write performance and the scalability of the read databases. MySQL’s master-slave model became a standard configuration for websites at this stage.
Table and Database Sharding
With the continued high-speed development of web 2.0, even with Memcached high-speed caching and MySQL master-slave replication for read/write separation, the write pressure on the MySQL master database started to bottleneck. Meanwhile, data volumes continued to surge. Because MyISAM uses table-level locking, it suffered severe locking issues under high concurrency. Many high-concurrency MySQL applications began switching to the InnoDB engine to replace MyISAM. At the same time, table and database sharding became popular to alleviate write pressure and data growth scalability issues. Sharding became a hot technology topic, both in interviews and industry discussions. It was also around this time that MySQL introduced its still somewhat unstable table partitioning feature, which brought hope to companies with average technical strength. Although MySQL released the MySQL Cluster suite, it had almost no success stories on the Internet and its performance could not meet Internet demands, even though it provided very high reliability guarantees.
MySQL’s Scalability Bottleneck
In the Internet context, most MySQL instances should be IO-intensive. In fact, if your MySQL is CPU-intensive, it is very likely that your MySQL design has performance issues and needs optimization. MySQL application development under big data and high concurrency conditions is becoming increasingly complex and technically challenging. Mastering the rules of table and database sharding requires experience. Although companies with strong technical capabilities like Taobao have developed transparent middleware layers to shield developers from complexity, the complexity of the overall architecture remains unavoidable. Sharded databases face expansion issues again at certain stages. Furthermore, changes in requirements might necessitate a new sharding strategy.
MySQL databases often store large text fields, causing database tables to become very large. This makes database recovery extremely slow and difficult to perform quickly. For example, 10 million 4KB text entries total nearly 40GB in size. If this data could be removed from MySQL, MySQL would become significantly smaller.
Relational databases are powerful, but they cannot perfectly handle all application scenarios. MySQL’s poor scalability (requiring complex techniques to implement), high IO pressure under large data volumes, and difficulty in changing table structures are the exact problems developers using MySQL currently face.
Advantages of NoSQL
Easy Scalability
There are many types of NoSQL databases, but a common feature is the removal of the relational characteristics of relational databases. Data has no relationships, making it extremely easy to scale. This inherently brings scalable capabilities at the architectural level.
Large Data Volumes, High Performance
NoSQL databases all have very high read and write performance, performing excellently especially under large data volumes. This benefits from their non-relational nature and simple database structure. Typically, MySQL uses Query Cache, where the cache is invalidated every time a table is updated. This is a coarse-grained cache, and for interactive web 2.0 applications, its cache performance is not high. NoSQL’s Cache, however, is record-level—a fine-grained cache—so NoSQL achieves much higher performance on this level.
Flexible Data Models
NoSQL does not require pre-defining fields for data to be stored; custom data formats can be stored at any time. In relational databases, adding or deleting fields is a very troublesome task. For tables with very large data volumes, adding a field is practically a nightmare. This is especially evident in the era of high-data-volume web 2.0.
High Availability
NoSQL can easily achieve a highly available architecture without significantly impacting performance. Models like Cassandra and HBase can also achieve high availability through replication models.
Summary
The emergence of NoSQL databases compensates for the deficiencies of relational databases (like MySQL) in certain areas, greatly saving development and maintenance costs in some respects.
Both MySQL and NoSQL have their own characteristics and applicable use cases. The close integration of the two will bring new ideas to the database development of web 2.0. Let relational databases focus on relations, and NoSQL focus on storage.
References
- NoSQL: http