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

LEOnidUKG,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем это вдруг стало не подходить? 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 ----------

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

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

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

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