MongoDB의 다국어 데이터 모델링

MongoDB의 다국어 데이터 모델링

MonogoDB에서 제 객체를 모델링하려고 하는데 어떻게 진행해야 할지 모르겠습니다.다음과 같은 제품 카탈로그를 만들고 있습니다.

• 제품 카탈로그를 자주 변경할 수 없습니다.대량 작업은 매주/이주일에 걸쳐 수행될 수 있습니다.
• 제품 정보는 다국어(영어, 스페인어, 프랑스어)로 제공되며 언제든지 새로운 언어를 추가할 수 있습니다.

다국어 기능을 캡처하려면 제품 카탈로그를 모델링해야 합니다.예를 들어 다음과 같습니다.

product : { 
 _id:xxx,
 sku:"23456",
 name:"Name",
 description: "Product details", 
 tags:["x1","x2"]}... 
}

물론 이름, 설명, 태그 및 가능한 이미지는 언어에 따라 달라질 것입니다.그럼 어떻게 모델링해야 할까요?

1. 각 언어(예: enProducts, esProducts 등)에 대해 별도의 컬렉션을 가질 수 있습니다.

2. JSON은 제품 자체에 다음과 같은 개별 언어로 표시됩니다.

   product :{
      id: xxx,
      en: {
            name: "Name",
            description: "product details.."
          },
      es: {
            name: "Name",
            description: "product details.."
          },
      ...   
   }
   

아니면 다른 해결책이 있습니까?여기에 이 필요합니다 :) MongoDB 모델 전문가의 도움이 합니다 :)

다른 옵션은 언어별로 값을 다르게 유지하는 것입니다.스키마를 훨씬 쉽게 유지 관리할 수 있습니다.

product : { 
 _id:xxx,
 sku: {
   und: "23456"
 },
 name: {
   en: "Fork",
   de: "Gabel"
 },
 description: {
   en: "A metal thingy with four spikes",
   de: "Eine Dinge aus metal der vier spitze hat"
 }  
}

und는 "en 즉언어에 할 수 "을 "flack", "flack", "en"을 "en을 ""으로 . 또는 원하는 경우 항상 "en"을 "flack"으로 사용합니다.

위의 예는 대략적으로 Drupal CMS가 언어를 관리하는 방법입니다(SQL에서 Mongo로 번역되기는 하지만).

이 접근 방식은 어떻습니까?

product: {
  id: 1,
  name: 'Original Name',
  description: 'Original Description',
  price: 33,
  date: '2019-03-13',
  translations: {
    es: {
      name: 'Nombre Original',
      description: 'Descripción Original',
    }
  }
}

한 경우translations개체에 존재하므로 병합만 하면 되며, 변환이 없는 키가 있으면 원본이 남아 있습니다.

또 다른 장점은 번역 기능을 제거하거나 일부 언어를 추가/제거해야 하는 경우 번역 키를 변경하거나 제거하기만 하면 되며 전체 스키마를 재팩터링할 필요가 없다는 것입니다.

두 솔루션 모두 일반적으로 이를 위한 표준이며, 첫 번째 솔루션은 RDBMS 기술에서도 표준입니다(또는 파일 기반 번역은 여기서는 불가능한 또 다른 방법입니다).

여기서 어떤 것이 가장 좋은지에 대해서는, 당신의 사용을 고려하여 두 번째 쪽으로 기울고 있습니다.

그 이유 중 일부는 다음과 같습니다.

• 모든 번역 및 제품 데이터에 대한 단일 문서 로드, JOIN 없음
• 디스크를 연속적으로 한 번 읽을 수 있도록 합니다.
• 원자력 업데이트를 허용하고 단일 제품에 새로운 언어 및 변경 사항 등을 추가할 수 있습니다.

하지만 몇 가지 단점이 있습니다.

• 업데이트는 (아마도) 2가지 크기의 힘으로 어느 정도(완전히는 아니지만) 해결할 수 있는 단편화를 생성할 수 있습니다.
• 이제 모든 작업이 실제로 병목 현상을 일으킬 수 있는 하드 디스크의 단일 부분으로 이동하지만, 시나리오는 업데이트를 자주 하지 않기 때문에 문제가 되지 않습니다.

참고로 다음과 같습니다.파편화는 당신에게 큰 문제가 아닐 수도 있다고 판단합니다.그 이유는 제품을 대량으로만 가져오기 때문입니다. CSV에서 제품을 대량으로 가져오기 때문에 문서가 정기적으로 삽입할 때 2의 거듭제곱보다 커지지는 않을 것입니다.따라서 이 점은 쓸모가 없을 수 있습니다.

따라서 전체적으로 계획된 권리가 있다면 두 번째 옵션은 좋은 옵션이지만 고려해야 할 몇 가지 고려 사항이 옵션은 다음과 같습니다.

• 다중 설명/필드가 문서를 16메가 제한을 초과할 수 있습니까?
• 공간을 효율적으로 사용하고 조각화를 방지하기 위해 문서에 수동으로 패드를 넣는 방법은 무엇입니까?

그것들은 당신이 두 번째 선택을 한다면 당신의 가장 큰 걱정입니다.

셰익스피어의 모든 작품을 4MB에 넣을 수 있고 여유 공간이 있다는 것을 고려하면 16MB의 한계에 도달할 수 있을지, 만약 그렇게 한다면 상당한 텍스트가 되어야 할 것이고, 어쩌면 이진법으로 된 이미지를 문서에 저장할 수도 있습니다.

첫 번째 옵션으로 돌아가서, 하나는 공통 데이터를 저장하는 데 사용하고 다른 하나는 번역(실제 4개의 문서는 2개의 쿼리를 사용함)하지 않는 한 귀하의 가장 큰 관심사는 특정 데이터, 즉 가격(프랑스와 스페인 모두 유로)의 중복입니다.

이 카탈로그는 대량으로 복제된 데이터가 크게 문제가 되지 않는 한 절대 업데이트되지 않을 것입니다(그러나 향후 확장 시 참조를 위해 주의하겠습니다).

• 번역당 하나의 문서를 사용할 수 있으므로 모든 지역에서 가격을 원자적으로 업데이트할 필요가 없습니다.
• 단편화 없이 디스크 하나를 읽었습니다.
• 수동으로 문서를 패딩할 필요 없음

그래서 두 가지 옵션 모두 쉽게 사용할 수 있지만 저는 두 번째 경우로 기울고 있습니다.

키 및 키에서 인덱싱해야 하는 값에 대해 다음 패턴을 사용합니다.

 {
"id":"ObjectId",
"key":"error1"
"values":[{
             "lang":"en", 
             "value":"Error Message 1"
          },
          {
             "lang":"fa", 
             "value":"متن خطای شماره 1"
          }] 
}

C#에서 이 코드를 사용

object = coleccion.find({"key": "error1"});

이 링크를 보십시오. 포함된 문서를 사용한 모델 일대일 관계!

정적인 언어 목록을 보려면 쿼리하기 쉽기 때문에 @Zagorulkin Dmitry 솔루션을 사용합니다.

동적 언어 목록의 경우 스키마를 변경하지 않고 데이터를 쉽게 관리할 수 있습니다.

단점은 쿼리가 덜 사소한 것이라는 것입니다.

  {
    "product": {
      "id": "xxx",
      "languageDependentData": [
        {
          "language": "en",
          "name": "Name",
          "description": "product details.."
        },
        {
          "language": "es",
          "name": "Name",
          "description": "product details.."
        }
      ]
    }
  }

이 방법이 가장 좋습니다.

product :{
       id: xxx,
       en: {
             name: "Name",
             description: "product details.."
           },
       es: {
             name: "Name",
             description: "product details.."
           },
       ...

  }

단지 하나의 제품만 검색해야 하고 어떤 언어를 선택할 수 있는 후에 검색할 수 있기 때문입니다.

또 다른 옵션은 기본 데이터를 한 언어로만 저장하고 텍스트 리소스를 기본 언어에서 다른 대상 언어로 매핑하는 별도의 텍스트 리소스 변환 모음을 사용하는 것입니다(텍스트 리소스가 기본 데이터 저장소에서 가져온 것이든 시스템의 시스템 메시지를 변환한 것이든 상관 없음).

즉, 스키마와 모델에 대해 언어별 조정을 전혀 하지 않습니다.

제가 볼 수 있는 단점은 제품이 기본 스토어에서 제거될 때 번역 컬렉션에서 정보를 제거하는 것입니다. 음, 동일한 리소스가 다른 곳에서 사용되지 않는다는 것을 보장하는 즉시 그것은 사소한 것이지만 프로그래밍되어야 합니다 :)

언급URL : https://stackoverflow.com/questions/23802834/multilingual-data-modeling-on-mongodb