MongoDB 속성 이름을 줄일 가치가 있습니까?

MongoDB 속성 이름을 줄일 가치가 있습니까?

mongodb 문서에서 저자는 속성 이름을 단축하는 것이 좋은 생각이라고 말합니다.

더 짧은 필드 이름을 사용합니다.

그리고 노드하는 방법의 이전 블로그 게시물에서 (현재 2022년 4월까지 오프라인입니다. 편집)

..mongoDB와 관련하여 자주 보고되는 문제는 디스크의 데이터 크기입니다.모든 레코드에는 모든 필드 이름이 저장됩니다.이것은 종종 '제목'이나 '본체'보다는 't'나 'b'와 같은 속성을 갖는 것이 더 공간 효율적일 수 있다는 것을 의미하지만, 혼란을 두려워하여 실제로 필요하지 않는 한 이것을 피할 것입니다!

나는 그것을 하는 방법에 대한 해결책을 알고 있습니다.저는 이것이 정말로 언제 필요한지에 대해 더 관심이 있습니다.

Donald Knuth의 말을 인용하자면:

조기 최적화는 프로그래밍에서 모든 악의 근원(또는 적어도 대부분)입니다.

그러나 애플리케이션을 구축하는 것이 가장 합리적이고, 유지보수가 가능하며, 논리적으로 보입니다.그런 다음 성능 또는 스토리지 문제가 있는 경우 성능이 만족스럽거나 수익률 감소의 법칙이 적용될 때까지 가장 큰 영향을 미치는 문제를 처리해야 합니다.

특정 설계 결정(예: 긴 특성 이름)의 영향을 확신할 수 없는 경우 다양한 가설(예: "더 짧은 특성 이름으로 많은 공간 절약")을 검정할 수 있는 프로토타입을 작성합니다.시험의 결과가 결정적일 것이라고 기대하지 마세요. 하지만 그것은 여러분이 배울 것이라고 기대하지 않았던 것들을 여러분에게 가르쳐줄 수도 있습니다.

사용자 자신의 상황과 테스트가 이러한 우선순위를 변경해야 하는 특정 이유를 제공하지 않는 한, 짧은 이름의 우선순위보다 의미 있는 이름의 우선순위를 유지합니다.

SERVER-863의 설명에서 언급한 바와 같이, 빠른 압축이 활성화된 WiredTiger 스토리지 옵션과 함께 MongoDB 3.0+를 사용하는 경우 압축이 단축을 효과적으로 처리하므로 긴 필드 이름은 문제가 되지 않습니다.

결론: 의미 있는 내용을 유지할 수 있도록 소형으로 유지합니다.

저는 이것이 꼭 한 글자의 이름으로 단축되어야 한다고 생각하지 않습니다.어쨌든 가능한 한 짧게 해야 하고, 마음이 편합니다.사용자 이름: {FirstName, MiddleName, Last}이(가) 있다고 가정해 보겠습니다. 짝수 이름: {first, middle, last}.당신이 편하다면 이름: {f,m,l}을(를) 써도 좋습니다.
짧은 이름을 사용해야 합니다.디스크 공간과 메모리를 사용하기 때문에 애플리케이션 속도가 다소 느려질 수 있습니다(메모리에 보관할 개체 수가 적을수록 조회 시간이 느려지고 데이터 검색 시간이 길어짐).
좋은 스키마 문서는 개발자에게 t가 제목이 아닌 town을 의미한다고 말할 수 있습니다.스택에 따라 일부 도우미 유틸리티를 통해 개발자가 이러한 바로 가기로 작업하지 못하도록 숨길 수도 있습니다.

마지막으로 스키마 이름을 언제, 얼마나 줄여야 하는지에 대한 지침이 없다고 말씀드리고 싶습니다.환경과 요구사항에 따라 크게 달라집니다.그러나 모든 것을 설명하고 개발자와 관리자의 삶을 쉽게 하기 위한 유용한 정보를 제공할 수 있는 좋은 문서를 제공할 수 있다면 압축된 상태를 유지하는 것이 좋습니다.어쨌든 관리자는 mongodb와 직접 상호 작용할 가능성이 높기 때문에 좋은 문서를 놓쳐서는 안 된다고 생각합니다.

약간의 벤치마크를 수행하고 다음과 같이 Excel에서 252줄의 데이터를 testShortNames 및 testLongNames 컬렉션에 업로드했습니다.

긴 이름:

{
    "_id": ObjectId("6007a81ea42c4818e5408e9c"),
    "countryNameMaster": "Andorra",
    "countryCapitalNameMaster": "Andorra la Vella",
    "areaInSquareKilometers": 468,
    "countryPopulationNumber": NumberInt("77006"),
    "continentAbbreviationCode": "EU",
    "currencyNameMaster": "Euro"
}

짧은 이름:

{
    "_id": ObjectId("6007a81fa42c4818e5408e9d"),
    "name": "Andorra",
    "capital": "Andorra la Vella",
    "area": 468,
    "pop": NumberInt("77006"),
    "continent": "EU",
    "currency": "Euro"
}

그런 다음 각각의 통계를 가져와 디스크 파일에 저장한 다음 두 파일에 대해 "diff"를 수행했습니다.

pprint.pprint(db.command("collstats", dbCollectionNameLongNames))

아래 이미지는 크기와 저장소 크기라는 두 가지 관심 변수를 보여줍니다.제가 읽은 결과 storageSize는 압축 후 사용된 디스크 공간의 양이며 기본적으로 size는 압축되지 않은 크기입니다.storageSize가 동일하다는 것을 알 수 있습니다.Wired Tiger 엔진은 필드 이름을 꽤 잘 압축합니다.

그런 다음 프로그램을 실행하여 각 컬렉션의 모든 데이터를 검색하고 응답 시간을 확인했습니다.

1초 미만의 쿼리임에도 불구하고 긴 이름은 지속적으로 약 7배의 시간이 걸렸습니다.물론 데이터베이스 서버에서 클라이언트 프로그램으로 더 긴 이름을 보내는 데는 더 오랜 시간이 걸립니다.

-------LongNames-------
Server Start DateTime=2021-01-20 08:44:38
Server End   DateTime=2021-01-20 08:44:39
StartTimeMs= 606964546  EndTimeM= 606965328
ElapsedTime MilliSeconds= 782
-------ShortNames-------
Server Start DateTime=2021-01-20 08:44:39
Server End   DateTime=2021-01-20 08:44:39
StartTimeMs= 606965328  EndTimeM= 606965421
ElapsedTime MilliSeconds= 93

Python에서 저는 다음을 수행했습니다(읽기를 강제하기 위해 실제로 항목을 반복해야 했습니다. 그렇지 않으면 쿼리가 커서만 반환합니다.).

results = dbCollectionLongNames.find(query)
for result in results:
    pass

여기에 내 2센트를 더하면..

이름이 긴 속성(또는 "비정상적으로 긴 이름 속성")은 데이터 모델을 설계하는 동안 방지할 수 있습니다.이전 조직에서 우리는 조직이 정의한 4-5자 인코딩 문자열과 같은 짧은 이름 속성 전략을 유지하는 것을 테스트했습니다. 예를 들어, 다음과 같습니다.

1. 이름 = FSTNM,
2. 성 = LSTNM,
3. 월별 이익 손실률 = MTPCT,
4. 연도별 매출 예상 = YOIPS 등)

네트워크를 통해 전송되는 데이터의 크기가 줄거나 (MongoDB와 함께 Java를 사용했기 때문에) MongoDB 문서/Java Map 힙 공간의 "키" 길이가 줄었기 때문에 쿼리 성능이 크게 향상되었지만, 전반적인 성능은 15% 미만이었습니다.

제 개인적인 의견으로는, 이것은 각 데이터 모델에 대한 데이터 속성 사전 관리 시스템을 추가로 유지/설계하는 데 드는 추가 비용(그리고 큰 골칫거리)이 드는 미시적 최적화였습니다.이 시스템은 애플리케이션을 디버깅하거나 클라이언트 쿼리에 응답하는 동안 조직 전체의 투명성이 요구되었습니다.

이 전략을 사용하여 성능을 최대 20% 향상시키는 것이 유리한 상황에 처해 있다면 MongoDB 서버를 확장하거나 다른 데이터 모델링/쿼리 전략을 선택하거나 다른 데이터베이스를 함께 선택해야 할 때일 수 있습니다.

자세한 xml을 사용하는 경우 사용자 지정 이름으로 이를 개선하는 것이 매우 중요할 수 있습니다.SERVER-863 티켓의 사용자 의견에 따르면, 저는 외부에서 정의된 XML 객체를 상세한 이름으로 저장하고 있습니다. 필드 이름은 아마도 전체 레코드 크기의 70%일 것입니다.따라서 필드 이름 토큰화는 I/O와 메모리 효율성 측면에서 모두 큰 성공을 거둘 수 있습니다.'

작은 이름의 컬렉션 - 큰 이름의 압축 컬렉션 삽입 - 일반 삽입

몽고샤드 클러스터에서 이 작업을 수행했으며 분석 결과가 표시됩니다.

1. 저장하는 동안 짧은 이름이 약 10-15% 증가하며 네트워크 지연 시간을 기준으로 합니다.여러 스레드를 사용하여 대량 삽입을 추가했습니다.따라서 한 번 삽입하면 더 많은 비용을 절약할 수 있습니다.

2. InsertCompress의 평균 데이터 크기는 280B이고 InsertNormal은 350B이며 2,500만 개의 레코드를 삽입했습니다.따라서 InsertNormal은 8.1GB, InsertCompress는 6.6GB를 나타냅니다.이것은 데이터 크기입니다.

3. 놀랍게도 Index 데이터 크기는 InsertCompress 컬렉션의 경우 2.2GB, InsertNormal 컬렉션의 경우 2GB로 표시됩니다.

4. InsertCompress 컬렉션의 스토리지 크기는 2.2GB인 반면 InsertNormal은 약 1.6GB입니다.

전체적으로 네트워크 지연 시간 외에는 스토리지에 대해 얻을 수 있는 것이 없으므로 스토리지를 절약하기 위해 이 방향으로 노력할 가치가 없습니다.문서 크기가 훨씬 크고 필드 이름이 작을 경우에만 고려할 수 있는 많은 데이터가 저장됩니다.

언급URL : https://stackoverflow.com/questions/12790861/is-shortening-mongodb-property-names-worthwhile