답변:
모든 데이터가 관계있는 것은 아닙니다. 이러한 상황에서는 NoSQL이 도움이 될 수 있습니다.
그러나 NoSQL은 "Not Only SQL"을 의미합니다. SQL을 중단 시키거나 대체하려는 것은 아닙니다.
SQL에는 몇 가지 큰 장점이 있습니다.
그것들은 사라지지 않았습니다.
이것을 하나의 / 또는 논쟁으로 생각하는 것은 실수입니다. NoSQL은 사람들이 필요할 때 고려해야 할 대안입니다.
CouchDB와 같은 비 관계형 데이터베이스에 문서를 저장할 수 있습니다.
SELECT blob FROM images WHERE blob CONTAINS('red car'). 따라서 데이터베이스에 원시 데이터를 저장할 수는 있지만 메타 데이터를 첨부하지 않고는 검색 할 수 없습니다. RDBMS 시스템의 전체 텍스트 검색 모듈은 일부 반 구조적 갭을 연결합니다.
역사는 다음과 같습니다.
Google은 역 검색 색인을위한 스토리지 계층이 필요합니다. 그들은 전통적인 RDBMS가 그것을 자르지 않을 것이라고 생각합니다. 따라서 GFS 파일 시스템 위에 NoSQL 데이터 저장소 인 BigTable을 구현합니다. 중요한 부분은 수천 개의 저렴한 상용 하드웨어 시스템이 속도와 중복성을 제공한다는 것입니다.
다른 사람들은 Google이 방금 한 일을 알고 있습니다.
브루어스 CAP 정리 가 입증되었습니다. 모든 RDBMS 사용 시스템은 CA 시스템입니다. 사람들은 CP와 AP 시스템을 가지고 놀기 시작합니다. K / V 매장 은 훨씬 단순하므로 연구의 주요 수단입니다.
서비스로서의 소프트웨어 시스템은 일반적으로 SQL과 유사한 저장소를 제공하지 않습니다. 따라서 사람들은 NoSQL 유형 저장소에 더 관심을 갖습니다.
이륙의 많은 부분이이 역사와 관련이 있다고 생각합니다. 스케일링 구글은 구글에서 몇 가지 새로운 아이디어를 얻었고 다른 사람들은 스케일링 문제에 대해 알고있는 유일한 솔루션이기 때문에 모든 사람들이 따라갑니다. 따라서 특정 크기 이상으로 확장 할 수있는 유일한 방법이기 때문에 Google의 분산 데이터베이스 아이디어와 관련된 모든 것을 기꺼이 재 작업 할 것입니다.
C-일관성
A-가용성
P-파티션 공차
K / V-키 / 값
NoSQL은 다음과 같은 이유로 NoSQL의 특성으로 인해 RDBMS보다 낫습니다.
편집하다:
"RDBMS가 확장 할 수없는 이유"에 답하려면 Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden 및 Michael Stonebraker가 작성한 RDBMS 오버 헤드 PDF 를 참조하십시오.
RDBMS는 엄청난 양의 테라 바이트 및 페타 바이트를 처리하는 데 어려움이 있습니다. RAID (Redundant Array of Independent / Inexpensive Disks) 및 데이터 분쇄 기능이 있어도 엄청난 양의 데이터에 맞게 확장 할 수 없습니다. 매우 비싼 하드웨어가 필요합니다.
로깅 : 로그 레코드를 조합하고 데이터베이스 구조의 모든 변경 사항을 추적하면 성능이 저하됩니다. 복구 기능이 필요하지 않거나 다른 방법 (예 : 네트워크의 다른 사이트)을 통해 복구 기능이 제공되는 경우 로깅이 필요하지 않을 수 있습니다.
잠금 : 기존 2 단계 잠금은 데이터베이스 구조에 대한 모든 액세스가 별도의 엔티티 인 잠금 관리자에 의해 관리되므로 상당한 오버 헤드가 발생합니다.
래치 : 다중 스레드 데이터베이스에서 많은 데이터 구조는 래치되기 전에 액세스해야합니다. 이 기능을 제거하고 단일 스레드 방식으로 전환하면 성능에 현저한 영향을 미칩니다.
버퍼 관리 : 기본 메모리 데이터베이스 시스템은 버퍼 풀을 통해 페이지에 액세스 할 필요가 없으므로 모든 레코드 액세스에서 간접적 인 레벨을 제거합니다.
이것은 NoSQL over SQL을 사용해야한다는 의미는 아닙니다.
여전히 RDBMS는 RDBMS의 다음과 같은 이유로 인해 NoSQL보다 낫습니다.
비즈니스 사례 및 요구 사항에 따라 RDBMS (SQL) 및 NoSQL (SQL뿐만 아니라)을 사용해야합니다.
NOSQL은 관계형 데이터베이스 모델에 비해 특별한 이점이 없습니다. NOSQL은 현재 SQL DBMS의 특정 제한 사항을 해결하지만 이전 데이터 모델에 비해 근본적으로 새로운 기능을 의미하지는 않습니다.
NOSQL은 SQL이 아님 (또는 " SQL 만이 아님 ")만을 의미하지만 관계형 이 아님을 의미하지는 않습니다 . 관계형 데이터베이스는 원칙적으로 매우 우수한 NOSQL 솔루션을 만듭니다. 현재 NOSQL 제품 세트 중 어느 것도 관계형 모델을 사용하지 않습니다.
위에 주어진 모든 정보에 추가하기 만하면됩니다.
NoSql 장점 :
1) 스키마가없고 객체 지향적 인 아키텍처를 지원하기 때문에 프로덕션 준비가 빠르면 NoSQL이 좋습니다.
2) NoSql DB는 최종적으로 일관성이있어 간단한 언어로 RDBMS의 경우와 같이 데이터 (문서)에 대한 잠금을 제공하지 않으며 최신 데이터 스냅 샷을 항상 사용할 수 있으므로 응용 프로그램의 대기 시간이 증가한다는 것을 의미합니다 .
3) 데이터 (문서)의 스냅 샷을 유지하고 생성하기 위해 MVCC (Multi view concurrency control) 전략을 사용합니다.
4) 인덱싱 된 데이터를 원할 경우 제공 한 뷰 정의에 따라 데이터를 자동으로 인덱싱하는 뷰를 만들 수 있습니다.
NoSql 단점 :
1) 궁극적으로 일관성이 있고 ACID 속성을 지원하지 않기 때문에 대규모 트랜잭션 응용 프로그램에는 적합하지 않습니다.
2) 또한 동시성 제어를 위해 MVCC 방법을 사용하기 때문에 데이터 (문서)의 여러 스냅 샷 (수정)을 만듭니다. 결과적으로 공간이 이전보다 더 빨리 소비되어 압축 및 재 색인 생성이 더 빈번 해지고 속도가 느려집니다. 애플리케이션의 데이터 및 트랜잭션이 증가함에 따라 애플리케이션 응답 노드를 수평으로 확장 할 수 있지만 SQL 데이터베이스와 비교할 때 비용이 더 많이 듭니다.
에서 mongodb.com :
NoSQL 데이터베이스는 다음 네 가지 주요 영역에서 이전 관계형 기술과 다릅니다.
데이터 모델 : NoSQL 데이터베이스를 사용하면 관계형 데이터베이스와 달리 스키마를 먼저 정의하지 않고도 응용 프로그램을 구축 할 수 있으므로 시스템에 데이터를 추가하기 전에 스키마를 정의 할 수 있습니다. 사전 정의 된 스키마가 없으므로 데이터 및 요구 사항이 변경 될 때 NoSQL 데이터베이스를 훨씬 쉽게 업데이트 할 수 있습니다.
데이터 구조 : 관계형 데이터베이스는 데이터가 관계에 의해 상당히 구조화되고 명확하게 정의 된 시대에 지어졌습니다. NoSQL 데이터베이스는 오늘날 존재하는 많은 데이터를 구성하는 비정형 데이터 (예 : 텍스트, 소셜 미디어 게시물, 비디오, 이메일)를 처리하도록 설계되었습니다.
확장 : 저렴한 상용 서버로 확장하여 용량을 추가 할 수 있기 때문에 관계형 데이터베이스보다 NoSQL 데이터베이스를 확장하는 것이 훨씬 저렴합니다. 반면 관계형 데이터베이스는 전체 데이터베이스를 호스팅하기 위해 단일 서버가 필요합니다. 확장하려면 더 크고 비싼 서버를 구입해야합니다.
개발 모델 : NoSQL 데이터베이스는 오픈 소스 인 반면 관계형 데이터베이스는 일반적으로 소프트웨어 사용에 따른 라이센스 비용으로 폐쇄 소스입니다. NoSQL을 사용하면 소프트웨어 비용을 사전에 많이 투자하지 않고도 프로젝트를 시작할 수 있습니다.