Есть много статей о аккуратных взломах для масштабирования MongoDB, но аккуратные взломы редко нужны. MongoDB предназначен для масштабирования. Большинству приложений нужно правильно понять эти пять вещей.
1. Индексы
Безусловно, самый важный аспект масштабирования. Для каждого общего запроса в каждой коллекции убедитесь, что у вас есть правильные индексы. Прочитайте подробное введение в индексы руководства MongoDB , а затем мою длинную статью по оптимизации составных индексов . Последний предлагает простые правила выбора индексов практически для любого запроса.
2. Файловая система
В Linux выберите ext4 или xfs . Поскольку MongoDB постоянно обращается к своим файлам, вы можете получить значительную производительность, сказав Linux не отслеживать время доступа к файлам. Добавьте noatimeв свой /etc/fstab:
# /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> /dev/sda1 / ext4 noatime 0 0
3. Рабочий набор
Ваш рабочий набор — это часть ваших данных, к которой часто обращаются. Например, в социальной сети последние обновления статуса доступны гораздо чаще, чем старые данные. Если ваш рабочий набор помещается в ОЗУ, вы можете обслуживать большинство запросов из кеша оперативной памяти ОС, не дожидаясь диска.
Расчет размера рабочего набора — это ремесло. Вы можете оценить это, суммируя размер документов, к которым вы обычно обращаетесь или вставляете, плюс все используемые вами индексы. Если вы переоцениваете свой рабочий набор и покупаете слишком много оперативной памяти, это дешевая ошибка. Если вы немного его недооцените, вы увидите высокую частоту сбоев страниц и не получите максимально возможную производительность.
Более подробная информация о рабочих комплектах находится в руководстве .
4. Диски
MongoDB использует ваш диск для произвольного доступа, поэтому узким местом является время поиска диска, а не пропускная способность диска. Все вращающиеся диски способны примерно на 100 запросов в секунду. Если ваш рабочий набор помещается в ОЗУ, 100 запросов в секунду может быть достаточно для обслуживания вашей постоянной нагрузки; в противном случае, вы можете увеличить производительность искать с RAID 10 , даже на EC2 . Или используйте SSD.
5. Осколок
Один набор реплик обычно может отвечать вашим требованиям к производительности, если вы оптимизируете свои индексы и правильно настраиваете файловую систему, если ваш рабочий набор помещается в ОЗУ и вы выбираете правильные диски. При необходимости вы можете масштабировать, разделяя данные между несколькими наборами реплик. Это увеличивает общий объем оперативной памяти, доступной в вашем кластере, поскольку каждому фрагменту нужно только кэшировать данные, за которые он отвечает. Это также увеличивает пропускную способность записи, поскольку вы можете выполнять запись во все сегменты параллельно.
Защищенный кластер сложнее настроить и администрировать, чем набор реплик. Простые правила: если вам не нужно осколок, не надо. Если вы должны в конечном итоге осколок, сделайте это сейчас. Проще спроектировать ваше приложение для изолированного кластера раньше, чем адаптировать существующее приложение.
You have many options. Rather than shard, you can put some collections on some replica sets, and other collections on others. Since MongoDB is non-relational, there’s no need for all your data to live on the same machine. And if any single collection experiences too much load for one replica set to handle, you can shard just that collection and leave the others unsharded.
Sharding is thoroughly covered in the manual.
There are always exceptions, of course. Sometimes you’ll need more complex techniques to scale MongoDB. But in almost all cases, stick to the basics. These five things will usually get you the performance you need.