Прежде всего, я использую MongoDB 3.0 с новым механизмом хранения WiredTiger. Также используйте snappy для сжатия.Оптимизация для случайных чтений
Вариант использования, который я пытаюсь понять и оптимизировать с технической точки зрения, следующий:
У меня довольно большая коллекция, в которой около 500 миллионов документов занимают около 180 ГБ, включая индексы.
Пример документа:
{
_id: 123234,
type: "Car",
color: "Blue",
description: "bla bla"
}
Запросы состоят из поиска документов с определенным значением поля. Вот так;
thing.find({ type: "Car" })
В этом примере type поле, очевидно, должны быть проиндексированы. Все идет нормально. Однако шаблон доступа для этих данных будет полностью случайным. В определенный момент я понятия не имею, к какому диапазону документов будет доступен доступ. Я знаю только, что они будут запрашиваться на проиндексированных полях, возвращаясь на максимально 100000 документов за раз.
Что я имею в виду, так это то, что кеширование в MongoDB/WiredTiger практически бесполезно. Индексы - единственное, что нужно вставить в кеш. Оценка рабочего набора сложна, если не невозможна?
Что я ищу, это в основном советы о том, какие типы индексов использовать и как настроить MongoDB для такого использования. Будут ли другие базы данных работать лучше?
В настоящее время я нахожу MongoDB достаточно хорошо работающим на ограниченном аппаратном обеспечении (16 ГБ оперативной памяти, без диска SSD). Запросы возвращаются в достойное время и, очевидно, мгновенно, если набор результатов уже находится в кеше. Но, как уже было сказано, это, скорее всего, не будет типичным случаем. Не важно, чтобы запросы были молниеносными, тем более что они надежны и что база данных будет работать стабильно.
EDIT:
Guess я оставил некоторые важные вещи. База данных будет в основном для архивных целей. Таким образом, данные поступают из другого источника навалом, говорят один раз в день. Обновления будут очень редкими.
Пример, который я использовал, был немного надуманным, но по сути это то, что вызывает вопрос. Когда я упомянул несколько индексов, я имел в виду поля type и color в этом примере. Поэтому при использовании этих полей будут запрашиваться документы. Как и сейчас, мы заботимся о возврате всех документов, которые имеют конкретные type, color и т. Д. Естественно, что мы планируем только запрашивать поля, для которых у нас есть индекс. Таким образом, специальные запросы находятся вне таблицы.
В настоящее время размеры индекса вполне управляемы. Для 500 миллионов документов каждый из этих индексов составляет около 2,5 ГБ и легко помещается в ОЗУ.
Что касается среднего размера данных операции, я могу только догадываться на этот момент. Насколько мне известно, типичные операции возвращают около 20 тыс. Документов со средним размером объекта в диапазоне 1200 байт. Это stat, о котором сообщается db.stats(), поэтому я думаю, что это сжатые данные на диске, а не то, сколько он действительно занимает один раз в ОЗУ.
Надеюсь, этот бит дополнительной информации помог!