Dry Foods | Where's the "relationship" of NoSQL?

You see, or you don't see me

I was right there.

No sorrow, no joy.

You read, or you don't read me.

The feeling is right there

Not going to come.

----Cang Gyatso

I think it is most appropriate to cite this poem to express the relationship of NoSQL.

What we call NoSQL stems from a technical gathering held in San Francisco on June 11, 2009. The initiator Johan that a name, simple, easy to remember, suitable for Twitter topics, Google search hit high. So NoSQL was born.

The term NoSQL is rapidly popular with wildfire prairie fire. But the definition of him is very ambiguous, it refers to those recently born "non-relational" database, such as Cassandra, MongoDB, neo4j and Riak and so on.

Since NoSQL is a "non-relational" database, where does NoSQL's "relationship" go?

Let's take a look at what a relational database is.

Relational databases are based on relational models (relational model) databases.

The relational model organizes data into relationships (relation) and tuples (tuples). A tuple is a collection of key-value pairs (Name-value pair), and a "relationship" is a collection of tuples.

Tuples and relationships are the "Rows" and "Tables" (table) that we often say. The data returned by our SQL statement operations are "relationships". Such as:

The biggest change in NoSQL is the abandonment of the "relational" model. The following four types of models are widely used.

Key values (Key-value), Document, column family (column-family), and graph (graph).

The relationship model organizes data in tuples, the combination of tuples or tuples (row), but tuples cannot contain lists of other tuples, and they must be returned by combining the list of Narimoto groups.

But NoSQL does not have this restriction, which organizes the data into aggregation units (agrregate unit).

In other words, it puts the "relationship" in the aggregation unit. And the relationship is diversified and more subdivided.

Let's look at four types of "non-relational" models:

• The key value (Key-value)---the "relationship" of this aggregation type is transparent to the database, and the database only knows that he has a key and a large blob of data. This aggregated data can only be used by the data program to analyze the "relationship", or use database Tools (such as SOLR) to search in this aggregation structure.

• Document---The structure and data type of the aggregation unit are known to the database. The database supports searching for aggregations using some functions.

• Column family (column-family)---the most influential big table from Google in the column family. The column family is a two-level aggregation structure (tow-level aggregate structure). The first is the row-level aggregation, the definition data structure (key-value), and then the column family-level aggregation (still key-value). To give a Cassandra simple example, define a user table and insert the data

CREATE TABLE users-91b56770-bf40-11df-969c-b2b36bca998e (column_name varchar, column_value varchar) UNIQUE column_name PRIMARY KEY column_name;

INSERT into users-91b56770-bf40-11df-969c-b2b36bca998e VALUES (' username ', ' Joe '), (' Password ', ' weak '), (' email ', ' [ Email protected] ');

• Graph---Graph database is not aggregation-oriented, its "relationship" not only has not disappeared, but also become a class of citizens, support many-to-many relationships. Since it does not vanish, it strengthens the relationship. This article does not do too much discussion (the subsequent it circles will do a special discussion on it).

In summary: As the beginning of the poem, the relationship actually did not disappear, but dispersed into the aggregation unit inside.

If you like the It circle of the article, please long press the QR code to identify the attention oh.

?

Dry Foods | Where's the "relationship" of NoSQL?