Добрый день, уважаемые!
Тема больше похожа на пятничную, но и по делу кое-что есть. Я редко сюда пишу, накопилось.

Итак. Немного предыстории. Моя программа - обычная программа автоматизации работы АЗК (заправок и магазинов при них). Занимается управлением касс и других устройств; сохранением всех событий и данных; предоставлением различных отчетов по этим данным. Конечно, все данные мигрируют в центр (самописным репликатором). Работает, конечно, 24/7. На данный момент есть несколько клиентов (по ~100 заправок).

Разрабатывалась программа за 3 месяца (до 1-го запуска на заправке) в 2002(3) году с нуля тремя программерамми (в т.ч. и мной, сейчас (уже лет 6) остался я один) в отделе автоматизации одного из владельцев сети заправок (сейчас это один из клиентов).

Так вот. Тогда была выбрана база FB 1.0. При этом - никто ее особенностей не знал. Так, на ходу разбирались. И в принципе всё получилось.
Сначала базы были крохотными (функционала было бало и данных поэтому тоже - чеки только), и мы с нетерпением долго ждали, пока центральная база нашего предприятия достигнет 4гб (на тот момент было около 20 терминальных баз).
Но постепенно (12 лет как-никак, за которые мы стали отдельной IT-конторой с множеством клиентов) в системе появилось куча наворотов (разнообразные бонусные, талонные, карточные системы, пос-терминалы, привязка товароведческой 1С со всякими остатками, документами, заявками, партиями, ценообразованиями...), а всё это хранится в одной базе, и размер ее начал расти.

Был момент (год эдак 2006-2007), когда я считал себя гуру в Firebird. Программа на заправках работала сверхнадежно. Неделями не перезапускаясь, в центре все отчеты работали быстро. Базы падали раз в полгода, в 90% случаев они легко лечились, а для неизлечимых написал выгрузку из центральной на дату (благо потеря терминальных данных за пару часов (если инета долго не было) не столь критична - набивается с чековой ленты службой тех. поддержки за пол дня максимум). Всё было отлично.

Мне тогда казалось, что ФБ - супербаза - быстрая, маленькая, мощная, а главное - простая для разработчиков и админов.
Сейчас я считаю себя (практически) полным ламером в Firebird. Из предыдущих убеждений незыблемо верными остались только "маленькая" и "быстрая в настройке".

Надо отметить, что во времена ФБ 1.5 (когда я считал себя гуру) я писал ужасный говнокод. И не только я (в тот момент еще). Мы, например, использовали (в основном) несколько "вечных" глобальных транзакции nowait RC, делая только CommitRetaining (чтобы "не закрывались" гриды с данными, открытыми в той же транзакции). Это осталось после перехода на скорую руку с BDE на IBX. И тем не менее все работало прекрасно! Крайне редко кто-то ненавязчиво жаловался, что после перезапуска компьютера программа запускается несколько минут, но это было совершенно не критично и я даже не заморачивался.
Были случаи, когда с заправки не поступало ни единого звонка в техподдержку. Я знаю заправку, проработавшую на моей программе всю свою жизнь (я лично туда ее ставил с ФБ 1.5 где-то в 2006(7)) без единого звонка и до лета этого года, пока она не перестала существовать физически (это Луганск).

Со временем, конечно, когда данных в базе становилось все больше, появлялось больше несколько коннектов к базе и т.д. это переросло в серьезную пробему, как несложно догадаться. Ну и я просветился (частично с помощью этого форума, кажется) и поубирал такие вещи, и такие проблемы ушли. К тому времени как раз я перешел на ФБ 2.1.1. На нем до сих пор и сижу, т.к. упорно начал ждать ФБ 3, когда он был заявлен после 2.0.

За это время проект все развивался и развивался, и терминальные базы уже по 1-2 гиг (сравнимо с центральной на начальном этапе), а центральные базы клиентов - соответственно, по 100-200 гиг.

Я люблю Firebird. Я с ним много намучился (из-за своей безграмотности, но всё же), но так долго и много, как с ним, я не работал ни с одной БД (даже с dbf на клиппере на заре своей молодости на 1-й работе). Сталкивался с MS и ORA (в основном для сверок данных о продажах в моей базе и базах всяких бонусных/карточных систем), и хоть это и мелочи, Firebird всегда казался мне лучше и быстрее (ну летают в нем простые хорошие запросы, а монстры типа оракла всегда что-то думают, пока выведут результат SELECT * FROM DUAL (я полный ламер в Oracle, это больше эмоция, я это понимаю), да и всякие (+) в запросах писать мне не нравилось, не говоря уже о собаках в переменных в процедурах Sybase/MS и невозможности приджойнить оные )

Но есть нюансы.

1. За время ожидания 3.0 пришлось в центре для подпроекта "отчеты в OLAP" вести копию части базы (некоторых таблиц) в MS. Исключительно из-за производительности, т.к. без SMP для SS (общий кэш тоже очень нужен) скорость расчетов на ФБ была меньше в разы (в кол-во процессоров). В связи с этим 1-й вопрос к знающим людям: действительно ли тройка SS "по-настоящему" использует все (настроенные в конф) процы (выбирает наименее загруженный для потока клиента, я имею ввиду, конечно)?
1.1. И еще связанный вопросик: будет ли SELECT с UNION выполняться разными потоками?

2. Сборка мусора. Очень редко, но иногда сборка мусора в 2.1.1 затыкается (я имею ввиду кооперативную). Мне так кажется, впрочем я ламер, но думаю из-за этого следующая проблема: ~раз в полгода (на ~300 терминалах) проскакивает ошибка lock conflict primary key violation в процедуре, которая имеет слудующий код:


Т.е. исключение на инсерте, а значит DELETE прошло, а значит блокировки другой транзакцией не было. Со второго раза процедура выполнилась (оператор кнопку еще раз нажал). Но потом появляется снова, и не лечится до бэкап/ресторе базы. И, да, тормозить выполнение процедуры начинает заметно (секунды).
Почему я думаю проблема с мусором - т.к. эта процедура вызывается несколько тысяч раз в день, и за год без сборки мусора при UPDATE сами понимаете, что произойдет. Но проблем нигде нет (все летает, т.е. сборка работает везде), пока раз в ~пол года где-то не проявится.
Т.ч. 2-й вопрос к знатокам: надежнее ли станет работать кооперативная сборка мусора в тройке для SS? Это очень критично.
(тут сразу хочу уточнить - возможно это и из-за аппаратного сбоя, уж очень редко эта проблема появляется, но всё же)

3. Время от времени (~раз-два в месяц) на относительно больших центральных базах (в районе 100Г) портятся индексы. Вернее 1 и тот же - некрасивый индекс с одним ключем по полю CHAR(1), которое принимает значения только T или F. Некрасивый, но он нужен (из десятков миллионов записей, с значением F всегда только единицы или ни одной записи). Тут даже две проблемы. Во-первых пришлось написать план вручную (ФБ 2.1.1 реально не всегда сам этот индекс в плане использует, хотя он однозначно оптимален для запроса), ну это ладно, а главное - при запросе с нужным планом (фильтр по этому индексу) в результате отсутствуют некоторые записи (из-за порчи индекса, т.к. после пересоздания индекса результат запроса становится верным).
Итак, 3-й вопрос знатокам (2): 3.1. Станут ли в тройке (такие) индексы портиться реже? Думаю, эта ошибка, т.к. вряд ли это аппаратный сбой - сервер работает не перезапускаясь месяцами, ошибок никаких нигде не видно. 3.2. Есть ли для такого случая (индекс со статистикой 0.5) улучшения в оптимизаторе при выборе плана?

4. На закуску. Тут в меня можно тыкать пальцами (хотя я буду считать, что в принципе безосновательно). В базе много блобов. Доходит до 1/3 данных (если не чистить неактуальные данные). Зачем мне блобы? Так устроен мой репликатор - он хранит все пакеты миграции в базе (архивы файлов). И если на терминале "старые" пакеты не нужны (я их автоматом чищу почти все - за N последних дней оставляю), то в центральной базе они иногда нужны (по ним можно иногда восстановить всё, что испорчено кривыми руками, а так же установить точную последовательность многих действий).
В итоге, если не чистить "старые" пакеты, как я говорил, размер базы будет на треть больше, чем размер данных, но это ничего страшного, совсем не критично. Критично то, что в связи с большим количеством блобов (обычно размер - 5-50кб) сервер производит довольно много операций с файлом БД (по разным причинам). Я много читал о том, чтобы не использовать такое. Много думал, как бы убрать и эту "гениальную фичу" моей программы (как бы передалать), но так и не решился трогать пока. Пока есть возможность терпеть.
Так вот 4-й вопрос к знатокам: улучшилась ли реализация работы с большим количеством блобов в тройке?
(особо не надеюсь - подготавливаю себя к переделке репликатора, но всё же - а вдруг)

Да, забыл написать (не особо важно) - использую D6 и родной IBX 6.02 (с мелкими моими подпилами типа GUID вместо RandomString для имени курсора, несвоевременное обращение в FDatabase в TIBUpdateObject.Destroy, обработка SELECT FOR UPDATE WITH LOCK и еще какие-то - лень в лог смотреть, не важно). Тут все устраивает (пока и относительно) - переходить на новую делфу планирую не раньше поддержки оной Windows 10 - деньги платить каждый год за новую версию не вижу смысла (а пока Win10 не выйдет - Win7 будет жить), да и на юникод переводить проект раньше времени (пока петух не клюнул) не охота.

Всем большое спасибо уже за прочтение моих многабуков. Ну и огромное - за ответы (если таковые будут).
Да, релизнотес я читаю регулярно. Вопросы задал - для уточнения того, в чем я не уверен или не нашел там.

hvlad, Спасибо за ответы. И небольшие уточнения, если позволите.

hvlad1. SS использует все доступные CPU\Cores. Для конкретного потока CPU\Core выбирает OS
1.1 Нет
1. Принято
1.1. А вообще такое хотябы планируется? Существуют реальные промышленные задачи, где это нужно. Понятно, что можно заплатить денег, но неужели до меня никто не просил? :)

hvladВерсия 2.1.1 - это нет слов. Давно уже есть 2.1.7, если говорить о 2.1.х
После 2.1.1 было множество исправлений, в том числе для индексов.
Это вселяет оптимизм перед переходом на 3.0.
А на счет 2.1.1., почему я не переходил дальше - база работала и так достаточно надежно, а начиная с 2.1.3 (кажется) у "моей версии" IBX появились проблемы с созданием базы, которые я решил не решать, пока не выйдет 3.0 (думаю эта проблема будет уже не единственной, ну что ж).

hvladYuRock3.2. Есть ли для такого случая (индекс со статистикой 0.5) улучшения в оптимизаторе при выборе плана?Тут, думаю, dimitr скажет больше меня
Буду ждать и надеяться. Больше ничего не остается :)

hvladYuRockулучшилась ли реализация работы с большим количеством блобов в тройке?Опять же - я не понимаю в чём проблема и что не устраивает в 2.1.1
Из-за большого кол-ва блобов, размазанных по всей базе, думаю (хотя я ламер опять же), что работа с обычными данными идет медленнее. Мне так реально кажется - если после удаления этих моих блобов и чистки мусора (путем SELECT COUNT(*)) (это кстати супер тормозной процесс), все остальное начинает работать не в 1.3 раза (блобов в базе 1/3 от размера) быстрее, а в разы.
hvladВозможно, вынос таблицы блобов в другую БД и работа с ними через EXECUTE STATEMENT ON EXTERNAL что-то даст, я не знаю
Ну да, переделака, на которую я уже почти решился. Я над другой базой и думал (STATEMENT ON EXTERNAL впринципе даже не понадобится). В общем, попробую а тройке, как будет работать все, и если особо ничего не изменится - буду переделывать, хотя и считаю все решения кроме нынешнего менее удобными.

Ivan_Pisarevsky, спасибо за ответ.

Ivan_Pisarevskyиз индекса с селективностью 0,5 можно сделать 0,05 просто добавить разных записей...
Для "обмана" оптимизатора существует и более штатный механизм - ключевое слово PLAN . Зачем все эти вещи? Это всё и так понятно. Я ж не спрашиваю, как оптимизировать конкретный запрос. Я спрашиваю, будет ли в дальнейшем необходимость оптимизировать каждый такой подобный конкретный запрос.

Ivan_PisarevskyПочему такая упертость в плане архитектуры суперсервер?
Я же писал - общий кэш необходим. Клиентов не так, чтобы много, но они "частые и быстрые", и выполняют зачастую одни и те же операции. Зачастую - не простые (требующие рассчетов по агрегатным ф-циям по большому числу записей). И если не будет общего кэша - это приведет к огромной нагрузке на сервер, ведь почти каждый клиент (1С, веб, репликатор, моя филиальная прога,..) часто запустится, посмотрит сменный отчет за вчера, или остатки конкретного товара, или еще что-то - и закроется. А через 5 секунд - повтор. И без общего кэша в данном случае - никуда.

И это - только первая причина (уже достаточная). А вот еще одна причина. Множество клиентов коннектятся под SYSDBA, например репликатор, или я в IBExpert. Так сложилось, можете меня попинать. И это приводит к тому, что на операцию "Базу в даун" они не реагируют. И когда надо быстро и корректно остановить сервер, то это превращается в неразрешимую задачу, т.к. после "Базу в даун" все SYSDBA остаются висеть вместе со своими fb_inet_server, даже после остановки службы. И чтобы их реально отключить - надо снять эти процессы, что неминуемо регулярно приводит к краху базы. А вот в SS всегда достаточно остановить службу - и всегда все нормально.
На данном этаме разрамотки моей системы, эта причина невозможности использования CS - тоже достаточная.

dimitr, спасибо за ответ.

dimitrа практическое подтверждение данной теории есть? Ибо файловый кеш ОС никто не отменял.

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

dimitrэти артефакты давно отсутствуют в 2.5, не говоря уж о 3-ке
Какие именно? "Базу в даун" или крэш базы при снятии процессов fb_iten_server?

dimitrесли в общем, то изменений нет. Но некоторые нюансы были доработаны, так что планы могут поменяться.
Понятно, спасибо. Придется ставить и надеяться.

dimitr,

по поводу преимуществ кэша - конечно же я имел ввиду тройку, т.к. если все клиенты на 1 проце - какие ж тут преимущества.

Насчет "выгоняния" коннектов - понял, появились новые средства.

Спасибо за ответы.

sysdba22,

Какой мне смысл переходить сейчас на 25, тратить на это кучу времени, денег (ведь это в ущерб заказам), сил и нервов, если через пару месяцев я собираюсь начать переходить на 30?

Таблоид, спасибо.

Симонов Денис, спсибо. Конечно, я начну переход до релиза (я ж писал - начну готовиться ). Мне чтобы всё своё оттестировать - месяцы нужно потратить. Пока это сделаю - и релиз выйдет.