Shulou(Shulou.com)05/31 Report--

This article mainly introduces the example analysis of NoSQL technology, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Relational database is almost the only choice for many developers and DBA for traditional three-tier architecture applications. There are many reasons for using this scenario, such as data modeling method, query language and data interaction, ensuring the consistent deployment of data, and being able to serve complex applications.

However, this is not the only solution to all data storage problems, but also the cause of NoSQL. NoSQL provides a new approach rather than a standard SQL-oriented paradigm.

NoSQL technology is seamlessly integrated with high scalability, and many technologies have both high distribution and high performance, which is the storage cornerstone of big data's analysis. Most of the time, they make the architecture implemented by the existing RDBMS technology more complete, such as cache server, search engine, unstructured storage, variable information storage and so on. It is mainly divided into four categories:

Key/value

Column storage

Document-oriented storage

Graph storage

Now delve into the various technologies and choose the one that is most suitable for the scenario you use.

Key/Value

The first and earliest NoSQL data store is key/value. This data, like a dictionary, matches value according to key, and is usually used in basic information storage that requires high performance, such as session information that needs to be read and written quickly, which is very efficient and usually highly scalable in such scenarios.

Key/value is also often used for context queuing to ensure that data is not lost, such as log architecture or search engine index architecture. Redis and Riak KV are well-known key/value data stores; Redis is more widely used because it has a memory-based KWeiV storage and persistence is optional. Redis is often used in web applications to store session-related data, such as node or-

Web application of PHP; can extract thousands of session information per second without performance loss. Another typical scenario is serialization, which I'll talk about later: Redis sits between Logstash and ElasticSearch to store the indexes in the t ElasticSearch query.

Column

Column storage is needed to store a large amount of record information when it reaches the key/value storage limit. Column storage technology may not be easy for engineers in the RDBMS world to understand, but it is actually very simple. Data is stored by row in RDBMS and by column in column storage. The main advantage of using a column database is that it can access large amounts of data at high speed. One row of RDBMS is a continuous storage on the hard disk, and multiple rows may be stored in different locations on the hard disk, which makes access slightly more complex, and a column of data in the column database is continuously stored.

For example, consider querying the title of an indexed blog in RDBMS, especially when there are millions of data, which requires a lot of IO operations, while in a column database, such a query is only a visit. Such databases are very easy to extract large amounts of data from specific clusters, but there is a lack of flexibility. The most frequently used column storage database is

Google Cloud Bigtable, but the open source column storage databases are Apache HBase and Cassandra.

Another benefit of column storage databases is that they are easy to scale, and these columns are highly scalable when stored in large quantities. This is why they are mainly used to preserve non-volatile and long-term retention of information.

Document

Column storage databases are not the best for the storage of structured data with deeply nested structures, which requires document-oriented data storage. Data is actually stored in key/value, but all compressed data is called a document. The document depends on a structure or encoding such as XML, but more often it is JSON (JavaScript Object Notation).

Although document database is very useful for structured storage and expression of data, it also has its fragile side, especially the interactive operation with data. They basically traverse the entire document, for example, when reading a particular field, traversing may affect performance.

When you need to store nested information, you can use a document database. For example, consider how to express an account in an application with the following information:

Basic information: name, birthday, photo, URL, creation date, etc.

Complex information: address, authentication method (password, Facebook, third-party authentication, etc.), interest, etc.

This is why NoSQL document databases often use web applications: it is very easy to express nested objects, because they all use JSON, and can be seamlessly integrated with front-end JavaScript technology.

The most frequently used document databases are MongoDB, Couchbase, and Apache CouchDB, all of which are easy to install and start, are well documented, and are scalable, in addition to being a clear choice for open modern web applications.

Graph

Graph database is essentially different from other databases. It uses different paradigms to express data-tree structure, nodes and edges connected together called relationships. These databases were born with social networks, such as expressing users' friend networks, their friend relationships, and so on. For other types of data storage, it is possible to store a user's friend relationship in a document, but storing a friend relationship is still very complex; using a graph database is very simple, creating nodes for each friend, connecting them through relationships, and browsing the diagram depending on the needs and scope of the query.

The most famous graph database is Neo4j, which, as mentioned earlier, is mainly used to deal with complex relational information, such as connections between entities, and can also be used for classified scenarios.

Figure 2-1 shows how three entities are connected in the graph database.

The two-day account nodes Jane and John in the figure, each of which defines their relationship, gets to know each other one day, and the two accounts connected by the other set of nodes show that Jane and Joh become members of the football team after one day.

Using NoSQL in the scene

According to the usage scenario, we first need a document-based NoSQL database, a JSON document to structure the data stored in the relational database. As mentioned earlier, traditional RDBMSs stores data in multiple relational tables, which becomes more complex and inefficient when you get a complete object. In Figure 2-2. You can see an example of an account being split into multiple tables.

If you want to get all the account information, you basically need two or three join tables. Now consider a situation where you need to handle every connection that all users have in the application, and these connections have different business logic. Finally, you want a view of the account itself. What kind of document is obtained from all user views through API by passing an account ID?

{"id": "account_identifier", "email": "account@email.com", "firstname": "account_firstname", "lastname": "account_lastname", "birthdate": "account_birthdate", "authentication": [{"token": "authentication_token_1", "source": "authenticaton_source_1", "created": "16-12-12"} {"token": "authentication_token_2", "source": "authenticaton_source_2", "created": "16-12-12"}], "address": [{"street": "address_street_1" "city": "address_city_1"zip": "address_zip_1"country": "address_country_1"created": "16-12-12"}]}

The benefits are obvious: by maintaining the JSON representation of an entity, you can access data faster and better. Further, generalize this method, reading all read operations from the NoSQL database, while leaving all write operations (create, update,delete) on RDBMS. But you must implement a logic to maintain RDBMS-to-NoSQL data synchronization and create an object for a relational database if not in the cache.

Why keep RDBMS when NoSQL creates documents efficiently and scalably? Because this is not the real purpose of the application. I don't want to have a Big Bang effect. Suppose RDBMS is ready, but an NoSQL store is integrated because RDBMS lacks flexibility. Want to take full advantage of the two best technologies-- in particular, the data consistency of RDBMS and the scalability of NoSQL.

Thank you for reading this article carefully. I hope the article "sample Analysis of NoSQL Technology" shared by the editor will be helpful to you. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you 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.