Basic knowledge of NoSQL NoSql database introduction NoSql database

I have been working on this project for one year, and I still have some understanding of the relational database structure. Sometimes I still feel that this kind of 2-dimensional table is not very comfortable. After reading one article, have a preliminary knowledge of NoSQL, (https: / / keen io/blog / 53958349217 / analytics - for - hackers how - to think - about - event - data). This article is well written, it does write out the "use of NoSQL" in the actual situation, and it USES MineCraft for analysis, but it may not be comprehensive enough. For example, the article only mentioned how to store entity data in relational form and event data in NoSQL form. I want to use this article to analyze how to store data in the original relational database of event type data. Then I will make a comparison between these two storage methods, which can be regarded as a supplement to the original text.

For this kind of death event, there are two data, one about the explosion of creeper and one about falling into magma. If I had to use a relational 2-dimensional table database, I would store it like this. (if you don't already know what kind of data it is, you can look at the NoSQL storage method later to see it more clearly.)

The data in this case can be said to be one of the more complex database design cases, because it contains two cases (of course, not only these two cases, then will produce more structure), different cases of the data table structure is different, which is very troublesome. Our one-of-a-kind solution is to design four tables that take advantage of the relational nature of relational databases. The following four tables are designed. (I'll abbreviate it here.)

Table 1

id # First for associations, the main table needs to have one id This is not the difference, because NoSQL1 There will be one, too _id The default 
  timestamp # All the common parts can exist 1 In the table. 
  cause
  player_UID
  player_experience
  player_age    # for player_inveneory_id  Because this is 1 An array of arbitrary length that can only be saved in another 1 In the table 

Table 2 (for saving the death events of the creeper mode of death)

id # This is for this chart id You can associate it with other tables later 
  mid # Used to associate the main table 
  enemy_type
  enemy_power
  enemy_distance
  enemy_age

Table 3 (for saving death events for lava mode of death)

  id # This is for this chart id You can associate it with other tables later 
  mid # Used to associate the main table 
  place_x
  place_y
  place_z 

Table 4 (for saving player_inveneory)

  id # This is for this chart id You can associate it with other tables later 
  mid # Used to associate the main table 
  inveneory

Now that the relational database has defined how to store events with different structures, let's store them as follows (I won't draw a table)

1.
  id  timestamp          cause    player_UID    player_experience  player_age
  1   "2013-05-23T1:50:00-0600"  "creeper"  "99234890823"   8873729        228    
  2   "2013-05-24T23:25:00-0600"  "lava"   "99234890823"   88737         22

2.
  id  mid   enemy_type  enemy_power  enemy_distance  enemy_age
  1   1    "creeper"   .887      3.34       .6677

3.
  id  mid  place_x  place_y  place_z
  1   2   45.366   -13.333  -39.288

4.
  id  mid  inveneory
  1   1   "diamend sword"
  2   1   "torches"
  3   2   "stone" 

At this point, we use a relational database to store the two event data. What a nuisance!

Let's look at the NoSQL method of storage, because each piece of data is not limited by the field (column name) and can be saved directly without a sub-table. (for example, JSON format)

# The first 1 The data 
{
  "timestamp": "2013-05-23T1:50:00-0600",
  "cause":"creeper",
  "enemy":{
    "type":"creeper"
    "power": .887
    "distance_from_player":3.34
    "age":.6677
  },
  "player": {
    "UID":"99234890823",
    "experience": 8873729,
    "age": 228,
    "inveneory":["diamend sword","torches"]
  }
}
# The first 2 The data 
{
  "timestamp": "2013-05-24T23:25:00-0600",
  "cause":"lava",
  "place":{
    x:45.366
    y:-13.333
    z:-39.288
  }
  "player": {
    "UID":"99234890823",
    "experience": 88737,
    "age": 22,
    "inveneory":["stone"]
  }
}

Let's analyze the benefits of NoSQL for this kind of data storage

1. The first is to integrate the scattered table structure, so that the data that should be at 1 is at 1.
It's like the difference between having multiple arrays in C and having a single struct array. It's a natural human idea to have a number of related data in one, which is of course more comfortable and can improve the relevance and ease of scaling.

2. Easy storage
Let's think about how we store data when it comes.
For a 2-dimensional table database:
1. What kind of data is analyzed
2. Store the main table data and get it back to id
3. Branch, plus main table id stores data to lava or creeper under different conditions
4. Open the loop and insert multiple records into the inveneory table
This is only a brief introduction, but also to consider the data rollback problem when operating on multiple tables, the actual writing is about 30 lines, so the possibility of error is greatly increased.
For the NoSQL type
One sentence:

insert (data); # pseudocode

When you think about it, you can see that the original relational database can be just as cumbersome when fetching data.

3.NoSQL is more convenient to dynamically generate the storage mode, which is much more flexible. At least we can design the database when we store the data (although it may be better to design it in advance).

Of course, if you're not storing eventful or similar data, that's another story. A 2-dimensional table has many advantages of its own. The above is my personal analysis, of course, there are a lot of commonly agreed views, the following is some commonly agreed about the advantages and disadvantages of the two database models, I also basically agree.

Relational advantages:
1. Transaction processing -- maintain the 1 uniqueness of data;
2. As the premise of standardization, the cost of data update is very small (the same field basically has only 1 place);
3. Complex queries such as Join can be conducted.

Relational disadvantages:
1. Scaling difficulties: due to the existence of multi-table query mechanism like Join, it is very difficult for the database to scale;
2. Slow reading and writing: this situation mainly occurs when the data volume reaches a certain scale. Because the system logic of the relational database is very complex, it is prone to deadlock and other concurrency problems.
3. High cost: the price of License for enterprise databases is amazing, and it keeps rising with the scale of the system;
4. Limited support capacity: current relational solutions cannot support massive data storage like Google;

The advantages of NoSQL are mainly reflected in the following points:
1. Simple extension: a typical example is Cassandra. Since its architecture is similar to the classic P2P, this cluster can be easily extended by adding new nodes;
2. Quick read and write: the main example is Redis, which has excellent performance due to its simple logic and pure memory operation. A single node can process more than 100,000 read and write operations per second.
3. Low cost: this is a common feature of most distributed databases, as they are mainly open source software without the expensive cost of License.

The NoSQL database still has a lot of shortcomings, which are mainly as follows:
1. No support for SQL: if industry standards like SQL are not supported, users will incur a fixed cost of learning and application migration;
2. Support features are not rich enough: the functions provided by the existing products are limited. Most NoSQL databases do not support transactions, nor do they provide various additional functions like BI and reports like MS SQL Server and Oracle;
3. Lack of maturity of existing products: most of the products are still in the initial stage, which cannot be compared with the improvement of relational database in a few years.