Как работает база данных Firebird, часть 3

[Siemargl]

Когда я 10 лет назад смотрел, как оно устроено в 3.0, запомнилось несколько моментов

1. хороший чистый код С++98

2. запутанная модель памяти сервера (супер классики итп)

3. GC-модель хранения данных

4. отсутствие отдельного лога, изменения пишутся прямо в файл базы, что прогнозируется в проблемы с онлайн бэкапом и хрупкостью самой базы.

5. простой и незатейливый оптимизатор запросов, и отсутствие CBO

   Собственно, я делал вывод, что ФБ хорошая для небольших систем, но где то дальше начнутся затыки, которые неустранимы принципиально.

   А все комьюнити утверждалось, что годится для задач любой сложности и объёма БД =)

Сейчас везде Ssd, будет конечно быстрее, но что будет с износом при GC-подходе при обязательном fsync?

Может что то изменилось в версиях 4 и 5, но по релнотам не заметил.

[sim_84]

1. Разный код был написан в разное время. В 3.0 местами используется фичи c++11. В 5-ке c++14/17. В 6.0 разрешено при написании кода использовать фичи c++20. Использование своих контейнеров вместо стандартных там по иным причинам, прежде всего для того чтобы использовать свой пул памяти.

2. Ну не такая уж она запутанная. Ты просто не въехал.

3. Она такая во всех СУБД с mvcc. Отдельный undo также требует очистки если что. А если не требует, а просто кольцевой буфер, то рано или поздно натыкаемся на проблему старого снапшота (Oracle).

4. Не то не другое оно не вызывает. Без redo лога есть всего две проблемы. Постоянный fsync м рпндомной записью, и не возможность делать физический hot stanby на основе этого лога. Начиная с 4.0 последний можно сделать с помощью встроенной логической репликации.

5. Оптимизатор в фб всегда был смешанный. Ты не поверишь но в других СУБД также. Ибо в некоторых случаях заведомо известно что дешевле. Но таки да сквозной оценки стоимости еще нет, но с каждым релизом доля стоимостной оценки повышается относительно доли на основе правил.