AWSVladimir,

AWSVladimirКакой сейчас самый большой рабочий размер базы у Firebird ?
7 терабайт. впрочем, сейчас, вероятнее всего уже 8.

p.s. странно слышать, что админ оракла что-то там вещает про размер (соотношение размер/производительность, или что вообще?)

Гаджимурадов Рустам Tables are limited to about 2,000,000,000 rows and, up to version 1.5.x, a maximum of about 30 Gigabytes per table.
это уже совсем устарело. И лимит был не 30 гиг, а 37 гиг.
А терабайтную базу я тестировал 9 лет назад.

Гаджимурадов РустамПо ссылке было сказано 11. Что в полтора раза больше уже тогда.
одно дело "тогда" такую базу "кто-то видел" или "кто-то про нее слышал".
А 7 терабайт я наблюдал воочию.

Про то, что "не к тебе" - разумеется, по статье вообще непонятно, когда писали и кто.
afgmЭто какая отрасль?
банк, транзакции. не микро, а какие-то совсем частые, забыл этот термин, торговые.

Гаджимурадов Рустам,

спасибо, оно - High Frequency Trading. У меня только "гипер трейдинг" (не трединг) на языке вертелся :-)

Siemarglкстати цитату майкрософтовцев где то пятилетней давности - "базы 1Тб уже не считаем большими".
На мой взгляд, у "больших" баз данных могут быть две проблемы -
1. внутренние идентификаторы (должны быть достаточными)
2. бэкапы.

Но если первая проблема архитектурная, и решается, то вторая проблема не решается без соответствующих технологий на уровне железа, и без технологий самого бэкапа.
Например, можно задать критерий, что если база бэкапится больше 12-ти часов, то она большая, и классический бэкап как средство резервирования уже не годится.

p.s. впрочем, у ФБ есть и радикальные способы увеличения производительности, например по записи - вырубить опцию сжатия записей. Не знаю как сейчас, но когда я это проверял еще на Yaffil, скорость записи возрастала в 2 раза, но и база тоже сильнее пухла. Но тут тогда возникает проблема опять же для больших баз - скорость х2 и объем ~х2. А стоимость объемов хранения пока что выше. Так что, надо выбирать.

Siemarglвот такое - хуже для больших баз 21445887
банальная проблема железа - хреново распараллеливается I/O. Или где-то что-то не включено, и т.д.
Я эту "проблему" про "поставили на новый сервер, а там всё тормозит" слышу регулярно. То кэш записи не включат, то драйвера контроллера старые, то еще какая золотуха.
Siemarglда просто надо использовать сильные стороны ФБ, а не пытаться сравниться
я и не пытаюсь сравниваться. Просто базы растут, и без изменения технологии и архитектуры за этим ростом успеть нельзя.
А если это к автору, то думаю, что и он сравнивать не пытался.
Пока что мы так и не услышали, о чем именно там был спор.
SiemarglФБ - отличная база для рабочих групп (Workgroup DBMS)
вот это дурацкое название убило нормальное отношение к InterBase, а впоследствии повлияло и на Firebird.
Workgroup - это типа человек 20-30. А не 600, с которыми ФБ вполне нормально работает.
Так что следите за произносимыми терминами. Хотел тут поставить смайлик, но даже улыбаться тут особо нечему.

Сейчас ни один нормальный производитель, какая бы мелкая его субд ни была, не охарактеризует ее как workgroup, потому что это автоматом поставит клеймо. А вот понятие Enterprise - в обратную сторону. 100 юзеров вполне себе Enterprise, разве нет?

к примеру
https://knowledgebase.progress.com/articles/Article/P133250
"The Progress Workgroup RDBMS offers many of the same powerful capabilities as the Enterprise RDBMS. It is optimized for workgroups of 2 to 50 concurrent users and provides..."

Ну что такое для ФБ 50 юзеров. Да вообще ничто, даже на не очень хорошем железе. Хорошая workgroup rdbms? Да. Но эта характеристика сразу дает лимит сверху в эти самые "50 users". А этого лимита ведь нет. И потом начинаются дурацкие споры "с админом оракла" на совершенно пустом месте.