Some tips on NoSQL database design

NoSQL database This concept for a long time, but also see a lot of companies and products are in use, the pros and cons seem to be analyzed clearly. But there is a doubt in my mind, what is its appearance in order to solve the problem?

User Information table, book information table, user Rating Information table for the book, comment form.

Now imagine to do a page that shows the content of the comments, there will be information about the user and related books, presumably we have a variety of select and join in mind.

If you're using NoSQL or the same design, you'll be pleasantly surprised to find that the performance of a NoSQL database is simply too bad to explode. The quick-tempered estimate is about to lift the table on the spot.

What junk database, not known as Performance-Class!

Well, performance problems will not be said, even the business is not supported!? So how do I get the same data when I insert four tables at the same time? It's a joke!

NoSQL database at this time silently tears, wronged ah ... Don't say it, it's a real injustice.

Starting with the most basic design elements, almost all NoSQL databases do not have the concept of tables (table) and are replaced by documents. What is a document? MongoDB's explanation, a document is a structure that uses JSON format to store data in a key-value way , such as:

" Item " " Pencil " " Qty "  - " type " " No.2 " }

Doesn't it look any different from the table? Cough, JSON supports nested structures, such as information that can be stored together with the user's rating:

{   "ID":"123ZXCRWEQ2",   "title":"the snow in the sword line",   "author":"The Beacon plays the Princes",   "scores": [     {       "userid":"454zxcfwer1",       "Nickname":"Allen",       "score":3,     },     {       "userid":"678ZXKIOU1",       "Nickname":"Judy",       "score":4,     }   ], }

A bunch of document stored together is called collection, and the document inside the same collection can be different. Note that this is also the key concept. If you switch to a relational database, the columns that correspond to each row of data in a table can be different. Isn't that a mess? It's really going to get messy with the bad.

The concept is finished, to see the following this product requirements should be how to do. The product manager said that to see all the comments on the book Information page, the comment person's information and taxi points also appeared.

If it is a relational database, the idea of getting the data is this:

1. Take the book information according to the book ID.

2. Take all comments based on the book ID.

3. Use the user ID in the comment information to access the relevant user's information.

4. Collect the scoring information based on the book ID and user ID.

That in a NoSQL database if we store data with the following structure ...

{   "ID":"123ZXCRWEQ2",   "title":"the snow in the sword line",   "author":"The Beacon plays the Princes",   "Comments": [     {       "author": {         "ID":"454zxcfwer1",         "Nickname":"Allen",         "Avatarurl":"Avatar 1.png",       },       "score":3,       "title":"Book review 1",       "content":"Book review content 1",     },     {       "author": {         "ID":"454zxcfwer1",         "Nickname":"Judy",         "Avatarurl":"Avatar 2.png",       },       "score":4,       "title":"Book review 2",       "content":"Book review content 2"     }   ], }

It seems as if you can get the results once you search by book ID ... Understand why NoSQL databases are more efficient? While looking for data from four collections and looking for data from a single collection, this is an efficient way to see the difference from the naked eye.

So here I get a design experience where I can store as much data as necessary for a presentation . This is the typical space-changing time. Fortunately, the price of space is very low under the current technological conditions, so it is a good deal.

According to this design structure, it does not seem to need the support of the transaction, the user for a book to score only need to add data in a document is enough.

Well, the usefulness of the document feature is clear, now to study the use of another principle in the NoSQL database, remember what it is? The document inside the same collection can be different.

or from a practical point of view, a product manager said on the book details page that the book's creation time should also be displayed.

What if I use a relational database?

1. Create a SQL script that adds the "creationtime" column to the review table.

2. Run to the database.

3. Modify the relevant code and stored procedures.

What about NoSQL?

1. Add CreationTime to the comment structure entity to increase the assignment code.

No, no need to modify historical data, because? The document inside the same collection can be different. What if we take historical data? Comment's creationtime will be empty. Very reasonable, and will not produce any harm.

As we all know, Internet products Update speed is very fast, often based on user feedback and market conditions to adjust the product shape, and data structure will often change. In order to adapt to this environment, how to deal with historical data has become a long-standing. Remember when you saw a DBA in the design of the table will leave a few fields called "Reserved1,reserved2 ...", feel good nonsense, wasted space, and later with the increase in product function to understand this is actually experienced performance. If you use NoSQL, you don't have to be so tangled.

To summarize, in my shallow experience, the advantages of NoSQL are: 1. In the careful design of the query performance is great. 2. The data structure is full of elasticity, especially suitable for fast developing products.

It is also important to note that MongoDB does not support transactions, so be sure to consider this when designing. The core business data is designed to achieve consistency in data insertion as much as possible through structural design. If this is not possible, please go back to the relational database immediately, or you will regret it sooner or later.

This article link: http://www.cnblogs.com/AllenDang/p/3507821.html#!comments

Some tips on NoSQL database design