электронный диск + сжатие СУБД

а как ты думаешь будут работать 32разряда с 10гигами оперативы(pae suxx)? :)

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

Не поддерживает ли firebird in memory-таблиц?

> Хочется сделать электронный диск (RAMDISK)

Теперь я верю, что ты начинал на Clipper в DOS. Причем это стопудово был Clipper'87, а не 5.0

> Лучше ли 32 или 64 разряда?

Только теплые ламповые 16 бит.

> база и так туда должна закешироваться
Не должна. Она на каждом commite сбрасывает дисковый кеш, и хотя можно это в какой-то степени ослабить настройками, всё равно невозможно гарантировать отсутствие обращений к диску.

> Не поддерживает ли firebird in memory-таблиц?
Насколько я знаю, моя версия - не поддерживает, но нужны не они, а именно всю базу положить на диск.

Тогда уточним вопрос:
мне нужна файловая система для linux, к-рая поддерживает сжатие файлов поблочно. Поскольку файл СУБД - пишется и читается поблочно, не "от начала до конца".

долго думал почему мне твоя идея не нравится. Вспомнил. Как ты думаешь с какой скоростью твоя база будет работать поверх сжатого устройства? Не только на запись но и на чтение.

а какую глобальную задачу ты решаешь?

Проверил под офтопиком. С помощью программы gavotte ramdisk создал диск на гиг, сжал его, забубенил на него базу. Стало быстрее в 2-3 раза, чем на RAID (опять же под оффтопиком), хотя сравнивать сложно, всё отличается, даже машины разные. Но меня практический результат, в общем-то радует. Потому что запросы чем дальше, тем сложнее и дольше работают.

Касаемо скорости - учитывая, что база сжимается раз в 6, а главный тормоз в ней - это HDD, то мне кажется, что будет работать быстрее, если сжатие сделано правильно. О том и вопрос.

Глобальная задача - складской учёт :)

Если база всего 10-12 гиг то вставь 16гиг и без сжатия.

Я думаю сжатие всё пожрёт т.к. это ресурсоёмкая задача. Лучше кэширование правильно настрой. Тем более что в линухе есть vm.dirty_background_ratio и vm.dirty_ratio которыми нюансы записи на диск можно подтюнить.

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

Кстати, на офтопике проверил влияние сжатия на скорость. Пример запроса, который интенсивно пишет в базу и не очень интенсивно читают из неё, работают на 3-5% медленнее при сжатии. Сжатие обычно происходит дольше, чем распаковка, поэтому можно ожидать, что сжатая база в целом работает быстрее - в основном запросы к базе обычно бывают на чтение.

Учитывая, что память в дефиците, очевидно, что имеет смысл сжимать базу в памяти, т.к. это освобождает память под другие задачи.

> Пример запроса, который интенсивно пишет в базу и не очень интенсивно читают из неё, работают на 3-5% медленнее при сжатии.

эм, что-то слабо верится. Что за алгортим сжатия и на сколько он грузит cpu?

> эм, что-то слабо верится. Что за алгортим сжатия и на сколько он грузит cpu?
ХЗ. Алгоритм по умолчанию для сжатых ФС в офтопике. Вообще, по моим наблюдениям, современные процессоры настолько быстры, что сжать файл - это быстрее, чем скопировать его на тот же диск. Хотя я не замерял.

Это если архиватор специально заточен под это(я видел такой, название забыл). Попробуй сжать dvd-болванку bzip2 и увидишь что это в общем случае не так. А диски щас до 100метров выжимают на линейном чтении/записи(к концу диска, конечно, скорость падает).

В общем, идея иметь очень быстрое блочное устройство неплохая, но без упса это очень ненадёжно.

Вот как раз UPS-то у меня имеется. Сегодня проводил ещё один эксперимент. Переиндексация файлов 1С в сжатых каталогах ускоряется на 20-30%. А вот электронный диск показал себя плохо и всё замедлилось (и непохоже, что дело в уменьшении дискового кеша). Либо криво написан, либо даже не знаю в чём дело.

> В общем, идея иметь очень быстрое блочное устройство неплохая, но без > упса это очень ненадёжно.
UPS есть.