Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"A K" wrote ... Добрый день! Возможность выполнять EXECUTE STATEMENT на другой базе позволяет легко реализовать надежную схему односторонней онлайн репликации. Но, вся засада в том, что коннект к базе открывается каждый раз при выполнении оператора. Мы собрали у себя тестовый пример. Изменения без репликации проходят на базе за 20 сек. А те же изменения, но с их репликацией на другую базу в триггерах уже за 4 мин 22 сек. Т.е. замедление в 13 раз. Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту тр-ции. Накапливать изменения можно в GTT. Если же полная синхронность не требуется, то можно выталкивать изменения ещё реже. Базы идентичны по структуре. Лежат на одном и том же сервере. Используется суперсервер. Какой протокол для внешнего коннекта используется ? Для локального сервера лучше всего локальный протокол. Такое предложение: чтобы можно было открыть из одной БД (например, внутри триггера на подключение к базе) коннект к другой базе и затем использовать его для выполнения операций EXECUTE STATEMENT. Внешние соединения кешироваться будут, но точно не в 2.5.1 -- Хорсун Влад
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту тр-ции. А что это изменит? Все равно каждый EXECUTE STATEMENT будет открывать-закрывать подключение к БД. Только что "подвисать" будет не каждая операция, а комит транзакции.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 01.07.2011 19:47, A K wrote: Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту тр-ции. А что это изменит? Все равно каждый EXECUTE STATEMENT будет открывать-закрывать подключение к БД. Только что "подвисать" будет не каждая операция, а комит транзакции. Транзакций существенно меньше чем CRUD операций как правило. Собственно именно так и нужно делать - применять изменения в удаленную БД на коммите транзакции. Потому что при откате транзакции изменения в другую базу не попадут, что как правило и нужно. В любом случае без журнала транзакций, в который пишутся изменения, не обойтись. Требуемые триггеры для записи в журнал транзакции пишутся автогенерацией через тот же EXECUTE STATEMENT на основе данных системных таблиц. Как пример можно посмотреть этот проект http://fibre.sourceforge.net/. Там более сложный вариант реализован - инкрементальной оффлайн репликации на базе журнала транзаций.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Транзакций существенно меньше чем CRUD операций как правило. я понимаю, что в общем случае их будет меньше. Но, например, накопил я в логе десять изменений в разных таблицах. Идет комит транзакции. Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней базе, причем каждый EXECUTE STATEMENT будет открывать-закрывать коннект. так?
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"A K" ... > Транзакций существенно меньше чем CRUD операций как правило. я понимаю, что в общем случае их будет меньше. Но, например, накопил я в логе десять изменений в разных таблицах. Идет комит транзакции. Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней базе, причем каждый EXECUTE STATEMENT будет открывать-закрывать коннект. так? Если они все будут использовать COMMON тр-цию (не вижу смысла тут делать автономную), то и коннект будет использован один и тот же. Триггер на коммит, а не на отдельные операции, позволит повторно использовать препарированный запрос в том случае, когда есть несколько изменений в одной и той же таблице. -- Хорсун Влад
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
А по моему лучше в триггерах накапливать изменения, а репликацию делать в отдельном потоке.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 01.07.2011 23:55, A K wrote: Транзакций существенно меньше чем CRUD операций как правило. я понимаю, что в общем случае их будет меньше. Но, например, накопил я в логе десять изменений в разных таблицах. Идет комит транзакции. Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней базе, причем каждый EXECUTE STATEMENT будет открывать-закрывать коннект. так? Можно и в одном соединении это делать. Но реальная причина в другом - в другую(-ие) БД должны попадать только те изменения, которые подтверждены в данной БД. В противном случае при любом откате транзакции базы начнут разбегаться. В отличии от того же MS SQL в Firebird одно удовольствие лог транзакций вести, не полагаясь на всякие там часы и т.п. Причем если текущая транзакция отвалится, то из записей в журнале не будет (а можно использовать и временные таблицы). Да и такую модель можно развить в асинхронную оффлайн репликацию если понадобиться. А вот с синхронной репликацией на уровне триггеров есть реальный шанс получить большие проблемы (по моему скромному мнению это путь в никуда). Т.к. стабильные соединения бывают только в "сферическом вакууме". И порой достаточно одного сбоя на миллион операций, чтобы случилась "непоправимая" разбежка и лавинообразное возрастание количества ошибок.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
А вот с синхронной репликацией на уровне триггеров есть реальный шанс получить большие проблемы (по моему скромному мнению это путь в никуда). Реальная ситуация. Большая база на большом предприятии. Работает медленно. Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. Изменения в оперативной БД, должны попадать на архивную. Синхронная репликация триггерами тут сгодилась бы как нигде. Сейчас все упирается в скорость, которая упирается в невозможность держать открытым соединение из одной БД в другую на уровне сервера.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"A K" ... Реальная ситуация. Большая база на большом предприятии. Работает медленно. Что именно "медленно" ? Запросы или обслуживание ? Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. И с чего бы оно стало быстрее ? Кривые запросы, читающие кучу не нужной информации ? -- Хорсун Влад PS Данные в архив обычно сбрасывают раз в день\неделю\месяц...
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
A K пишет: А вот с синхронной репликацией на уровне триггеров есть реальный шанс получить большие проблемы (по моему скромному мнению это путь в никуда). Реальная ситуация. Большая база на большом предприятии. Работает медленно. Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. Изменения в оперативной БД, должны попадать на архивную. Синхронная репликация триггерами тут сгодилась бы как нигде. Сейчас все упирается в скорость, которая упирается в невозможность держать открытым соединение из одной БД в другую на уровне сервера. Только не надо такую базу называть "архивной". А то волосы дыбом встают от "синхронной репликации триггерами в архивную БД". В качестве конструктива предлагаю подумать над архивированием в отдельную БД только устаревших данных из наиболее быстрорастущих таблиц. При этом архив должен только пополняться, но не редактироваться. Те запросы (предположительно, редкие), которым нужен доступ к обеим частям БД, можно переписать, например, с использованием процедур, где анализировать, действительно ли затребованы архивированные данные. В архив данные сбрасывать раз в месяц/квартал/полгода/год - на выбор.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 04.07.2011 19:48, A K wrote: Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. Изменения в оперативной БД, должны попадать на архивную. Возьмите/купите одну из готовых систем репликации под Firebird - будет дешевле и быстрее, чем изобретать велосипед. Может вполне хватит следующих действий и при существующей структуре: * Более производительное оборудование специально выделенное под работу СУБД - быстрый дисковый массив, много оперативной памяти, 64битный Firebird; * Изучение узких мест - вполне возможно будет достаточным построить пару-тройки дополнительных индексов, оптимизировать ряд SQL запросов, особенно если речь идет об отчетах; * Более частое архиврование БД; * Периодическое обслуживание БД - с проверкой структуры, сборкой мусора, проверка отсутствия множества активных транзакций, бэкап БД с последующим восстановлением и т.п.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
A K wrote: Реальная ситуация. Большая база на большом предприятии. Работает медленно. Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. Это ничего почти не даст. Если запросы используют только данные за последнее время, то размер таблиц фактически не влияет за исключением медленного логарифмического роста. Если же запросы кривые, то да - ускорение будет.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
в первую очередь обслуживание. бэкап-восстановление 5-7 часов. для предприятия с почти непрерывным циклом это неприятно. хорошо что есть окно в воскр. On 04.07.2011 17:40, Vlad Khorsun wrote: "A K" ... Реальная ситуация. Большая база на большом предприятии. Работает медленно. Что именно "медленно" ? Запросы или обслуживание ? Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. И с чего бы оно стало быстрее ? Кривые запросы, читающие кучу не нужной информации ? -- Хорсун Влад PS Данные в архив обычно сбрасывают раз в день\неделю\месяц...
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Может вполне хватит следующих действий и при существующей структуре: * Более производительное оборудование специально выделенное под работу СУБД - быстрый дисковый массив, много оперативной памяти, 64битный Firebird; если бы мы писали на оракле или на 1С, тогда да, стандартный подход придти к клиенту и сказать: единственное решение ваших проблем -- это апгрейд или полная замена железа :) а так, имеем таких клиентов, которые элементарно жмутся на технике и тяжко им что-то втолковать.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
а так, имеем таких клиентов, которые элементарно жмутся на технике и тяжко им что-то втолковать. Значит остальное попробовать. Был случай когда добавление двух индексов уменьшило время выполнения операции с 30 минут до 20 секунд. Наличие долгих снэпшот транзакций может сильно нагружать сервер и диски. Помогало увеличение оперативной памяти сервера. Увеличить память используемую под кеш страниц. Может вообще отказаться от классического сервера и использовать суперсервер, если так мало памяти. И т.п.
RE: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
В итоге все равно будет перегрузка по производительности. Решение с архивом верное. Теперь когда проектирую новые системы сразу предусматриваю архивирование. Хотя есть еще вариант, например копим данные за 10 лет потом начинаем стирать, тем самым получаем более менее постоянный объем базы, без бесконечного роста. Перед операцией стирания делаем копию базы, на случай если кому то очень захочется порыться в древностях. А вот встроить архивирование в уже работающую систему с сотнями таблиц и тысячами процедур у нас не получилось - по трудоемкости не реaльно, проще все переписать. -Original Message- From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On Behalf Of Евгений Виноградный Sent: Tuesday, July 05, 2011 9:37 PM To: ru-firebird@googlegroups.com Subject: Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта > а так, имеем таких клиентов, которые элементарно жмутся на технике и > тяжко им что-то втолковать. > Значит остальное попробовать. Был случай когда добавление двух индексов уменьшило время выполнения операции с 30 минут до 20 секунд. Наличие долгих снэпшот транзакций может сильно нагружать сервер и диски. Помогало увеличение оперативной памяти сервера. Увеличить память используемую под кеш страниц. Может вообще отказаться от классического сервера и использовать суперсервер, если так мало памяти. И т.п.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 05.07.2011 22:00, Михаил Викторович wrote: > В итоге все равно будет перегрузка по производительности. Решение с архивом > верное. Теперь когда проектирую новые системы сразу предусматриваю > архивирование. Тем не менее для более дельных рекомендаций по данному случаю мало информации: * Версия Firebird, тип и параметры. * Аппартаные ресурсы; * Продукт тиражируемый или заказной; * И т.п. P.S. И в результате настоятельно советовал бы не использовать синхронное обновление БД в триггерах на IUD операциях. Ну не будет это нормально работать на реальной системе в виду наличия концептуальной проблемы такого решения. А если еще учесть особенности/огрехи в проектировании БД...
RE: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
>Тем не менее для более дельных рекомендаций ... А зачем мне Ваши рекомендации? Разве их я спрашивал? Я написал свое мнение о том, что человек прав, придя к идее архива. На счет реализации на триггерах и использования передачи в другую базу возможно вам видней, такой вариант пока не использовал и не тестировал. В одном из проектов мы использовали архивные таблицы в той же базе. Конечно время бакапа растет, но пока приемлемо. Реализовали исключительно из-за возрастающего времени при сохранении документов.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Михаил Викторович wrote: Я написал свое мнение о том, что человек прав, придя к идее архива. Это плохая идея. Если уж делать ахрив, то создавая копию базы на на какой то момент времени. В одном из проектов мы использовали архивные таблицы в той же базе. Конечно время бакапа растет, но пока приемлемо. Реализовали исключительно из-за возрастающего времени при сохранении документов. Т.е. анализ планов запросов ниасилили? На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает сливание битовых карт индексов на сверхбольшых таблицах, но это излечимо ручным тюнингом.
RE: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
>Т.е. анализ планов запросов ниасилили? Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас столь исключительную своей оригинальностью мысль. :) >На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает >сливание битовых карт индексов на сверхбольшых таблицах, но это излечимо >ручным тюнингом. Неоднократная вставка в таблицы за 20 млн не быстра... Без системы продуманного архивирования нормальная система работать не будет. В одном из проектов обрабатывается в месяц 400-600тыс документов (скажем так - накладных хотя это не совсем точно). Понимаю что это не очень то и много, но факты говорят о необходимости архива, после десяти лет эксплуатации.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Михаил Викторович wrote: Т.е. анализ планов запросов ниасилили? Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас столь исключительную своей оригинальностью мысль. :) Тогда хотелось бы услышать о выявленных узких местах в вашей ситуации. На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает сливание битовых карт индексов на сверхбольшых таблицах, но это излечимо ручным тюнингом. Неоднократная вставка в таблицы за 20 млн не быстра... Что именно за вставка? Простые инсерты сильно не могут тормозить в принципе каких бы размеров таблица не была. Кстати вот: http://ibase.ru/devinfo/fb1tbtech.htm Без системы продуманного архивирования нормальная система работать не будет. Почему? Делай во всех селектах за последний месяц например ограничение.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 06.07.2011 1:39, Михаил Викторович wrote: Тем не менее для более дельных рекомендаций ... А зачем мне Ваши рекомендации? Разве их я спрашивал? Я написал свое мнение о том, что человек прав, придя к идее архива. Вы написали ответ на мой пост. Так что ничего личного. Ответил в той же ветке.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Михаил Викторович wrote: Кто же их упомнит. Несколько десятков определенных вручную планов. Ручные ещё не значит хорошие. Вставка как вставка обычная где то в три-четыре таблицы, что про нее еще можно сказать я не знаю. Индексов штук 8-10 в каждой таблице. При активной работе 400-650 человек имеем тормоз на занесении новых документов в систему. Повышение производительности сервера естественно тоже используем, но компания растет быстрее чем производительность серверов. Так тут дело не во вставке а в общем торможении сервера (ЦПУ, винт, память) при большой нагрузке. Если это суперсервер, то естественно большое количество кривых селектов будет тормозить параллельные инсерты. Но это в кузницу... Все банальные решения давно используются. И это никак не влияет на вставку. Может просто о разных системах и масштабах говорим? Ну сколько документов в секунду вставляется? Люди не могут их создавать с бесконечной скоростью.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"Михаил Викторович" ... Тест интересный, но я в нем не нашел теста на вставку большие таблицы когда уже седаны индексы, падение будет существенным, Прям предсказатель :-D по хорошему тоже надо бы протестировать, будет время займусь. Мой опыт говорит о том что убирая не нужные индексы можно получить значительную прибавку в скорости на вставке. Да. Но это не связано с размером таблицы. Можно и на маленькой таблице получить большие тормоза при вставке - просто создав десятки индексов с длинными ключами. -- Хорсун Влад PS Размер файла БД может влиять на среднее время случайного доступа к разным его страницам. Но это должно компенсироваться кешем контроллера диска.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Vlad Khorsun wrote: Да. Но это не связано с размером таблицы. Можно и на маленькой таблице получить большие тормоза при вставке - просто создав десятки индексов с длинными ключами. Вопрос то в рависимости от размера таблицы. Ведь она в любом случае должна быть логарифмической. PS Размер файла БД может влиять на среднее время случайного доступа к разным его страницам. Сейчас прибегут сторонники кластерных индексов... Но это должно компенсироваться кешем контроллера диска. Не должно, т.к. кэш это когда что то делается повторно регулярно. Лучше наращивать память сервера.
RE: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
>Так тут дело не во вставке а в общем торможении сервера (ЦПУ, винт, >память) при большой нагрузке. Это верно. >Если это суперсервер, то естественно большое количество кривых селектов O да Вы оказывается экстрасенс.
RE: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
>Прям предсказатель :-D А то :) Подскажите в IB была такая фигня, если в индексе низкая селективность, то вставка начинала очень сильно тормозить, получалось что при вставке IB просматривает все одинаковые значения ключа и только потом делает вставку в конце, для борьбы с этим делали составные ключи добавляя в них первичный ключ (код). За FB подобного не замечал. Подскажите в FB на уровне базы это решено?
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
06.07.2011 18:59, Михаил Викторович пишет: Подскажите в IB была такая фигня, если в индексе низкая селективность, то вставка начинала очень сильно тормозить, получалось что при вставке IB просматривает все одинаковые значения ключа и только потом делает вставку в конце, для борьбы с этим делали составные ключи добавляя в них первичный ключ (код). Ты вставку с удалением (сборкой мусора) часом не путаешь? -- Дмитрий Еманов
RE: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
>> Подскажите в IB была такая фигня, если в индексе низкая селективность, то >> вставка начинала очень сильно тормозить, получалось что при вставке IB >> просматривает все одинаковые значения ключа и только потом делает вставку в >> конце, для борьбы с этим делали составные ключи добавляя в них первичный >> ключ (код). >Ты вставку с удалением (сборкой мусора) часом не путаешь? Нет. Можно задать вопрос по другому. Опишу ситуацию есть таблица из 1 записей в ней есть индекс по полю у которого всего два значения(приход/расход). В IB было замечания что одинаковые значения ключа сортируются в порядке вставки в базу для этого IB их последовательно (IMHO) просматривал что приводило к большим тормозам. Вопрос как FB определяет точно место вставки ключа в индекс с большим количеством одинаковых значений?
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
06.07.2011 19:43, Михаил Викторович пишет: Можно задать вопрос по другому. Опишу ситуацию есть таблица из 1 записей в ней есть индекс по полю у которого всего два значения(приход/расход). В IB было замечания что одинаковые значения ключа сортируются в порядке вставки в базу для этого IB их последовательно (IMHO) просматривал что приводило к большим тормозам. О каком именно ИБ речь? Вопрос как FB определяет точно место вставки ключа в индекс с большим количеством одинаковых значений? В ОДС10 и ранее - в начало цепочки дубликатов, в ОДС11 - в соответствии с номером записи (в случае массового инсерта - в конец цепочки). Но это не значит, что просматривается вся цепочка. -- Дмитрий Еманов
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"Михаил Викторович" wrote ... Подскажите в IB была такая фигня, если в индексе низкая селективность, то вставка начинала очень сильно тормозить, получалось что при вставке IB просматривает все одинаковые значения ключа и только потом делает вставку в конце, для борьбы с этим делали составные ключи добавляя в них первичный ключ (код). За FB подобного не замечал. Подскажите в FB на уровне базы это решено? Как уже сказал DY, при вставке никаких тормозов не было. Правда я не могу знать за IB5 и ниже, но не думаю что там было такое. Тормоза были при удалении ключей из низкоселективных индексов и эта проблема полностью решена в ODS11, введённой в FB2.0. Могу только предположить, что тормоза были при апдейте, который собирал мусор после предыдущего апдейта и, соответственно, удалял старые ключи из индекса. -- Хорсун Влад
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
Hello, Михаил Викторович! Михаил Викторович wrote: При активной работе 400-650 человек имеем тормоз на занесении новых документов в систему. Повышение производительности сервера естественно тоже используем, но компания растет быстрее чем производительность серверов. гм. извините, не узнаю вас в гриме. можете к нам на support отписать, что за система? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"Khorsun Vlad" сообщил/сообщила в новостях следующее: news:iuklug$bcf$1...@dough.gmane.org... Внешние соединения кешироваться будут, но точно не в 2.5.1 В 3.0 будут? Этот вопрос для меня очень животрепещущ.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"Voroshin Dmitry" wrote ... "Khorsun Vlad" сообщил/сообщила в новостях ... Внешние соединения кешироваться будут, но точно не в 2.5.1 В 3.0 будут? Этот вопрос для меня очень животрепещущ. Это есть в todo, но не с самым высоким приоритетом. -- Хорсун Влад
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
"Vlad Khorsun" сообщил/сообщила в новостях следующее: news:ivmbdn$ktc$1...@dough.gmane.org... "Voroshin Dmitry" wrote ... "Khorsun Vlad" сообщил/сообщила в новостях ... Внешние соединения кешироваться будут, но точно не в 2.5.1 В 3.0 будут? Этот вопрос для меня очень животрепещущ. Это есть в todo, но не с самым высоким приоритетом. Грустно это. Спасибо. Придётся тогда отказаться от ES и что-то другое придумать.
