Очень большие столы Mnesia в производстве

Мы используем Mnesia в качестве основной базы данных для очень большой системы. Фрагментированные таблицы Mnesia показали себя очень хорошо за период тестирования. В системе около 15 таблиц, каждая из которых реплицируется на 2 сайта (узлы), и каждая таблица сильно фрагментирована. На этапе тестирования (которое было сосредоточено на тестах доступности, эффективности и нагрузки) мы приняли Mnesia с ее многочисленными преимуществами сложных структур, которые нам подойдут, учитывая, что все наши приложения, работающие поверх службы, являются приложениями Erlang / OTP. Мы используем Yaws 1.91 в качестве основного веб-сервера.

Для эффективной настройки фрагментированных таблиц мы использовали ряд ссылок, которые использовали мнезию в больших системах:
Это: Блог Mnesia One Year Later, Часть 2 блога, Читал даже здесь , О хешировании. Эти сообщения в блоге помогли нам настроить здесь и там лучшую производительность.

Теперь проблема. У Mnesia есть ограничения по размеру стола, да, мы согласны. Однако ограничения на количество фрагментов нигде не упоминались. По соображениям производительности и для обслуживания больших объемов данных о том, сколько фрагментов сохранит мнезию «в порядке»?

В некоторых наших таблицах 64 фрагмента. с n_disc_only_copies, установленным на количество узлов в кластере, так что каждый узел имеет копию на фрагмент. Это помогло нам решить проблемы, связанные с ошибкой записи mnesia, если данный узел находится вне досягаемости в мгновение ока. Также в блоге выше он предполагает, что 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 бит.

При каком количестве фрагментов производительность мнезии может начать ухудшаться? Ничего страшного, если мы увеличим количество фрагментов с 64 до 128 для данной таблицы? как насчет 65536 фрагментов (2 ^ 16)? Как с помощью фрагментации масштабировать нашу мнезию, чтобы использовать терабайтное пространство?

Пожалуйста, дайте ответы на вопросы, и вы можете дать совет по любым другим параметрам, которые могут улучшить Систему.

ПРИМЕЧАНИЕ. Все таблицы, которые должны содержать миллионы записей, созданы с типом disc_only_copies, поэтому проблем с ОЗУ нет. ОЗУ будет достаточно для нескольких запускаемых нами таблиц ОЗУ. Другие СУБД, такие как MySQL Cluster и CouchDB, также будут содержать данные и используют то же оборудование, что и наша СУБД Mnesia. Кластер MySQL реплицируется на двух серверах (каждый из которых содержит два узла NDB, сервер MySQL), причем узел управления находится на другом ХОСТЕ.


person Muzaaya Joshua    schedule 17.08.2011    source источник
comment
Может быть, вы могли бы попробовать задать вопрос в списке рассылки erlang-questions ... В нем много сильных людей с большим опытом, и более вероятно, что вы получите хороший ответ на такой открытый вопрос.   -  person knutin    schedule 17.08.2011
comment
спасибо @knutin, позволь мне попробовать   -  person Muzaaya Joshua    schedule 17.08.2011
comment
Привет, @MuzaayaJoshua, если ты разместил сообщение на erlang-questions, не могли бы вы поделиться ссылкой?   -  person jtmoulia    schedule 17.04.2013


Ответы (1)


Намек на наличие мощности двух фрагментов просто связан с тем фактом, что модуль фрагментации по умолчанию mnesia_frag использует линейное хеширование, поэтому использование фрагментов 2 ^ n гарантирует, что записи равномерно распределены (более или менее, очевидно) между фрагментами.

Что касается имеющегося оборудования, это больше вопрос тестирования производительности. Факторов, которые могут снизить производительность, много, и настройка базы данных, такой как Mnesia, - лишь одна часть общей проблемы. Я просто советую вам провести стресс-тест на одном сервере, а затем протестировать алгоритм на обоих серверах, чтобы понять, правильно ли он масштабируется.

Говоря о масштабировании количества фрагментов Mnesia, помните, что при использовании disc_only_copies большая часть времени уходит на две операции:

  • решить, какой фрагмент содержит какую запись

  • получить запись из соответствующей таблицы dets (серверная часть Mnesia)

Первый на самом деле не зависит от количества рассматриваемых фрагментов, поскольку по умолчанию Mnesia использует линейное хеширование. Второй больше связан с задержкой жесткого диска, чем с другими факторами.

В конце концов, хорошим решением может быть больше фрагментов и меньше записей на фрагмент, но в то же время попытка найти золотую середину и не потерять преимущества некоторых повышений производительности жесткого диска, таких как буферы и кеши.

person Vincenzo Maggio    schedule 17.08.2011