저는 비 관계형 DB로 시작했을 뿐이고 여전히이 DB에 머리를 감고 최상의 모델이 무엇인지 알아 내려고 노력하고 있습니다. 그리고 저는 CouchDB에 대해서만 말할 수 있습니다.
그래도 몇 가지 예비 결론이 있습니다.
비 관계형 세계에서 훨씬 더 잘 작동하는 대체 설계를 생각해 보셨습니까?
디자인 초점이 바뀝니다. 문서 모델 (DB 테이블에 해당)의 디자인은 거의 관련이없는 반면 모든 것이 뷰 (쿼리에 해당) 디자인에 달려 있습니다.
문서 DB 종류는 복잡성을 바꿉니다. SQL에는 유연하지 않은 데이터와 유연한 쿼리가 있으며 문서 DB는 그 반대입니다.
CouchDB 모델은 "JSON 문서"(기본적으로 중첩 된 해시 테이블)의 모음입니다. 각 문서에는 고유 한 ID가 있으며 ID로 간단하게 검색 할 수 있습니다. 다른 쿼리의 경우 맵 / 축소 함수의 이름이 지정된 "뷰"를 작성합니다. 뷰는 키 / 값 쌍 목록으로 결과 집합을 반환합니다.
비결은 SQL 데이터베이스를 쿼리한다는 의미에서 데이터베이스를 쿼리하지 않는다는 것입니다. 뷰 함수를 실행 한 결과는 인덱스에 저장되며 인덱스 만 쿼리 할 수 있습니다. ( "모두 가져 오기", "키 가져 오기"또는 "키 범위 가져 오기")
SQL 세계에서 가장 가까운 비유는 저장 프로 시저를 사용하여 DB 만 쿼리 할 수있는 경우입니다. 지원하려는 모든 쿼리는 미리 정의되어야합니다.
문서의 디자인은 매우 유연합니다. 두 가지 제약 만 찾았습니다.
- 조인에 해당하는 것이 없으므로 관련 데이터를 동일한 문서에 함께 보관하십시오.
- 모든 문서 업데이트가 재 인덱싱을 트리거하므로 문서를 너무 크게 만들어 너무 자주 업데이트하지 마십시오 (예 : 해당 연도의 모든 회사 판매를 동일한 문서에 넣음).
그러나 모든 것은 뷰 디자인에 달려 있습니다.
내가 발견 한 대체 설계는 어떤 SQL 데이터베이스보다 CouchDB에서 더 나은 작업 순서가 스토리지 수준이 아닌 시스템 수준에 있다는 것을 발견했습니다. 일부 데이터가 있고 웹 페이지에 제공하려는 경우 전체 시스템의 복잡성이 최소 50 % 감소합니다.
- DB 테이블 설계 없음 (사소한 문제)
- ODBC / JDBC 중간 계층 없음, http를 통한 모든 쿼리 및 트랜잭션 (중간 문제)
- JSON의 간단한 DB-to-object 매핑은 SQL에서 동일한 것에 비해 거의 사소합니다 (중요!)
- AJAX를 사용하여 브라우저에서 직접 검색 할 문서를 디자인하고 HTML로 표시되기 전에 약간의 JavaScript 폴리싱을 추가 할 수 있으므로 전체 애플리케이션 서버를 건너 뛸 수 있습니다. (거대한!!)
일반 웹앱의 경우 문서 / JSON 기반 DB는 큰 승리이며, 유연성이 떨어지는 쿼리와 데이터 유효성 검사를위한 추가 코드의 단점은 비용이 적게 드는 것 같습니다.
불가능 해 보이는 것에 머리를 부딪힌 적이 있습니까?
아직. 데이터베이스 쿼리 수단으로서의 매핑 / 축소는 익숙하지 않으며 SQL을 작성하는 것보다 더 많은 생각이 필요합니다. 매우 적은 수의 프리미티브가 있으므로 필요한 결과를 얻는 것은 주로 키를 지정하는 방법을 창의적으로 만드는 문제입니다.
쿼리가 동시에 두 개 이상의 문서를 볼 수 없다는 제한이 있습니다. 조인이나 다른 종류의 다중 문서 관계는 없지만 지금까지 극복 할 수있는 것은 없습니다.
제한의 예로서 개수와 합계는 쉽지만 평균은 CouchDB보기 / 쿼리로 계산할 수 없습니다. 수정 : 합계와 개수를 별도로 반환하고 클라이언트에서 평균을 계산합니다.
예를 들어 하나에서 다른 것으로 변환하기 위해 디자인 패턴과의 격차를 해소 했습니까?
그게 가능한지 모르겠습니다. 기능적 스타일 프로그램을 객체 지향 스타일로 번역하는 것과 같은 완전한 재 설계에 가깝습니다. 일반적으로 각 문서에 SQL 테이블과 더 많은 데이터가있는 것보다 훨씬 적은 문서 유형이 있습니다.
이를 생각하는 한 가지 방법은 삽입 및 일반적인 쿼리에 대한 SQL을 보는 것입니다. 예를 들어 고객이 주문할 때 어떤 테이블과 열이 업데이트됩니까? 월별 판매 보고서에는 어떤 것이 있습니까? 해당 정보는 아마도 동일한 문서에 있어야합니다.
즉, 고객 ID 및 제품 ID가 포함 된 주문 문서 하나, 쿼리를 단순화하는 데 필요한 복제 된 필드가 있습니다. 문서 내의 모든 항목을 쉽게 쿼리 할 수 있으며, 주문과 고객간에 상호 참조가 필요한 모든 작업은 클라이언트가 수행해야합니다. 따라서 지역별 판매 보고서를 원하면 주문에 지역 코드를 입력해야합니다.
지금은 명시 적 데이터 모델을 전혀 수행하고 있습니까 (예 : UML)?
죄송합니다. 문서 DB 전에 UML을 많이 한 적이 없습니다. :)
그러나 어떤 필드가 어떤 문서에 속하고 어떤 종류의 값이 포함되어 있는지 알려주는 일종의 모델이 필요합니다. 나중에 참조하고 DB를 사용하는 모든 사람이 규칙을 알고 있는지 확인하십시오. 예를 들어 텍스트 필드에 날짜를 저장하는 경우 더 이상 오류가 발생하지 않고 누구나 원하는 필드를 추가하거나 제거 할 수 있으므로 여유를 가져 오기 위해 유효성 검사 코드와 규칙이 모두 필요합니다. 특히 외부 리소스로 작업하는 경우.
RDBMS가 제공하는 주요 추가 서비스를 놓치고 있습니까?
아니. 하지만 제 배경은 웹 애플리케이션 개발자입니다. 우리는 데이터베이스를 다뤄야합니다. :)
제가 근무하던 회사에서 여러 벤더의 SQL 데이터베이스에서 실행되도록 설계된 제품 (웹앱)을 만들었는데 "추가 서비스"는 DB마다 너무 다르기 때문에 각 DB에 대해 별도로 구현해야했습니다. 따라서 RDBMS에서 기능을 이동하는 것은 우리에게 더 적은 작업이었습니다. 이것은 전체 텍스트 검색으로 확장되었습니다.
그래서 내가 포기하고있는 것은 처음에 내가 결코 가지지 못한 것입니다. 분명히 당신의 경험은 다를 수 있습니다.
주의 사항 : 지금 작업중인 것은 재무 데이터, 주식 시세 등을위한 웹 앱입니다. 이것은 문서 DB와 매우 잘 일치합니다. 제 관점에서 DB의 모든 이점 (지속성 및 쿼리)을 번거 로움없이 얻을 수 있습니다.
그러나 이러한 데이터는 서로 상당히 독립적이며 복잡한 관계형 쿼리가 없습니다. 시세별로 최신 시세를 확인하고 시세 및 날짜 범위별로 시세를 확인하고 회사 메타 정보를 확인하세요. 그게 전부입니다. 내가 본 또 다른 예는 블로그 애플리케이션이며 블로그는 엄청나게 복잡한 데이터베이스 스키마로 특징 지워지지 않습니다.
내가 아는 문서 DB의 모든 성공적인 응용 프로그램은 처음에 문서 (Google 검색에서와 같이), 블로그 게시물, 뉴스 기사, 재무 데이터와 같이 상호 연관성이없는 데이터를 사용했습니다. .
문서 모델보다 SQL에 더 잘 매핑되는 데이터 세트가있을 것으로 예상하므로 SQL이 살아남을 것이라고 생각합니다.
그러나 데이터를 저장하고 검색하는 간단한 방법을 원하는 사람들에게는 (CouchDB에서와 같이) 문서 데이터베이스가 신의 선물입니다.