3 년 동안 myisam을 사용하고 행 수가 Mio 인 경우 약 500 개의 열을 사용하고 나면 mongodb에 강제로 메모리에 인덱스를 저장하여 빠른 읽기 성능을 구현하는 방법을 궁금합니다.mongodb : 메모리 내 강제
일반적으로 단순한 구조의 테이블이며 모든 쿼리는 index1 = .. 또는 index2 = ... 또는 index3 = .. (myisam)이며 mongodb에서도 매우 단순합니다. mongodb가 인덱스와 램을 자체적으로 관리하는 것이 좋습니다. 그러나 mongodb가 인덱스에서만 이러한 쿼리를 빠르게 처리 할 수 있는지 여부는 확실하지 않습니다.
감사합니다.
mongodb이 인덱스와 램을 자체적으로 관리하는 것이 좋습니다.
MongoDB는 RAM을 전혀 관리하지 않습니다. 그것은 메모리 매핑 파일을 사용하고 기본적으로 모든 것이 항상 RAM이라는 "가장"입니다.
대신 운영 체제는 RAM에 보관되는 개체를 관리해야합니다. 일반적으로 LRU 기준.
인덱스의 크기를 확인하는 것이 좋습니다. 이러한 모든 인덱스를 RAM에 보관할 수 없다면 MongoDB의 성능이 좋지 않을 것입니다.
그러나 mongodb가 인덱스에서만 이러한 쿼리의 속도를 향상시킬 수 있는지 여부는 확실하지 않습니다.
MongoDB는 Covered Indexes을 사용하여 DB에서 직접 검색 할 수 있습니다. 그러나 반환 된 필드에 대한 특정 매우 특정 있어야합니다. 인덱스의 일부가 아닌 필드를 포함하면 "인덱스 전용"쿼리가 반환되지 않습니다.
기본 동작은 모두 필드를 포함하므로 특정 쿼리를보고 "인덱스 전용"을 허용하도록 적절하게 변경해야합니다. 이러한 쿼리에는 _id이 포함되지 않으므로 문제가 발생할 수 있습니다.
메모리에 색인을 저장하도록 "강요"할 필요가 없습니다. 색인은 사용시 메모리에 저장되고 OS가 실행될 때까지 메모리에 유지됩니다.
MongoDB는 가능한 경우 자동으로 커버 인덱스를 사용합니다.
최고 성능 (읽기 전용)이 필요한 기본 쿼리 : db.largecollection.find ({$ 또는 : {{identifierX : "sha1_hash123"}, {identifierY : "md5_hash456"}, {identifierZ : "another_hash789 "}]}) 삽입/업데이트는 사용 사례에 따라 지연되거나 대기 상태가 될 수 있습니다. .find ({rarely_access_data : {...}})와 같은 다른 검색어가있을 수도 있습니다. 그런 쿼리로 인해 메모리 캐시가 "플러시"되고 내 정기 쿼리가 느려질 수 있습니까? 그래서 저는 인덱스 인 메모리를 제거하는 다른 쿼리가 없으며 mongodb 자체가 이것에 대해 결정하는 유일한 인스턴스라고 믿어야합니다. – ledy
OS는 mongo가 아닌 메모리를 관리합니다. 그렇기 때문에 항상 메모리 캐시가 플러시 될 가능성이 있습니다. – Sid
작은 수정 일 수도 있습니다 : 'MongoDB는 덮어 쓴 인덱스를 사용하여 ** 메모리 **에서 직접 검색 할 수 있습니다.' – sergiuz
당신이 찾고있는 인덱스 데이터가 쿼리가 발행 될 때 실제 메모리에 있지 않을 수도있는 유일한 종류의 "메모리"입니다. –