A quick understanding of NoSQL database Analytics for Hackers:how to Think about Event Data

Do a year of freshman year project, for relational database structure still have some understanding, sometimes think this two-dimensional table is not very handy. After reading an article, I had a preliminary understanding of NoSQL (Https://keen.io/blog/53958349217/analytics-for-hackers-how-to-think-about-event-data). The article here is very good, and it does write the "where" of NoSQL in real-world situations, and uses Minecraft for analysis, but perhaps not comprehensive enough. For example, only mentioned in the article, Entity data with the relationship type how to save, the event data with NoSQL How to save, I would like to borrow this article, to analyze the event type of data of the original relational database is how to save data, and then the two storage methods to do a comparison, It is a supplement to the original.

For this kind of death, there are two data, one is about Creeper explosion, one is falling into magma. If I had to use a relational two-dimensional table database, I would store it this way. (If you don't know what kind of data it is, you can look at the following NoSQL storage methods, which looks clearer.) ）

This data can be described as a complex case of database design, because it contains two cases (of course, more than the two cases, then there will be more structure), different data table structure is different, which is very troublesome. Our general solution is to design four tables, using relational database relationships. The following four tables are designed. (I'll abbreviate it here.)

First sheet

    # first for correlation, the main table needs to have an ID, which is not the difference, because NoSQL will also have a _id preset    # All common parts can exist in a single table.      cause    player_uid    player_experience    player_age         #  For player_inveneory_id because this is an array of arbitrary lengths and can only be saved in another table

Second table (used to save the death of Creeper death)

    # This is the ID of this table that can be associated    with other tables later # used to correlate the main table     enemy_type    enemy_power    enemy_distance    enemy_age

Third table (for saving lava death)

    # This is the ID of this table that can be associated    with other tables later # used to correlate the main table     place_x    place_y    place_z

Table IV (for saving player_inveneory)

    # This is the ID of this table that can be associated    with other tables later # used to correlate the main table    Inveneory

At this point the relational database will have the different structure of the event storage in the same way, and then stored as follows (I do not draw a table)

1. ID timestamp cause player_uid player_experience player_age1"2013-05-23t1:50:00-0600"    "Creeper"    "99234890823"8873729 228 2"2013-05-24t23:25:00-0600"   "Lava"      "99234890823"88737 222. ID mid enemy_type enemy_power enemy_distance enemy_age1 1"Creeper".887 3.34.66773. ID mid place_x place_y place_z1 2 45.366-13.333-39.2884. ID Mid inveneory1 1"Diamend Sword"2 1"Torches"3 2"Stone"

At this point, we have stored the two event data in a relational database. (It's a good problem!) ）

We look at the NoSQL storage method, because each data is not limited by the field (column name), it can be saved directly without the table. (e.g. JSON format)

#The first piece of 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 second piece of data{    "timestamp":"2013-05-24t23:25:00-0600",    "cause":"Lava",    " Place": {x:45.366y:-13.333Z:-39.288    }    "player": {        "UID":"99234890823",        "Experience": 88737,        " Age": 22,        "inveneory":["Stone"]    }}

below we analyze the benefits of NoSQL for this data storage method
1. The first is to integrate the decentralized table structure, so that the data should be together.
It's like having multiple arrays stored in C or a struct array, putting together some relational data is a natural idea for humans, which of course makes people more comfortable and can improve the simplicity of relevance and escalation.

2. Storage becomes convenient
Let's consider how we can store the data.
for a two-dimensional table database:
1. Analytical data is that type of
2. Store the master table data and get the return ID
3. Branching, plus the primary table ID stores data in different cases to the lava or Creeper table
4. Open the loop and insert multiple records into the Inveneory table
This is just a brief, but also to consider the multiple table operations when the data rollback problem, the actual write up about 30 rows or so, then the likelihood of error is greatly improved.
for NoSQL types
sentence:

Insert (data); # Pseudo Code

in fact, if you think about it, the original relational database will be just as troublesome when you take the data.

3.NoSQL is more conducive to dynamic generation of storage, flexibility is much more flexible, at least we can store data at the time of the design database (although may be better in advance design)


of course, if the storage is not an event or similar to such data, it is another matter, the two-dimensional table has a lot of its own advantages. These are some of my personal analysis, of course, there are a lot of commonly accepted views, the following are some commonly agreed on the two database models of the pros and cons of the analysis, I also basically agree. The following views are mainly quoted (http://blog.csdn.net/chenhuajie123/article/details/9374969)
The advantages of the relationship:
1. Transaction Processing---maintain consistency of data;
2. Due to standardization, the cost of updating data is small (the same field is basically only one place);
3. Complex queries such as joins can be made.
Relationship-based disadvantages:
1. Expansion difficulties: Due to the existence of a similar join such a multi-table query mechanism, making the database is very difficult to expand;
2. Slow reading and writing: This situation mainly occurs when the data volume reaches a certain scale due to the complexity of the system logic of the relational database, which makes it very prone to the concurrency problem of deadlock and so on, so its reading and writing speed decline is very serious;
3. High cost: The license price of enterprise database is amazing, and it keeps rising with the scale of the system .
4. Limited support capacity: Existing relational solutions cannot support Google's massive data storage;
The NoSQL advantage is mainly reflected in the following points:
1. Simple extension: typical example is Cassandra, because its architecture is similar to the classic peer-to, so it can easily add new nodes to expand the cluster;
2. Fast Read and write: The main example is Redis, because of its simple logic, and pure memory operation, so that its performance is excellent, single node can handle more than 100,000 reads and writes per second;
3. Low cost: This is the common feature of most distributed databases, because it is mainly open source software, there is no expensive license cost;
NoSQL databases also have a lot of shortcomings, common mainly in the following:
1. Does not provide support for SQL: If the industry standard such as SQL is not supported, the user will have some learning and application migration cost .
2. Unsupported features are not rich enough: existing products offer limited functionality, most NoSQL databases do not support transactions, and do not provide a variety of additional features like MS SQL Server and Oracle, such as BI and reports;
3. The existing product is not mature enough: most of the products are still in the start-up period, and the relational database decades of improvement is not the same;

A quick understanding of NoSQL database Analytics for Hackers:how to Think about Event Data