Мы сохраняем журналы отладки и транзакций в MongoDB.
Нам очень нравится, MongoDBпотому что:
- Пылающая вставка перфорация
- ориентированный на документ
- Возможность отключения двигателя при необходимости повышения производительности
Но есть большая проблема с MongoDB: индекс должен помещаться в физическую оперативную память. На практике это ограничивает нас 80-150 ГБ необработанных данных (сейчас мы работаем на системе с 16 ГБ ОЗУ).
Таким образом, чтобы иметь 500 ГБ или ТБ данных, нам понадобится 50 ГБ или 80 ГБ оперативной памяти.
Да, я знаю, что это возможно. Мы можем добавлять серверы и использовать MongoDB sharding. Мы можем купить специальный серверный ящик, который может вместить 100 или 200 ГБ ОЗУ, но это хвост, виляющий собакой! Мы могли бы потратить кучу $$$ на оборудование для запуска FOSS, когда SQL Server Express может обрабатывать НАМНОГО больше данных на НАМНОГО меньшем оборудовании, чем Mongo(SQL Server не соответствует нашим архитектурным желаниям, иначе мы бы его использовали!) Мы не собираемся тратить огромные $ на оборудование здесь, потому что это необходимо только из-за архитектуры Mongo, а не из-за внутренних потребностей в обработке/хранении. (А сегментирование? Оставим в стороне затраты, кому нужна постоянная сложность трех, пяти или более серверов для управления относительно небольшой нагрузкой?)
Итог: MongoDBесть FOSS, но нам придется потратить $$$$$$$ на оборудование, чтобы его запустить? Лучше купим коммерческое ПО!
Я уверен, что мы не первые, кто столкнулся с этой проблемой, поэтому мы просим сообщество:
Куда мы пойдем дальше?
(Мы уже используем Mongo v2)
решение1
Если вы находитесь в точке, где текущая производительность слишком низкая или достигнуты пределы, то у вас есть три варианта. И они верны для любой проблемы.
- Масштабировать вертикально: Имеется в виду увеличение мощности вашего компьютера. Больше процессора или больше оперативной памяти.
- Масштабировать по горизонтали: Имеется в виду увеличение количества рабочих. Больше процессов, больше потоков, больше машин.
- Изменить дизайн: Сделай по-другому. Другое ПО, другие алгоритмы, другая система хранения, что угодно другое.
Поскольку вы исключили 1) и 2) из своих вариантов, осталось только решение 3). Так что дерзайте...
решение2
Мы разместили этот же вопрос на форуме Mongo, и технический директор Mongo ответил, попросив пересмотреть его презентацию о том, как оптимизировать индексы.
http://www.10gen.com/presentations/mongosf2011/schemascale
В этой презентации г-н Горовиц прямо заявляет, что сегментирование/горизонтальное масштабирование может оказаться излишним во многих ситуациях и что подходы к проектированию (включая некоторые не совсем интуитивные подходы, характерные только для Mongo) могут значительно расширить масштабирование данного сервера.
Это представило несколько интересных концепций, включая использование клиентской логики для оптимизации того, как база данных используется несколькими «ненормализованными» способами. В презентации есть четкий подтекст в том смысле, что «если вы просто строите по книге, вы можете легко столкнуться с нежелательными проблемами, связанными с масштабированием». Например, г-н Хоровиц (технический директор 10Gen, создателя MongoDB) представляет «гибридный» дизайн, в котором вместо одного документа на «запись» вы помещаете, возможно, 100 «записей» в документ, что приводит к подходу типа «корзины». Это сделано явно для уменьшения объема индекса. Это то, что кодируется на клиенте и не является «функцией» MongoDB. Этот гибридный подход может сработать для нас и может дать нам 4-кратное или 8-кратное улучшение размера индекса.
Он также обсуждает «сбалансированные справа» b-деревья, которые по сути оптимизируют конструкцию индекса таким образом, чтобы большинство запросов обращались только к «правой части» индекса (в отличие от случайного доступа по всему индексу, который для хорошей работы требует, чтобы весь индекс помещался в ОЗУ). Этот подход нам не поможет, так как нам нужно делать запросы по всему индексу.
Мы собираемся использовать эти концепции в ходе обзора нашей системы.
(Интересно, что из всех мест, где я задавал этот вопрос, единственным человеком, давшим конструктивный ответ, оказался технический директор самой MongoDB.)
ОБНОВЛЕНИЕ (2017)
Мы обнаружили, что Mongodb в конечном итоге не подходит для производственной среды. Каждые пару месяцев он сбрасывает/удаляет всю базу данных, и все данные теряются. (Это не основной источник данных, поэтому мы можем жить с этой проблемой, хотя и не очень счастливо.)
Мы уже завершили проект по переходу на стек Elasticsearch и сейчас запускаем его в производство. (Мы успешно используем Elasticsearch уже много лет.) Данные Elasticsearch не такие долговечные, как, скажем, Microsoft SQL Server (у нас были сбои кластеров Elasticsearch с невосстановимой потерей данных), но Elasticsearch как минимум в 10 раз (по опыту, более чем в 100 раз) надежнее MongoDB. (Elasticsearch, разумно, не делает вид, что поддерживает Windows как производственную платформу, что является одним из больших грехов MongoDB.)
Мы рассчитываем очистить всю нашу среду MongoDB в течение ближайших недель.
Вперед!
ОБНОВЛЕНИЕ (2018-2019)
Стек elasticsearch себя оправдал. Мы обнаружили, что он очень надежный, очень масштабируемый, и не оглядывались назад. Mongo пахло здорово в то время, но его уже много лет нет, и скатертью ему некуда. Мы запустили два эластичных кластера, один для данных журнала (который заменил наш сервер Mongo), а второй для реальных данных приложений. Каждый кластер содержит 1-2 ТБ данных. Потребовалосьмногоработы по архитектуре (особенно на стороне приложения), чтобы добиться гибкости как в масштабировании, так и в производительности, но при этом обеспечить ее.
решение3
Вам могут не понравиться ответы на вашу проблему "масштабирования", потому что у вас на самом деле нет проблемы масштабирования; у вас есть проблема дизайна и реализации. Вы не индексируете эффективно.
Серьёзно, если вы чувствуете, что вам непременно нужно хранить индексы такого размера, у вас будет та же проблема с хранением отвратительно огромных индексов в оперативной памяти в любой базе данных, которую вы ищете. Вам придётся купить сервер высокой ёмкости (DL380 G7 может это сделать, и это сервер среднего класса; ничего экзотического) для хранения этих индексов.
В качестве помощи можно воспользоваться поиском по запросу «mongodb optimizing indexes», который выдаст несколько полезных ссылок:
http://www.mongodb.org/display/DOCS/Оптимизация
http://www.10gen.com/events/indexingmatters
http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/
http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer
Вы можете начать оправдываться, говоря о том, что ваше исследование было проведено, но те из нас, кто использует MongoDB в производстве, знают, что вы упускаете много моментов.
Далее, комментарий «Итог: MongoDB — это FOSS, но нам придется потратить $$$$$$$ на оборудование для его запуска? Мы бы лучше купили коммерческое ПО!» — крик невежества и высокомерия.
решение4
Почему вы говорите: «SQL Server Express может обрабатывать НАМНОГО больше данных на НАМНОГО меньшем оборудовании, чем Mongo (SQL Server не соответствует нашим архитектурным требованиям, иначе мы бы его использовали!)». Если вам нужно изменить архитектуру вашей базы данных (поскольку ваша другая база данных не может масштабироваться так, как вам нужно, и вы бы использовали SQL Server, ответ для меня — исправить дизайн вашей базы данных для работы с SQL Server. Единственное, что я могу придумать, что «не поддается исправлению», — это если вы действительно хотите базу данных без ACID (что показалось бы мне странным, что отладочные и транзакционные вставки в журнал можно отбрасывать)