"NoSQL"데이터베이스에서 데이터 모델이 확장 성과 성능에 얼마나 영향을 줍니까?

CAP 정리 (Consistency, Availability, Partition : pick two)를 가져 오지 않고 "NoSQL"데이터베이스에 대해 이야기 할 수는 없습니다. MongoDB (Partition, Consistency)와 CouchDB (Availability, Partition) 사이에서 선택해야 할 경우 가장 먼저 생각해야 할 것은 "올바른 데이터가 필요합니까? 아니면 항상 액세스해야합니까?"입니다.

그 새 데이터베이스가되었다 만든 분할 될 수 있습니다. 하지만 내가 하지 않으면 어떻게됩니까? 관계형 데이터베이스 대신 데이터베이스 / 키, 값, 열, 문서가 있고 서버 인스턴스를 하나만 작성하고 샤드하지 않는 것이 좋다고 생각한다면 어떻게해야합니까? 이 경우 가용성과 일관성이 모두 없습니까? MongoDB는 아무것도 복제 할 필요가 없으므로 사용할 수 있습니다. 그리고 CouchDB는 하나의 데이터 소스만을 가지므로 꽤 일관성이 있습니다.

그렇다면 MongoDB와 CouchDB는 유스 케이스의 기간에 거의 차이가 없을 것입니까? 물론 성능, API 및 al을 제외하고는 기본적으로 서로 다른 두 가지 요구 사항을 갖는 것보다 PostgreSQL과 MySQL 중에서 선택하는 것과 비슷합니다.

내가 여기있어? 인스턴스를 두 개 이상 만들지 않으면 서 AP 또는 CP 데이터베이스를 AC 데이터베이스로 변경할 수 있습니까? 아니면 내가 놓친 것이 있습니까?

질문을 반대로하자. 관계형 데이터베이스를 가져 와서 MySQL이라고 말하고 마스터 / 슬레이브 구성에 넣으면 어떻게 될까요? ACID 트랜잭션을 사용하지 않습니다. 쓰기를 즉시 슬레이브에 동기화해야한다면 CP 데이터베이스가되지 않습니까? 미리 정의 된 간격을 동기화하면 클라이언트가 슬레이브에서 오래된 데이터를 읽는지 여부는 중요하지 않습니다. 그것이 AP 데이터베이스가되지 않습니까? ACID 준수를 포기하더라도 여전히 분할 된 데이터베이스에 관계형 모델을 사용할 수 있다는 의미는 아닙니까?

본질적으로 : 기본 데이터 모델보다 더 많은 CAP 정리에서 포기할 준비가 된 것에 대한 확장 성이 있습니까? 열, 문서, 키 값 등이 관계형 모델에 비해 확장 성을 향상시키는 것은 무엇입니까? 파티션 공차를 위해 처음부터 설계된 관계형 데이터베이스를 설계 할 수 있습니까? (아마도 존재합니다). NoSQL 데이터베이스 ACID를 준수 할 수 있습니까?

죄송합니다. 많은 질문이 있지만 최근에 NoSQL 데이터베이스에 대해 많이 읽었으며이 데이터베이스를 사용하면 얻을 수있는 가장 큰 이점은 파티션 인 CAP보다는 데이터의 "모양"에 더 잘 맞는다는 것입니다. ACID 준수 포기. 결국, 모든 사람이 데이터를 분할해야 할만큼 많은 데이터를 가지고있는 것은 아닙니다. 데이터 분할에 대해 생각하기 전에 관계형 모델을 사용하지 않으면 성능 / 확장 성 이점이 있습니까?

데이터를 샤딩하지 않아도 NoSQL 데이터베이스를 사용하면 확장 성이 향상됩니까? 확장 성을 정의하자. 데이터베이스 / 백엔드 시스템과 관련하여 확장 성을 언급하는 경우 수평 스케일링이 샤딩 데이터 인 수직 및 수평 스케일링이있는 경우, 이것은 당신이 남겨둔 유일한 옵션이기 때문에 대답이 절대적으로 아니오이므로 사소한 질문이됩니다. 수직 확장 (즉, 더 나은 하드웨어를 얻는 것)입니다. 그러나 응용 프로그램의 유연성, 데이터 값 등을 참조하여 확장성에 대해 더 넓은 의미로 이야기하는 경우 여러 답변이있는 완전히 다른 질문입니다. 그리고 당신이 언급 한 것처럼 그것은 종종 당신이 데이터로 무엇을하고 있고 어떻게 저장 해야하는지에 달려 있습니다. 대부분의 경우 여전히 RDBMS를 사용해야하고 NoSQL은 틈새 시장을 채워야한다는 진술로 여기에 모든 것을 소개하겠습니다. 다음은 특정 요구 사항에 따라 NoSQL 데이터베이스가 더 유용하고 수평 확장을 무시할 수있는 특정 인스턴스에 대한 설명입니다.

예를 들어 Google 드라이브, 보관함 또는 상자와 유사한 클라우드 파일 저장 시스템을 만들고 있지만 실제 파일 시스템을 사용하는 대신 파일 시스템을 가상화하는 것이 더 유리하다고 생각하십시오. 이제 데이터 모델이 RDBMS에서 엄청나게 비효율적 인 트리 구조이기 때문에 문제가 있습니다 (모든 것이 인덱스되는 방식 임에도 불구하고). 이제 이름, 사용자 및 상위가있는 3 개의 열 테이블이 있습니다. User는 users 테이블에 대한 외래 키이고 Parent는 자체 참조 nullable 외래 키입니다 (루트 디렉터리에 부모가 없어 null이 가능함). 기본 키는 무엇입니까? 이 경우 모든 열에 걸쳐 복합 키입니다. 갑자기 부모를 최악의 적으로 만듭니다.

대신 어떤 형태의 문서 저장소에 어떻게 넣을 것인지 생각해보십시오. 데이터와 싸우는 대신 데이터를 사용하여 트리 구조로 저장하여 개발 시간을 줄이고 유지 관리 비용을 줄일 수 있습니다. 비용을 줄이더라도 다른 종류의 확장 성이 허용되지 않습니까? 또한이 경우 처음부터 시스템을 올바르게 작성하여 애플리케이션 자체에 더 많은 유연성을 제공해야합니다. 현재 MongoDB를 사용하여 단일 서버에서 이것을 실행하고 있습니다.이 설명에 따르면 MySQL 또는 Postgres의 차이점을 보는 것과 크게 다르지 않은 Available, Consistent 모델이 제공됩니다.

MongoDB를 사용하면 쿼리가 성공하기 위해 통신해야하는 서버 수를 정의 할 수 있습니다. 예. 모든 쿼리에 모든 서버 인스턴스와 통신하도록 지시하면이를 일관성 있고 사용 가능한 모델로 변환 할 수 있습니다.

따라서 데이터 저장 방법에 큰 이점이 있다는 점에서 귀하는 권리가 있다고 생각합니다. 다른 모델에 잘 맞는 관계형 모델에는 적합하지 않은 것들이 있습니다 (또 다른 간단한 예로서 Amazon은 제품에 대한 권장 엔진으로 어떤 형태의 그래프 데이터베이스를 사용합니다).

귀하의 질문을 올바르게 이해 했습니까?

편집 : 더 많은 데이터로 인해 속도가 느려 집니까? 예. 얼마나 느려질까요? 솔직히 충분한 답변을 드릴 충분한 경험이 없습니다. 키 / 값 : 기본적으로 조회 키와 관련된 많은 양의 데이터가있는 조회 테이블입니다. 키로 만 물건을 찾을 수 있기 때문에 이것은 정말 빠릅니다. 열 / 가족 : 기본적으로 훨씬 구조화 된 키 / 값 저장소입니다. 열을 기준으로 쿼리 할 수 ​​있으므로 너무 빠릅니다. 문서 : 집계 스타일 스키마. 여기에서 유사한 데이터를 모으고 싶을 것입니다. 이러한 종류의 데이터베이스에는 비정규 화가 정상이며 예상됩니다. 쓰기 또는 읽기를 많이 수행하는지 여부에 따라 데이터를 여러 샤드에 분산하여 쓰기 또는 읽기를 분산하도록 데이터를 구성 할 수 있습니다 (두 가지 모두에 적합한 하이브리드 방식을 만들 수 있음에 유의하십시오) 하나 또는 다른 하나에 대한 최적화를 선택해야합니다.) 그래프 : 이것의 장점은 관계를 정말 빠르게 생성하고 해제 할 수 있다는 것입니다. 데이터간에 변경해야하는 관계가있는 데이터가있는 경우 (일부 형식의 추천 엔진 생각)이를 사용해야합니다.

이러한 데이터베이스 중 하나에 데이터를 저장하는 방법은 성능에 영향을줍니다 (일부 RDBMS에 데이터를 잘못 저장하면 성능에 영향을 미친다는 점과 유사). 따라서이를보다 명확하게하기 위해 사용해야 할 데이터베이스 시스템과 해당 데이터베이스 시스템에 데이터를 저장하는 방법을 알아야합니다.