Comments 28
Кто-то до сих пор использует это гумно?
О боже!
Спасибо
А вот тут начинается очень интересная политика, на самом деле. Сам кипер делает бэкапы, причём так часто что некоторые клиенты просто офигевают с объёмов бэкапов, а sql уже считается, по крайней мере в глазах дилера, обязанностью клиента. И опять же, не от красивой жизни вся эта чернуха происходит — редкий клиент выделяет больше 2-5% бюджета на айти структуру. Вот и получаются "решения побюджетнее".
А что исподьзуете Вы? Не зависимо от ответа, всегда найдется индивидум, который напишет комментарий в роде вашего: ОМГ, кто использует это…
На всевозможных форумах, посвящёных базам данных, регулярно возникают холивары по поводу выбора СУБД для проекта. И заканчиваются они всегда абсолютно ничем. Потому, что нет однознчного ответа.
Живи Firebird! :))
А позвольте узнать, что не так с fb? Раз вы так резко высказываетесь, возможно у вас есть список конкретных претензий?
У меня за момент интеграции pos-систем(2года, более 100 новых точек) всего раз приходилось ехать и "поднимать" кассу одной строкой фикса бд.
Может у вас есть более интересный опыт?
кроме этого у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения. без лога транзакций фб вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.
у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения.
Тогда от PostgreSQL вы вообще бежите как черт от ладана?
вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.
1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу, но пишут. Просто fsync делают только на log.
2) зато файербёрду не нужно прокручивать лог на старте в случае чего, не нужно иметь две сущности (датафайлы и лог). Если они смогли сделать так, что rps не сильно страдает, то чем же это плохо?
Конечно rps будет страдать. Но:
a) во многих охвученных применениях база локальна небольшому числу пользователей, а значит rps заведомо небольшой
б) некоторые озвученные применения подразумевают немаленький rps, а огнептах при этом справляется. Странно да?
Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?
Тогда от PostgreSQL вы вообще бежите как черт от ладана?
да. убер хорошо расписал как все хреново там где нет полноценного undo. собственно enterprisedb — основной вкладчик в постгрес, признает преимущество undo и уже года 3 пилит undo для постгрес
1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу
вот это не прям сразу дает на порядок большую производительность. потому что одно дело пару блоков в лог записать и освободить транзакцию, другое дело держать транзакцию пока каждый блок по всему диску не разложишь. и дело не в том что это транзакция дольше висит, а то что она 100500 соседних транзакций на более длительный срок задерживает.
б) некоторые озвученные применения подразумевают немаленький rps, а огнептах при этом справляется. Странно да?
пару лет назад Таблойд с sql.ru гонял тесты с 256 параллельными тредами. ФБ просто вставал колом. он отрепортил с десяток чудовищных проблем и наглядно показал, что такие нагрузки никто на ФБ не практикует
Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?
плохо то что транзакция остается активной, когда конкуренты с логом уже следующую могут обрабатывать.
Это конечно интересно… но что может побудить в 2019 выбрать именно эту бд для нового проекта? Чем она лучше более популярных? Я бы с удовольствием прочитал аргументы, а лучше статью) о том зачем вообще выбирать firebird.
Интересная статья, но страдает от распространенного явления — во многих местах говорится, что надо сделать, но не объясняется, почему и зачем.
Число VMA по умолчанию 64K, его необходимо увеличить в 4 раза
Зачем? На что это повлияет применительно к работе этой системы? А если в 2, а не в 4? А если в 8? А если БД не 600 гиг, а 100 или 1200?
Увеличили минимальный зарезервированный размер памяти для специальных процессов ОС
Опять же — а в каких случаях надо увеличивать? А если не увеличивать? А если еще больше увеличить? А от чего зависит, насколько увеличивать (косвенно указан только объем ОЗУ сервера безотносительно сценариев использования — неужели больше ничего не влияет?)
DefaultDbCachePages
Достаточно странный мотив для ограничения — а вдруг у нас там тестовая база… А если у нас все-таки нормальная контролируемая среда и база только боевая — тогда как?
FileSystemCacheThreshold
Тут вообще надо начинать с вопроса "а зачем нам этот файловый кэш на сервере БД нужен и нужен ли вообще, ибо если мы кэшируем сначала в ОС, а затем в кэше самой БД — зачем нам этот оверхед". И не упомянуто, что ежели всё-таки почему-то нужен, размер этого кэша тоже неплохо бы контролировать (при этом забавно, что в, судя по всему, вашей же презентации двухлетней давности про схожую БД тема раскрыта несколько более полно).
TempCacheLimit
Индивидуально для каждой системы — ОК, а как определить-то? Ну вот у кого-то другая структура БД, другие паттерны нагрузок и размеры, и что ему толку от ваших "20ГБ"?
LockMemSize и LockHashSlots
То же самое — конкретные цифры для вашей системы без всякого намека, как вычислить оптимум.
Для БД настроена репликация на резервный сервер (вопрос о репликации вне рамок этой статьи).
Было бы интересно почитать как это делается для Firebird
2) После переезда на 3 версию фаерберда в режим superserver, появилась странная особенность: если одновременно от сервера отваливается примерно 15-20 клиентов, например из-за обрыва связи, то firebird иногда почему-то перестаёт принимать новые подключения. Штатно как сервис перезапуститься не может, приходится убивать сам процесс.
3) сама инфоклиника, на мой взгляд какой-то чемодан без ручки.
— Ребят, а вы можете собрать sql-запрос, чтобы сосчитать количество оказанных услуг?
— Нет не можем, если услуги по профосмотрам, то они в одной таблице, а если платные, то в другой.
— Это как так?
— ну вот так…
— А вы можете посчитать себестоимость услуги по расходным материалам?
— ну если каждая услуга будет в отдельном приеме, то да. А если несколько услуг в одном, то будет непонятно, что к чему относится. И такая же фигня с оплатой, нельзя в одном приеме оплатить одну услугу полностью, а вторую полностью оставить в долг, только разделять на два приема…
— Ребят, а вы можете в таблицу добавить новый столбец, и вносить туда данные?
— нет, не можем.
— как так-то?
— ну там или столбец пропадёт после обновления, и в интерфейсе программы он все равно не появится.
— а если заказчику захочется учитывать какой-то новый параметр пациента или врача для лечения, ну например, совместимость врача и пациента по знаку зодиака, (реальный случай, кстати) то что делать?
— ну это будет скорее всего платная доработка со стороны СДС.
— шта?
— ну да, так и живем…
И тут выходит статья на хабре про инсталляцию инфоклиники на 1,5к пользователей. Даже и не знаю, как реагировать, пожалеть людей или порадоваться за них.
Но я соглашусь с ними, что лезть в схему, которая будет обновляться в рамках техподдержки приложения вендором, нелогично.
В таком случае, уровень этой разработки, как вы говорите «инхаус», а не для крупной ЛПУ, которой нужна уже полноценная ERP-система, в которой нужно добавлять произвольные справочники и классификаторы, в том числе цветов глаз и знаков зодиака, как бы это парадоксально не звучало.
Тюнинг Firebird и Linux для БД размером 691 Гб с 1000+ пользователей