우리의 응용 프로그램은 짧은 텍스트 (100-1000 자의 문자열)가있는 레코드를 저장합니다. 주어진 쿼리 텍스트에 대해 가장 유사한 레코드를 검색 할 수 있습니다. 우리는 텍스트를 색인하기 위해 Lucene을 사용합니다. 전체 레코드가 데이터베이스에 저장됩니다. 각 레코드는 정확히 하나의 도메인에 속하므로 1000 개가 넘는 도메인이 있습니다. 도메인 수는 무제한이지만 느리게 커집니다. 레코드가 모든 도메인에 지속적으로 추가되고 있습니다 (균일하지는 않음).MongoDB는 임의의 레코드를로드하는 데 적합합니까?
우리는 각 도메인이 자체 테이블을 가지고있는 데이터베이스로 MySQL을 사용했습니다. 스케일 아웃으로 인해 MongoDB로 이전하려고합니다. 모든 레코드는 단일 컬렉션에 저장되며 도메인은 레코드의 특성입니다. ID는 여전히 Lucene 검색에서 가져옵니다. 그러나 우리는 Mysql의 솔루션과 비교하여 MongDB에서 레코드를로드하는 성능이 떨어지는 것을 관찰합니다. MongoDB의 "메모리 매핑 된 스토리지 엔진"이 이유라고 생각합니다. 각 검색은 "임의 레코드"를 반환 할 수 있습니다. 한 도메인에서 계속해서 더 많은 검색을하는 경우가 있습니다. 한 도메인의 레코드는 컬렉션의 한 위치에 저장되지 않습니다. 이로 인해 많은 페이지 오류가 발생할 수 있습니다.
내 설명이 맞습니까? MongoDB는 그러한 레코드로드에 적합합니까? 무엇이 성능을 향상시킬 수 있습니까? MongoDB 서버와 응용 프로그램이 Linux에서 실행 중입니다. 고마워요.
하나는 레코드 모양입니까? 어떻게 데이터를 가져오고 있습니까? 리눅스 서버의 사양은 무엇입니까? –
레코드에는 텍스트와 몇 가지 추가 속성 (timestamp, created_by, ...)이 있습니다. 레코드는 사용자가 지속적으로 추가합니다 - 단일 삽입 또는 대량 삽입. 매스 삽입은 실제로 단일 삽입 시퀀스입니다. 레코드가 mongoDB에 삽입되고 id가 Lucene 인덱스에 대한 텍스트가 삽입됩니다. Linux Ubuntu 10.04 8GB RAM, 2 개의 CPU 코어 (예 : Amazon EC2 대형 인스턴스). – user1482750
전체 레코드를 Lucene에 저장하는 것은 적합하지 않습니다. 또한 한 도메인의 텍스트가 거의 동일한 레코드는 최적화 때문에 인덱서에서 하나의 문서로 인덱싱됩니다. – user1482750