|
Dimitry Sibiryakov
ASCRUS
Я все таки не очень понял - чем Вас не устраивает решение, предложенное
в ASA ?
Меня не устраивает это решение? Почему Вы так думаете? Я просто пытаюсь
определить тип магии, применённой там для генерации уникальных значений
в распределённой БД. Понятно, что используется некий "идентификатор БД",
но откуда он берётся и каким способом укладывается в обычный целый тип
пока неясно. Оппоненты настаивают, что всё делается автоматически, а это
подозрительно, поскольку даже bigint не резиновый, а выяснять при
создании БД уже использованные "идентификаторы БД" серверу мешает связь
через FTP или e-mail.
В БД есть опция Global_DataBase_ID. Для консолидированной БД Вы ее устанавливаете в 0. Распределенные БД нумеруете по очереди дальше (или подгатавливаете распределенную БД с консолидированной штатными средствами ASA, которые сразу присваивают ей очередной код БД, создают БД, переносят в нее обьекты БД и все данные, которые по условиям репликации будут в области видимости распределенной БД). Теперь примеры по проектированию. У Вас есть таблица, которая изменяется только в центре и односторонне реплицируется в распределенные БД. Если данных в ней не планируется более 4 млрд. записей, то Вы обьявляете в ней тип unsigned int, ставите DEFAULT AUTOINCFREMENT, прописываете ее в публикации (в ASA штатно можно выполнить команду на консолидированной БД и она уйдет по реплике и выполнится на всех распределенных БД, так что звонить и просить всем в БД писать таблицу в публикацию или писать дополнительный код для этого не придется). Все как обычно с инкрементами. Далее у Вас есть таблица, в которой в консолидированной БД в итоге может быть более 4 млрд записей, она будет участвовать в двусторонней репликации, где планируется, что в каждой распределенной БД свой интервал записей не превысит 1 млрд записей. Тогда Вы обьявляете в ней тип unsigned bigint, пишите DEFAULT GLOBAL AUTOINCREMENT (1000000000), так же включаете ее в реплику. Теперь у Вас записи, введенные в консолидированной БД в эту таблицу, начнут нумероваться с 1, для распределенной базы 1 начнут нумероваться с 1000000001 и так для каждой базы далее, поэтому при сливе записей в консолидированную БД наложений PK или UK не будет. Но что же делать, если все таки какая то распределенная БД достигнет предела своей нумерации ? ASA так же предлагает штатно решить эту проблему - пишите событие (EVENT) на внутренней системное событие RemainingValues, в котором или присваиваете новый код БД или отсылаете письмо администратору с уведомлением, если не хотите делать автоматом. Теперь вопрос - что будет для консолидированной БД, если распределенная БД изменит свой код и начнет генерить ключи в новом диапазоне ? Ответ - да ничего не будет, репликация будет продолжать работать, так как уникальность соблюдается, логика тоже будет работать, так как глобальные инкременты и код БД - это просто штатный функционал и на бизнес логику он никакого отношения не влияет. Логика распределения данных должна уже быть спроектирована самим архитектором БД - если БД на самом деле одна, просто есть удаленные или мобильные офисы, которые не могут с ней работать из за плохих или периодических каналов связи - то достаточно просто навесить на таблицы БД двустороннюю репликацию. Если в наличии удаленные подразделения (филиалы), значит будет справочник подразделений, в таблицах будет стоять поле КодПодразделения, в реплике на таблицы, данные которых имеют область видимости по подразделениям будет стоять определение области видимости в публикации по полю КодПодразделения, а для подписок распределенных БД указано значение КодПодразделения. Таким образом, если в распределенной БД вводится запись, она попадает в консолидированную БД, если в консолидированной БД добавить запись с кодом подразделения, на которую крутиться распределенная БД, то эта запись так же в итоге добавится в распределенную БД этого подразделения, но не появится в прочих распределенных БД, имеющих другой код подразделения. Все это позволяет строить многоуровневые схемы репликации, разбивая потоки реплицируемых данных по нужной логике, где можно запросто поднять консолидированную БД, на нее навесить 2 распределенных БД с разной областью видимости, на каждую из них навесить еще по 2 распределенных БД, у которых будет одинаковая область видимости и т.д. и т.п.
Все управление данным хозяйством реализовано штатным DDL и функциями (например для инкрементов и глобальных инкрементов есть функция, которая возвращает новое значение для указанной таблицы и является аналогом сиквенсеров). Сервер репликации так же управляется прямо из SQL. Для каждой из распределенной БД сервер репликации может использовать доставку из 3 способов передачи информации - файлами через зашаренный ресурс, email или ftp. Все это организуется автоматически и сервер репликации сам с лога БД считывает изменения, определяет куда они реплицируются, нарезает файлы с информацией, кладет их по нужному протоколу, забирает ответные файлы от второй стороны, и применяет их на БД. В случае ошибок (не хватает файлов, не сошлось CRC и т.д.), он тем же способом генерит запросы к второй стороне (просьба переслать повторно, необходима информация начиная с такого то места и т.д.).
P.S. Я лично из виденного считаю репликацию ASA лучшей в реализации, именно из за того, что она штатно и гармонично составляет единое целое с самим сервером, поэтому достигается такая легкость в проектировании, настройке и управлении ею. Any questions ?
|
