Есть проект на FB, все замечательно, НО очень сильно растет размер файла.
За прошедший год размер БД увеличился на 40ГБ, у меня при таком росте файла не хватит места, на планируемый срок.

Мои предположения роста файла, это поле поле VARCHAR(2000), но по требованиям к ПО такое поле должно быть, там хранится URL куда ходил пользователь.

Что можно выбрать, что бы у меня такие поля сжимались?


--------------------------------------------------------------
Изменить мир возможно, но не каждому это под силу

Dimitry SibiryakovLarsikЗа прошедший год размер БД увеличился на 40ГБ, у меня при таком росте файла не хватит
места, на планируемый срок.

Пойди в магазин и купи террабайтный винт. Хватит на 25 лет.


Ну если вы мне покажите, где можно купить 1Tb SCSI винт, то я прикуплю, и не один, а 10.
Да еще и обновление биоса для IBM ServerRAID 7 сделаете, Вам вообще не будет равных!

Dimitry Sibiryakov,

Спасибо большое!

Я наверное дебил, но все таки SAS отличается от SCSI 68-пинового. Да еще и RAID контроллер не поддерживает винты больше чем 160Gb.

Может хватит флудить, дайте свои предложения, более конкретные.

Мне нужно хранить статистику использования Internet'a за 5 лет. Требование СБ такое.
Все работает нормально, только места не хватает. Готов перененсти все на другую СУБД, где строки могут быть сжаты сильнее, чем в FB

Dimitry SibiryakovТак, может, позволишь этому динозавру наконец-то умереть?.. Или таки потрёшь порнуху... 10
винтов по 160 Гб в RAID 5 дают всё тот же террабайт.

Ну тут Вы не правы, железка великолепно справляется с задачами, поставленными ей. Винтов максимум в нее впихнуть можно только 6, а не 10. Да и порнухи нет, не судите людей по себе.

Dimitry SibiryakovИ, кстати, можешь искать пока не заржавеешь, но по компактности хранения данных Firebird
равных нет.


Не знаю, не видел, приведите тесты, сравнения с другой СУБД. Холивар устраивать не хочу и не буду, мне самому, очень нравится FB, но если есть система у которой данные более компактно хранятся это будет великолепно.


PS
Dimitry Sibiryakov

Не стоит думать, что Вы самый умный. Мы тоже все вокруг, не пальцем деланные, может я не такой спец, как Вы в FB, но в другом я смогу Вам нос утереть. Подумайте на досуге.

Dimitry Sibiryakov,

Я смотрю, не получается нормального диалога с Вами.
Dimitry Sibiryakovно давай поищем что-нибудь в чём Вы сможете утереть мне нос

В моем отношении к людям и моей воспитанности и адекватности. Я задал вопрос про СУБД, а не про сервера и жесткие диски, если мне нужен будет совет про железо, то я пойду на тематический форум.

vadiminfo,

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

Соответственно в таблице Jurnal есть FK на PK 3 других таблиц. Если Вы мне подскажите из за чего может расти, буду благодарен Вам.

hvladLarsikЕсть проект на FB, все замечательно, НО очень сильно растет размер файла.
За прошедший год размер БД увеличился на 40ГБ, у меня при таком росте файла не хватит места, на планируемый срок.На всякий случай спрошу - есть уверенность, что это не накопившийся мусор ?


Возможно, как его тогда почистить?

hvladLarsikМои предположения роста файла, это поле поле VARCHAR(2000), но по требованиям к ПО такое поле должно быть, там хранится URL куда ходил пользователь.На сколько, в среднем, заполнено это поле ? Firebird сжимает записи и не хранит декларированную длину поля - только содержимое (с небольшим оверхедом).


Я думаю в среднем около 60%, есть много Web-сервисов внутренних, а там url очень длинный.

hvladLarsikЧто можно выбрать, что бы у меня такие поля сжимались?Чудес не бывает. Можно выбрать одну из новомодных СУБД, хранящих данные поколоночно, но там будут другие проблемы.

Я знаю и работаю с FB и немного с ASA11 (но он платный), знал бы другие не спрашивал бы совета у сообщества.

hvladLarsikпропущено...
Возможно, как его тогда почистить?Как обычно - sweep'ом. Сделай gstat -r и покажи результат, можно в более правильном форуме, можно мне мылом.

Как долго будет идти эта операция?