Очень большие таблицы Mnesia в производстве
Мы используем Mnesia как основную базу данных для очень большой системы. Mnesia Fragmented Таблицы ведут себя так хорошо в течение периода тестирования. Система имеет около 15 таблиц, каждая из которых реплицируется на 2 сайта (узлы), и каждая таблица сильно фрагментирована. Во время фазы тестирования (которая была сосредоточена на тестах на доступность, эффективность и нагрузку) мы приняли Mnesia с ее многочисленными преимуществами сложных структур для нас, учитывая, что все наши приложения, работающие поверх службы, являются приложениями Erlang/OTP. Мы запускаем Yaws 1.91 в качестве основного веб-сервера.
Для эффективной настройки фрагментированных таблиц мы использовали ряд ссылок, которые использовали mnesia в больших системах:
Это: Блог Mnesia One Year Later, Часть 2 в блоге, Последовало даже здесь, О Hashing. Эти сообщения в блоге помогли нам улучшить мелодию здесь и там, чтобы улучшить производительность.
Теперь проблема. У Mnesia есть ограничения по размеру стола, да, мы согласны. Однако ограничения на количество фрагментов нигде не упоминались. По соображениям производительности и для обработки больших данных о том, сколько фрагментов будет держать mnesia "хорошо"?
В некоторых наших таблицах имеется 64 фрагмента. с n_disc_only_copies установлено количество узлов в кластере, чтобы каждый node имел копию на фрагмент. Это помогло нам решить проблемы с записью mnesia write, если данный node недоступен в одно мгновение. Также в блоге выше он предлагает, чтобы the number of fragments should be a power of 2, это утверждение (по его словам) было исследовано по тому, как mnesia делает хэширование записей. Мы, однако, нуждаемся в более подробных объяснениях по этому поводу, и о силе двух говорят здесь: 2,4,16,32,64,128,...?
Система предназначена для работы на HP Proliant G6, содержащей процессоры Intel (2 процессора, 4 ядра, скорость 2,4 ГГц для каждого ядра, 8 Мбайт кэша), 20 ГБ оперативной памяти, 1,5 терабайта дискового пространства. Теперь, 2 из этих мощных машин в нашем распоряжении. Системная база данных должна быть реплицирована по двум. На каждом сервере выполняется Solaris 10, 64 бит.
При каком количестве фрагментов может начаться ухудшение производительности mnesia? Все в порядке, если мы увеличим количество фрагментов от 64 до 128 для данной таблицы? как насчет 65536 фрагментов (2 ^ 16)? Как мы масштабируем нашу mnesia, чтобы использовать пространство Terabyte, используя фрагментацию?
Пожалуйста, предоставьте ответы на вопросы, и вы можете дать рекомендации по любым другим параметрам, которые могут улучшить систему.
ПРИМЕЧАНИЕ. Все таблицы, содержащие миллионы записей, создаются в типе disc_only_copies, поэтому проблем с ОЗУ нет. ОЗУ достаточно для нескольких таблиц RAM, которые мы запускаем. Другие СУБД, такие как MySQL Cluster и CouchDB, также будут содержать данные и используют одно и то же оборудование с нашей СУБД Mnesia. MySQL Cluster реплицируется на двух серверах (каждый из которых имеет два NDB Nodes, сервер MySQL), а Management node находится на другом HOST.
Ответы
Ответ 1
о количестве вопросов о фрагментах: намек на наличие мощности двух чисел фрагментов просто связан с тем фактом, что модуль фрагментации по умолчанию (mnesia_frag) использует линейное хеширование, поэтому использование 2 ^ n фрагментов гарантирует, что записи одинаково распределены ( более или менее, очевидно) между фрагментами.
Об оборудовании в распоряжении, это скорее вопрос тестирования производительности.
Я много раз работаю над другими технологиями (не на Mnesia), потому что факторами, которые могут снизить производительность, является настолько много, что настройка базы данных, такой как mnesia, - не что иное, как одна из проблем.
Я просто советую вам провести стресс-тест на одном сервере, а затем проверить алгоритм на обоих серверах, чтобы понять, правильно ли он масштабируется.
И для номера фрагментов mnesia помните, что с помощью disc_only_copies большая часть времени проводится в двух операциях:
Первый не зависит от количества фрагментов, учитывая, что по умолчанию mnesia использует линейное хеширование.
Второй вариант зависит от задержки на жестком диске, чем другие факторы.
Таким образом, хорошим решением было бы иметь больше фрагментов и меньше записей на фрагмент, но попытайтесь найти равновесие, чтобы не потерять преимущества некоторых усилителей производительности жестких дисков, таких как буферы и кеши.
