[MONGODB] "인덱스에 너무 큰 키를", MongoDB를에 인덱스를 만들 수 없습니다

"인덱스에 너무 큰 키를", MongoDB를에 인덱스를 만들 수 없습니다

나는 1000 만 개 기록을 가지고 있지만, 오류를 다음과 MongoDB를에 인덱스를 생성하고

db.logcollection.ensureIndex({"Module":1})
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 3,
        "ok" : 0,
        "errmsg" : "Btree::insert: key too large to index, failing play.logcollection.$Module_1 1100 { : \"RezGainUISystem.Net.WebException: The request was aborted: The request was canceled.\r\n   at System.Net.ConnectStream.InternalWrite(Boolean async, Byte...\" }",
        "code" : 17282
}

어떻게하여 MongoDB에서 createindex하는 저를 도와주세요,

해결법

1. ==============================

   1.기존 문서의 인덱스 항목이 인덱스 키 제한 (1024 바이트)를 초과하는 경우 MongoDB를 콜렉션에 인덱스를 생성하지 않습니다. 당신은 그러나 해시 인덱스 또는 텍스트 인덱스를 대신 생성 할 수 있습니다 :

   기존 문서의 인덱스 항목이 인덱스 키 제한 (1024 바이트)를 초과하는 경우 MongoDB를 콜렉션에 인덱스를 생성하지 않습니다. 당신은 그러나 해시 인덱스 또는 텍스트 인덱스를 대신 생성 할 수 있습니다 :

   db.logcollection.createIndex({"Module":"hashed"})
   

   또는

   db.logcollection.createIndex({"Module":"text"})
   

2. ==============================

   2.할 수 있습니다 침묵 다음 명령을 mongod 인스턴스를 시작하여이 동작 :

   할 수 있습니다 침묵 다음 명령을 mongod 인스턴스를 시작하여이 동작 :

   mongod --setParameter failIndexKeyTooLong=false
   

   또는 몽고 쉘에서 다음 명령을 실행하여

   db.getSiblingDB('admin').runCommand( { setParameter: 1, failIndexKeyTooLong: false } )
   

   당신은 당신의 분야는 다음, 아주 드물게 한계를 초과 없다는 것을 보장하는 경우 이 문제를 해결하는 한 가지 방법은 분할하여 필드에 의해 (즉 한계 중 원인 인덱스) 바이트 길이 부에 <1킬로바이트 예컨대 필드에 대해 나는 등 필드 val_1, val_2와의 튜플로 분할 할 발. UTF-8 유효한 값으로 몽고 저장 텍스트입니다. 그것은 당신이 제대로 UTF-8 문자열을 분할 할 수있는 기능을해야한다는 것을 의미합니다.

      def split_utf8(s, n):
       """
       (ord(s[k]) & 0xc0) == 0x80 - checks whether it is continuation byte (actual part of the string) or jsut header indicates how many bytes there are in multi-byte sequence
   
       An interesting aside by the way. You can classify bytes in a UTF-8 stream as follows:
   
       With the high bit set to 0, it's a single byte value.
       With the two high bits set to 10, it's a continuation byte.
       Otherwise, it's the first byte of a multi-byte sequence and the number of leading 1 bits indicates how many bytes there are in total for this sequence (110... means two bytes, 1110... means three bytes, etc).
       """
       s = s.encode('utf-8')
       while len(s) > n:
           k = n
           while (ord(s[k]) & 0xc0) == 0x80:
               k -= 1
           yield s[:k]
           s = s[k:]
       yield s
   

   그런 다음 당신은 당신의 화합물 색인을 정의 할 수 있습니다 :

   db.coll.ensureIndex({val_1: 1, val_2: 1, ...}, {background: true})
   

   각 val_i 당 또는 여러 인덱스 :

   db.coll.ensureIndex({val_1: 1}, {background: true})
   db.coll.ensureIndex({val_1: 2}, {background: true})
   ...
   db.coll.ensureIndex({val_1: i}, {background: true})
   

   다른 경우에는 하나의 해시 또는 텍스트 인덱스를 사용합니다.

3. ==============================

   3.다른 사람들이 대답에서 지적한 바와 같이, 인덱스 수단에 너무 큰 오류 키는 필드 길이가 1024 바이트를 초과 필드에 인덱스를 만들려고 시도됩니다.

   다른 사람들이 대답에서 지적한 바와 같이, 인덱스 수단에 너무 큰 오류 키는 필드 길이가 1024 바이트를 초과 필드에 인덱스를 만들려고 시도됩니다.

   ASCII 측면에서, (1024)는 일반적으로 바이트 길이가 1024 주위에 문자로 변환합니다.

   이 MongoDB의 제한 및 임계 값 페이지에서 언급 한 바와 같이 MongoDB를 설정 본질적인 한계는 이에 대한 해결책은 없다 :

   서버 매개 변수 매뉴얼 페이지에서 언급 failIndexKeyTooLong 오류를 설정하면, 해결되지 않습니다 :

   어떤 문장 수단은 기분을 상하게 문서가 색인에 포함되지 않습니다 및 쿼리 결과에서 누락 될 수 있다는 것이다.

   예를 들면 :

   > db.test.insert({_id: 0, a: "abc"})
   
   > db.test.insert({_id: 1, a: "def"})
   
   > db.test.insert({_id: 2, a: <string more than 1024 characters long>})
   
   > db.adminCommand( { setParameter: 1, failIndexKeyTooLong: false } )
   
   > db.test.find()
   {"_id": 0, "a": "abc"}
   {"_id": 1, "a": "def"}
   {"_id": 2, "a": <string more than 1024 characters long>}
   Fetched 3 record(s) in 2ms
   
   > db.test.find({a: {$ne: "abc"}})
   {"_id": 1, "a": "def"}
   Fetched 1 record(s) in 1ms
   

   failIndexKeyTooLong 오류를 무시 MongoDB를 강제함으로써, 마지막 쿼리가 잘못된 문서 (_id로 즉 문서 : (2) 결과에서 누락)를 포함하지 않는, 따라서 쿼리가 잘못된 결과 집합의 결과.

4. ==============================

   4.은 "인덱스 키 제한"으로 실행하는 경우,이 솔루션은 스키마의 요구에 따라 달라집니다. 매우 드문 경우,> 1024 바이트의 값에 키 매칭은 디자인 요구 사항입니다. 사실, 거의 모든 데이터베이스는 쉽게 스스로 발을 쏠 수 있도록, 아직 일반적으로 어느 정도 기존 관계형 DB를의 구성 (오라클 / MySQL을 / PostgreSQL을), 인덱스 키 제한 제한을 부과.

   은 "인덱스 키 제한"으로 실행하는 경우,이 솔루션은 스키마의 요구에 따라 달라집니다. 매우 드문 경우,> 1024 바이트의 값에 키 매칭은 디자인 요구 사항입니다. 사실, 거의 모든 데이터베이스는 쉽게 스스로 발을 쏠 수 있도록, 아직 일반적으로 어느 정도 기존 관계형 DB를의 구성 (오라클 / MySQL을 / PostgreSQL을), 인덱스 키 제한 제한을 부과.

   빠른 검색 들어, "텍스트"인덱스는 긴 텍스트 필드에 최적화 된 검색 및 패턴 매칭에 설계, 잘 유스 케이스에 적합합니다. 그러나, 더 일반적으로, 긴 텍스트 값의 고유성 제약 요구 사항이다. 고유 플래그가 설정되어 고유의 스칼라 값처럼 그리고 "텍스트"인덱스가 동작하지 않습니다  {독특한 : TRUE} (더 필드의 모든 텍스트 문자열의 배열과 같은).

   MongoDB를의 GridFS에서 영감을 촬영, 고유성 검사는 쉽게 문서에 "MD5"필드를 추가하고 그의 고유 스칼라 인덱스를 생성하여 구현 될 수있다. 정렬 사용자 정의 고유 한 해시 인덱스 등을. 이 컬렉션에서 검색 및 독특한에 대한 인덱스가 사실상 무제한 (~ 16메가바이트) 텍스트 필드의 길이를 할 수 있습니다.

   const md5 = require('md5');
   const mongoose = require('mongoose');
   
   let Schema = new mongoose.Schema({
     text: {
       type: String,
       required: true,
       trim: true,
       set: function(v) {
           this.md5 = md5(v);
           return v;
       }
     },
     md5: {
       type: String,
       required: true,
       trim: true
     }
   });
   
   Schema.index({ md5: 1 }, { unique: true });
   Schema.index({ text: "text" }, { background: true });
   

5. ==============================

   5.내 경우에는 내가 큰 하위 배열에 인덱스려고, 내가 가서 내 쿼리에서 보았을 때 내가 말한 subsubproperty에 초점을 인덱스를 변경하고 좋아했다, 그래서 쿼리는 하위 속성의 하위 속성에 대한 사실이었다.

   내 경우에는 내가 큰 하위 배열에 인덱스려고, 내가 가서 내 쿼리에서 보았을 때 내가 말한 subsubproperty에 초점을 인덱스를 변경하고 좋아했다, 그래서 쿼리는 하위 속성의 하위 속성에 대한 사실이었다.

   {: 1, "emailsDisabled": 1, "priorityEmailsDisabled"1 "목표"}이처럼 보였다 쿼리 내 경우에는, 목표는 큰 하위 배열처럼 보였다 실패 "키가 너무 큽니다"인덱스했다 :

   emailsDisabled: {$ne: true},
   priorityEmailsDisabled: {$ne: true},
   goals: {
     $elemMatch: {
       "topPriority.ymd": ymd,
     }
   }
   

   내가 할 인덱스를 변경하면하고 { "goals.topPriority.ymd": 1, "emailsDisabled": 1, "priorityEmailsDisabled": 1}는 벌금을했다.

   내가 여기서 일했다 확신 모든 것을 명확하게하는 것은 그것이 나 인덱스를 만들 수 있다는 것입니다. 해당 인덱스가 쿼리에 대한 작동하는지의 문제는 아직 응답하지 않은 것을 별도의 하나입니다.

from https://stackoverflow.com/questions/27792706/cannot-create-index-in-mongodb-key-too-large-to-index by cc-by-sa and MIT license