관계형 데이터베이스 대신 문서 기반 데이터베이스를 사용해야 하는 이유는 무엇입니까?

관계형 데이터베이스 대신 문서 기반 데이터베이스를 사용해야 하는 이유는 무엇입니까?

관계형 데이터베이스를 사용하는 대신 카우치DB와 같은 문서 기반 데이터베이스를 사용해야 하는 이유는 무엇입니까?관계형 데이터베이스보다 문서 기반 데이터베이스가 더 적합한 전형적인 응용프로그램 또는 도메인이 있습니까?

아마 하지 말아야 할 것 같습니다 :-)

두 번째로 분명한 대답은 데이터가 관계가 없는 경우 이를 사용해야 한다는 것입니다.이는 일반적으로 데이터를 열 집합으로 설명하는 쉬운 방법이 없는 것으로 나타납니다.좋은 예는 사무실 메일을 스캔하여 종이 문서를 실제로 저장하는 데이터베이스입니다.데이터는 스캔된 PDF이며 항상 존재하는 메타 데이터(스캔된 문서 유형)와 가능한 메타 데이터 필드(고객 번호, 공급업체 번호, 주문 번호, 파일 유지, OCR 처리된 전문 등)가 많이 있습니다.일반적으로 앞으로 2년 이내에 어떤 메타데이터 필드를 추가할지 미리 알 수 없습니다.카우치DB와 같은 것들은 관계형 데이터베이스보다 그런 종류의 데이터에 훨씬 더 잘 작동합니다.

저는 또한 개인적으로 요즘 거의 모든 프로그래밍 언어에 포함되어 있는 HTTP 클라이언트를 제외하고는 카우치DB를 위한 클라이언트 라이브러리가 필요하지 않다는 사실을 좋아합니다.

아마도 가장 명확하지 않은 대답:RDBMS를 사용할 때 통증이 없다면, RDBMS를 사용하세요.작업을 수행하기 위해 항상 RDBMS 주위에서 작업해야 하는 경우, 문서 지향 데이터베이스는 볼만한 가치가 있습니다.

좀 더 자세한 목록은 리차드 존스의 게시물을 확인해 보세요.

카우치DB 문서(https://web.archive.org/web/20090122111651/http ://couchdb.apache.org/docs/overview.html) :

• "RESTful JSON API를 통해 접근할 수 있는 문서 데이터베이스 서버." 일반적으로 관계형 데이터베이스는 REST 서비스를 통해 단순히 접근하는 것이 아니라 훨씬 더 복잡한 SQL API가 필요합니다.종종 이러한 API(JDBC, ODBC 등)는 매우 복잡합니다. REST는 매우 간단합니다.

• 주소 공간이 일정하지 않은 애드혹 및 스키마가 필요 없습니다.관계형 데이터베이스에는 복잡하고 고정된 스키마가 있습니다.테이블, 열, 인덱스, 시퀀스, 보기 및 기타 항목을 정의합니다.카우치는 복잡하고 값비싸며 깨지기 쉬운 고도의 계획을 필요로 하지 않습니다.

• 양방향 충돌 감지 및 관리를 통해 강력한 점진적 복제 기능을 제공하는 분산형.일부 SQL 상용 제품은 이를 제공합니다.SQL API와 고정된 스키마 때문에 복잡하고 어렵고 비용이 많이 듭니다.카우치의 경우 단순하고 저렴해 보입니다.

• 쿼리 가능 및 인덱스 가능 - 자바스크립트를 쿼리 언어로 사용하는 테이블 지향 보고 엔진을 특징으로 합니다.SQL 및 관계형 데이터베이스도 마찬가지입니다.여기는 새로운게 없습니다.

그래서 왜 카우치DB?

• REST는 JDBC나 ODBC보다 간단합니다.
• 스키마보다 간단한 스키마는 없습니다.
• 단순하고 저렴하게 보이는 방식으로 배포됩니다.

다른 서버 데이터를 바보같이 저장하고 서비스하는 경우.

지난 몇 주 동안 저는 제 피드(맛있는, 플리커, 깃허브, 트위터)를 폴링하여 카우치db에 저장하는 라이프스트림 앱을 가지고 놀았습니다.카우치db의 장점은 오버헤드 없이 원본 데이터를 원래 구조로 유지할 수 있다는 것입니다.각 문서에 'class' 필드를 추가하여 소스 서버를 저장하고 소스별 자바스크립트 렌더 클래스를 작성하였습니다.

일반적으로, 서버가 다른 서버와 통신할 때마다 스키마를 제어할 수 없으므로 스키마 없는 스토리지가 가장 좋습니다.보너스로 couchdb는 서버와 클라이언트의 기본 프로토콜인 표현을 위한 JSON과 전송을 위한 HTTP REST를 사용합니다.

빠른 애플리케이션 개발이 떠오릅니다.

지속적으로 스키마를 발전시킬 때 MySQL/SQLite에서 스키마를 유지해야 하는 것에 대해 지속적으로 좌절합니다.아직 CouchDB를 많이 사용하지는 않았지만, RAD 과정에서 스키마를 발전시키는 것이 얼마나 간단한지가 마음에 듭니다.

관계형이 아닌 데이터베이스를 사용하고 싶지 않은 경우는 다대다 관계가 많은 경우입니다. 특히 가입 관계에서 메타데이터를 사용해야 하는 경우, 이러한 관계를 중심으로 좋은 MapReduce 기능을 만드는 방법에 대해 아직 이해하지 못했습니다.확실하지는 않지만, 카우치DB 맵 기능은 무한 루프를 일으킬 수 있기 때문에 데이터베이스에서 자체 쿼리를 호출할 수 없다고 생각합니다.

각 레코드에 대해 동일한 크기의 필드가 있는 테이블에 데이터를 저장할 필요가 없는 경우 문서 기반 데이터베이스를 사용합니다.대신 각 레코드를 특정 특성을 가진 문서로 저장해야 합니다.먼저 "테이블을 수정"할 필요 없이, 길이에 상관없이 임의의 수의 필드를 문서에 언제든지 동적으로 추가할 수 있습니다.문서 기반의 필드에는 여러 개의 데이터가 포함될 수도 있습니다.

smdelfin에 대해 자세히 설명하자면: 유연성.구조화되지 않은 모든 구조로 데이터를 저장할 수 있으며 모든 문서가 완전히 다를 수 있습니다.CouchDB는 데이터베이스의 하위 집합을 원할 때 특정 문서를 필터링하고 해당 보기만을 쿼리할 수 있기 때문에 특히 유용합니다.

JSON 형식으로 데이터를 저장하는 문서 데이터베이스의 가장 큰 성공 포인트: 이것이 자바스크립트의 기본 형식입니다.따라서 자바스크립트 웹 애플리케이션은 카우치DB와 매우 잘 작동합니다.최근에 카우치DB를 활용한 웹 앱을 만들었는데 속도가 빠르고 데이터 구조도 변화가 없습니다.

문서 기반 데이터베이스는 데이터를 입력하기 전에 스키마를 미리 정의할 필요가 없기 때문에 관계형 데이터베이스에 비해 큰 이점을 가집니다.

또한 데이터가 관계형이 아니며 테이블에 저장할 수 없으며 이미지 집합이거나 신문 기사와 같은 경우에는 문서 데이터베이스를 사용해야 합니다.

또 다른 장점은 웹 개발에서 문서 기반 데이터베이스를 쉽게 사용할 수 있다는 것입니다.NoSQL 데이터베이스 모델 비교에 대한 자세한 내용은 이 소스를 확인하십시오. https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

사정에 따라 다르겠지.

예, 그것은 사용 사례입니다.네, 개발자 경험이기도 합니다.예, 입력할 데이터의 특성(예측 가능성이 높고, 직교적이고, 합리적이며, 정규화하기 쉽거나, 정규화/정리될 가능성이 적음)이 중요합니다.예, 하나의 기록/객체가 다른 문제에 대한 관계(있는 경우)입니다.네, 데이터를 분석하는 방법이 중요합니다.예, 지원되는 응용프로그램의 성격(응용프로그램에서 데이터를 사용하는 방식)이 중요합니다.

예, 기록/문서의 구조(스킴)가 급변해야 하는 경우 또는 각 기록/문서마다 필드 자체가 의무사항이 아니어야 하는 경우가 중요합니다.

예, 저장할 데이터가 너무 많아 검색 시간을 줄이려는 경우에도 중요합니다.정규화된 데이터(여러 개의 별개의 테이블에 있는 데이터)는 유용한 결과를 반환하기 위해 특정한 방법으로 (조인, 하위 쿼리 등) 결합해야 하는 경향이 있습니다.몇 개의 문서나 컬렉션만 반환하면 동일한 결과를 더 빨리 반환할 수 있습니다(일부 필터링 포함).

아, 네, 그리고 새로운 세계질서를 인정받기 위해서...네, 자바스크립트나 파이썬을 첫 프로그래밍 언어로 배운 분들은 SQL에 대한 부담감을 느끼지 않는 것이 좋습니다.예를 들어, MongoDB는 데이터를 BSON으로 저장합니다. 이는 스키마 없이 데이터를 저장/가져오기만 하고 다음 단계로 넘어갑니다.

솔직히 어느 쪽을 먼저 배웠는지가 중요합니다.SQL을 먼저 배웠다면 그 자리에 모든 것과 모든 것을 담을 수 있는 공간이 마련된 것입니다.스키마는 데이터를 매우 잘 알 수 있기 때문에 스키마를 정의하거나 변경해도 상관없습니다.실제로 어떤 사람들은 SQL을 선호하기도 하는데, 이는 컨트롤의 느낌을 즐기기 때문입니다.사용자에게 주는 권한 때문에 도메인 특정 언어를 아는 것에 개의치 않습니다.SQL은 70년대부터 있어 왔기 때문에 기본적으로 오래된 학교 비즈니스 방식입니다.

SQL RDBMS를 사용하는 데 드는 비용은 스키마를 계획하고 수정하는 데 드는 시간(필요할 때 파티셔닝), 테이블 크기 및 확장성을 계획하는 데 드는 시간(클러스터링), 데이터베이스와의 인터페이싱을 배우고 기록을 프로그래밍 언어 데이터 구조(ORM 또는 기타)로 변환하는 데 드는 비용입니다.

그러나 SQL은 데이터를 분석하고 복잡한 질문을 할 때 매우 효과적입니다.단순한 스토리지 및 검색 요구 이상의 요구사항이 있는 경우(소소한 분석을 통해) SQL을 사용하면 업계에서 훨씬 앞서 나갈 수 있습니다.

그러나 애플리케이션의 모든 데이터 요구사항에 대해 애플리케이션을 위한 모노리쓰로서 정규화된 SQL 데이터베이스가 반드시 우수한 것은 아닙니다.애플리케이션(웹 또는 다른 방식)에는 비즈니스의 지속적인 관심사에 핵심적이고 핵심적이지 않은 측면이 있을 수 있습니다.

만약 당신이 은행인 경우처럼 당신의 재무 기록(결제, 구매 등)에 대한 (롤백과 함께) 시도되고 진정한 ACID 준수 트랜잭션 기록 시스템을 원한다면, 나는 문서 데이터베이스가 아무리 좋아도 SQL을 사용할 것입니다.그러나 UI의 일부 do-hicky 위젯은 고객 기록/비즈니스 트랜잭션에도 영향을 미치지 않을 수 있습니다.왜 그것만을 위한 스키마가 있습니까?

사실상 그것이 핵심 UI 웹 개발자 세트의 관점입니다.문서 데이터베이스를 정당화하여 개발 기간을 단순화할 수 있지만 비즈니스 트랜잭션을 준수하지는 않습니다.더 많은 경험을 쌓을수록 문서 데이터베이스의 편리함이 바로 편리함이라는 것을 알게 될 것입니다.

제가 이것을 입력해도 누군가가 XX 문서 DB에 ACID 호환 트랜잭션이 있다고 하는데 SQL이 있습니까?결국, 모든 것에 대한 문서 DB를 원하는 사람들은 그것을 실현할 방법을 찾을 것입니다. 그것은 컬렉션과 문서가 더 많은 제약을 갖게 되고, 스키마 형태로 변하기 시작한다는 것을 의미할 것입니다.

REST나 GraphQL API 같은 것들을 사용하면 어디서 데이터를 얻을 수 있는지 전혀 알 수 없습니다.모든 데이터의 형태를 미리 예측하거나 계획할 수는 없습니다.이와 같은 경우(예: Amazon Web Services API와의 인터페이스) 문서 데이터베이스는 타당합니다.이렇게 많은 데이터를 정규화하고 싶지 않을 것입니다.애플리케이션의 요구를 충족시키기 위해 액세스하고 필터링하고 기본적인 작업을 수행하기만 하면 됩니다.이 데이터를 SQL 데이터베이스에 버리면 시간 낭비가 될 수 있습니다.AWS가 새로운 데이터로 서비스를 업데이트할 때마다 코드와 스키마를 변경하여 서비스를 수용해야 할 수도 있습니다.ACKKKK! 이미 소장품과 문서에 보관해두시면 됩니다!

위의 AWS API 예제는 트랜잭션을 포함하지 않습니다.API 정보의 일부를 유지해야 한다면 테이블이 많이 필요하지 않습니다.안타깝게도, 어떤 사람들은 모든 시나리오를 이 사용 사례에 맞게 만들려고 하면 틀릴 수 있습니다!

또한 AWS API에서 수집할 수 있는 데이터의 양을 고려할 때 SQL 데이터베이스를 파티셔닝 및 클러스터링하는 것에 비해 컬렉션 및 문서에 저장된 데이터를 공유하고 클러스터링하는 것이 훨씬 간단합니다.작업을 수행하는 경우 문서 데이터베이스를 보다 쉽게 관리할 수 있습니다.

그래서 저는 여기서 많은 답변을 좋아하지만, 많은 사람들은 자신들의 진영을 옹호하고 스키마 기반의 직교 SQL 데이터베이스보다 문서 데이터베이스가 더 적합한 시나리오에 대해서만 약간 설명하는 것 같습니다.

경험칙:

1. 비즈니스 운영 및 지속적인 관심사(CRUD, ACID, 트랜잭션)에 핵심적이고 중요한 요소라면 SQL로 이동합니다.
2. 애플리케이션과 UI에서 처리하기 위한 방대한 양의 데이터를 처리하기 위한 것이라면, 문서화/NoSQL 데이터베이스.

한 가지 이유는 동일한 구조/스킴이 필요하지 않은 JSON(또는 다른 자체 설명 형식) 문서에 대한 빠른 전체 텍스트 검색을 제공하는 것입니다.

언급URL : https://stackoverflow.com/questions/441441/why-should-i-use-document-based-database-instead-of-relational-database