ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / GUID-ключи хуже для распределенных БД, чем числовые
25 сообщений из 28, страница 1 из 2
  1  все
GUID-ключи хуже для распределенных БД, чем числовые
    #38270953
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Здравствуйте!

Я думаю, что уже одно упоминание темы про GUID-ключи должно вызывать смех, но тем не менее :)

Дано:
Есть 2 базы данных (OLTP). Теоретически их может быть больше, но это очень маловероятно. Ну пусть их будет максимум даже 1000. В каждую базу в сутки пишется порядка 2 млн. записей. Базы по сути представляют собой локальный буфер для данных. Раз в сутки данные собираются в единый архив, а из этих баз удаляются.

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

В БД несколько таблиц, связанных внешними ключами :)

Проблемы:
Не понятно как определить какие данные уже скопированы в архив, а какие - нет. Записи удаляются из OLTP-баз не сразу после копирования в хранилище. Искать в OLTP первичные ключи, которых нет в хранилище, и копировать только такие записи - либо медленно (если перебирать записи в OLTP построчно), либо требует много памяти (если кешировать ключи в оперативной памяти).

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

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

Вопросы:
Я правильно понимаю, что в такой ситуации никак не обойтись без автоинкрементных числовых ключей? Ну, по крайней мере, это самый простой способ?

При использовании GUID-ключей конечно проще обеспечивать их глобальную уникальность, но гораздо сложнее потом консолидировать данные? Как это обычно делается?
...
Рейтинг: 0 / 0
23.05.2013, 22:18
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38270961
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ares_ekbЯ правильно понимаю, что в такой ситуации никак не обойтись без
автоинкрементных числовых ключей?
В этой ситуации не обойтись без админа, поскольку:
1) Совершенно пофиг сколько записей накопится в буферной базе, их можно и нужно скинуть
все зараз.
2) Скинутые записи можно удалить сразу после получения подтверждения о том, что они дошли
до целевой базы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
23.05.2013, 22:29
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271018
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
А я думал что времена самодельных репликаторов ушли.
Воспользуйтесь встроенным репликатором вашей СУБД. Избежите множества хитрых граблей.
...
Рейтинг: 0 / 0
23.05.2013, 23:09
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271032
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
SERG1257А я думал что времена самодельных репликаторов ушли.

Это ты зря думал.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
23.05.2013, 23:27
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271088
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
Ares_ekbНо это жесть, т.к. часы на компах могут переводиться
Во-первых, если предположить, что часы могут переводиться бесконтрольно, то тогда надо ещё защиту от дурака-админа реализовать ))))
Во-вторых, можно сделать аналог времени записи, только огрублённый, по сути идентификатор пакета обновления, соответственно весь пакет залетает транзакцией, тип его int или хоть даже datetime (timestamp). Это если сильно охота руками.
...
Рейтинг: 0 / 0
24.05.2013, 01:03
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271089
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Сергей Васкецоввесь пакет залетает транзакцией
Если СУБД аффтара поддерживает транзакции чуть сильнее чем на минимальном уровне Dirty
Read, то все трюки с какими-либо таймштампами или приравненными к ним автоинкрементами
идут лесом прямо в морг. Ибо рано или поздно в пакете не окажется пары записей, которые
попали в базу перед стартом репликации, но коммит их транзакции произошёл позднее.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
24.05.2013, 01:10
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271197
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Dimitry Sibiryakov1) ... их можно и нужно скинуть все зараз.
2) ... можно удалить сразу после полученияЭто конечно всё упрощает, но данные в OLTP пишутся круглосуточно. Я опасаюсь, что если разом вытягивать много записей, просядет производительность учетной системы. Плюс, пока копируются одни записи, в базе уже появятся новые. Причем как в основной таблице (сначала вытягивается она), так и в связанных с основной внешними ключами.

Я не понял насчет админа ) По-моему админ - по определению менее надежный способ. Всё, что может сделать админ, можно автоматизировать.


SERG1257 , у заказчика Oracle SE1, ничего докупать не планируется ;(


Сергей Васкецов , ну по сути получается, то о чем я и говорю: нужно автоинкрементное поле. Время все-таки слишком не детерминировано. Коррекция на миллисекунды-секунды возможна запросто. Огрубление конечно интересная мысль, но всё-равно возможно всякое: могут и переход на летнее/зимнее время вернуть и вообще мало ли что...

У времени есть одно преимущество: оно по крайней мере одинаково в разных таблицах. И если вытягивать из всех таблиц записи на определенный момент времени, то эти данные будут однозначно целостными. С числовыми ключами этого добиться сложнее. Пока я придумал такой вариант: 1) Перед началом копирования одной транзакцией получаем последние идентификаторы во всех таблицах. 2) Копируем записи только с меньшими идентификаторами.
...
Рейтинг: 0 / 0
24.05.2013, 08:05
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271207
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
А начальные идентификаторы берем из хранилища. По-моему должно работать... И не обязательно сразу удалять данные из OLTP-базы. Скорей всего, потребуется, чтобы данные хранились в OLTP-базах какое-то время.
...
Рейтинг: 0 / 0
24.05.2013, 08:20
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271326
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
Dimitry SibiryakovИбо рано или поздно в пакете не окажется пары записей, которые
попали в базу перед стартом репликации, но коммит их транзакции произошёл позднее.
Лечится любым пряморуким. Впрочем, могут быть особенности.

Ares_ekbОгрубление конечно интересная мысль, но всё-равно возможно всякое: могут и переход на летнее/зимнее время вернуть и вообще мало ли что...
UTC, не? Зачем локальное время для таких целей?
...
Рейтинг: 0 / 0
24.05.2013, 09:50
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271443
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
Ares_ekbDimitry Sibiryakov1) ... их можно и нужно скинуть все зараз.
2) ... можно удалить сразу после полученияЭто конечно всё упрощает, но данные в OLTP пишутся круглосуточно. Я опасаюсь, что если разом вытягивать много записей, просядет производительность учетной системы. Плюс, пока копируются одни записи, в базе уже появятся новые. Причем как в основной таблице (сначала вытягивается она), так и в связанных с основной внешними ключами.Самый простой вариант - партицирование. Например, по дате. Практически не требует изменений в логике приложения. И "арихивировать" ничего не надо - оно уже как-то само "раскладывается"... По партициям...
Более сложный вариант - использование промежуточной базы, где находятся только необработанные данные, которые (по мере обработки) переносятся в основную БД.
Ares_ekbЯ не понял насчет админа ) По-моему админ - по определению менее надежный способ. Всё, что может сделать админ, можно автоматизировать.Интересный вопрос: кто, кроме достаточно квалифицированного админа способен настроить такую автоматизацию и контроллировать правильность ее функционирования?
Ares_ekbу заказчика Oracle SE1, ничего докупать не планируется ;(Вариант с партицированием, к сожалению, не доступен - только EE... :(
Ares_ekbУ времени есть одно преимущество: оно по крайней мере одинаково в разных таблицах. И если вытягивать из всех таблиц записи на определенный момент времени, то эти данные будут однозначно целостными.По дате - не будут.
Изменения в таблицах делаются не мгновенно. Соответственно, всегда можно попасть на доли секунд разницы для нескольких последовательных обновлений в рамках единой транзакции даже для одной таблицы. Теперь рассмотрите вариант, когда последовательно изменяется несколько разных таблиц.
...
Рейтинг: 0 / 0
24.05.2013, 10:36
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271560
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
sphinx_mv , партицирование не очень подходит, т.к. OLTP-баз несколько. Всё-равно данные нужно сводить в одну.

Насчет админа я согласен, я только хотел уточнить: эта задача в принципе автоматизируется или нужна какая-то ручная работа? Что значит "не обойтись без админа"?

sphinx_mv...можно попасть на доли секунд...я думаю, что это решается временнОй задержкой. Можно не копировать данные за последние несколько минут-часов, а для более старых записей все транзакции уже завершатся. Данные только добавляются, обновлений нет.
...
Рейтинг: 0 / 0
24.05.2013, 11:24
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38271774
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ares_ekbЯ опасаюсь, что если разом вытягивать много записей, просядет
производительность учетной системы. Плюс, пока копируются одни записи, в базе уже появятся
новые. Причем как в основной таблице (сначала вытягивается она), так и в связанных с
основной внешними ключами.
1) Не просядет.
2) И что? Именно для этого придумали уровни изоляции транзакций выше Read Committed.

Ares_ekbЧто значит "не обойтись без админа"?
Считается, что "админ" - существо, обладающее мозгом и умеющее читать документацию.
Безмозглый нечитатель только всё изгадит.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
24.05.2013, 12:27
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38272603
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
и все равно смотрите в сторону партиций пусть даже рукопашных.
Суть - в момент Х (наименьшей нагрузки) создается новая таблица, старая таблица лочится, они переименовываются и вуаля.
Старую (полную) таблицу передаем как можем, после подтверждения усекаем.
...
Рейтинг: 0 / 0
24.05.2013, 17:00
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38272681
Александр52
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр52
Участник
хмм....
у вас есть БД, с данными, которую надо поместить в архив.
Бэкап-ресторе её на сервере-архиве, и используйте в дальнейшем только как архив на чтение.
Создавайте новую бд и в конфигах указывайте уже её.

Таким образом у вас архив будет состоять из нескольких баз. А запись будет идти в текущую, которая потом станет архивом.
Ограничить можно например по размеру, при достижении - выполняется эта задача.
С такими темпами у вас архив разрастется и с ним без секционирования очень сложно будет работать.
...
Рейтинг: 0 / 0
24.05.2013, 17:44
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38272722
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Еще один чисто админский способ - с OLTP баз шлются логи, которые гарантировано (в смысле никаких конфликтов) накатываются на копию баз на хранилищном сервере. Хранилищная копия открывается на только чтение и вуаля - синхронизируем как можем в пределах одной сетки. Плюс имеем еще одну копию на случай дизастер рекавери. Плюс это может быть копия с отложенными изменениями на случай человеческой ошибки. Минус - удвоенные требования к дисковому пространству. Но диски не обязаны быть супер-пупер.
...
Рейтинг: 0 / 0
24.05.2013, 18:12
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299043
avb1987
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avb1987
Гость
Можно создать sequence, из которого записям будут присваиваться номера, и соответственно перенос в основную базу будет идти по порядку возрастания этой последовательности. При частичной синхронизации имеем последний скопированный id, соответственно все что меньше - можно удалить, а все что больше - нужно докопировать.
...
Рейтинг: 0 / 0
16.06.2013, 15:52
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299044
avb1987
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avb1987
Гость
Сорри, не дочитал ваше сообщение до конца. В общем имхо то что вы написали (про автоинкремент) и есть самый простой способ.
...
Рейтинг: 0 / 0
16.06.2013, 15:54
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299047
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
avb1987При частичной синхронизации имеем последний скопированный id, соответственно
все что меньше - можно удалить, а все что больше - нужно докопировать.

Да, и останется только маленькая фигня: использовать СУБД без транзакций. Потому что нигде
больше эта схема надёжно не работает.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.06.2013, 16:04
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299049
avb1987
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avb1987
Гость
Dimitry SibiryakovДа, и останется только маленькая фигня: использовать СУБД без транзакций. Потому что нигде
больше эта схема надёжно не работает.


И в чем заключается проблема использования транзакций с последовательностями?
...
Рейтинг: 0 / 0
16.06.2013, 16:06
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299057
avb1987
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avb1987
Гость
Автор вроде не указал как именно записи добавляются - если добавление идет в одном потоке последовательно, то никаких проблем быть не должно, если параллельно - то действительно как вы и сказали может получиться что несколько записей не попадут в выборку.

Можно еще как вариант сделать чтобы основной сервер перед тем как делать выборку помечал записи в базах-накопителях, чем то вроде id-выборки (т.е. добавить в табличку поле "id выборки"), а потом все записи которые были помечены - выбрать и удалить, таким образом хотя данные из незавершенных транзакций в эту выборку не попадут, но и удалены не будут.
...
Рейтинг: 0 / 0
16.06.2013, 16:19
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299229
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Я нашел более-менее работающее решение. Перед началом копирования получаю максимальное значение ora_rowscn (автоинкрементальный ключ и метка времени в одном флаконе), после чего копирую записи только с меньшим значением. Это не потребовалось бы если бы SSIS поддерживал (без дополнительных усилий) Oracle-транзакции. Тогда действительно можно было бы всё копировать одной транзакцией.
...
Рейтинг: 0 / 0
16.06.2013, 23:07
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299239
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Про автоинкрементальный ключ шутка ) Мозг высох на урановых рудниках даче )
...
Рейтинг: 0 / 0
16.06.2013, 23:30
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299292
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
автор Проблемы:
Не понятно как определить какие данные уже скопированы в архив, а какие - нет. Записи удаляются из OLTP-баз не сразу после копирования в хранилище. Искать в OLTP первичные ключи, которых нет в хранилище, и копировать только такие записи - либо медленно (если перебирать записи в OLTP построчно), либо требует много памяти (если кешировать ключи в оперативной памяти).

Как бы другого варианта-то и нет.
У тебя в любом случае должны быть идентификаторы для строк данных, которые тебе позволили бы понять, есть данная строка в целевой БД или нет. И видимо это должны быть какие-то предметно-ориентированные идентификаторы, потому что тебе ещё надо видимо понимать,
что две одинаковые записи из разных исходных баз тоже не нужно заносить в итоговую.

авторДругой вариант - смотреть последние даты у записей в хранилище. И копировать из OLTP записи с большей датой.

Это может видимо быть только первичный фильтр на обрабатываемые данные, потом всё равно надо проверять.

Но это жесть, т.к. часы на компах могут переводиться.

Ну, не переводи часы.


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

Не единственный.

авторЯ правильно понимаю, что в такой ситуации никак не обойтись без автоинкрементных числовых ключей? Ну, по крайней мере, это самый простой способ?

Видимо, неправильно.

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

GUID даёт уникальность , тебе же нужна не только уникальность, а ещё и сериализованность процесса создания твоих записей.
Т.е. тебе нужно строго упорядочить записи в каждой БД (и возможно глобально тоже) в порядке (видимо) их появления.
Для этого GUID не подходит, для этого нужен какой-то упорядочивающий критерий. Время появления записи -- достаточно хороший
критерий. Можно и счётчик, но счётчик будет заведомо уникален только в рамках одной БД, не глобально.
...
Рейтинг: 0 / 0
17.06.2013, 04:55
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299293
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Если это оракл, там есть же уже готовые решения для репликации данных,
даже интеллектуальной.
Может лучше их попробовать ?
...
Рейтинг: 0 / 0
17.06.2013, 04:58
| Ответить | Цитировать | Написать  
GUID-ключи хуже для распределенных БД, чем числовые
    #38299296
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Dimitry Sibiryakov2) И что? Именно для этого придумали уровни изоляции транзакций выше Read Committed.



Dimitry, уровни изоляции тут ни при чём, вообще, в топике.
...
Рейтинг: 0 / 0
17.06.2013, 05:01
| Ответить | Цитировать | Написать  
25 сообщений из 28, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / GUID-ключи хуже для распределенных БД, чем числовые
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/search_topic.php?author=teiriko&author_mode=last_topics&do_search=1]:
 0ms
get settings:
 10ms
get forum list:
 15ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 154ms
get topic data:
 14ms
get forum data:
 3ms
get page messages:
 67ms
get tp. blocked users:
 2ms
others: 1109ms
total:  1407ms
созд. / загр.: 1407ms
x
x
Закрыть


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