Запустите аналитику на огромной базе данных MySQL

Question

У меня есть база данных MySQL с несколькими (если быть точным, пятью) огромными таблицами.По сути, это хранилище данных на основе звездной топологии.Размеры таблиц варьируются от 700 ГБ (таблица фактов) до 1 ГБ, а вся база данных занимает до 1 терабайта.Теперь мне дали задание запустить аналитику для этих таблиц, которая может даже включать объединения.Простым аналитическим запросом к этой базе данных может быть «найти количество курильщиков в каждом штате и отобразить его в порядке убывания». Это требование можно преобразовать в простой запрос, например

select state, count(smokingStatus) as smokers 
from abc 
having smokingstatus='current smoker' 
group by state....

Этот запрос (и многие другиеприрода) занимает много времени для выполнения в этой базе данных, время занимает порядка десятков часов.

Эта база данных также активно используется для вставки, что означает, что каждые несколько минут добавляются тысячи строк.

В таком случае, как я могу решить эту проблему запроса?Я посмотрел на Cassandra, который казался простым в реализации, но я не уверен, будет ли он так же прост для выполнения аналитических запросов к базе данных, особенно когда мне нужно использовать «where предложение и группировать по конструкции»

Также посмотрел в Hadoop, но я не уверен, как я могу реализовать запросы типа RDBMS.Я не слишком уверен, хочу ли я сразу же инвестировать в приобретение как минимум трех машин для name-node, zookeeper и data-узлов !!Прежде всего наша компания предпочитает решения на основе окон.

Я также думал о предварительном вычислении всех данных в более простых сводных таблицах, но это ограничивает мою способность выполнять различные виды запросов.

Существуют ли другие идеи, которые я могу реализовать?

РЕДАКТИРОВАТЬ

Ниже приводится настройка среды mysql

1) master-slave setup 2) master для вставок / обновлений 3) slave для чтения и выполнения хранимых процедур 4) все таблицы имеют innodb с файлами в таблице 5) индексы в строке, а также столбцы int.

Предварительный расчет значенийэто вариант, но так как требования для этого типа агрегированных значений постоянно меняются.

Answer 1

1 ТБ не такой большой.MySQL должен быть в состоянии справиться с этим.По крайней мере такие простые запросы не должны занимать часы!Не может быть очень полезным, не зная общего контекста, но я могу предложить некоторые вопросы, которые вы могли бы задать себе, в основном связанные с тем, как вы используете свои данные:

• Есть ли способ, которым выможно разделить чтение и запись?Сколько вы читаете, так вы делаете в день и сколько пишет?Можете ли вы жить с некоторой задержкой, например, писать в новую таблицу каждый день и объединять ее с существующей таблицей в конце дня?

• Каковы большинство ваших запросов?Это в основном запросы агрегации?Можете ли вы сделать частичную агрегацию заранее?Можете ли вы заранее рассчитывать количество новых курильщиков каждый день?

• Можете ли вы использовать hadoop для процесса агрегации выше?Hadoop довольно хорош в этом.В основном используйте hadoop только для ежедневной или пакетной обработки и сохраняйте результаты в БД.

• На стороне БД вы используете InnoDB или MyISAM?Индексы в столбцах String?Можете ли вы сделать это целыми и т. Д .?

Надеюсь, что поможет

Answer 2

Глядя на это с позиции попытки заставить MySQL работать лучше, чем предлагать совершенно новую архитектурную систему:

Во-первых, проверьте, что на самом деле происходит.Объясните запросы, которые вызывают проблемы, а не угадывайте, что происходит.

Сказав это, я угадаю, что происходит, поскольку у меня нет планов запросов.Я предполагаю, что (а) ваши индексы не используются правильно, и вы получаете кучу сканируемых таблиц, которых можно избежать, (б) ваши серверы БД настроены на OLTP, а не аналитические запросы, (в) запись данных во время чтения(d) работа со строками просто отстой, и (e) у вас есть несколько неэффективных запросов с ужасными объединениями (у каждого есть некоторые из них).

Чтобы улучшить вещи, я 'd исследуем следующее (примерно в таком порядке):

• Проверьте планы запросов, убедитесь, что существующие индексы используются правильно - посмотрите на сканы таблицы, убедитесь, что запросы действительно делаютsense.

• Уберите аналитические запросы из системы OLTP - настройки, необходимые для быстрых вставок и коротких запросов, сильно отличаются от настроек для запросов такого типа, которые потенциально читают большую часть большой таблицы.,Это может означать наличие другого подчиненного только для аналитики ведомого, с другой конфигурацией (и, возможно, типами таблиц - я не уверен, в каком состоянии сейчас находится MySQL).

• Удалите строки из таблицы фактов - вместо того, чтобы иметь столбец состояния курения со строковыми значениями (скажем, «текущий курильщик», «недавно бросил», «бросить курить 1+ лет», «никогда не курил»), перенесите эти значения вдругой таблицы, и иметь целочисленные ключи в таблице фактов (это также поможет размерам индексов).

• Остановить обновление таблиц во время выполнения запросов - еслииндексы движутся во время выполнения запроса. Я не вижу хороших событий.(К счастью) прошло много времени с тех пор, как я заботился о репликации MySQL, поэтому я не могу вспомнить, можно ли выполнить пакетную запись записей в ведомый аналитический запрос без особых усилий.

• Если вы дойдете до этого момента без решения проблем с производительностью, , тогда пришло время подумать о том, чтобы убрать MySQL.Сначала я бы посмотрел на Infobright - это открытый исходный код / ​​$$ и основанный на MySQL, поэтому, вероятно, его проще всего вставить в вашу существующую систему (убедитесь, что данные поступают в базу данных InfoBright, а затем направьте свои аналитические запросы в Infobright.сервер, оставьте остальную часть системы такой, какая она есть, выполненную работу), или если Vertica когда-либо выпустит Community Edition.Hadoop + Hive имеет много движущихся частей - это довольно круто (и отлично подходит для резюме), но если он будет использоваться только для аналитической части вашей системы, он может потребовать больше внимания и питания, чем другие варианты.

Answer 3

MySQL имеет серьезное ограничение, которое мешает ему быть способным работать в таких ситуациях.Проблема заключается в отсутствии возможности запроса parralel - он не может использовать несколько процессоров в одном запросе.
В Hadoop есть дополнение типа RDMBS, которое называется Hive.Это приложение, способное переводить ваши запросы в Hive QL (sql like engine) в задания MapReduce.Так как это на самом деле небольшое дополнение к Hadoop, оно наследует линейную масштабируемость
. Я бы посоветовал развернуть куст вместе с MySQL, реплицировать туда ежедневные данные и запускать тяжелые агрегации.Это разгрузит серьезную часть нагрузки для MySQL.Он все еще нужен для коротких интерактивных запросов, обычно поддерживаемых индексами.Они нужны вам, поскольку Hive по своей сути неинтерактивен - каждый запрос займет не менее нескольких десятков секунд.
Cassandra создана для доступа типа Key-Value и не имеет масштабируемой встроенной функции GroupBy.Существует DataStax Brisk, который интегрирует Cassandra с Hive / MapReduce, но может быть нетривиально отобразить вашу схему в Cassandra, и вы все еще не получаете гибкости и возможности индексирования RDBMS.

Как итог - Hive вместе с MySQL должен быть хорошим решением.