У нас есть база данных MySQL (в основном только для чтения, то есть таблицы MyISAM), которая находится в центре обработки данных и взаимодействует с базой данных SQL Server, расположенной на месте. В сети WAN наблюдается значительная задержка (более 100 мс); примерно через 6 месяцев СУБД SQL Server перейдет в центр обработки данных (например, в ту же гигабитную локальную сеть).
В базе данных MySQL у меня есть несколько тысяч строк, которые мне нужно обновить из результатов в базе данных SQL Server. БД MySQL подключена к приложению rails, работающему в Linux, поэтому я хотел бы сохранить логику для максимально возможного переноса данных либо в сценариях оболочки, либо в задачах rake / ruby (мы не windows разработчики приложений, поэтому приложения Win32 и т.п. прямо !).
Это довольно простой процесс. В псевдокоде:
SELECT id
, amount
FROM bank_account.on_SQL_Server
WHERE (some logic)
FOREACH ROW:
UPDATE bank_account.on_MySQL
SET amount = $some_amount
WHERE id = $some_id
Предположим, что есть несколько тысяч строк, которые нужно обновлять и делать так часто (каждые 5 минут). Также предположим, что у меня нет возможности узнать, в каких строках SQL Server произошло изменение количества (к сожалению!), Поэтому я не могу ограничить его только измененными строками - я должен отправить их повсюду (да, но БД SQL Server) является сторонним приложением, которое не может быть изменено edit: у нас действительно есть контроль над СУБД, поэтому мы могли бы сделать небольшое изменение, такое как триггер на столе или новая хранимая процедура - просто без схемы таблицы изменения, чтобы добавить, скажем, последний обновленный столбец - но я бы хотел сохранить этот параметр как последнее средство ).
Как лучше всего выполнить этот процесс обновления, минимизируя время выполнения? Этот процесс нужно будет запускать каждые несколько минут (чем раньше, тем лучше), а выпуск двойных соединений с SQL Server и MySQL из Ruby слишком медленный. Это могут быть некоторые блокировки таблицы записи, выдаваемые движком MyISAM, но преобразование в Innodb, кажется, не делает это быстрее (система находится в тестировании, и поэтому нелегко имитировать такую же нагрузку, какую получит производство, что приводит меня к считаю, что это не связано с блокировкой).
В настоящее время я склоняюсь к тому, чтобы BCP отображал VIEW (который соответствует приведенному выше выражению SQL Server) для файла, FTP для Linux-сервера, а затем использую Ruby для доступа к файлу (и выполнения МНОГО сериализованного Операторы SQL), но я должен представить, что есть лучшие способы.