Shulou(Shulou.com)06/03 Report--

This article mainly explains "how Mysql uses NOSql to speed up high concurrency systems". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how Mysql uses NOSql to accelerate high concurrency systems".

NoSQL

NoSQL generally refers to non-relational databases. Now people prefer to translate into not only sql

According to the storage and other characteristics of NoSQL, it can be divided into the following categories

Key value (Key-Value) stores the database. Related products: Redis, Riak, SimpleDB, Chordless, Scalaris, Memcached. It mainly solves the problem that the relational database can not store the data structure.

Column stores the database. Related products: BigTable, HBase, Cassandra, HadoopDB, GreenPlum, PNUTS. Solving the problem of "I / O" in the scene of big data, a relational database

Document database. Related products: MongoDB, CouchDB, ThruDB, CloudKit, Perservere, Jackrabbit. Solve the problem of strong schema constraint in relational database.

Graphic database. Related products: Neo4J, OrientDB, InfoGrid, GraphDB. Mainly solve a large number of complex, interconnected, low-structured graph structure situations, such as social networks, recommendation systems, etc.

Full-text search engine. Related products: Elasticsearch. It mainly solves the problem of full-text search performance of relational database.

Thus it can be seen that no kind of NoSql is perfect, and each Nosql has its own areas of expertise, which is also an important factor to be considered in our system architecture.

Scenario 1

In the commodity design process of e-commerce, the attributes of each commodity are different, the number of attributes is different, the attribute name is different, the same commodity may belong to multiple categories, and with the development of business, many goods will add new attributes. and the biggest headache for programmers is that each attribute may have the possibility of search (of course, search can be realized by search engines). In such a requirement scenario, if you use a relational database to store, the table will have a lot of fields, and the definition of fields is very troublesome.

Such a scenario is ideal for document databases in NOsql, such as MongoDB. It is very simple to add new fields in document database. Unlike relational databases, which need to execute DDL to add fields, you can directly use the program to read and write. Historical data will not be abnormal even if there are no corresponding fields. Most importantly, document databases are very good at storing data with complex structures, and generally business can take advantage of highly expressive json data structures.

{"Id": 1, "ProductName": "Durex enhanced", "Price": 100, "Type": [1,2,4], "Length": 20, "Height": 2}

If all product information is stored in mongodb, some scenarios are not perfect. For example, the problem of withholding inventory after the successful purchase of goods, the problem of joint query, due to the inherent lack of support for ACID in Nosql, a transactional operation is very difficult to achieve in Nosql, so in many cases when designing the system, relational database + Nosql is used to realize the business together.

Scenario 2

There are requirements scenarios for recording data and then doing statistics in many specific businesses, such as those systems that count uv,pv. The amount of log-based data is very large, and there may be peaks. If you use a relational database to store, it is likely that there will be a bottleneck on IO, and it may affect other normal business. Unfortunately, when executing statistical statements, the performance is even less satisfactory. This kind of log statistics business is very suitable for column Nosql like HBase. Business needs to count uv,pv data for a day, and HBase is very suitable for the scenario of counting a column of data, because only the corresponding columns need to be counted. Unlike relational databases, all rows need to be loaded into memory, and column storage generally has a larger compression ratio and takes up less disk space than row storage.

The application scenarios of column storage have certain limitations, which are generally used in statistics and big data's analysis.

Scenario 3

There is a cache design in most high concurrency systems, and the general data structure of cache is Kmurv structure. Cache is an effective means to improve system performance, because it needs to provide fast access, the cache is generally placed in memory. For example, now we want to design a user management system, in which each user information can be cached to provide high-speed access. Because many systems use distributed deployment, it is not advisable to use in-process caching. At this time, we need a high-speed external storage to provide this kind of service, which is one of the typical application scenarios of KV Nosql. Represented by redis, user id can be used as key in specific business, and user information can be stored in redis for value, and redis can be clustered after 3.0, which can help the business side in terms of high availability and expansion. Redis supports many data types, and different data types are selected in different scenarios.

Scenario 4

When a system has search business, if the search conditions are some simple types of search, the relational database can still be satisfied, but if there is full-text search, which is the like'% xx%' search that we usually write by sql, relational database may not be the best choice, full-text search engine type Nosql may be a better solution, with Elasticsearch as the representative. The search conditions of full-text search engine can be arranged and combined at will, and the fuzzy matching of relational database like can be realized.

The technical principle of full-text search engine is called "inverted index" (inverted index), which is an indexing method, and its basic principle is to build an index from words to documents. In contrast, it is a "positive index", which is based on the principle of indexing documents to words.

Scenario 5

The most common example in social systems is the relationship between people in social networks. The effect of relational database used to store "relational" data is not good, and its query is complex, slow and beyond expectations, and the unique design of graphical database just makes up for this defect. to solve the problem of weak function of relational database in storing and dealing with complex relational data.

At this point, I believe you have a deeper understanding of "how Mysql uses NOSql to accelerate high concurrency systems". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.