Меню
Что нового?

Сихнронизация таблиц из различный баз

masp

Новичок
Сихнронизация таблиц из различный баз

Есть две таблицы в разных базах. Одна формируется на основе другой (берет из нее часть полей и соответсвенно содержить указатель на id записи из которой взяты данные из первой таблицы). Эти таблицы ОЧЕНЬ большие > 25 000 000 строк. Первая таблица может обновить свои данные после того как они были импортированы во вторую. Задача: написать скрипт, который проверяет данные второй таблицы (производной) с соответствующими данными первой таблицы (связаны через указатель id). Вопрос: Как это сделать наиболее оптимально в плане производительности? Варианты? Банальный SQL запрос выполняется слишком долго.
 

phpdev2007

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

masp

Новичок
Вариант, с внешними ключами сразу отпадает. Есть таблица в том виде в каком она сейчас. Любые модификации, то бишь alter table и т.д. неприемлемы, в силу определенных причин. Так что нужен вариант другой.
 

nail

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

========
Это только в случае если мы контролируем процесс выполнения апдейтов.
Если же нет, то я бы последовательно читал обе таблицы по порядку (по возрастанию первичного ключа, если это innodb) и вносил изменения.
 

masp

Новичок
Синхронно апдейтить нельзя - критична скорость первой таблицы (причем ОЧЕНЬ). Запоминать апдейты тоже проблема, поскольку первая таблицы апдейтится совершенно другим application'ом в который вносить изменения я не могу. Так что в исходных данных у меня только таблица (в этом то и есть основная проблема) и я не знаю когда и куда вносились в нее изменения.

Если же нет, то я бы последовательно читал обе таблицы по порядку (по возрастанию первичного ключа, если это innodb) и вносил изменения.
Нажмите для раскрытия...
Имеется в виду построчное чтение записей и сравнение?
 

phpdev2007

Новичок
masp
скажите что за сервер, скажите какие размеры таблиц в мегабайтах, какой тип таблиц, какие права ваши как пользователя на данном сервере?
 

masp

Новичок
Сервер Debian Linux/Apache/MySQL4.*
Размер таблиц: > 8Gb
Тип Таблиц: MyISAM.
Права - read/write
 

phpdev2007

Новичок
masp
Вести лог обновления данных по id в первой таблице, после с помощью данного лога обновлять таблицу два, - ну не буквально с помощью лога :) чистить лог после окончания обновления, можно для этого завести таблицу которая будет содержать все данные про записи которые нужно обновить.
 

masp

Новичок
Вести лог обновления данных по id в первой таблице, после с помощью данного лога обновлять таблицу два, - ну не буквально с помощью лога чистить лог после окончания обновления, можно для этого завести таблицу которая будет содержать все данные про записи которые нужно обновить.
Нажмите для раскрытия...
Думал об этом - завести отдельную таблицу, в которую писать id'шники записей, которые были обновлены, а затем по ним апдейтить вторую таблицу. Но, есть несколько моментов - скорость обновления первой таблицы ОЧЕНЬ критична, посему дополнительные нагрузки, вроде записи в лог (или в таблицу) не очень-то приветсвуются.
 

Gas

может по одной?
посему дополнительные нагрузки, вроде записи в лог (или в таблицу)
Нажмите для раскрытия...
из серии "я это говорю, основываясь... ни на чём!" (с)Картмен, South Park.

Были проведены тесты, которые свидетельствуют о слишком большой нагрузке этих операций ?
 

masp

Новичок
из серии "я это говорю, основываясь... ни на чём!" (с)Картмен, South Park.
Были проведены тесты, которые свидетельствуют о слишком большой нагрузке этих операций ?
Нажмите для раскрытия...
Если я так говорю значить на это есть основания!!!! Данная таблица используется в приложении, которое ОЧЕНЬ критичну к скорости, а посему любые дополнительные манипуляции неизбежно приведут к увеличению веремени пинга сервера. (сейчас пинг и так почти на пределе)
По поводу тестов - тесты не были проведены, более того, как я писал выше, я сам придерживаюсь мнения что нужно завести таблицу логов апдейтов, и затем по ней апдейтить вторую таблицу. НО! меня интерисуют возможные другие варинаты реализации данной задачи, учитывая специфику приложения.
 
phprus

phprus

Moderator
Команда форума
masp
Если я так говорю значить на это есть основания!!!!
Нажмите для раскрытия...
Из твоих слов следует что оснований нету, так как если разрабатывают чтото что должно держать высокие нагрузки, то без тестирования скорости ни одно решение использовать не будут.

приведут к увеличению веремени пинга сервера. (сейчас пинг и так почти на пределе)
Нажмите для раскрытия...
К увеличению чего? Как БД связана с отправкой ОС сервера ICMP Echo-Reply пакетов? Пинг вообще-то позволяет определить загруженность каналов, а не время работы твоего приложения. (По крайней мере я никогда не слышал чтобы время отклика приложения называли пингом)

По поводу тестов - тесты не были проведены
Нажмите для раскрытия...
Да я был прав. Раз небыло тестов значит нет и оснований для того чтобы говорить что какое-либо решение будет работать очень медленно.

НО! меня интерисуют возможные другие варинаты реализации данной задачи, учитывая специфику приложения.
Нажмите для раскрытия...
Триггер на изменение первой таблицы, который будет менять значения во второй таблице.
 
phprus

phprus

Moderator
Команда форума
Gas
Вообщето у него тип таблицы MyISAM, а она триггеры не поддерживает, но если не нравится ведение логов или дополнительной таблицы, то другого решения я в принципе не вижу.
 

nail

Новичок
Автор оригинала: masp
Думал об этом - завести отдельную таблицу, в которую писать id'шники записей, которые были обновлены, а затем по ним апдейтить вторую таблицу. Но, есть несколько моментов - скорость обновления первой таблицы ОЧЕНЬ критична, посему дополнительные нагрузки, вроде записи в лог (или в таблицу) не очень-то приветсвуются.
Нажмите для раскрытия...
Вы уж определитесь, можно менять код апдейта или нельзя. Если можно, делайте очередь, если критична скорость, значит делайте очередь в памяти (mysql heap или shared memory)
 

masp

Новичок
К увеличению чего? Как БД связана с отправкой ОС сервера ICMP Echo-Reply пакетов? Пинг вообще-то позволяет определить загруженность каналов, а не время работы твоего приложения. (По крайней мере я никогда не слышал чтобы время отклика приложения называли пингом)
Нажмите для раскрытия...
Виноват, неправильно выразился, хотя думаю поняли все ;)

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

Вы уж определитесь, можно менять код апдейта или нельзя. Если можно, делайте очередь, если критична скорость, значит делайте очередь в памяти (mysql heap или shared memory)
Нажмите для раскрытия...
В этом проблема есть - апдейт первой таблицы делает другое приложение, которое разрабатывает другая команда. Я пытаюсь повлиять сейчас на них, чтобы прикрутить данную систему..... Но на первых порах прийдется извращаться...

в любом случае спасибо всем за посты.
 
phprus

phprus

Moderator
Команда форума
Gas
честно говоря не слышал о таком, можно ссылочку где об этом сказано.
А то на Restrictions on Stored Routines and Triggers и Using Triggers не нашёл этого.
Нажмите для раскрытия...
Я перепутал триггеры и транзакции.

А кроме этого триггеры появились только в MySQL 5.0.

masp
А есть возможность обновить сервер до MySQL 5.* ? Если да, то триггеры решат вашу задачу.
 
Войдите или зарегистрируйтесь для ответа.
Сверху