mongodb에서 데이터 중복이 너무 많습니까?
저는이 모든 NOSQL 항목에 익숙하지 않으며 최근 mongoDB에 관심이 있습니다. 저는 처음부터 새 웹 사이트를 만들고 MONGODB / NORM (C # 용)을 유일한 데이터베이스로 사용하기로 결정했습니다. 문서 모델 데이터베이스를 올바르게 디자인하는 방법에 대해 많이 읽었으며 대부분의 경우 디자인이 꽤 잘 작동했다고 생각합니다. 새 사이트를 시작한 지 약 6 개월이되었고 계속해서 처리해야하는 데이터 복제 / 동기화 문제를보기 시작했습니다. 내가 읽은 바에 따르면 이것은 문서 모델에서 예상되며 성능 측면에서는 의미가 있습니다. IE는 문서에 포함 된 개체를 삽입하여 읽기가 빠르며 조인이 없습니다. 그러나 물론 항상 포함 할 수는 없으므로 mongodb에는 기본적으로 관계형 DB의 외래 키와 유사한 DbReference 개념이 있습니다.
여기에 예가 있습니다. 사용자와 이벤트가 있습니다. 둘 다 자신의 문서를 얻고, 사용자는 이벤트에 참석하고, 이벤트에는 사용자가 참석합니다. 제한된 데이터가있는 이벤트 목록을 User 개체에 포함하기로 결정했습니다. 사용자 목록도 이벤트 개체에 "참석자"로 포함했습니다. 여기서 문제는 이제 사용자를 이벤트 개체에도 포함 된 사용자 목록과 동기화 상태로 유지해야한다는 것입니다. 내가 읽었을 때, 이것이 선호되는 접근 방식이며 일을 수행하는 NOSQL 방식 인 것 같습니다. 검색은 빠르지 만 기본 사용자 문서를 업데이트 할 때 대비책은 이벤트 개체로 이동하여 해당 사용자에 대한 모든 참조를 찾아서 업데이트해야한다는 것입니다.
그래서 제가 가진 질문은 이것이 사람들이 처리해야하는 매우 일반적인 문제입니까? "NOSQL 전략이 내가 여기서 수행하려는 작업에 맞지 않을 수도 있습니다."라고 말하기 전에이 문제가 얼마나 발생해야합니까? 포함 된 개체에서 데이터를 동기화 상태로 유지하고이를 위해 DB에 대한 여러 읽기를 수행하는 데 어려움을 겪고 있기 때문에 조인을 수행하지 않아도되는 성능 이점이 언제 단점이됩니까?
그것은 문서 저장소와의 상충 관계입니다. 표준 RDMS와 같이 정규화 된 방식으로 저장할 수 있으며 가능한 한 정규화를 위해 노력해야합니다. 정규화를 깨고 데이터 구조를 평탄화해야하는 것은 성능 저하가있는 곳뿐입니다. 트레이드 오프는 읽기 효율성과 업데이트 비용입니다.
Mongo는 전통적인 RDMS처럼 쉽게 정규화 할 수있는 매우 효율적인 인덱스를 가지고 있습니다 (대부분의 문서 저장소는 이것을 무료로 제공하지 않기 때문에 Mongo는 순수한 문서 저장소 대신 하이브리드에 가깝습니다). 이를 사용하여 사용자와 이벤트 간의 관계 수집을 만들 수 있습니다. 테이블 형식 데이터 저장소의 서로 게이트 테이블과 유사합니다. 이벤트 및 사용자 필드를 인덱싱하면 매우 빠르며 데이터를 더 잘 정규화하는 데 도움이됩니다.
레코드 데이터를 업데이트하는 데 걸리는 시간과 쿼리에서 필요한 것을 읽는 데 걸리는 시간과 관련하여 구조를 평탄화하는 것과 정규화하는 것의 효율성을 플롯하고 싶습니다. 큰 O 표기법으로 할 수는 있지만 그렇게 화려할 필요는 없습니다. 데이터에 대해 서로 다른 모델을 사용하는 몇 가지 사용 사례를 기반으로 몇 가지 숫자를 종이에 적어두고 얼마나 많은 작업이 필요한지에 대해 좋은 직감을 얻으십시오.
기본적으로 내가하는 일은 먼저 레코드에 얼마나 많은 업데이트가 있을지와 읽히는 빈도를 예측하는 것입니다. 그런 다음 정규화 또는 평탄화 (또는 내가 생각할 수있는 두 가지의 부분적 조합 ... 많은 최적화 옵션) 일 때 업데이트 비용과 읽기 비용을 예측하려고합니다. 그런 다음 평평하게 유지하는 데 따른 절감 효과와 정규화 된 소스에서 데이터를 구축하는 데 드는 비용을 판단 할 수 있습니다. 일단 모든 변수를 플로팅 한 후이를 평평하게 유지함으로써 절약 할 수 있다면 평평하게 유지할 것입니다.
몇 가지 팁 :
- 빠르고 원자적인 (완벽한 최신) 조회가 필요한 경우 정규화보다 평탄화를 선호하고 업데이트에서 히트를 취하는 솔루션을 선호 할 수 있습니다.
- 신속하게 업데이트하고 즉시 액세스해야하는 경우 정규화를 선호하십시오.
- 빠른 조회가 필요하지만 완벽하게 최신 데이터가 필요하지 않은 경우 일괄 작업에서 정규화 된 데이터를 구축하는 것이 좋습니다 (맵 / 리 듀스 사용 가능).
- 쿼리 속도가 빨라야하고 업데이트가 드물고 업데이트에 즉시 액세스 할 수 있어야하거나 업데이트가 디스크에 기록되었음을 보장하기 위해 트랜잭션 수준 잠금이 100 % 수행되어야하는 것은 아닙니다. 업데이트를 백그라운드에서 처리하는 대기열에 쓰는 것을 고려할 수 있습니다. (이 모델에서는 나중에 충돌 해결 및 조정을 처리해야 할 것입니다.)
- 다양한 모델을 프로파일 링합니다. 나중에 데이터 저장소 구조를 리팩토링 할 수 있도록 코드에서 데이터 쿼리 추상화 계층 (방식에서 ORM과 같은)을 구축합니다.
사용할 수있는 다른 아이디어가 많이 있습니다. highscalabilty.org와 같은 훌륭한 블로그가 온라인에 많이 있으며 CAP 정리를 이해하고 있는지 확인합니다.
Redis 또는 Memcache와 같은 캐싱 계층도 고려하십시오. 이러한 제품 중 하나를 데이터 영역 앞에 배치합니다. mongo (정규화 된 모든 것을 저장하고 있음)를 쿼리 할 때 데이터를 사용하여 평면화 된 표현을 구성하고 캐시에 저장합니다. 데이터를 업데이트 할 때 업데이트중인 항목을 참조하는 캐시의 모든 데이터를 무효화합니다. (스케일링 요인을 고려하여 업데이트되는 캐시에서 데이터를 무효화하고 데이터를 추적하는 데 시간이 걸립니다). 누군가는 "컴퓨터 과학에서 가장 어려운 두 가지는 이름 지정과 캐시 무효화"라고 말했습니다.
도움이 되었기를 바랍니다.
User 개체에 UserEvent 속성 유형의 IList를 추가해보세요. 도메인 모델이 어떻게 설계되었는지에 대해 많이 지정하지 않았습니다. NoRM 그룹 http://groups.google.com/group/norm-mongodb/topics 에서 예를 확인하세요 .
참고 URL : https://stackoverflow.com/questions/4010032/too-much-data-duplication-in-mongodb
'IT TIP' 카테고리의 다른 글
| C #에서 이름이있는 값 튜플에 별칭을 정의 할 수 있습니까? (0) | 2020.11.05 |
|---|---|
| Android를 통해 Google 계정 ID / 사용자 이름에 액세스 (0) | 2020.11.05 |
| CSS 픽셀이 분수 일 수 있습니까? (0) | 2020.11.05 |
| Angular 2의 동적 템플릿 URL (0) | 2020.11.05 |
| Linux 커널 모듈을 사용하는 것이 무엇인지 알아내는 방법이 있습니까? (0) | 2020.11.05 |