MongoDB 구조: 단일 컬렉션 대 여러 소규모 컬렉션
일반적인 데이터베이스 구조에 대한 질문이 있습니다.내 시나리오에서 나는 mongodb를 사용하고 있습니다.
사용자가 노래 목록(제목, 아티스트 등)을 업로드할 수 있는 응용 프로그램을 만들고 있지만 모든 사용자에 대해 하나의 songList 컬렉션을 가져야 할지 개별 사용자에 대해 별도의 songList.user# 컬렉션을 가져야 할지 모르겠습니다.사용자는 자신과 관련된 노래만 쿼리할 수 있으므로 사용자 A는 사용자 B의 노래에 대해 절대 알지 못합니다.
코드 예:
사용자당 여러 컬렉션
db.songList.userA.find()
{"title": "Some song of user A", "artist": "Some artist of user A"}
db.songList.userB.find()
{"title": "Some song of user B", "artist": "Some artist of user B"}
- 장점
- 쿼리할 컬렉션 크기가 더 작음
- 단점
- 유지관리성
- 1,000명의 사용자는 1,000개의 컬렉션을 의미합니다.
- 유지관리성
소유하는 '사용자' 필드가 있는 단일 컬렉션과 비교
db.songList.find({"user":"A"})
{"title": "Some song of user A", "artist": "Some artist of user A", "user": "A"}
- 장점
- 필요한 경우 사용자 간에 유연하게 쿼리 가능
- 단점
- 성능
나는 찬성/반대자 명단을 작성하려고 노력하고 있지만 여전히 보류 중입니다.각 사용자의 노래가 서로 격리될 것이라는 점을 고려할 때 어떤 접근 방식이 더 나은가요?저의 주된 관심사는 유지보수와 쿼리 성능입니다.
잘 부탁드립니다.
추천합니다.NOT
사용자별로 별도의 수집을 만듭니다.
설명서 읽기
기본적으로 MongoDB는 데이터베이스당 약 24,000개의 네임스페이스로 제한됩니다.각 네임스페이스는 628바이트이며 .ns 파일은 기본적으로 16MB입니다.
각 컬렉션은 각 인덱스와 마찬가지로 네임스페이스로 계산됩니다.따라서 모든 컬렉션에 하나의 인덱스가 있으면 최대 12,000개의 컬렉션을 만들 수 있습니다.--nssize 매개 변수를 사용하면 이 제한을 늘릴 수 있습니다(아래 참조).
수집당 최소 오버헤드는 몇 KB입니다.또한 b-tree 페이지 크기가 8KB이기 때문에 인덱스에는 최소 8KB의 데이터 공간이 필요합니다.수집이 많고 메타데이터가 페이징 아웃되면 특정 작업이 느려질 수 있습니다.
따라서 사용자가 네임스페이스 제한을 초과할 경우 이를 정상적으로 처리할 수 없습니다.또한 사용자 기반의 증가로 인해 성능이 높지 않을 것입니다.
갱신하다
@Henry Liu가 댓글에서 언급했듯이.WiredTiger 스토리지 엔진을 사용하는 Mongodb 3.0 이상의 경우 더 이상 제한이 되지 않습니다.
docs.mongodb.org/manual/reference/limits/ # 네임스페이스
MongoDB는 수평으로 확장하는 데 탁월합니다.동적 클러스터 간에 수집을 셰이딩하여 신속하고 신속한 데이터 수집을 생성할 수 있습니다.
따라서 수집 크기가 작아지는 것은 전문가가 아니며 SQL에도 없고 MongoDB에도 없다는 이론이 어디서 나왔는지 잘 모르겠습니다.샤딩의 성능은 (오버헤드가 작은) 단일 소규모 데이터 컬렉션을 쿼리하는 성능과 관련이 있어야 합니다.그렇지 않으면 샤딩을 잘못 설정한 것입니다.
@Sushant가 인용한 것처럼 MongoDB는 수직 확장에 뛰어나지 않습니다. 여기서 MongoDB의 ns 크기는 심각한 제한이 될 것입니다.인용문에서 언급하지 않는 한 가지는 인덱스 크기와 카운트가 ns 크기에도 영향을 미친다는 것입니다. 따라서 다음과 같이 설명합니다.
따라서 모든 컬렉션에 하나의 인덱스가 있으면 최대 12,000개의 컬렉션을 만들 수 있습니다.--nssize 매개 변수를 사용하면 이 제한을 늘릴 수 있습니다(아래 참조).
언급URL : https://stackoverflow.com/questions/13794595/mongodb-structure-single-collection-vs-multiple-smaller-collections
'programing' 카테고리의 다른 글
SELECT 쿼리 성능 최적화 (0) | 2023.06.26 |
---|---|
Kotlin + Gradle 확인되지 않은 참조 (0) | 2023.06.26 |
클래스 속성을 만드는 방법? (0) | 2023.06.26 |
두 개의 선택 테이블을 결합하여 선택 쿼리에 실제 결과를 표시하는 것과 동일하지 않은 이유 (0) | 2023.06.26 |
인스턴스 간에 클래스 데이터가 공유되지 않도록 하려면 어떻게 해야 합니까? (0) | 2023.06.26 |