문서 데이터베이스와 관계형 데이터베이스 : 선택 방법

저는 SQL 전문가이지만 SQL 데이터베이스 뿐만 아니라 주로 문서 데이터베이스 가 있다는 것을 알고 있습니다 . 대부분의 기술과 마찬가지로 각 기술마다 장단점이 있습니다.

나는 몇 가지 기사를 읽었지만 너무 이론적이었다. 내가 원하는 것은 두 가지 실제 경우입니다.

1. 관계형 데이터베이스에서 문서 데이터베이스로의 전환이 개선되었을 때
2. 문서 데이터베이스에서 관계형 데이터베이스로의 전환이 개선되었을 때

개선 개발 시간, 확장 성, 성능, 프로그래밍과 관련된 모든 것-더 나은 프로그램을 만드는 것입니다. 2에 대한 경고가 있습니다. "모든 사람이 SQL을 알고 있기 때문에 관계형 데이터베이스로 돌아 가기"와 같은 이야기는 좋지 않습니다.

지난 몇 년간 NoSQL 데이터베이스를 선택한 주된 이유는 가용성 입니다. Amazon, Google 및 Facebook과 같은 회사의 경우 한 시간의 가동 중지 시간이 허용되지 않습니다. 고 가용성을 달성하려면 단일 실패 지점을 줄여야합니다. 즉, 컴퓨터 충돌시 여러 컴퓨터가있는 분산 시스템을 사용해야하므로 서비스를 계속 사용할 수 있습니다.

전통적인 Relatione 데이터베이스는 분산 다중 마스터 설정에서 그리 좋지 않습니다. 이것이 바로 NoSQL이 최근에 인기를 얻은 이유입니다. 따라서 고 가용성이 필요한 경우 Riak, Cassandra, HBase, S3 또는 BigTable과 같은 NoSQL 데이터베이스를 선택할 수 있습니다.

분산 된 NoSQL 데이터베이스에 대한 좋은 소개 인 Amazon Dynamo 에 대한 좋은 블로그 게시물 이 있습니다.

이제 NoSQL 용어는 매우 광범위하므로 분산되지 않은 많은 NoSQL 데이터베이스가 있습니다. 그러나 그들은 다른 문제를 해결합니다. 예를 들어 Neo4j- 그래프 데이터베이스는 전통적인 RDBMS에 최적화되지 않은 쿼리 유형에 적합합니다. 또는 일부 경우 문서에 일부 필드를 추가하려는 경우 스키마를 변경할 필요가없는 문서 데이터베이스입니다. 즉, 대부분의 게시물 (문서)에 다른 필드가있을 때 문서 데이터베이스가 양호하므로 사전 정의 된 열이있는 관계형 테이블을 사용할 수 없습니다.

그러나 대부분의 NoSQL 데이터베이스는 기존 RDBMS 데이터베이스만큼 유연하지 않으므로 더 이상 문제를 해결할 수 없을 때까지 기존 RDBMS 데이터베이스를 사용하는 것이 좋습니다.

데이터에 가장 적합한 데이터베이스를 결정하는 간단한 방법이 있습니다.

나는 단지 나 자신에게 묻습니다 : 데이터베이스가 없다고 가정하면 가장 중요한 데이터를 문서로 저장하거나 스프레드 시트에 저장하려고합니다.

답이 "스프레드 시트"이면 관계형 모델과 기존 RDBMS가 대부분의 작업에 가장 적합하다는 명백한 신호입니다. 키 값 쌍이나 간단한 테이블처럼 데이터가 실제로 단순하고 참조 무결성이 주제가 아닌 경우 NoSQL 데이터베이스가 해당 작업에 가장 적합하고 성능을 상당히 향상시킬 수 있습니다!

또한 공통 구조를 전혀 찾을 수없는 경우 NoSQL 데이터베이스가 작업에 가장 적합합니다.

데이터가 명확한 관계없이 계층 구조화 된 텍스트 데이터와 같이 문서와 같은 경우에는 즉시 계층 구조화 된 문서를 쉽게 저장할 수있는 XML- 데이터베이스를 생각합니다. 때로는 문서 관리 소프트웨어를 사용하는 것이 가장 좋습니다.

따라서 두 질문에 대한 구체적이고 간단한 답변을 제공하려면 데이터에 따라 다릅니다.

관계형 데이터베이스에서 문서 데이터베이스로의 전환이 개선되었을 때

계층 적으로 구조화 된 텍스트 데이터를 유지해야하는 경우 Xml 데이터베이스는 유지 관리 성 및 확장 성 측면에서 크게 향상 될 수 있습니다.

문서 데이터베이스에서 관계형 데이터베이스로의 전환이 개선되었을 때

예를 들어, 데이터가 명확한 관계로 대부분 테이블과 같은 형식이고 무결성을 보장해야하는 경우가 있습니다.

우리가 받고있는 데이터에는 단순하고 명백하며 고정 된 정적 스키마가 없었기 때문에 관계형 모델을 포기해야했습니다.

사용자와 사용자 스토리에는 고정 된 정적 스키마가 없었습니다.

고정 된 정적 RDBMS 스키마를 적용하려고 시도했지만 실수였습니다.

고객 및 공급 업체로부터의 각 타사 데이터 전송은 비슷하지만 동일하지는 않았습니다. 고정 관계형 스키마에 매핑하려고했지만 가변성이 너무 컸습니다. 매주 여러 파일마다 필드를 추가하거나 고정 된 정적 관계형 스키마에서 벗어나야했습니다.

각 레코드를 요소 의 공통 서브 세트 와 추가 데이터 요소의 고유 한 (잘 정의되지 않은) 콜렉션이 있는 "문서"로 보았을 때 훨씬 더 행복했습니다.

잘못 정의 된 데이터 요소 모음은 사용자가 실제로 사용 사례에 필요한 것입니다.

관계형 모델의 고정 된 정적 스키마는 사용 사례에 맞지 않았습니다.