powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Оффлайн-тяпничная репликация
25 сообщений из 151, страница 5 из 7
Оффлайн-тяпничная репликация
    #39924528
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Куда сложнее выглядит задача обеспечения каскадной целостности, так как дифф нужно применить в правильном порядке.

И да. Если идти от способа вычисления хеша от ключа, то задача -- не выполнимая. Потому что натуральные ключи могут меняться. Для репликатора изменение ключа, это удаление + создание. А на мастере это ON UPDATE CASCADE.

Репликатор тупо встанет раком со своими космическими алгоритмами.

Сложные решения -- плохо, уродливо и некрасиво. Простые решения -- хорошо, и красиво.

Тоже хорошее замечание. Порядок обновления.

Я опишу его ещё пунктом.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924529
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Я опишу его как ещё один пункт.

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

И еще остается отдельный вопрос что делать при изменении структуры БД.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924531
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
mayton
Ожидаю ваших предложений.


Почему не хеш? Потому что хеш медленный и нафиг он тут не упал.
Он медленный.
Достаточно выбрать подходящую CRC функцию с хорошим распределением.

Для нашей задачи (в однопоточном варианте) узким местом будет IO подсистемы БД и Network.

Я не вижу смысла тратить время на поиски "хороших" или других распределений.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924534
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T


И еще остается отдельный вопрос что делать при изменении структуры БД.

Мы начали с простой утилиты. И хотелось бы сохранить определенную простоту use case и в дальнейшем.

Требования касающиеся изменений обьектов схемы (table columns) я опишу отдельным пунктом.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924538
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Как быть с удалёнными строками?

Никак. Удалять не нужно. Сделай флаг deleted и всё.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924557
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
crutchmaster
mayton
Как быть с удалёнными строками?

Никак. Удалять не нужно. Сделай флаг deleted и всё.

Как ты себе это представляешь? Логика которая работает с master удаляет строку?
Эта (основная) бизнес-логика нам недоступна. Мы ее не меняем.

Это конечно моя вина что я не описал и этот пункт. Опишу чуть позже.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924560
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Изменить его мы не можем.

Так надо с этого было начинать. А что с ним можно делать?
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924567
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавляю еще дополнения к базовому ТЗ.

14) Репликатор не вносит изменений в логику основных приложений которые работают с master и slave.
Однако репликатор (по согласованию с db owner) может добавить дополнительные таблицы. Поля.
И триггеры для отслеживания INSERT/DELETE/UPDATE на целевых таблицах ( RDS ).

15) Репликатор обладает сведениями относительно зависимостей таблиц.
Зависимости описываются в конфигурационном файле.

replicator.conf
Код: sql
1.
2.
dept -> emp
emp -> sales



В данном примере описано что таблица emp - дочерняя по отношению к dept. И процесс репликации (sync)
должен учитывать направление от дочерних к родительским.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924572
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
16) Репликатор имеет команду полной синхронизации (fullsync)

Код: sql
1.
$ replicator fullsync {...}



По согласованию с владельцем БД для поддержки плановых обновлений версии ПО master/slave
(добавление новых колонок) может потребоваться принудительное обновление 100% объема
реплицируемых справочников (replicated dictionaries set ( RDS )).

Логика расчета hash, lastUpdateTime и прочих служебных полей в этом случае исходит из
предположения что 100% datarows обновились и требуется перерасчет всего объема.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924576
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Опишу чуть позже.

Да, я пробежался по треду и не понял ситуацию. То изобретение git'а, то велик для синхронизации двух бд. Что есть вообще? Что может ваш чорный ящик и как вы с ним работаете? Как узнаете, что запись удалена? Надо пройти по всем, найти удаленные и передать? Не понятно.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924603
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Для нашей задачи (в однопоточном варианте) узким местом будет IO подсистемы БД и Network.

Я не вижу смысла тратить время на поиски "хороших" или других распределений.


IO всегда является узким местом, при его наличии. Не только в этой задаче, а в любой другой в принципе.
Насчет хеша, всё же согласиться не могу. У хеша другие задачи.
Ваша задача -- это именно CRC.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924604
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
И триггеры для отслеживания INSERT/DELETE/UPDATE на целевых таблицах ( RDS ).


Дык если триггер можно добавить, то всё, задача решена like a charm.

О чём тогда говорить? :)
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924611
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
mayton
Для нашей задачи (в однопоточном варианте) узким местом будет IO подсистемы БД и Network.

Я не вижу смысла тратить время на поиски "хороших" или других распределений.


IO всегда является узким местом, при его наличии. Не только в этой задаче, а в любой другой в принципе.
Насчет хеша, всё же согласиться не могу. У хеша другие задачи.
Ваша задача -- это именно CRC.

Хвост. Я, идя тебе навстречу объявлю настроечный тип хеширования. Какой настроишь - тот и будет.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924613
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
mayton
И триггеры для отслеживания INSERT/DELETE/UPDATE на целевых таблицах ( RDS ).


Дык если триггер можно добавить, то всё, задача решена like a charm.

О чём тогда говорить? :)

Отлично. Но где реализация?
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924616
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
crutchmaster
mayton
Опишу чуть позже.

Да, я пробежался по треду и не понял ситуацию. То изобретение git'а, то велик для синхронизации двух бд. Что есть вообще? Что может ваш чорный ящик и как вы с ним работаете? Как узнаете, что запись удалена? Надо пройти по всем, найти удаленные и передать? Не понятно.

Если вы внимательно читали - я описал только ограничения и требования. Не было ни строчки по самому алгоритму.

Но я верю в вашу фантазию и в ваше умение синтезировать алгоритмы. Попробуйте.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924649
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Отлично. Но где реализация?


Создаём триггер на insert/update/delete, для каждой из таблиц или для всех (зависит от возможностей СУБД).
Триггер пишет в табличку Changes(Timestamp, TableName,Key,ChangeType), где ChangeType одно из значений C|U|D.

Отправляем обновления по Timestamp, фильтруя по времени последнего обновления. Старые записи по какому-то регламенту подчищаем.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924651
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

Key это конкатенация значений ключа, допустим, через знак |.
Можно конечно и хеши, но нафига они тут нужны непонятно.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924653
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Более того, хеш здесь не поможет, так как нам нужно находить записи для C|U из оригинальных таблиц, и там эти хеши вообще не упёрлись.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924660
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Насчет хеша, всё же согласиться не могу. У хеша другие задачи.
Ваша задача -- это именно CRC.

Хэш это альтернативное название для алгоритмов расчета контрольной суммы.
https://ru.wikipedia.org/wiki/Контрольная_сумма С точки зрения математики контрольная сумма является результатом хеш-функции , используемой для вычисления контрольного кода — небольшого количества бит внутри большого блока данных
И CRC это не контрольная сумма, а один из алгоритмов расчета контрольной суммы
https://ru.wikipedia.org/wiki/Циклический_избыточный_код Циклический избыточный код (англ. Cyclic redundancy check, CRC[1]) — алгоритм нахождения контрольной суммы, предназначенный для проверки целостности данных[2]. CRC является практическим приложением помехоустойчивого кодирования, основанным на определённых математических свойствах циклического кода.
В общем если хочешь называть хэш контрольной суммой и писать CRC, пусть будет так.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924687
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Но где реализация?

Алгоритм:
1. Получаем из приёмника ts1, время последней удачной репликации.
2. Получаем текущее время ts2 и сохраняем в файл.
3. Для каждой таблицы из списка реплицируемых таблиц выполняем select * where lastModified >= :ts1 и сохраняем результат в файл(ы).
4. Получаем список удалённых записей из таблицы, заполняемой триггерами и сохраняем в файл(ы).
5. Упаковываем все вышеперечисленные файлы и отправляем на приёмник.
6. Спокойно спим до следующего сеанса.

На приёмнике полученные файлы распаковываются и применяются, включая значение ts2, которое потом будет выдано как ts1.

Кодируется прямолинейно на любом языке, имеющем средства доступа к любой БД. Ява сойдёт.

PS: Список таблиц в пункте 3 лучше иметь предварительно отсортированным по зависимостям внешних ключей. Тогда на приёмнике не придётся использовать отложенные ограничения целостности.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924706
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
mayton,

Key это конкатенация значений ключа, допустим, через знак |.
Можно конечно и хеши, но нафига они тут нужны непонятно.

Если таблица (table1) большая. От 1 млн строк и мы детектируем удалённые - то
нам надо чтобы 1 экземпляр приложения репликатор открыл два
курсора на master/slave и после merge принял решение об удалённых datarows.

Но я до последнего избегаю этого сценария, пытаясь соптимизировать networking.

Этот пункт важен и я его включал уже в SR.

Если вы считаете что хеши не нужны - ОК выбрасывайте. Но я их пока оставляю
как опцию.

Если они есть - хорошо. Нету - тоже сойдет.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924724
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

5. Упаковываем все вышеперечисленные файлы и отправляем на приёмник.

Пока мы еще не обсуждали нигде способы отправки. Да и нет такого протокола.
Есть две базы. Висят где-то в космосе. И есть 1 ваш процесс который поднят
либо "тут" либо "там".

Никакого другого протокола связи нет.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924735
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Никакого другого протокола связи нет.
Телепатическая доставка данных?
А разве "доставка любым протоколом" не подпадает под этот случай???
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924738
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov
mayton
Никакого другого протокола связи нет.
Телепатическая доставка данных?
А разве "доставка любым протоколом" не подпадает под этот случай???

Дмитрий писал.

4. Получаем список удалённых записей из таблицы, заполняемой триггерами и сохраняем в файл(ы).
5. Упаковываем все вышеперечисленные файлы и отправляем на приёмник.

Это был ответ на предложение по отправке файлов. О файлах я еще не думал. Это - другой уровень репликации.
...
Рейтинг: 0 / 0
Оффлайн-тяпничная репликация
    #39924792
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

Кодируется прямолинейно на любом языке, имеющем средства доступа к любой БД. Ява сойдёт.


2 All!

Давайте - маленкий челлендж. Пускай это будет не требование но Secondary Goal этого топика.

Сделаем на языках:
- Rust
- Go


Я очькую только в части сопряжения с БД. Не знаю насколько хорошо Rust укомплектован дровами
к PG/ORA/MS/MySQL.

На обоих языках я написал аж ПреведМир так што я недалеко ушел в этом смысле от вас, коллеги.
...
Рейтинг: 0 / 0
25 сообщений из 151, страница 5 из 7
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Оффлайн-тяпничная репликация
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]