Introduction
In the last years,relational databases have been the only option when we talk about data persistence. Our unique choice have been which database we should use. Should we use a sql Server? Should we use a MysqL? Oracle? Even in these cases,some choices come by default. E.g. if we are using .NET,we almost always work with sql Servers,if we are using Java we almost always use Oracle,ruby-MysqL,python-MysqL/postgre and so on.
The reason is obvIoUs,relational databases are in the field for decades,they proved to be robust for most of the applications. We can rely on them to take care of concurrency,transactions and so on. But if relational databases are reliable as I’m saying why they are losing market to Nosql databases? Relational Databases have some problems that Nosql Databases are resolving.
Problems with Relational Databases
Impedance Mismatch
We use to write software using Python,Ruby,Java,.NET. What they have in common?They are object-oriented languages.But we persist the data using MysqL,Postgre,Oracle and sql Server. What they have in common?They are relational databases.Can you spot the difference? Impedance Mismatch is the name we gave to this difference. Our memory structures are object-oriented and our databases are relational,every time we need to save or retrieve data we need to make a conversion. ORM (Object Relational Mapping) Frameworkds,like Hibernate,Entity Framework,make easier to map objects and relational databases but it’s still a issue,principally when we need high performance queries.
Applications are getting bigger
Web applications are increasing in scale.We have to store more data,we have to serve more users and we need more computing capability.To handle this scenario we have to scale. We can scale in two ways. We can scale up,that is buying better machines,more disk,more memory and so on. Or we can scale out,that is buy a lot of small machines and use them in a cluster. In big applications scale up is not an option.Bigger machines are more expensive and they have a limit,we don’t have a machine that can handle the traffic from Google or Facebook.Given this context,we need new databases,since relational database are not designed to run on clusters. Yes,you have clustered relational databases,but they work sharing a disk,that isn’t the scenario we want to have when we’re building a cluster. Some of the companies who needs to handle a lot of traffic like Google,Facebook,Amazon started to develop databases that are designed to run on clusters and this was the beginning of Nosql era.
Nosql Era
Nowadays,there are a lot of Nosql databases,MongoDB,Redis,Riak,HBase,Cassandra and so on. And each one has at least one of these characteristics.
- Nosql databases don’t use sql,some of the has query languages like MongoDB and Cassandra
- Usually they are open-source projects
- They we’re built to run on clusters
- Schemaless,you don’t have rigid schema defining the data structure
Types of Nosql
Nosql databases can be divided in 4 types.Key-value,document-oriented,Column-Family DatabasesandGraph-Oriented Databases. Let’s see what are each one of these types,his characteristics and where we should be using them.
Key-Value Databases
What are:A key-value store works like a simple hashtable that we are used to use in Traditional languages. You can add,retrieve and delete data through keys. Since they use primary key access they tend to have a good performance and are easily scalable.
Examples:Riak,Memcached,Amazon’s Dynamo,Project Voldemort
Who’s using:GitHub (Riak),BestBuy (Riak),Twitter (Redis and Memcached),StackOverFlow (Redis),Instagram (Redis),Youtube (Memcached),Wikipedia (Memcached).
When we should use:
- To store user information,like Session,Profiles,Preferences,Shopping Cart and so on.These info are often associated to a id(key). This case is exactly the best scenario to use a key-value database.
When we shouldn’t use:
- If we need to query the data by value instead by keys.There is no way to query a key-value database by value.
- If we need to save relationship between data.We can’t relate data between two or more keys in a key-value database.
- If we need transactions.In a key-value database,we can’t roll back a operation if a failure occurs.
document-oriented Databases
What are:document-oriented databases store data as documents. Documents can be defined as a set of maps,collections and scalar values. Documents are like rows,but unlike rows that have to have the same schema,documents can be totally different between themselves. These documents can be stored using XML,JSON or JSONB.
Examples:MongoDB,CouchDB,RavendB
Who’s using:SAP (MongoDB),Codecademy (MongoDB),Foursquare (MongoDB),NBC News (RavendB)
Logging.In a enterprise environment,each application has different logging info. document-oriented databases don’t have a fixed schema. So we can use them to store all these different info.
If we need to have transactions between documents.document-oriented databases don’t support transaction between documents,if we need it,we shouldn’t use a document database.
Column-Family Databases
What are:Column-Family databases store data in column families. A column family can be defined as groups of related data that are often queried together. Let me give a example. When we have a Person class we often access their name and age together but not his salary. In this case,name and age belong to one column-family and salary belongs to another one.
Examples:Cassandra,HBase
Who’s using:Ebay (Cassandra),Instagram (Cassandra),NASA (Cassandra),Twitter (Cassandra and HBase),Facebook (HBase),Yahoo!(HBase)
Logging.Since we can store data with different columns,each application can write their info with their own column families.
If we need ACID transactions.Cassandra doesn’t support transactions.
Graph-Oriented Databases
What are:Graph databases allow us to store data as graphs. Entities can be represented as vertices and the relationships between these entities can be represented as edges. In a example,we Could have 3 entities. Steve Jobs,Apple and Next. And two edges called “Founded by” that relate Apple to Steve Jobs and Next to Steve Jobs.
Examples:Neo4J,Infinite Graph,OrientDB
Who’s using:Adobe (Neo4J),Cisco (Neo4J),T-Mobile (Neo4J)
Connected Data.If we have data that are connected through relationship,we have a good case to use a graph database,the vertices can be people,cities,companies and edges can be “lives in”,“employed by” and so on.
Data model not suitable.Most of the cases are not suitable for graph databases since operations involving the whole graph are not trivial.
原文地址：https://www.jb51.cc/nosql/204220.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
