Всем привет.
Я тут немного порассуждаю вслух, а если начну гнать чушь ошибусь в чем, то бейте меня ногами поправьте меня :)

Дано: FB 2.5.3 Classic Win64. База 9Гб + 25Гб блобы в файловой системе (читаются - пишутся через UDF). В пике ~100 коннектов. Озу 24Гб, бд практически всегда в кэше ОС.

Небольшая преамбула.

Возникла необходимость к информационной системе привязать федеральную адресную базу ФИАС. База ФИАС в развернутом виде занимает ~10 Гб, что сравнимо с моей рабочей базой (РБ). Адресная база (АБ) полностью обновляется раз неделю (на самом деле есть и инкрементные обновления, но, как я не пробовал, получить полностью идентичные данные с помощью накатанных инкрементов не удалось. Трафика не жалко, считаем что обновляется полностью :))
Поскольку мне не нужны жесткие связи на уровне ФК, я решил хранить АБ в отдельной Readonly базе.

Плюсы этого решения:
- не распухает РБ. Время б/р остается на прежнем уровне;
- невозможно убить РБ в случае неудачного импорта (в какую-то неделю был архив с мусором в dbf-файлах);
- быстрый (~1 часа с учетом загрузки архива) и простой процесс создания АБ с помощью Emb-сервера и External таблиц (на рабочем сервере Ext таблицы, естественно, запрещены);
- МУСОР. Перезаливать 50% объёма данных раз в неделю - нет уж. И RECREATE TABLE тут тоже не спасает.
- Время несогласованности данных минимально (Shutdown старая АБ, MOVE новая АБ).

Минусы:
- необходим второй коннект из приложения или доступаться к АБ из РБ с помощью Execute on external (мой вариант). Запросы препарятся каждый заново (не смертельно);
- необходимо больше ресурсов сервера или доп. сервер;
- две базы -> в два раза больше шансов сломаться.

По параметрам АБ вроде все понятно:
- сразу после создания, до заливки данных ставим no reserve. Меньше ИО, меньше кэш ОС, больше данных влезет в кэш FB;
- после заливки ставим флаг Readonly. Не уверен, но по-моему, FB открывает такие файлы с флагом readonly, что быстрее чем без него (тут я плаваю, по-моему политика кэширования ОС как то меняется). Хуже точно не будет.
- FW - без разницы, пусть ради экзотики будет OFF;
- SWEEP INTERVAL - по привычке 0. Хотя тоже без разницы.

Остаются вопросы по размещению АБ и политике сохранения коннекта (при выполнении Execute on external c флагом WITH AUTONOMOUS TRANSACTION каждый запрос выполняется в своем коннекте, который рвется после окончания запроса; без этого флага, коннект остается висеть до коммита (а в моем случае до дисконекта РБ, поскольку я использую одну транзакцию RC+RO), но и следующие запросы будут использовать этот коннект).

Варианты:
- Повесить АБ на инстанс FB от РБ (а у меня напомню classic). Плохо. В случае сохранения коннекта - отжирается много ресурсов (количество процессов fb_inet_server удваевается, пусть я и оставлю мизерный кэш 75 страниц, но велики шансы выкинуть РБ из кэша ОС). В случае установки коннекта каждый раз, много накладных расходов (создать процесс, вычитать кэш метаданных и т. д.);
- Поднять Супер на другом порту. Уже лучше. С режимом сохранения коннектов, я думаю супер не потянет (100 коннектов на одно ядро). А с режимом короткого коннекта наверняка справится (поставить большой общий кэш и обеспечить с помощью isql чтобы один коннект был всегда. База всегда будет "разогрета");
- Поднять суперклассик. Не знаю. Не работал с ним. Видимо то же, что и классик.
- Старый добрый классик на резервный сервер. Хороший вариант, но... Смущает размазывание БД по нескольким серверам. Надежность системы падает в два раза. 10054 опять же.

Ваши советы? Хотя пока писал, я для себя уже почти все решил :)

Dimitry SibiryakovshiliaevС режимом сохранения коннектов, я думаю супер не потянет (100 коннектов на
одно ядро).
Что ему помешает?..


Все 100 потоков будут крутиться на одном ядре, за которое конкурируют еще процессы классика.

Хотя...
Реально трудится будет штук 5-10 одновременно, может и ничего.

ЗЫ: с супером не общался со времен FB1, там он переставал принимать новые подключения на 60-70 коннектах. Помню было шаманство с галкой "Разрешить взаимодействие с рабочим столом".
Сейчас, конечно, и железо другое и исправили наверное.
А может это только мой склероз :)

Симонов Денисshiliaev,

нормальный супер будет только в FB3. Вроде его к концу года обещают

Кстати да! Денис, хорошая идея.

Рисков то практически нет. Базу не сломает, а если и умудрится сломать - то и фиг с ней :).
Если ФБ упадет - то гвардеец (или что там вместо него сейчас) поднимет.
Единственный риск что тройка зависнет и повесит рабочий сервер.

Был бы я помоложе, поставил бы альфу тройки. :)

ТаблоидСимонов Дениспока ODS не стабилизировался (заморозился) опасно. Каждый новый снапшот может потребовать миграции через b/r1) в чём опасность, если база всё время может быть пересоздана ?
2) сомневаюсь, что ТС будет часто менять билды. Поставит и забудет.

Уговорили. Попробую на тестовой тачке погонять трешкин супер. Насчет продакшена буду сильно думать.

А embedded в снапшотах есть? Не могу найти.

hvladВ 3-ке нет отдельного embedded.
Просто распакуй снапшот, не запускай сервер и подключайся через fbclient.dll в каталоге снапшота.
Есс-но, используя локальный коннект.
О, Влад, вы стерли разницу между городом и деревней клиентом и embedded. Круто! Более не придется думать об реестре и прочих .ini, .cfg.
Я так понимаю, что локальный протокол изжит навсегда и и париться о локальном, неизвестно кем и когда установленном сервере более не надо? Спасибо вам за работу.

dimitrshiliaevЯ так понимаю, что локальный протокол изжит навсегда
это не так. Но по умолчанию он не используется.

Спасибо. Дмитрий.
Читаю Release Notes.