2014-10-22 4 views
0

У меня есть документы, которые выглядят следующим образом:Какой индекс использовать для mongodb?

{ 
    { 
     "_id": ObjectId("5444fc67931f8b040eeca671"), 
     "meta": { 
     "SessionID": "45", 
     "configVersion": "1", 
     "DeviceID": "55", 
     "parentObjectID": "55", 
     "nodeClass": "79", 
     "dnProperty": "16" 
     }, 
     "cfg": { 
     "Name": "test" 
     } 
    } 

Имена и данные только для тестирования атм. но я имею в общей сложности 25 миллионов документов в БД. И я использую find() для получения определенного документа (ов) в этом find(). В этом случае я использую четыре аргумента: dnProperty, nodeClass, DeviceID и configVersion, ни одна из них не является уникальной.

Atm. У меня есть установка индекса так же просто, как:

ensureIndex([["nodeClass", 1],["DeviceID", 1],["configVersion", 1], ["dnProperty",1]]) 

Другими словами, у меня есть указатель на четыре аргумента. У меня все еще есть большие проблемы, если вы выполняете поиск, который вообще не находит никакого документа. В моем примере все «данные» случайны от 1-100, поэтому, если я нахожу find() с одним из значений> 100, тогда для выполнения поиска требуется от 30 до 180 секунд, чтобы он также использовал все мое 8-гигабайтное ОЗУ, то, поскольку RAM не осталось, компьютер идет очень медленно.

Что было бы лучше индексов? Правильно ли я использую индексы? Мне просто нужно больше оперативной памяти, так как он будет «все» БД в рабочей памяти? Вы бы порекомендовали другой БД (кроме монго) справиться с этим лучше?

Извините за несколько вопросов. Надеюсь, они достаточно коротки, чтобы вы могли дать мне ответ.

+0

Можете ли вы показать нам свои медленные запросы? – joao

+0

25 миллионов документов много. Вы можете рассмотреть следующие вещи: использовать несколько коллекций для разделения данных; Используйте набор данных (например, google bigquery), быстрый и sql-подобный. –

ответ

1

MongoDB использует файлы с отображением памяти, что означает, что копия ваших данных и индексов сохраняется в ОЗУ и всякий раз, когда есть запрос, он извлекает ее из самой ОЗУ. В текущем сценарии ваши запросы медленнее, потому что размер ваших данных + индексов настолько велик, что он не поместится в ОЗУ, поэтому будет много операций ввода-вывода для получения данных с диска, что является узким местом.

Sharding помогает решить эту проблему, потому что, если вы разбиваете/обманываете свои данные, например, на 5 машинах, тогда у вас будет 8 ГБ * 5 = 40 ГБ ОЗУ, которое может удерживать ваш (набор данных + индексы = рабочий набор) в самой ОЗУ и накладные расходы на ввод-вывод будут уменьшены, что приведет к повышению производительности.

Следовательно, в этом случае ваши индексы не улучшат производительность за определенный период времени, вам придется очертить свои данные на нескольких машинах. Sharding будет иметь тенденцию увеличивать скорость чтения, а также записывать пропускную способность линейно. Sharding in MongoDB

Смежные вопросы