Сжатие столбцов (MariaDB 10.3.3>)

12
LEOnidUKG
На сайте с 25.11.2006
Online
1587
479

Обнаружил такую приятную функцию как сжатие столбцов:

https://mariadb.com/kb/en/library/storage-engine-independent-column-compression/

Под сжатие можно пустить:

TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT, VARCHAR, VARBINARY

Индексные столбцы нельзя, но это и не нужно.

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

Я уже загнал на пары новостных сайтов, все столбцы с новостями и анонсами. Уменьшение примерно в 2-а раза.

Меньше место на диске, быстрее делается бэкап, быстрее считываются данные. Все настройка по умолчанию, они меня устраивают.

Доступ к этим столбцам точно такой же, никаких проблем экспорт/импорт. Всё делается прозрачно.

Чтобы сжать существующие столбцы достаточно выполнить:

alter table `tablename` modify `col1` text compressed;

Для нескольких:

alter table `tablename` modify `col1` text compressed,modify `col2` text compressed;

Если столбцов много и таблица большая, то лучше делать сразу для всех. Иначе будет копирование полностью таблицы для каждой команды. А если таблица более 1 ГБ это уже не быстро, особенно на HDD.

✅ Трастовых площадок под размещение статей и ссылок. Опыт 12 лет! ( https://searchengines.guru/ru/forum/675690 ) ⭐ Купить вечные трастовые ссылки для сайта ( https://getmanylinks.ru/?srh ) ⭐ Ускорение ваших сайтов (WP, Opencart и др.) + Настройка сервера ( https://searchengines.guru/ru/forum/997205 )
edogs software
На сайте с 15.12.2005
Offline
739
#1

LEOnidUKG,

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

Невозможность индексов вкупе с нагрузкой на проц при поиске по всей таблице обессмысливает затею.

Если делать по правильному, то все поля которые компрессируешь - нужно выносить в отдельную таблицу, если они на фиг не нужны для работы с ними - фигли они место занимают там? Размер оставшейся рабочей таблицы уменьшится так, как не уменьшится даже при компрессии, при этом бонусом останется возможность индексации.

С трудом себе представляем сценарий когда при правильной архитектуре это может понадобится.

Разработка крупных и средних проектов. Можно с криптой. Разумные цены. Хорошее качество. Адекватный подход.
-S
На сайте с 10.12.2006
Offline
Модератор1221
#2

LEOnidUKG, а нет каких-то цифр на больших базах для сравнения? На сколько отличается разница в производительности - возможно, можно как-то сравнить.

Mik Foxi
На сайте с 02.03.2011
Offline
925
#3

-= Serafim =-, надо чтоб в ячейках были объемные данные, если это короткая строка типа заглавие страницы, то там толком ничего и не сожмется, т.е. размер не сэкономим, а нагрузку на сжатие при записи и распаковку при каждом чтении получим. А вот если это объемный текст, который при этом не нужно индексировать и искать по нему, то сжатие в 2-5 раз может получиться легко. А когда база в 3 раза меньше - это полюбому прирост производительности.

---------- Добавлено 13.11.2019 в 08:31 ----------

edogs, это применимо везде, в любом говноблоге или новостнике на 100500 страниц. Сжимать поле контент, большие тексты и html отлично сожмутся, а для поиска есть яндекс и гугл.

Антибот защита сайта от накрутки поведенческих, от спама, взлома и поиска xss, от хит и клик ботов, от парсинга и кражи контента, снижение нагрузки на сервер - https://antibot.cloud/ Вам все еще конкуренты генерят отказы?
IL
На сайте с 20.04.2007
Offline
418
#4
foxi:
а для поиска есть яндекс и гугл.

Для "себя" - elasticsearch, sphinx и (хотел было ссылку дать.. но, топик, по всей видимости, был снесён.. после очередного последнего китайского ))

... :) Облачные серверы от RegRu - промокод 3F85-3D10-806D-7224 ( http://levik.info/regru )
LEOnidUKG
На сайте с 25.11.2006
Online
1587
#5
т.к. декомпрессия все же проц грузит.

Да ничего она не грузит. Уже давно не IBM386 стоит. То что, у большинство nginx сжимает на лету данные и отдаёт клиенту в доли секунды не напрягает, никто не париться.

Кто же спорит, если у вас там по 1 ляму посетителей на сайте, там уже по другому надо делать и решать. И то возможно при стресс тестах там всё будет нормально.

Я же говорю о новинке, которая может пригодиться как и мне.

нужно выносить в отдельную таблицу, если они на фиг не нужны для работы с ними

Вот как раз для этого, чтобы НЕ выносить и НЕ менять структуру рабочего проекта и реализовали такой функционал. НО! Если даже структуру "правильная", почему и не сжать тоже эти данные массивные.



---------- Добавлено 13.11.2019 в 11:56 ----------

-= Serafim =-:
LEOnidUKG, а нет каких-то цифр на больших базах для сравнения? На сколько отличается разница в производительности - возможно, можно как-то сравнить.

Сама база в производительности вообще не меняется т.к. все данные и индексы доступны также без сжатия, время уходит исключительно на процессор и момент декомпрессии. По умолчанию там стоит степень сжатия 6, я думаю это оптимальное соотношения размер данных и скорость их разжатия.

Я просто до этого тестировал, когда таблица в полном сжатии т.к. у неё тип Сжатый. Вот там ППЦ производительность падает. Кому нужен такой тип таблиц, я даже не знаю. Если только хранить какие-то архивы, которые запрашивают раз в неделю, на динамические сайты, вообще не катит.

---------- Добавлено 13.11.2019 в 12:05 ----------

foxi:
-= Serafim =-, надо чтоб в ячейках были объемные данные

Именно так, поэтому я сжимал новостной сайт, где текст новости 2500-5000 знаков. Сжимать данные до 255 символов не вижу смысла реального.

Mik Foxi
На сайте с 02.03.2011
Offline
925
#6

LEOnidUKG, вообще я похожую схему на sqlite юзаю, blob поле и в нем сжатый на php текст 1-3к знаков через gzdeflate с 9 степенью сжатия. Размер базы в 3 раза экономится.

Нагрузка на проц упала, т.к. стало быстрее выполняться чтение с диска и быстрее высвобождаться ресурсы. Но так по идее на расжатие расход проца должен быть на процентов 10-15 больше.

LEOnidUKG
На сайте с 25.11.2006
Online
1587
#7
foxi:
LEOnidUKG, вообще я похожую схему на sqlite юзаю, blob поле и в нем сжатый на php текст 1-3к знаков через gzdeflate с 9 степенью сжатия. Размер базы в 3 раза экономится.
Нагрузка на проц упала, т.к. стало быстрее выполняться чтение с диска и быстрее высвобождаться ресурсы. Но так по идее на расжатие расход проца должен быть на процентов 10-15 больше.

Я тоже такое юзаю для доров. И хотел найти такое же, но без изменения скриптов и структуры данных. И оказывается реализовали. Кстати это ещё раньше появилось в Percona Server Mysql, там более расширенный функционал.

Просто процессоры это не только гигагерцы, это ещё всякие интересные инструкции и сопроцессоры, которые помогают как раз выполнять сжатие и разжатие + не забываем, что разжатие идёт с распределением по всем ядрам т.е. это долисекунды для многоядерного сервера. А вот чтение с диска, это более дорогое удовольствие в плане скорости. На современных веб сервера уже давно всё упёрлось в диск, процессор просто отдыхает в основном. Да и Чё?! ему делать то? 1 раз просчитать мелкий PHP скрипт, а потом заниматься передачей данных с диска пользователю.

edogs software
На сайте с 15.12.2005
Offline
739
#8
LEOnidUKG:
Вот как раз для этого, чтобы НЕ выносить и НЕ менять структуру рабочего проекта и реализовали такой функционал. НО! Если даже структуру "правильная", почему и не сжать тоже эти данные массивные.

Если структура правильная и вынесено, то можно сжимать всю таблицу, а не по колонкам, не теряя возможности индексации и других возможностей.

foxi:
edogs, это применимо везде, в любом говноблоге или новостнике на 100500 страниц..

Чем это вдруг стало не подходить? https://dev.mysql.com/doc/refman/5.7/en/innodb-compression-usage.html без потери индексации, в этом вопрос.

-S
На сайте с 10.12.2006
Offline
Модератор1221
#9
LEOnidUKG:
Сама база в производительности вообще не меняется т.к. все данные и индексы доступны также без сжатия, время уходит исключительно на процессор и момент декомпрессии. По умолчанию там стоит степень сжатия 6, я думаю это оптимальное соотношения размер данных и скорость их разжатия.

Я просто до этого тестировал, когда таблица в полном сжатии т.к. у неё тип Сжатый. Вот там ППЦ производительность падает. Кому нужен такой тип таблиц, я даже не знаю. Если только хранить какие-то архивы, которые запрашивают раз в неделю, на динамические сайты, вообще не катит.

Спасибо. Тогда попробуем ужать, протестировать, а то есть много больших баз со статьями, если не будет падения производительности, то можно будет выиграть много в размерах баз.

LEOnidUKG
На сайте с 25.11.2006
Online
1587
#10
edogs:
Если структура правильная и вынесено, то можно сжимать всю таблицу, а не по колонкам, не теряя возможности индексации и других возможностей.

Чем это вдруг стало не подходить? https://dev.mysql.com/doc/refman/5.7/en/innodb-compression-usage.html без потери индексации, в этом вопрос.

Вы сами тестировали сжатые таблицы полностью? Я тестировал. Это УГ на динамических проектах. Именно в этом и проблема, что индексы тоже сжимаются, и чтобы их считать они разжимаются каждый раз.

А тут и индексы целы и информация сжата.

---------- Добавлено 13.11.2019 в 18:45 ----------

Вот есть тесты по сжатию персоны:

https://mydbops.wordpress.com/2019/10/06/save-space-on-mysql-data-with-column-compression/

И там как раз при сжатии полностью таблицы, не всё так радужно по экономии места:



---------- Добавлено 13.11.2019 в 19:08 ----------

-= Serafim =-:
Спасибо. Тогда попробуем ужать, протестировать, а то есть много больших баз со статьями, если не будет падения производительности, то можно будет выиграть много в размерах баз.

Только рекомендую делать так:

1. Сделать копию таблицы, можно даже через phpmyadmin. Просто когда будет делаться копия, она будет делаться на чистую и если было много удалений в таблице, то они тоже очистятся и освободится место. Напоминаю, что при InnoDB данные не удаляются, а просто помечаются как удалённые и скрываются, и место не освобождается.

2. Ужать всё, что надо на копии таблицы

3. Переименовать таблицы копию на OLD, а копию переименовать на оригинал.

12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий