CouchDB와 RDBMS를 사용하는 경우
다음을 포함하여 관계형 데이터베이스에 비해 매력적인 기능이 많이있는 CouchDB를 살펴보고 있습니다.
- 직관적 인 REST / HTTP 인터페이스
- 간편한 복제
- 정규화 된 테이블이 아닌 문서로 저장된 데이터
이 제품이 성숙한 제품이 아니므로주의해서 채택해야하지만 실제로 RDBMS를 대체 할 수 있는지 궁금합니다 (소개 페이지에서 달리 언급 했음에도 불구하고-http: //couchdb.apache.org/docs) /intro.html ).
- 어떤 상황에서 CouchDB가 확장 성, 설계 + 개발 시간, 안정성 및 유지 관리 측면에서 RDBMS (예 : MySQL)보다 더 나은 데이터베이스 선택일까요?
- 여전히 RDBMS가 여전히 올바른 선택 인 경우가 있습니까?
- 이것은 둘 중 하나 또는 선택입니까, 아니면 하이브리드 솔루션이 모범 사례로 나타날 가능성이 더 높습니까?
저는 최근 런던에서 열린 NoSQL 컨퍼런스에 참석했으며 이제 원래 질문에 답하는 방법을 더 잘 알고 있다고 생각합니다. 나는 또한 블로그 게시물을 썼고, 다른 몇 가지 좋은 게시물 이 있습니다 .
키 포인트:
- 관계형 데이터베이스 관리에 대한 지식을 30 년 정도 축적 해 왔으므로 신중하게 고려하지 않고 교체해서는 안됩니다. 비 관계형 데이터 저장소는 관계형 데이터 저장소보다 덜 성숙하므로 본질적으로 채택하기가 더 위험합니다.
- 다양한 유형의 비 관계형 데이터 저장소가 있습니다. 일부는 키-값 저장소, 일부는 문서 저장소, 일부는 그래프 데이터베이스입니다.
- 소셜 소프트웨어 사이트를위한 RDBMS 및 그래프 데이터 저장소의 조합과 같은 하이브리드 접근 방식을 사용할 수 있습니다.
- 문서 데이터 저장소 (예 : CouchDB 및 MongoDB)는 아마도 관계형 데이터베이스에 가장 가깝고 테이블 조인을 수행 할 필요가 없도록 계층 적으로 제시된 모든 필드가 포함 된 JSON 데이터 구조를 제공하며 (일부는 주장 할 수 있음) 기존 객체를 개선 한 것입니다. 현재 대부분의 응용 프로그램에서 사용하는 관계형 매핑
- 비 관계형 데이터베이스는 복제를 지원합니다 (마스터-마스터 포함). 관계형 데이터베이스도 복제를 지원하지만 비 관계형 옵션만큼 포괄적이지 않을 수 있습니다.
- Twitter, Digg 및 Facebook과 같은 대규모 사이트는 클러스터링을 지원하기 위해 처음부터 구축 된 Cassandra를 사용합니다.
- 관계형 데이터베이스는 아마도 90 %의 경우에 적합 할 것입니다.
요약하면, 합의는 "주의해서 진행"되는 것 같습니다.
누군가가 더 깊이있는 답변을 제공 할 때까지 CouchDB의 장단점은 다음과 같습니다.
장점 :
- 데이터를 성가신 고차 정규 형식 중 하나에 맞출 필요가 없습니다.
- 언제든지 데이터의 "스키마"를 변경할 수 있습니다.
- 데이터는 쿼리에 대해 정확히 인덱싱되므로 일정한 시간에 결과를 얻을 수 있습니다.
단점 :
- 각각의 모든 쿼리에 대한 뷰를 생성해야합니다. 즉, 임시 쿼리 (예 : SQL에서 동적 WHERE와 SORT를 연결) 쿼리를 사용할 수 없습니다.
- 중복 데이터가 있거나 "클라이언트 측"에서 직접 결합 및 정렬 논리를 구현하게됩니다 (예 : 여러 필드에서 다 대다 관계 정렬).
장단점 :
- 뷰를 만드는 것은 SQL처럼 간단하지 않으며 퍼즐을 푸는 것과 비슷합니다. 이것이 장단점인지 유형에 따라 다릅니다. :)
CouchDB는 사용 가능한 여러 '키 / 값 저장소'중 하나이며, 다른 것에는 BDB 와 같은 오래된 저장소, Persevere , MongoDB 및 CouchDB와 같은 웹 지향 저장소, memcached (RAM 전용) 및 Tokyo Cabinet 과 같은 새로운 초고속 저장소, Hadoop과 같은 거대한 저장소가 포함됩니다. 및 Google의 BigTable (MongoDB도이 공간에 있다고 주장함).
확실히 키 / 값 저장소와 관계형 DB를위한 공간이 있습니다. 전통적으로 대부분의 RDB는 키 / 값 위의 계층으로 간주됩니다. 예를 들어 MySQL은 테이블의 선택적 백엔드로 BDB를 사용했습니다. 간단히 말해서 키 / 값은 SQL의 기초 인 필드와 관계에 대해 아무것도 모릅니다.
키 / 값 저장소는 일반적으로 확장하기가 더 쉽기 때문에 Twitter처럼 폭발적으로 성장할 때 매력적인 선택이됩니다. 물론 이는 저장된 값 사이의 모든 관계를 SQL에서 선언하는 대신 코드에서 관리해야 함을 의미합니다. CouchDB의 접근 방식은 값 부분에 큰 '문서'를 저장하여 (대부분) 자체 포함하여 단일 쿼리에서 필요한 대부분의 데이터를 얻을 수 있습니다. 많은 사용 사례가이 아이디어에 적합하지만 다른 사례는 그렇지 않습니다.
내가 본 현재 테마는 "레일이 확장되지 않는다 !!"이후입니다. 이제 많은 사람들이 웹 프레임 워크에 관한 것이 아니라는 사실을 깨닫고 있습니다. 하지만 지능적인 캐싱에 관해서는 데이터베이스와 가능한 경우 웹 앱에 충돌하지 않도록합니다. 떠오르는 별은 memcached입니다.
항상 그렇듯이 모든 것은 귀하의 필요에 달려 있습니다.
이것은 대답하기 어려운 질문입니다. 그래서 저는 CouchDB가 당신에게 불리하게 작용할 수있는 영역을 강조하려고 노력할 것입니다.
사람들이 가지고있는 Couch Users 및 Dev 메일 링리스트에서 가장 어려운 두 가지 원인은 다음과 같습니다.
- 복잡한 데이터 조인.
- 다단계지도 / 축소.
소파 뷰는 그 자체로 거의 섬입니다. 뷰 세트를 집계 / 병합 / 교차해야하는 경우 지금은 애플리케이션 계층에서 수행해야합니다. 조인에 도움이되는 뷰 데이터 정렬 및 복잡한 키로 수행 할 수있는 몇 가지 트릭이 있지만 지금까지는 일부 데이터 유형에만 적용됩니다. 이것은 다른 응용 프로그램에 대해 살 수도 있고 살 수 없을 수도 있습니다. 데이터를 다르게 구성함으로써이 문제를 줄이거 나 없앨 수 있다고 여러 번 말하고 있습니다.
이 질문에 대한 다른 사람들의 의견은 CouchDB에 적합한 다양한 유형의 데이터 중 일부를 보여줍니다.
명심해야 할 또 다른 사항은 결합 / 병합 / 교차해야하는 데이터가 어쨌든 RDBMS 데이터베이스에서 오프라인으로 수행 할 데이터 일 수 있으므로 CouchDB에서 동일한 작업을 수행해도 아무것도 잃지 않을 수 있다는 것입니다.
짧은 답변 : 결국 CouchDB는 여러분이 던지고 싶은 모든 종류의 문제를 처리 할 수있을 것이라고 생각합니다. 그러나 사용하는 편안함 수준은 개발자마다 다를 수 있습니다. 다소 주관적이라고 생각합니다. 저는 튜링 완전한 언어를 사용하여 데이터를 쿼리하고 애플리케이션 계층에 더 많은 논리를 유지하는 것을 좋아합니다. 귀하의 마일리지가 다를 수 있습니다.
Sam you have to take another approch with CouchDB and in general with map or document based database. You can't define a constraint, such a unique, but you can query data to check if that email is used and if that login is used too. That's the right approch, you have to change your mind.
Correct me if I am wrong. Couchdb is useless for the cases when you need to validate uniqueness of docs over multiple fields. For example it's impossible to enforce validation rule like "both login and email required to be unique" and keep data in consustent state. You can check that before saving the doc, but someone can push before you and data becomes inconsistent.
If you are working with tabular data where there is only a shallow data hierarchy, than an RDBMS system is probably your best choice. This is the main use for RDBMS systems, and the documentation and tool support is very good.
For more nested data like xml, a document database should provide faster access to your data. Also, the storage model more closely resembles that of the data, so retrieval should be more straight forward.
참고URL : https://stackoverflow.com/questions/1307100/when-to-use-couchdb-vs-rdbms
'UFO ET IT' 카테고리의 다른 글
| jquery를 사용하여 상단 위치를 설정하는 방법 (0) | 2020.11.25 |
|---|---|
| C ++에서 float를 std :: string으로 변환 (0) | 2020.11.25 |
| 값이없는 테이블에 삽입하기위한 구문? (0) | 2020.11.24 |
| WordPress MVC를 준수합니까? (0) | 2020.11.24 |
| JPA Hibernate를 사용하여 자동으로 자식 개체 저장 (0) | 2020.11.24 |