Comparison between relational database and non-relational database

Source: Internet
Author: User
Tags cassandra joins memcached mongodb sharding riak neo4j couchdb

1. Traditional SQL database has 3 drawbacks

      • Licensing fees are expensive
      • Cannot automatically sharding
      • A strict schema

2.

relational database and non-relational database in the use of the scene is relatively large, so there is no strong or weak, only the combination of their own business characteristics to play out the advantages of these two types of databases, the following are some of the characteristics of these two types of databases:
First, the general non-relational database is based on the CAP model, and the traditional relational database is based on the acid model.


1. Data storage structure:
First of all, the relational database has a fixed table structure, and need to modify the table structure through the DDL statements, not easy to expand, but not the relational database storage mechanism is many, such as document-based, k-v key-value pairs, as well as based on graphs and so on, for the data format is very flexible without a fixed table structure, Easy to scale, so non-relational databases are a good choice if the data structure of the business is not fixed or often changes relatively large.

2. Extensibility
Traditional relational database gives people a kind of horizontal extension difficult, not good for data fragmentation, and some non-relational database natively support the level of data expansion (such as MongoDB sharding mechanism), and this is probably a lot of NoSQL's selling point, In fact, the horizontal expansion of the relational database like MySQL is not difficult, even though the nosql level is easy to expand but there is no good solution to the scenario of joins across shards, whether it is a relational or non-relational database, to solve horizontal expansion or cross-Shard joins this scenario, It might be a good idea to add a layer of middleware to the application layer and database layer to do data processing.

3. Data consistency
Non-relational databases generally emphasize the final consistency of the data, without the strong consistency of the data, like acid, or the data that is read from a non-relational database that is likely to be in an intermediate state, so if your business has a high degree of consistency in data, then a non-relational database is not a good choice. Non-relational databases may be more biased towards OLAP scenarios, and relational databases are more biased towards OLTP scenarios

(

Olap

Online Analytical Processing (olap--online analytical procession) allows aggregated and organized data from commercial data sources, such as data warehouses, to be accessed in a multidimensional structure called a cube. OLAP brings 3 benefits to a relational database: Continuous rapid response, metadata-based queries, and spreadsheet-style formulas. The main advantage is the ability to calculate values in advance so that the report can be rendered quickly. OLAP tools are typically divided into two basic basic patterns: the spreadsheet model and the database model.

)

3. Summary of nine points the difference between NoSQL and RDBMS is very good.

    1. Understand the difference between acid and base (acid is the four requirements for strong consistency of relational databases, and base is a weak requirement for the availability and consistency of NoSQL databases, they mean, acid:atomicity, consistency , isolation, durability; Base:basically Available, soft-state, eventually consistent. At the same time, it is interesting that acid is acidic in English, base meaning is alkali) (basic available, soft state, eventually consistent)
    2. Understand the difference between persistence and non-persistence. That's because some nosql systems are purely memory-stored.
    3. You must be aware of the essential differences between traditional relational databases and nosql systems in data structures. Traditional relational databases are typically row-based, tabular storage, while NoSQL systems include Columnstore (Cassandra), Key/value Storage (Memcached), document Storage (CouchDB), and graph-structured storage (NEO4J)
    4. Unlike traditional relational databases, which have a unified SQL language operating interface, NoSQL systems often have their own API interfaces.
    5. On the architect, you have to figure out that the NoSQL system is designed to be used in clusters of hundreds of machines, rather than the architecture of a shared database system.
    6. In a nosql system, you may have to get used to the fact that you don't know exactly where your data is. (accustomed to possible uncomfortable realizations, you don't know the life of the data (most of the time))
    7. In a nosql system, you'd better get used to its weak consistency. "Eventually consistent" (final consistency) is an important item in the base principle. For example, on Twitter, you will often experience data delays in the followers list.
    8. In a nosql system, you have to understand that data is not always available at all times. (The fact that customary data may not always be available)
    9. You have to understand that some programs are tolerant of zoning, and some are not necessarily.

Original:

Here's their list of things to know:

  1. Understand how ACID compares with BASE (basically Available, soft-state, eventually consistent)
  2. Understand persistence vs non-persistence, i.e., some NoSQL technologies is entirely in-memory data stores
  3. Recognize there is entirely different data models from traditional normalized tabular formats:columnar (cassand RA) vs Key/value (Memcached) vs document-oriented (CouchDB) vs graph oriented (neo4j)
  4. Be-ready-to-deal with no-standard interface like JDBC/ODBC or standarized query language like SQL; Every NoSQL tool has a different interface
  5. Architects:rewire your brain to the fact that Web-scale/large-scale NoSQL systems is distributed across dozens to Hundre DS of servers and networks as opposed to a shared database system
  6. Get used to the possibly uncomfortable realization so you won ' t know where data lives (most of the time)
  7. Get used to the fact, the data may isn't always consistent; ' Eventually consistent ' is one of the keys elements of the BASE model (I See this latency issue all the time in Twitter, in ' Followers ' list)
  8. Get used to the fact, the data may isn't always being available
  9. Understand that some solutions is partition-tolerant and some is not

These attributes vary from one system to another. It's as important to understand the differences among NoSQL technologies as it's important to understand how they differ From a traditional RDBMS.

Here are a pretty good list of the many NoSQL products, from a respected member of the community, Alex Popescu.

Some pits in 4.MongoDB (2.4.10 versions)

Http://www.cnblogs.com/nucdy/p/7871973.html

A.COUCHDB uses the development language of Erlang, which complies with the Apache license and uses the Http/rest protocol. The main advantage is that data consistency and ease of use are maintained while allowing multiple stations to be deployed. COUCHDB is primarily suitable for applications that accumulate and change data less. such as CRM, CMS systems and so on.

The development language used by B.redis is C + + and complies with the BSD license, using the Telnet-like protocol. The main advantage is the extremely fast speed. Redis is used primarily for applications where data set data is constantly changing. But the memory consumption is large. Mainly used in financial institutions, real-time analysis, real-time data collection, real-time communication and so on.

The development language used by C.MONGODB is C + +, followed by AGPL (Drivers:apache), using the Custom,binary (BSON) protocol. MongoDB is suitable for dynamic querying, and it is better to define indexes than map/reduce performance. However, as with COUCHDB, its data is more volatile and requires a high-capacity disk. MongoDB can be used in any mysql/postgresql environment.

The development language used by D.cassandra is Java, followed by Apache, using the Custom,binary (Thrift) protocol. The Cassandra is suitable for applications where more than a query is written, such as banking and financial industries where real-time data analysis is required.

The development language used by E.riak is Erlang & C, Javascript. Follow Apache and use the Http/rest protocol. Riak is characterized by high fault tolerance. Riak and Cassandra are very similar. Riak is a good choice when it comes to high scalability and high fault tolerance. However, multi-site deployments require a fee. Riak is applicable to sales data entry, industrial control systems and other occasions do not allow downtime.

The development language used by F.hbase is Java, followed by Apache, using the Http/rest protocol. HBase can support up to billions of of columns. HBase is a good choice if you love bigtable and need a database that provides random, real-time access to your massive amounts of data. HBase is now used by the Facebook mail database.

The above collection and network, as the use of learning.

Comparison between relational database and non-relational database

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.