Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / GUID-ключи хуже для распределенных БД, чем числовые / 25 сообщений из 28, страница 1 из 2
  1  все
23.05.2013, 22:18
    #38270953
Ares_ekb
Ares_ekb
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GUID-ключи хуже для распределенных БД, чем числовые
Здравствуйте!

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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



Dimitry, уровни изоляции тут ни при чём, вообще, в топике.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / GUID-ключи хуже для распределенных БД, чем числовые / 25 сообщений из 28, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 503ms
Закрыть
start [/forum/topic.php?fid=32&mobile=1&tid=1541165]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 158ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 59ms
get tp. blocked users:
 2ms
others: 236ms
total:  503ms
x
x
Закрыть


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