Преимущества барракуды и компрессии


12

Я читал о форматах файлов MySQL Antelope и Barracuda некоторое время назад, и мне интересно, смогу ли я получить пользу от Barracuda и Compression.

Мой сервер в настоящее время использует антилопу, так как это по умолчанию MySQL.
У меня много раз возникали проблемы с памятью из-за большой базы данных. Моя база данных увеличивается с каждым днем.

Кажется, что сжатие дает преимущества нескольким людям, например:
http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/

Я понимаю , память и дисковое пространство может быть ниже, но я не уверен , если я понимаю , это (цитата из статьи):
«~ 5% загрузку процессора в зависимости от верхней части (от 80-100% в основном в ожидании ввода / вывода)
0,01 среднее время поиска по первичному ключу (от 1-20 секунд до преобразования) "

Я думал, что эти две вещи НЕ улучшатся, потому что, если данные сжимаются, сервер должен распаковывать, чтобы снова получить исходные данные, поэтому не имеет ли смысл увеличивать использование ЦП?

Это полезно для интенсивного чтения / записи? Вы бы порекомендовали мне перейти на Барракуда и Сжатие?

Вам известны какие-либо проблемы Барракуда?
Кажется, что ответ на следующий вопрос указывает на несколько проблем, но поскольку это с 2011 года, я бы сказал, что они уже исправлены: /server/258022/mysql-innodb-how-to-switch -в-баррачуды-формате

Ответы:


14

Что касается «Динамического» , несжатого формата Barracuda-only, очень мало что изменилось по сравнению с компактным, главным образом в том, как хранятся BLOB-объекты (и любые очень динамические поля) . У меня никогда не было проблем с компактностью и динамикой, поэтому я могу смело рекомендовать динамику Барракуда. Помните, что Barracuda также поддерживает старые избыточные и компактные форматы строк .

Вероятно, статья, о которой вы упоминаете, слишком старая (5.1), и, как отмечает Питер З., генеральный директор Percona, в комментариях она может вводить в заблуждение. Это не означает, что сжатие не может быть огромным преимуществом в зависимости от рабочих нагрузок. Тем не менее, я бы порекомендовал вам попробовать его на версиях> = 5.6, так как Facebook и Oracle сделали много улучшений.

В качестве более свежих справочных материалов я бы порекомендовал вам:

В частности, мне нравятся материалы Facebook, поскольку они являются сторонними организациями (нет необходимости в повестке дня), и у них одно из крупнейших развертываний MySQL в мире. Как вы можете видеть, у них были очень успешные установки, сочетающие технологию SSD со сжатием.

Будет ли это полезно для вас? Это будет зависеть от вашей рабочей нагрузки, рабочего набора и настроек (IOPS, память) . В зависимости от того, связаны ли вы с вводом-выводом, с процессором или с памятью, в некоторых случаях сжатие может отрицательно сказаться на добавлении ЦП, требованиях к памяти (сжатые и несжатые страницы хранятся в пуле буферов InnoDB) или создании слишком большого количества сбоев сжатия, увеличивая латентность Это также зависит от типа данных: сжатие может очень помочь с большими текстовыми объектами, но может оказаться бесполезным для уже сжатых данных.

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

В общем, очень сложно предсказать результаты, обычно вам нужно настроить тестовую среду для бенчмаркинга, а затем выяснить, почему вы получаете лучшие или худшие результаты (и таким образом вы можете играть с разными размерами блоков и т. Д.). Барракуда полностью безопасна. Сжатие может быть или нет для вас. И вы всегда можете поэкспериментировать с другими методами сжатия, такими как сжатие больших двоичных объектов на стороне клиента (например, если вы в конечном итоге привязаны к процессору) или другими сторонними механизмами, такими как RocksDB и TokuDB , в которых сжатие является большим приоритетом, поскольку оно сфокусировано в производительности для больших наборов данных, чем InnoDB может обработать.

В двух словах: основными причинами использования Barracuda являются обработка BLOB, innodb_large_prefixсовместимость (большие индексы) и сжатие. Динамический, на MySQL 8.0 теперь формат файла по умолчанию.


1
Это действительно УДИВИТЕЛЬНЫЙ и четкий ответ! Это имеет смысл, и это именно тот ответ, который я хотел получить. Вы упоминаете MySQL 5.6 (который я недавно обновил) и ссылаетесь на Facebook в качестве примера, как мне нравится, поскольку им обычно приходится преодолевать трудности раньше всех. К сожалению, сначала это будет непросто протестировать, поскольку тестовая среда не будет иметь такую ​​же нагрузку на ЦП / В / ОЗУ, как в рабочей среде, но на самом деле мне придется попробовать! Спасибо вам большое за ваше время.
Нуно

Поскольку формат строки может быть выбран на уровне таблицы, это может дать вам некоторую гибкость для тестирования на производстве (после надлежащего тестирования на отдельной машине). Однако такой подход потенциально затруднит отладку и сравнительный анализ.
jynus

Да, я мог бы сначала попытаться преобразовать несколько таблиц (может быть, те, которые не так велики / используются). Тем не менее, для больших, это потребует нескольких простоев, а не одного простоя, когда я буду конвертировать их все сразу. Я должен увидеть, каков наилучший подход. Однако я не понимаю, почему это затрудняет отладку. Что именно вы имеете в виду здесь? Большое спасибо.
Нуно

1
У вас есть инструменты, такие как pt-online-schema-change percona.com/doc/percona-toolkit/2.2/… для воссоздания таблиц в режиме онлайн. Я только что упомянул, что смешивание только некоторых таблиц может усложнить измерение изменений процессора / памяти / iops из-за изменения движка и отличать его от нормальных изменений нагрузки или из-за изменений кэширования при его воссоздании. Это также трудно увидеть на другой машине с другим оборудованием, так что просто удачи!
января

На ZFS это не совсем то, что плохо при использовании LZ4 в файловой системе.
Денис Денисов
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.