Как управлять огромными операциями на MySql - PullRequest
Новая
       41

Как управлять огромными операциями на MySql

4 голосов
/ 14 июня 2011

У меня есть база данных MySql.У меня есть много записей (около 4 000 000 000 строк), и я хочу обработать их, чтобы уменьшить их (уменьшить примерно до 1 000 000 000 строк).

Предположим, яесть следующие таблицы:

  • таблица RawData : у меня более 5000 строк в секунду, которые я хочу вставить в RawData

  • таблица ProcessedData : эта таблица является обработанным (агрегированным) хранилищем для строк, которые были вставлены в RawData. минимальное количество строк> 20 000 000

  • таблица ProcessedDataDetail : я записываю детали таблицы ProcessedData (агрегированные данные)

    пользователи хотят просматривать и искать в таблице ProcessedData , к которой нужно присоединиться более чем к 8 другим таблицам.Вставка в RawData и поиск в ProcessedData (ProcessedData INNER JOIN ProcessedDataDetail INNER JOIN ...) очень медленные.Я использовал много индексов.предположим, что моя длина данных составляет 1G, но моя длина индекса составляет 4G :).(Я хочу использовать эти индексы, они замедляют мой процесс)

Как я могу увеличить скорость этого процесса?

Я думаю, мне нужна таблица тенейиз ProcessedData , назовите его ProcessedDataShadow .затем обработайте RawData и агрегируйте их с помощью ProcessedDataShadow , затем вставьте результат в ProcessedDataShadow и ProcessedData .В чем ваша идея ??

(я разрабатываю проект на C ++)

заранее благодарю.

Ответы [ 2 ]

3 голосов
/ 14 июня 2011

Не зная больше о вашем действительном заявлении, у меня есть следующие предложения:

  1. Используйте InnoDB, если вы этого еще не сделали. InnoDB использует блокировки строк и намного лучше обрабатывает параллельные обновления / вставки. Это будет медленнее, если вы не будете работать одновременно, но блокировка строк, вероятно, необходима для вас, в зависимости от того, сколько источников у вас будет для RawData.

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

  3. Если вы будете выбирать огромный объем данных, который может помешать сбору данных, рассмотрите возможность использования реплицированного подчиненного сервера баз данных, который вы используете только для чтения. Даже если это заблокирует строки / таблицы, основная (основная) база данных не будет затронута, и ведомое устройство вернется к скорости, как только это будет свободно.

  4. Вам нужно обрабатывать данные в базе данных? Если возможно, возможно, собрать все данные в приложении и только вставить ProcessedData.

2 голосов
/ 14 июня 2011

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

Однако самой неотложной проблемой будет снижение скорости 5000 строк в секунду. Вам понадобится очень большая, очень быстрая машина (вероятно, кластер с осколками).

Если возможно, я бы порекомендовал записать буфер консолидации (используя хеш-таблицу в памяти, а не в СУБД), чтобы поместить консолидированные данные - даже если они были только частично консолидированы - а затем обновить их в таблицу processingData. чем пытаться заполнить его напрямую из rawData.

Действительно, я бы, вероятно, подумал о том, чтобы разделить необработанные и консолидированные данные на отдельные серверы / кластеры (механизм объединения MySQL удобен для обеспечения унифицированного представления данных).

Вы проанализировали свои запросы, чтобы увидеть, какие индексы вам действительно нужны? (подсказка - этот скрипт очень полезен для этого).

...