NoSQL (originally referring to "non-SQL" or "non-relational") is an approach to database design that focuses on providing a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. Instead of the typical tabular structure of a relational database, NoSQL databases house data within one data structure. Since this non-relational database design does not require a schema, it offers rapid scalability to manage large and typically unstructured data sets.  NoSQL systems are also sometimes called "Not only SQL" to emphasize that they may support SQL-like query languages or sit alongside SQL databases in polyglot-persistent architectures.

Non-relational databases have existed since the late 1960s, but the name "NoSQL" was only coined in the early 21st century, triggered by the needs of Web 2.0 companies. NoSQL databases are increasingly used in big data and real-time web applications.

Motivations for this approach include simplicity of design, simpler "horizontal" scaling to clusters of machines (which is a problem for relational databases), finer control over availability, and limiting the object-relational impedance mismatch. The data structures used by NoSQL databases (e.g. key–value pair, wide column, graph, or document) are different from those used by default in relational databases, making some operations faster in NoSQL. The particular suitability of a given NoSQL database depends on the problem it must solve.  Sometimes the data structures used by NoSQL databases are also viewed as "more flexible" than relational database tables.

Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of availability, partition tolerance, and speed. Barriers to the greater adoption of NoSQL stores include the use of low-level query languages (instead of SQL, for instance), lack of ability to perform ad hoc joins across tables, lack of standardized interfaces, and huge previous investments in existing relational databases. Most NoSQL stores lack true ACID transactions, although a few databases have made them central to their designs.

Instead, most NoSQL databases offer a concept of "eventual consistency", in which database changes are propagated to all nodes "eventually" (typically within milliseconds), so queries for data might not return updated data immediately or might result in reading data that is not accurate, a problem known as stale read. Additionally, some NoSQL systems may exhibit lost writes and other forms of data loss. Some NoSQL systems provide concepts such as write-ahead logging to avoid data loss. For distributed transaction processing across multiple databases, data consistency is an even bigger challenge that is difficult for both NoSQL and relational databases. Relational databases "do not allow referential integrity constraints to span databases". Few systems maintain both ACID transactions and X/Open XA standards for distributed transaction processing. Interactive relational databases share conformational relay analysis techniques as a common feature. Limitations within the interface environment are overcome using semantic virtualization protocols, such that NoSQL services are accessible to most operating systems.

History 
The term NoSQL was used by Carlo Strozzi in 1998 to name his lightweight Strozzi NoSQL open-source relational database that did not expose the standard Structured Query Language (SQL) interface, but was still relational. His NoSQL RDBMS is distinct from the around-2009 general concept of NoSQL databases.  Strozzi suggests that, because the current NoSQL movement "departs from the relational model altogether, it should therefore have been called more appropriately 'NoREL'", referring to "not relational".

Johan Oskarsson, then a developer at Last.fm, reintroduced the term NoSQL in early 2009 when he organized an event to discuss "open-source distributed, non-relational databases". The name attempted to label the emergence of an increasing number of non-relational, distributed data stores, including open source clones of Google's Bigtable/MapReduce and Amazon's DynamoDB.

Types and examples 
There are various ways to classify NoSQL databases, with different categories and subcategories, some of which overlap. What follows is a non-exhaustive classification by data model, with examples:

Key–value store 

Key–value (KV) stores use the associative array (also called a map or dictionary) as their fundamental data model. In this model, data is represented as a collection of key–value pairs, such that each possible key appears at most once in the collection.

The key–value model is one of the simplest non-trivial data models, and richer data models are often implemented as an extension of it. The key–value model can be extended to a discretely ordered model that maintains keys in lexicographic order. This extension is computationally powerful, in that it can efficiently retrieve selective key ranges.

Key–value stores can use consistency models ranging from eventual consistency to serializability. Some databases support ordering of keys. There are various hardware implementations, and some users store data in memory (RAM), while others on solid-state drives (SSD) or rotating disks (aka hard disk drive (HDD)).

Document store 

The central concept of a document store is that of a "document". While the details of this definition differ among document-oriented databases, they all assume that documents encapsulate and encode data (or information) in some standard formats or encodings. Encodings in use include XML, YAML, and JSON and binary forms like BSON. Documents are addressed in the database via a unique key that represents that document. Another defining characteristic of a document-oriented database is an API or query language to retrieve documents based on their contents.

Different implementations offer different ways of organizing and/or grouping documents:
 Collections
 Tags
 Non-visible metadata
 Directory hierarchies

Compared to relational databases, collections could be considered analogous to tables and documents analogous to records. But they are different – every record in a table has the same sequence of fields, while documents in a collection may have fields that are completely different.

Graph 

Graph databases are designed for data whose relations are well represented as a graph consisting of elements connected by a finite number of relations. Examples of data include social relations, public transport links, road maps, network topologies, etc.

 Graph databases and their query language

Performance 

The performance of NoSQL databases is usually evaluated using the metric of throughput, which is measured as operations/second. Performance evaluation must pay attention to the right benchmarks such as production configurations, parameters of the databases, anticipated data volume, and concurrent user workloads.

Ben Scofield rated different categories of NoSQL databases as follows:

Performance and scalability comparisons are most commonly done using the YCSB benchmark.

Handling relational data 
Since most NoSQL databases lack ability for joins in queries, the database schema generally needs to be designed differently. There are three main techniques for handling relational data in a NoSQL database. (See table Join and ACID Support for NoSQL databases that support joins.)

Multiple queries 
Instead of retrieving all the data with one query, it is common to do several queries to get the desired data. NoSQL queries are often faster than traditional SQL queries so the cost of additional queries may be acceptable. If an excessive number of queries would be necessary, one of the other two approaches is more appropriate.

Caching, replication and non-normalized data 
Instead of only storing foreign keys, it is common to store actual foreign values along with the model's data. For example, each blog comment might include the username in addition to a user id, thus providing easy access to the username without requiring another lookup. When a username changes however, this will now need to be changed in many places in the database. Thus this approach works better when reads are much more common than writes.

Nesting data 
With document databases like MongoDB it is common to put more data in a smaller number of collections. For example, in a blogging application, one might choose to store comments within the blog post document so that with a single retrieval one gets all the comments. Thus in this approach a single document contains all the data you need for a specific task.

ACID and join support 

A database is marked as supporting ACID properties (Atomicity, Consistency, Isolation, Durability) or join operations if the documentation for the database makes that claim. However, this doesn't necessarily mean that the capability is fully supported in a manner similar to most SQL databases.

See also

 CAP theorem
 Comparison of object database management systems
 Comparison of structured storage software
 C++
Database scalability
 Distributed cache
 Faceted search
 MultiValue database
 Multi-model database
 Triplestore
 Schema-agnostic databases

References

Further reading

External links 
 
 
 
 
 

 
Data management
Distributed data stores
Structured storage
Data analysis
NoSQL(원래 의미: non SQL 또는 non relational) 데이터베이스는 전통적인 관계형 데이터베이스 보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 위한 매커니즘을 제공한다. 이러한 접근에 대한 동기에는 디자인의 단순화, 수평적 확장성, 세세한 통제를 포함한다. NoSQL 데이터베이스는 단순 검색 및 추가 작업을 위한 매우 최적화된 키 값 저장 공간으로, 레이턴시와 스루풋과 관련하여 상당한 성능 이익을 내는 것이 목적이다. NoSQL 데이터베이스는 빅데이터와 실시간 웹 애플리케이션의 상업적 이용에 널리 쓰인다. 또, NoSQL 시스템은 SQL 계열 쿼리 언어를 사용할 수 있다는 사실을 강조한다는 면에서 "Not only SQL"로 불리기도 한다.

이러한 접근의 동기는 다음을 포함한다: 설계의 단순성, 머신들의 클러스터에 대한 더 단순한 수평 확장(관계형 데이터베이스의 문제), 이용성에 대한 더 세밀한 통제. NoSQL 데이터베이스에 의해 사용되는 자료 구조(예: 키-값, 와이드 컬럼, 그래프, 도큐먼트)들은 관계형 데이터베이스에서 기본적으로 사용되는 것들과는 다르며 일부 작업들은 NoSQL에서 속도가 더 빠른 편이다. 주어진 NoSQL 데이터베이스의 특정한 적합 여부는 해결해야 하는 문제에 따라 다르다. NoSQL 데이터베이스에 쓰이는 자료 구조들은 관계형 데이터베이스 테이블보다 "더 유연한" 것으로 간주되기도 한다.

수많은 NoSQL 스토어들은 이용성, 파티션 내구성, 속도의 선호로 (CAP 정리 측면에서) 일관성을 타협한다. NoSQL 스토어를 채용하는 데 생기는 장벽에는 저급의 쿼리 언어의 사용(SQL 사용 대신. 예: 테이블을 경유하여 애드혹 조인-join을 수행하는 기능이 부족), 표준화된 인터페이스의 부족, 기존 관계형 데이터베이스의 상당한 개선이 포함된다.
대부분의 NoSQL 스토어는 진정한 ACID 트랜잭션이 결여되어 있으나 마크로직, 에어로스파이크, 페어컴(FairCom) c-treeACE, 구글 스패너(기술적으로 NewSQL 데이터베이스이긴 하지만), Symas LMDB, OrientDB 등의 일부 데이터베이스들은 이를 염두에 두고 설계하였다.

그 대신, 대부분의 NoSQL 데이터베이스들은 "궁극적인 일관성" 개념을 제공함으로써 데이터베이스의 변경사항이 모든 노드에 "궁극적으로"(일반적으로 밀리초 내) 전파되므로 데이터에 대한 모든 쿼리들이 즉각 업데이트된 데이터를 반환하지 않을 수 있고 정확하지 않은 데이터를 읽는 결과가 발생할 수 있는데 이 문제를 스테일 리드(stale read)라고 부른다. 게다가 일부 NoSQL 시스템들은 손실된 쓰기(write)와 기타 형태의 데이터 손실을 보이는 경우도 있다. 일부 NoSQL 시스템들은 로그 선행 기입과 같은 개념들을 제공하여 데이터 손실을 막는다. 여러 데이터베이스를 거치는 분산 트랜잭션 처리의 경우 데이터 일관성은 NoSQL과 관계형 데이터베이스에게 훨씬 더 큰 도전이 된다. 현행의 관계형 데이터베이스들 조차도 데이터베이스 스팬을 위한 참조 무결성 제약(referential integrity constraint)을 허용하지 않는다. 분산 트랜잭션 처리를 위해 ACID 트랜잭션과 X/Open XA 표준을 모두 준수하는 시스템들도 일부 있다.

역사 

카를로 스트로찌(Carlo Strozzi)는 1998년 표준 SQL 인터페이스를 채용하지 않은 자신의 경량 오픈 소스 관계형 데이터베이스를 NoSQL이라고 명명했다.
스트로찌는 현재의 NoSQL 운동이 “전반적인 관계형 모델에서 점차 멀어지고 있으므로” NoREL로 부르는 것이 더 적절하다고 언급했다.

2009년 초에 라스트 FM의 요한 오스칼손(Johan Oskarsson)이 오픈 소스 분산 데이터베이스를 논하기 위한 미트업 행사를 조직하면서, 이와 같은 데이터베이스를 NoSQL이라고 불렀다. 고전적인 관계형 데이터베이스 시스템의 주요 특성을 보장하는 ACID 제공을 주로 시도하지 않은 수많은 비관계형, 분산 데이터 자료 공간의 등장에 따라 이 이름이 사용되었다.

NoSQL 데이터베이스의 예 
NoSQL 데이터베이스를 분류하는 접근 방식은 분류와 하위 분류와 함께 다양하다. 다양한 접근 방식으로 인해 비관계형 데이터베이스를 포괄적으로 파악하는 데에는 어려움이 있다. 그럼에도 동의할만한 수준의 기본적인 분류는 데이터 모델에 기반을 둔다. 이 가운데 몇 가지와 이들이 가진 프로토타입은 다음과 같다:
 와이드 컬럼 스토어: H베이스, 아큐물로, 카산드라
 도큐먼트: 몽고DB, 카우치베이스
 키 값: 다이나모DB, 리악, 레디스, 캐시, 프로젝트 볼드모트
 그래프: Neo4J, AgensGraph, 알레그로그래프, 버투오소

스티븐 옌은 자신의 블로그의 글 "NoSQL is a Horseless Carriage"에서 NoSQL 데이터베이스들을 다음과 같이 분류했다.

성능 
벤 스코필드는 여러 유형의 NoSQL 데이터베이스의 등급을 다음과 같이 평가했다:

성능과 확장성 비교는 종종 YCSB 벤치마크를 통해 이루어진다.

ACID 및 JOIN 지원 

ACID 속성(원자성, 일관성, 고립성, 지속성) 또는 JOIN 동작을 지원하는 것으로 문서에 표현되어 있는 경우 지원으로 표기된다. 그러나 이 기준에는 대부분의 SQL 데이터베이스와 비슷한 방식으로 완전히 지원할 필요는 없다.

같이 보기 
 CAP 정리
 트리플스토어

참조

더 읽기

외부 링크 
 
 
 
 
 

 
데이터베이스 관리 시스템
데이터 관리