|
Задавайте вопросы, мы ответим
Вы не зашли.
Подскажите, какую стратегию управления и какую структуру данных лучше использовать в следующем сценарии.
БД содержит интенсивно пополняющийся журнал (скажем, посещения пользователей), интенсивность входящего потока записей - несколько сотен в секунду. По данным журнала периодически строятся стат. отчеты (с заранее неизвестной сложностью). Главное требование - производительность БД, т.е. время обработки запроса на вставку должно оставаться минимальным с ростом БД и построение отчетов не должно ощутимо замедлять работу БД. Возможно агрегирование данных по временнЫм периодам.
Интересует, какие могут потребоваться размеры памяти на серверах (пусть будет 4 узла данных) при данных параметрах, какие вообще есть ограничения кластера при данной нагрузке и какие подходы можно применить для поддержания высокой производительности. Понятно, что много параметров неизвестно из описания - размеры и количество индексных полей (которые насколько я понимаю, обязательно хранятся в оперативке) и т.д. Но хотелось бы увидеть общую картину, чтобы понять с чего начать, что иметь в виду и т.д.
Неактивен
Самый простой вариант - сделать репликацию. На мастере будут вставки, а на слейве обработка. Если обработка жесткая, то можно несколько слейвов сделать. В качестве мастера можно использовать кластер, а в качестве слейва вряд ли он подойдет - запросы на обработку обычно сложные и кластер выйгрыша не даст. Памяти нужно достаточно для хранения данных и индексов, если используется кластер (хранить данные в кластере не диске при 4 машинах не даст выйгрыша).
Неактивен
Да, думал про репликацию, но боюсь, что она может быстро заполнить диск слэйва при больших объемах, т.к. на него навалится вся информация со всех машин кластера. Как насчет выполнения пре-селектов данных в реалтайме в зависимости от нужд отчета? а потом удалять если больше не нужны. Например, сделать на одной из нод кластера federated-таблицы для предвыборок, которые ссылаются на таблицы, расположенные на сервере статистики?
rgbeast написал:
(хранить данные в кластере не диске при 4 машинах не даст выйгрыша)
поясните, плиз, почему?
И что происходит при недостаточности памяти для приема новых данных? Как эту ситуацию отследить?
Неактивен
Насчет "иметь в виду" - имейте в виду, что скорость вставок будет падать с ростом размера таблицы -
нужно бить таблицы на части.
Насчет реплик - объем на дисках будет такой же, как и на мастере - ведь реплики тянут данные с
мастера. С другой стороны - мастер один, а реплик может быть несколько, поэтому Вы можете раскидывать
сложные отчеты по разным машинкам, увеличивая производительность кластера в целом.
Неактивен
Как я понимаю, обращение к статистике не будет узким местом в производительности, поэтому можно использовать FEDERATED или просто копировать таблицы скриптами ежедневно (или спериодичностью обновления статистики).
shutdown написал:
rgbeast написал:
(хранить данные в кластере не диске при 4 машинах не даст выйгрыша)
поясните, плиз, почему?
Хранение данных кластера на диске работает медленно, но лучше протестируйте для собственной задачи. 4 машины - не то количество, чтобы получить таким образом выигрыш, учитывая также, что каждая запись должна храниться как минимум на двух нодах. По производительности будет лучше реализовать разделение вручную - например, в зависимости от четности номера сессии пользователя (или id пользователя) записывать на первый или второй MySQL-сервер. Если удастся и обработку разделить по пользователям, то будет очень удобно - два мастера (четный и нечетный), два слейва (по одному к каждому мастеру). На мастер запись - на слейве обработка, агрегировать общую статистику на одном из слейвов и затем распространять куда требуется.
shutdown написал:
И что происходит при недостаточности памяти для приема новых данных? Как эту ситуацию отследить?
"Вы пришли к нам делать бинес, а у Вас денег нет?" (фильм Револьвер).
Происходит ошибка вставки в таблицу (Table is full). Проверить доступную память в настоящее время можно только с помощью команды ALL DUMP 1000 в консоли управления кластером. http://dev.mysql.com/doc/ndbapi/en/ndb- … -1000.html
Неактивен
Спасибо за советы, будем пробовать. Вообще говоря, у нас была мысль сделать распределение БД вручную, но я подумал, что все равно придется реализовывать часть кластерного функционала и как-то эту идею "задвинул" в пользу кластера. Но раз Вы говорите, что по производительности ручное распределение может выиграть.... Будем пробовать, тестировать. Если что интересное получится - напишу. В конце концов, можно раскидывать запросы по front-end'ам просто с помощью DNS. Единственное, что настораживает - при плотном потоке вставок не будет ли "загибаться" выборка статистики со слейва при копировании на него с помощью репликации?
Неактивен
Поясню свою мысль. Кластер - это синхронная репликация, то есть он позволяет приложению не знать о том, что данные распределены. Если происходит запись - она не завершится, пока о ней не узнают все дата-ноды, на которых она должна храниться (как минимум две). На маленьком числе машин - усилия по координации приводят к значительному расходу ресурсов. Если Вы знаете свои данные, то можете упростить логику взаимодействия на основе этого знания (в случае статистики достаточно ясно как упростить). Еще один момент - пусть у Вас есть несколько связанных таблиц и данные статистики попадают в две таблицы, например в sessions и access. Так как кластер разделяет данные по нодам просто на основании четности хэш-функции (или остатка от деления на число нод), то данные одного юзера будут записаны на разные машины. Также и при считывании придется задействовать несколько машин, собрать все на одной и сделать на ней JOIN (это внутренний алгоритм кластера, который Вы не увидите, но заметите, что он привел к торможению). Вручную Вы сможете разделить данные по номеру или по ip юзера так, что редко потребуется делать выборку с разных машин.
Чтобы SLAVE не погиб, перед обработкой данных выполните STOP SLAVE SQL_THREAD, тогда он будет продолжать скачивать с мастера binary-лог, но не будет повторять вставки. После обработки START SLAVE SQL_THREAD запустить работу SLAVE. SLAVE будет отставать от мастера какое-то время после обработки, но должен догнать, если правильно все настроить.
Неактивен
Да, точно, можно тормознуть sql_thread! Проблемой меньше.
Еще вопрос: можно ли пойти на такой трюк, как сделать на мастере таблицы с минимумом ключей, чтобы инсертам поменьше работы было по обновлению индексов, а на слейве сделать ту же структуру для реплик, но ключей навешать для оптимизации выборки? Естественно, продумать, чтобы не было конфликтов при вставке на слейве, но в принципе, не слишком "криминально"?
Неактивен
Безусловно можно. Можно даже делать таблицы разных типов (только учтите, что ALTER
доедет до SLAVE тоже).
Другое дело, что нужно очень хорошо себе представлять, что реплика всегда накатывается
в один поток и на сильно нагруженном записями сервере это может приводить к отставанию.
Особенно хорошо это проявится именно в случае различных индексов, т.к. на мастере
индексов не будет => вставки будут проходить гораздо быстрее, чем на реплике, что еще
больше увеличит дисбаланс нагрузки.
Неактивен
Имеет ли смысл воспользоваться таблицей FEDERATED для агрегирования данных с нескольких слейвов в одну таблицу, физически расположенную на отдельном сервере статистики? Будет ли это оптимально?
Т.е. я так представляю: на каждом слейве, хранящем исходные логи, создаем таблицы FEDERATED, которые ссылаются на одну и ту же таблицу на сервере статистики. И на каждом слейве выполняем один и тот же запрос на выборку статистических данных. В итоге получаем полную выборку. Нет ли тут каких-то нетривиальных ограничений?
Неактивен
Ограничения только в реализации механизма FEDERATED. Если у Вас будет какой-то
нетривиальный запрос, то все данные из таблицы переедут на другой сервер, запрос
выполнится, а потом ненужная информация удалится. Вы можете значительно потерять
в скорости выполнения запросов. С другой стороны, простые запросы будут выполняться
непосредственно на удаленном сервере, что может увеличить скорость.
Неактивен
