Comments 13
Нормальная работа и полезный результат, но .. из заголовка почему-то ожидал что статья будет про нормализации данных как средство сокращения объема.
Почитал про нормализацию. На сколько я понял это что-то типа интенсивного метода сокращения данных, когда мы детально анализируем и возможно как-то переделываем данные.
Мы решили пойти экстенсивным путем и удалить ненужные, тем более что определить их дешево, а проверить их ненужность просто.
Нормализация обошлась бы дорого, так как потребовала больше специалистов для анализа и выполнения работ, это было бы очень сложно продать.
переименовываем базу данных / таблицу в
{name}_to_delete
А просто взять и отобрать у учётной записи привилегию чтения из таблицы - не? оно как бы куда как проще... И не надо, как в случае имитации удаления БД, заниматься переносом таблиц.
При первой же попытке мы увидели странное предупреждение от MariaDB, о том, что сервер не умеет
OPTIMIZEи будет делатьrecreate + analyze, нам было не до конца понятно.
Ну вообще-то сервер сказал, что вот именно данная конкретная таблица не может быть OPTIMIZE по месту (INSTANT/INPLACE), и будет использоваться алгоритм COPY. И это прямое следствие ограничений вашего движка - в документации на него прямо пишется "No online OPTIMIZE TABLE before 10.0.11 (r4199)".
А теперь разберем что не так было в понимании
OPTIMIZE TABLE
OPTIMIZE TABLE - это всего лишь внешний интерфейс. Он почти без изменений передаёт вашу просьбу движку таблицы, то есть всё ниже написанное по вопросу - относится к движку, а не к команде.
А просто взять и отобрать у учётной записи привилегию чтения из таблицы - не?
Не, учетных записей слишком много, показалось проще так как сделали.
Ну вообще-то ...
Ну так то да)
учетных записей слишком много, показалось проще так как сделали.
Если вы используете отдельные учётные записи на каждый чих, то оно, может, и правда так было дешевле. Но уж коли вы взялись за переделку, то можно подумать о том, чтобы вместо отдельных учётных записей на всё про всё подумать об использовании ролей? Конечно, это всего плюс слой, но станет немножко проще.
Почитал про роли, не понял как это может упростить задачу, это же почти те же привилегии, можете подсказать?
У нас может быть пачка юзеров созданных для отдельных таблиц в разных базах данных.
Да, это те же привилегии - но только группа привилегий. Назначаем пользователям группу - они получают привилегии группы. Убираем привилегию у группы - она убрана и у всех пользователей группы. Но в одной точке, а не у каждого по отдельности.
Да, существуют схемы назначения прав такие, что от групп практически не будет толку. Но чаще привилегии всё же ходят группами.
Интересная статейка, спасибо! По результату, кажется трудозатраты многократно превзошли результат. Я так понял, место на диске можно увеличивать практически бесконечно, были бы деньги. А стоимость сотрудника куда выше, чем гигабайты для хранилища.
Спасибо за отзыв)
Забыл упомянуть что на том продовом сервере уже диск никак не расширить без длительного даундайма самого сервера. Думали разные схемы, эта показалась самой дешевой.
А по стоимости профита, имхо, это нужно было сделать, чтобы снизить уровень энтропии. Диски можно бесконечно наращивать при должной организации инфраструктуры, но зачем если можно поддерживать порядок в данных?) Но это мое видение как инженера, а не бизнеса.
У нас Mariadb 10.10, Galera, база InnoDB, Перконой пользуемся постоянно для миграций, показала себя отлично.
Наша проблема не в размере базы (~570G на сжатом ZFS весит ~170G, а в фрагментации индексов и иногда в переполнении поля автоинкремента в некоторых таблицах (в основном в логах действий пользователей). Для решения этих проблем тоже планируем использовать pt-online-schema-change, но пока руки не дошли, т.к сначала запланирован переход на Марию 11.4.
Если у ТС остро стоит проблема размера БД на диске, рекомендую попробовать ZFS. Не знаю, насколько эффективно сжатие таблиц TokuDB, да и хранение их на ZFS в целом, не имел дела с этим движком, но таблицы InnoDB с определенным тюнингом и ФС и движка, полет нормальный, эффективность сжатия lz4 на средних по агрессивности настройках отлично справляется с функцией экономии места, плата процессором не такая уж и высокая, с учётом того, что алгоритм на аппаратном уровне поддерживается нашими процессорами. Чтение с диска за счёт сжатия заметно ускоряется, замедление записи в пределах погрешности измерений. А снапшоты - вообще вещ!
Как мы уменьшали размер базы данных