Xpoint
   [напомнить пароль]

Производительность репликации

Метки: [без меток]
2009-03-24 15:54:57 [обр] Thirteensmay(0/157)[досье]

Родилась alpha версия системы master-master репликации. Несколько затрудняюсь с оценкой производительности, а именно со сравнением полученного результата с аналогами. Хотелось бы услышать циферки типичной производительности такого рода систем, или конкретные, кто пользовал, у кого что получалось ?

О системе: кол-во серверов в принципе не ограничено, их организация в кластере - древовидная, структура БД - произвольная, описывается шаблоном, едина в пределах кластера, репликация любых нативных типов данных БД, в т.ч. LOB, не требует модификации существующих приложений, оставляет локальные в пределах сервера первичные и внешние ключи, обеспечивает их связанность в пределах кластера за счет отдельных GUID, сбор изменений - триггерный (триггера генерируются автоматически по описанию структуры), устойчива к обрывам связи и долговременному ее отсутствию (до нескольких дней), после чего восстанавливается автоматически, распространение изменений типа master-master, т.е. любое изменение любого сервера в общем случае распространяется на все остальные, настраивается, физическая целостность обеспечивается механизмом распространения изменений, логическая (например задвоение сущности операторами разных серверов) - не отслеживается, последовательность и время репликации серверов настраивается, пакет изменений с одного сервера на др. имеет простейший формат и может быть передан любым транспортом. И т.д., тут можно рассказывать долго, главное что я хочу сказать что система вполне себе не шел скрипт пересылки дампа.

Теперь собственно говоря что вылазит: т.к. структура в общем случае может быть произвольна, в плане производительности думаю есть смысл говорить о количестве полей реплицируемых в единицу времени между двумя серверами. Я тестил на int, varchar, и date полях, LOB конечно медленнее, но это отдельный разговор. На средненьком Pentium dual-core с обычным винтом получилось 400 тыс. полей в час, что равно 30 тыс. строк если в таблице 13 полей, тестил по 3 разным таблицам, в среднем так и получилось. Кол-во строк при моей архитектуре равно кол-ву изменений, т.к. они отслеживаются с точностью до строки. Одно изменение это одна строка затронутая командой INSERT, UPDATE или DELETE. Итак получается 30 тыс. изменений в час (процедура формирования пакета отрабатывает за 5 мин., применения - за час). Это если сервер больше ни чем не занимается. В реальности надо оставить минимум две трети свободного времени, т.е. получается 10 тыс. изменений в час. В пределах дня получается что один сервер может обработать около 100 тыс. изменений. Наиболее нагруженным является корневой сервер, в него все и уткнется, т.е. для средней паршивости машинок сколько бы их в кластере не было (кластер тут конечно не совсем уместное слово ;)), все равно больше 100К изменений в день кластер не переварит. Много ли это или мало ? В моих условиях означает среднюю конторку с одним центральным и парой - тройкой серверов филиалов. Честно говоря по началу это казалось более менее нормальным, ТЗ толком никто не ставил, теперь когда оказалось что оно таки может заработать, сложилось ощущение что мало ;)

Вопрос, это хоть сколь-нибудь подобающий уровень ? или совсем ниже плинтуса ? что и при каких условиях получалось у вас ? Я имею ввиду скорость (производительность) на обычных среднепаршивых машинках.

спустя 20 часов [обр] GRAy(3/259)[досье]
Thirteensmay[досье] База данных надо полагать Oracle?
спустя 1 час 58 минут [обр] Thirteensmay(0/157)[досье]

GRAy[досье] Ну да ;) XE.

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

Можно сформулировать вопрос иначе, какой уровень производительности вы считаете приемлемым и технически обоснованным для систем подобного рода ? Напомню при этом, что репликация master-master, на обычных десктопных недорогих машинках, структура базы - резиновая, при ее изменении достаточно подправить лишь описание, не требует модификации существующих приложений, т.е. все правки только в базе и сводятся только к добавлению в реплицируемые таблицы одного GUID поля, механизм автоматически преобразовывает локальные ключи одного сервера в локальные другого, для отдельного сервера все прозрачно, устойчивость к обрывам связи, причем не за счет всяких там флагов примененности, переданности и т.п., (они тоже могут недойти, оборваться), а за счет скажем так избыточности хранилища, что ведет конечно к увеличению объема, но и надежность при этом можно выделить.

Вообще в упор не могу найти людей знакомых с master-master репликацией, уже и знакомых из вполне себе разветвленных госструктур достал, казалось бы должны быть в курсе, ан нет, у всех в лучшем случае master-slave.

спустя 21 час [обр] GRAy(3/259)[досье]
Oracle Streams видели, читали? Очень неплохая вещь для организации репликации, в XE правда возможен только Apply process (т.е. грубо говоря только приём данных) а Capture process сделать нельзя (видимо потому что XE не поддерживает режим Archive log - ведь Capture process не полагается на триггеры, он работает непосредственно с redo log`ом).
Что касается вашей системы ;) вы и сами понимаете что приемлемость производительности определятся потребностями системы база данных которой реплицируется вашим механизмом, для каких-то этого будет достаточно, а для каких-то нет - дело не только в масштабе (количестве нод и объёмах бд).
Организовать действительно прозрачную (и быструю :)) для произвольного приложения master-master репликацию практически невозможно - всегда вылезет какая-нибудь ерунда. Всегда нужно будет что-то подгонять под конкретные условия - либо ваш механизм, либо приложение и далеко не всегда это удастся сделать по разным причинам.
спустя 2 часа 31 минуту [обр] Thirteensmay(0/157)[досье]

Угу, Oracle Streams не в курсе, но собственно получается что он мне и не поможет, кроме того что ХЕ, я в общем то сразу определился что совсем уж уникальные Oracle штуки пользовать не буду, понятно что конкретный код если что придется переписать, другое дело общие идеи и схема механизма будет отработана и останется.

Что касается Вашего Организовать действительно прозрачную (и быструю :)) для произвольного приложения master-master репликацию практически невозможно - всегда вылезет какая-нибудь ерунда. - это точно. Я в своем случае сделал упор на прозрачность, обобщенность и надежность, уж признаться прельщает меня сильно тот факт что приложение можно не трогать и при изменении структуры БД практически не надо ничего переделывать. Отсюда и вылезла ерунда, в первую очередь с необходимостью трансляции ключей, и вообще получается что т.к. система не привязана жестко к приложению, в перспективе могут вылезти всякие тонкие моменты связанные с особенностью его работы.

По поводу производительности, по ходу выяснилось что есть заметный задел в плане оптимизации алгоритмов, ну не в десятки раз конечно, но раза в 2 - 3 думаю можно будет подтянуть, к тому же мне диспетчер задач помог вспомнить что XE утилизирует только одно ядро максимум, если поставить полноценный сервер уже будет лучше, еще лучше наверное если процессор будет какой нить Xeon, и винты в RAID можно ставить, а в идеале вообще SSD, короче получается что при желании, после оптимизации, на соответствующем ПО и железе можно будет варить не 100К а вплоть до миллиона изменений в день, что уже помоему более-менее. Самая большая текущая задача - репликация СКУД завода между удаленными зданиями, 15К чел, 150К изменений в день, причем сервера реальной работой заняты не более 6 часов в день, остальное можно под репликацию, получается решается, мелкие заказчики понятное дело само собой, остается вопрос перспективы, ну хай если че ставят мэйнфреймы ;) Вообще сложилось у меня впечатление что нормальный уровень производительности для такой задачи и условий, это 100К изменений между 2 серверами за 30 мин., а не за 4 часа как у меня сейчас, в принципе всячин там много, может и можно вытянуть, буду смотреть...

спустя 4 часа 5 минут [обр] GRAy(3/259)[досье]
Thirteensmay[досье] Как только вы ставите не XE - Streams вам в помощь. Там конечно не обойтись без доводки напильником (ну а где по-другому?), но главное его преимущество: работа напрямую с redo логами и использование Advanced queuing как транспорта, отсюда скорость.
Powered by POEM™ Engine Copyright © 2002-2005