Лучший способ получить данные из одной таблицы базы данных с несколькими потоками?

Question

у нас есть система, где каждую секунду мы собираем данные об активности пользователей на нескольких веб-сайтах.мы сбрасываем эти данные в базу данных X (скажем, MS SQL Server).теперь нам нужно извлечь данные из этой единственной таблицы из базы данных X и вставить в базу данных Y (скажем, mySql).

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

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

Заранее спасибо!Рави

Answer 1

Если вы перемещаете данные из одной базы данных в другую, вы не получите никаких преимуществ, если будете работать с несколькими потоками.Это только увеличит конкуренцию.

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

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

1. идентификации новых / обновленных / удаленных строк (триггеры)., запросы на основе диапазона, полные дампы)
2. транспортировка данных (выгрузка в файл и FTP, извлечение / загрузка из программы)
3. загрузка данных в другую базу данных (импорт, массовая вставка)

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

1. Каков ожидаемый объем данных?
2. Наибольшая допустимая задержка между созданием строки в исходной БД и доступностью в TargetDB

Answer 2

Темы не путь. База данных является узким местом здесь. Несколько потоков будут только увеличить конкуренция. Даже если 10 процессов затирают данные в SQL Server, один поток (а не многие) может извлечь их быстрее. В этом нет абсолютно никаких сомнений.

Сам SELECT может вызвать блокировки в основной таблице, уменьшая пропускную способность INSERT, поэтому я бы "входил и выходил" как можно быстрее. Если бы это был я, я бы:

1. ВЫБЕРИТЕ строки на основе запроса диапазона (дата, recno, что угодно), выведите их в файл и закройте результирующий набор (курсор).
2. УДАЛИТЬ строки на основе одного и того же запроса диапазона.
3. Затем обработать дамп. Если возможно, формат дампа должен быть доступен для массовой загрузки в MySQL.

Я не хочу бить вашу архитектуру, но в целом дизайн звучит проблематично. ВЫБОР И УДАЛЕНИЕ строк из таблицы, подвергающейся высокой скорости ВСТАВЛЕНИЯ, создаст огромные проблемы с блокировкой. Я хотел бы посмотреть на «двойную буферизацию» данных в SQL Server.

Например, каждую минуту вставки переключаются между двумя таблицами. Например, в первую минуту INSERT переходят в TABLE_1, но когда минута переворачивается, они начинают INSERT в TABLE_2, на следующей минуте возвращаются в TABLE_1 и так далее. Пока INSERTS входят в TABLE_2, ВЫБЕРИТЕ все из TABLE_1 и сбросьте его в MySQL (настолько эффективно, насколько это возможно), затем TRUNCATE таблицы (удалив все строки с нулевым штрафом). Таким образом, между читателями и писателями никогда не будет раздоров.

Координация точки прокрутки между TABLE_1 и TABLE_2 - сложная часть. Но это можно сделать автоматически с помощью умного использования многораздельных представлений SQL Server.

Answer 3

Существует два уровня озабоченности вашей проблемы:

1. Транзакция между этими двумя базами данных:

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

2. Производительность передачи данных:

   Если в базе данных X всегда есть входящие данные, которые являются онлайновой базой данных, не рекомендуется просто собирать данные, сохранять их в Y и удалять их. Планируя размер пакета, программа запускает транзакцию для этого пакета; повторное выполнение программы до тех пор, пока число данных в X не станет меньше размера пакета.

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

INIT - The start of batch, this value should be synchronized between two databases
COPIED - In database Y, the insertion of data and the update of this status should be in one transaction.
FINISH - In database X, the deletion of data and the update of this status should be in on transaction.

Когда программа запущена, она сначала проверяет партии в состоянии «INIT» или «COPIED» и перезапускает сеанс для обработки.

• Если X имеет запись INIT, а Y - нет, просто вставьте эту же запись INIT в Y, затем выполните вставку в Y.
• Если запись в Y «COPIED», а X «INIT», просто измените состояние X на «COPIED», затем выполните удаление до X.
• Если запись в X имеет значение «FINISH», а соответствующая запись в Y «COPIED», просто обновите состояние Y до «FINISH».

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

Answer 4

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