Задавайте вопросы, мы ответим
Вы не зашли.
Заканчивается место на сервере, думаю применить сжатие, новые рапторы больше некуда воткнуть.
Я вижу 3 варианта:
1. Сжимать файловой системой
2. Сжимать базой
3. Сжимать данные в приложении и заносить их в базу уже сжатыми.
На мой взгляд второй вариант идеален, т.к. база знает структуру данных и может сжать их оптимально (т.е. только текстовые и бинарные поля типов text,blob varchar). В случае приложения - будет проблематично, если вдруг придется отказаться от сжатия. А в случае файловой системы, при выборке (переборе таблицы) будет происходить распаковка. А распаковывать и сжимать нужно непосредственно только данные. Это всё логика. А как на практике я не знаю.
Где-то давно читал, сейчас не могу найти, что по сути сжатие в базе данных ничем не отличается от сжатия файловой системы, упаковывается абсолютно всё, включая индексы, и при каждом селекте происходит их распаковка. Соответственно банальный просмотр всей базы со включенным сжатием вызовет такую же нагрузку, как если сжимать данные файловой системы. Тогда по скорости работы вроде как должен значительно выигрывать третий вариант. Возможно это было и не про innodb barracuda...
Так ли это, как вы считаете?
Отредактированно gif-t (06.09.2012 20:30:44)
Неактивен
InnoDB выполняет сжатие хитро, не так как FS-сжатие и отдельно для страниц данных и страниц индекса. Описание см. http://dev.mysql.com/doc/refman/5.5/en/ … rnals.html
На практике надо протестировать конкретно ваш случай
Неактивен
Я прочитал, но что-то не понял насчет сжатия индекса. В моем понимании в сжатом виде индексом воспользоваться нельзя, его нужно распаковать, разве не так? Как-то не логично. С другой стороны разработчики ведь не дураки, зачем-то это сделали
Неактивен
Индекс хранится не целиком, а по страницам. Разработчики придумали как сжимать олтдельные страницы так, чтобы число обращений к диску было минимальным.
Неактивен