ускорить работу на MySQL

Question

В настоящее время я пишу Java-проект против MySQL в кластере с десятью узлами. Программа просто извлекает некоторую информацию из базы данных и делает некоторые вычисления, а затем отправляет некоторые данные обратно в базу данных. Однако в таблице миллионы строк. Есть ли способ разделить работу и использовать кластерную архитектуру? Как сделать многопоточность на другом узле?

Answer 1

Я смотрел интересную презентацию об использовании Gearman для создания элементов Map / Reduce style в базе данных mysql. Это может быть то, что вы ищете: см. здесь . На веб-странице mysql есть запись здесь (хотя нужно зарегистрироваться на mysql.com).

Answer 2

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

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

Таким образом, вашими лучшими вариантами будет обновление в чистом SQL, если это вообще возможно, или использование хранимой процедуры, чтобы вся обработка могла выполняться на сервере MySql, и перемещение данных не требуется.

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

Answer 3

Поскольку у вас есть только один сервер mysql, убедитесь, что вы используете механизм innodb для уменьшения блокировки таблиц при обновлениях.

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

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

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

Answer 4

Предположим, что таблица (A), которую вы хотите обработать, содержит 10 миллионов строк. Создайте таблицу B в базе данных для хранения набора строк, обработанных узлом. Таким образом, вы можете написать Java-программу таким образом, что она сначала извлечет последнюю строку, обработанную другими узлами, а затем добавит запись в той же таблице, информирующую другие узлы, какой диапазон строк она собирается обработать (вы можете решить это число). В нашем случае, давайте предположим, что каждый узел может обрабатывать 1000 строк одновременно. Узел 1 выбирает таблицу B и находит ее пустой. Затем узел 1 вставляет строку ('Node1', 1000), информирующую о том, что он обрабатывается до тех пор, пока первичный ключ A не будет <= 1000 (при условии, что первичный ключ таблицы A числовой и находится в порядке возрастания). Узел 2 приходит и обнаруживает, что 1000 первичных ключей обрабатываются другим узлом. Следовательно, он вставляет строку («Узел 2», 2000), информируя других о том, что он обрабатывает строки в промежутке между 1001 и 2000. Обратите внимание, что доступ к таблице B должен быть синхронизирован, то есть только один может работать с ней одновременно. </p>

Answer 5

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

Я могу ошибаться, но стоит посмотреть прототип.