1. Пишите в начале
Облачная служба vivo предоставляет пользователям возможность резервного копирования данных, таких как контакты, текстовые сообщения, заметки и закладки, на своих мобильных телефонах. Базовое хранилище использует базу данных MySQL для хранения данных.
С развитием бизнеса облачных сервисов vivo количество пользователей облачных сервисов быстро росло, а объем данных, хранящихся в облаке, становился все больше и больше.Массивные данные создали огромные проблемы для внутреннего хранилища. Самая большая проблема в сфере облачных услуг в последние годы - это решение проблемы хранения больших объемов данных пользователей.
2. Решение проблем
С 2017 по 2018 год основные показатели продуктов облачных сервисов были сосредоточены на увеличении количества пользователей. Облачная служба внесла существенные изменения в стратегию продукта. После того, как пользователи войдут в учетную запись vivo, переключатель синхронизации данных облачной службы будет включен по умолчанию.
Эта продуктовая стратегия привела к резкому росту числа пользователей облачных сервисов. Число пользователей резко увеличилось с одного миллиона до десяти миллионов, а объем данных, хранящихся в серверной части, также увеличился с десятков миллиардов до сотен миллиардов.
Чтобы решить проблему хранения больших объемов данных, облачный сервис реализовал четыре метода суб-таблицы суб-базы данных: горизонтальную суб-таблицу, вертикальную суб-таблицу, горизонтальную суб-базу данных и вертикальную суб-базу данных.
1. Таблица оценки уровня
Путь шипов 1: что мне делать, если объем данных в одной таблице превышает 100 миллионов в закладках браузера, библиотеке списков заметок и одной таблице?
Я верю, что братья, которые разбираются в системе знаний о подбазах и подтаблицах, скоро смогут ответить: если количество данных в одной таблице слишком велико, то таблица будет разделена. Мы сделали то же самое, разделили единую таблицу закладок браузера и модулей заметок на 100 таблиц.
Перенесите миллиардный объем данных закладок браузера и листов заметок в 100 подтаблиц, каждая из которых содержит объем данных 1000 Вт .
Это первая атака, с которой все знакомы: таблица очков за уровень .
2. Горизонтальная подбиблиотека
Path of Thorns 2: данные контактов и SMS были разделены на таблицы, но изначально было разделено только 50 таблиц, и ни одна база данных не была разделена. После взрывного роста числа пользователей общий объем контактных данных в одной базе данных достиг нескольких миллиардов, а объем данных в одной таблице достиг 5000 Вт. Продолжающийся рост серьезно повлияет на производительность mysql. Что мне делать?
Второй трюк - разделить библиотеку по горизонтали : если одна библиотека не может ее поддерживать, разделите ее еще на несколько библиотек. Мы разделили исходную единую базу данных на 10 баз данных и расширили исходную единую базу данных с 50 таблиц контактов и текстовых сообщений до 100. В тот же период миграция и перенаправление миллиардов хранимых данных было очень болезненным.
3. Вертикальная подбиблиотека, вертикальная подтаблица
Path of Thorns 3: Изначально хранилище данных каждого модуля облачной службы смешано.
Когда в пространстве есть узкое место, мы проанализировали распределение пространства для хранения данных каждого модуля, и ситуация выглядит следующим образом:
Емкость диска одной библиотеки составляет 5 ТБ , контактные данные занимают 2,75 Т (55%) дискового пространства , данные SMS занимают 1 Т (20%) дискового пространства , все остальные данные модуля занимают в общей сложности 500 ГБ (5%) дискового пространства , а оставшееся свободное пространство составляет 1 ТБ . Данные о людях и SMS занимают 75% от общей площади .
Оставшийся 1Т пространства не может поддерживать непрерывный рост пользовательских данных, и ситуация не является оптимистичной. Если места недостаточно, все модули будут недоступны из-за нехватки места. Что мне делать?
(На рисунке ниже показано распределение пространства для хранения данных для облачных сервисов в то время)
Третья и четвертая оси, вертикальная подбаза данных и вертикальная подтаблица: мы храним и разделяем контактные данные, данные SMS и другие данные модуля. Разделите контактные данные и данные SMS в библиотеки.
На данный момент облачный сервис отработал все четыре трюка с суббазой и субтаблицами. Данные должны быть разделены, а данные должны быть разделены.
4. Схема динамического расширения на основе таблицы маршрутизации
Path of Thorns 4: Из вышеприведенного описания известно, что база данных с разделенными контактами принимает фиксированную стратегию с 10 суббазами баз данных. Предварительная оценка 10 баз данных * 100 таблиц может удовлетворить потребности роста бизнес-данных. Темпы роста контактных данных превзошли ожидания.
Через девять месяцев после того, как база данных контактов была разделена отдельно , пространство для хранения одной базы данных увеличилось с 35% до 65% . Согласно этим темпам роста, после еще 6 месяцев поддержки независимая база данных контактов снова столкнется с проблемой нехватки места.
Как решить? Продолжение расширения является положительным, и ключевым моментом является принятая стратегия расширения. Если мы примем традиционный план расширения, то мы столкнемся с проблемой миграции и перенаправления массивных данных о запасах, что слишком дорого.
После общения и обсуждения технической командой в сочетании с характеристиками контактного бизнеса облачных сервисов (количество контактов для старых пользователей в основном стабильно, большое количество контактов добавляется нечасто, а скорость роста контактных данных для старых пользователей находится под контролем), Наконец, мы приняли схему динамического расширения на основе таблицы маршрутизации.
Ниже описаны особенности этой программы:
- Добавьте таблицу маршрутизации пользователей для записи, в какую базу данных и таблицу перенаправляются контактные данные пользователя;
- Контактные данные нового пользователя будут перенаправлены в новую расширенную базу данных, что не вызовет нагрузки на хранилище данных в исходной старой базе данных.
- Данные старого пользователя не будут перемещены и по-прежнему хранятся в исходной базе данных.
- Особенность этого решения состоит в том, чтобы гарантировать, что исходная старая база данных должна обеспечивать рост данных только старых пользователей, а все новые пользователи переносятся только что расширенной базой данных.
Хотя темп роста старых пользовательских контактов поддается контролю, мы ожидаем, что исходная библиотека сможет зарезервировать 60% дискового пространства для поддержки роста объема данных старых пользователей. В настоящее время в старой библиотеке осталось только 35% доступного места, что не соответствует нашим требованиям.
Чтобы уменьшить пространство для хранения, занимаемое данными старой базы данных, мы, естественно, подумали о том, чтобы начать с уровня сжатия данных .
3. Предварительные исследования схемы сжатия.
Облачный сервис провел предварительное исследование следующих 3 решений для сжатия данных базы данных:
Схема 1: Программа сама реализует сжатие данных и сохраняет их в базе данных после сжатия.
Преимущество:
Нет необходимости изменять базу данных, изменения полностью обрабатываются самой программой, а поля, которые необходимо сжать, можно свободно контролировать.
Недостатки:
Существующие данные требуют разработки дополнительных задач сжатия для сжатия данных, а объем существующих данных слишком велик, а сжатие данных программами занимает много времени и не поддается контролю.
После того, как данные сжаты и сохранены в базе данных, содержимое поля запроса выбора, которое необходимо выполнить напрямую с платформы db, больше не читается, что увеличивает сложность последующих проблем с определением местоположения.
Вариант 2: база данных MySQL InnoDB имеет возможности сжатия данных
Преимущество:
Используйте существующие возможности InnoDB для сжатия данных без каких-либо изменений в программе верхнего уровня и не влияет на последующие запросы на выборку данных.
Недостатки:
Он подходит для бизнес-сценариев с большим объемом данных и меньшим количеством операций чтения и записи и не подходит для предприятий, которым требуется высокая производительность запросов.
Решение 3. Переключите механизм хранения InnoDB на TokuDB и используйте естественные возможности сжатия данных механизма TokuDB.
Преимущество:
TokuDB, естественно, поддерживает сжатие данных и несколько алгоритмов сжатия, поддерживает частые сценарии записи данных и имеет естественные преимущества для хранения больших объемов данных.
Недостатки:
MySQL необходимо установить дополнительные плагины для поддержки движка TokuDB, и в настоящее время у компании нет бизнеса со зрелым опытом TokuDB, риск после доступа неизвестен, и последующее обслуживание DBA также является проблемой.
После всестороннего рассмотрения мы наконец решили принять вторую схему сжатия: собственные возможности сжатия InnoDB .
Основные причины следующие:
- Простая операция: измените формат файла существующей таблицы данных innodb на dba, чтобы сжать данные;
- Регулируемая скорость сжатия: после тестирования таблицу данных мощностью 2000 Вт можно использовать для сжатия всей таблицы в течение 1-2 дней;
- Низкая стоимость преобразования: весь процесс преобразования требует только dba для выполнения связанного SQL, изменения формата файла таблицы данных и отсутствия необходимости вносить какие-либо изменения в верхний программный код;
- Больше подходит для бизнес-сценариев облачных сервисов: резервное копирование и восстановление пользовательских данных не является высокопроизводительным, бизнес-сценарии с высоким QPS, а таблицы данных облачных сервисов в основном соответствуют характеристикам большого количества строковых полей, которые очень подходят для сжатия данных.
В-четвертых, проверка схемы сжатия
1. Введение в возможности сжатия InnoDB
До версии MySQL 5.1.38 существовал только механизм хранения innodb-base. Формат файла по умолчанию - Antelope. Этот формат файла поддерживает два формата строк (ROW_FORMAT): COMPACT и REDUNDANT, ни один из которых не является строковым форматом типа сжатия данных.
После MySQL 5.1.38 был представлен плагин innodb, а также формат файлов типа Barracude. Barracude полностью совместим с форматом файлов Antelope и поддерживает два других строковых формата ДИНАМИЧЕСКИЙ и СЖАТЫЙ (поддерживает сжатие данных).
2. Подготовка компрессионной среды.
Измените конфигурацию базы данных: измените формат файла базы данных, по умолчанию - Antelope, измененный на Barracuda.
УСТАНОВИТЬ ГЛОБАЛЬНЫЙ innodb_file_format = Barracuda;
УСТАНОВИТЬ ГЛОБАЛЬНЫЙ innodb_file_format_max = Barracuda;
УСТАНОВИТЬ ГЛОБАЛЬНЫЙ innodb_file_per_table = 1
Примечание: innodb_file_per_table должен быть установлен в 1. Причина в том, что системное табличное пространство InnoDB не может быть сжато. Системное табличное пространство не только содержит пользовательские данные, но также содержит внутреннюю системную информацию InnoDB, которую невозможно сжать, поэтому для поддержки сжатия необходимо настроить разные табличные пространства для разных таблиц.
После установки OK вы можете выполнить SHOW GLOBAL VARIABLES LIKE '% file_format%' и SHOW GLOBAL VARIABLES LIKE '% file_per%', чтобы подтвердить, вступили ли изменения в силу.
(Этот параметр действует только для текущего сеанса и станет недействительным после перезапуска экземпляра mysql. Если вам нужно, чтобы он вступил в силу постоянно, настройте его в глобальном файле конфигурации mysql)
3. Тестовая проверка эффекта сжатия
Подготовьте таблицу данных, поддерживающую формат сжатия, и таблицу данных, которая не поддерживает сжатие. Все форматы полей одинаковы.
Таблица сжатия:
Описание: row_format = сжатый, указанный формат строки сжат. Рекомендуемый key_block_size = 8. По умолчанию key_block_size равен 16. Необязательные значения 16, 8, 4 представляют размер страницы данных InnoDB. Чем меньше значение, тем больше степень сжатия. На основе всестороннего учета ЦП и степени сжатия рекомендуемая онлайн-настройка - 8.
Несжатая таблица:
Подготовка данных: используйте хранимую процедуру для одновременной вставки 10 Вт одинаковых данных в таблицу t_nocompress и таблицу t_compress. Место, занимаемое двумя таблицами, выглядит следующим образом:
Данные таблицы t_compress занимают 10 МБ, данные таблицы t_nocompress занимают 20 МБ, а степень сжатия составляет 50%.
Примечание: эффект сжатия зависит от типа поля таблицы.Типичные данные обычно имеют повторяющиеся значения, поэтому их можно эффективно сжать. CHAR, VARCHAR, TEXT, BLOB и т. Д.
Строковые данные обычно хорошо сжимаются. Однако двоичные данные (целые числа или числа с плавающей запятой) и сжатые данные (изображения JPEG или PNG) обычно не достигают сжатия.
Пять, онлайн-практика
Из приведенной выше проверки теста, если степень сжатия может достичь 50%, пространство, занимаемое базой данных контактов, будет сжато с 65% до 33%, и 60% оставшегося пространства может быть достигнуто.
Но нам нужно трепетать перед онлайн-данными. Перед онлайн-практикой нам нужно проверить офлайн-план. В то же время нам также необходимо рассмотреть следующие вопросы:
1. Влияет ли сжатие и распаковка данных на производительность сервера db?
Мы используем стресс-тестирование производительности, чтобы оценить влияние на ЦП сервера базы данных до и после сжатия. Ниже приведена сравнительная таблица ЦП сервера db до и после сжатия:
При условии, что объем данных в списке контактов уже составляет 2000 Вт, данные вставляются в эту таблицу.
Перед сжатием: вставьте 50 контактов одновременно, 200 одновременных, 10 минут, TPS 150, CPU 33%
После сжатия: вставьте 50 контактов за раз, 200 одновременных, 10 минут, TPS 140, CPU 43%
После сжатия таблицы данных ЦП частых вставок данных в базу данных действительно увеличится, но это не сильно повлияет на TPS. После повторного стресс-тестирования ЦП сервера баз данных в основном стабильно составляет около 40%, что приемлемо для бизнеса.
2. Повлияет ли изменение формата файла таблицы данных на чтение и запись бизнес-кода SQL и на нормальные бизнес-функции?
В основном мы выполняли офлайн-проверку и онлайн-проверку :
Автономная проверка: в тестовой среде все таблицы с контактными данными были скорректированы до сжатого формата, а инженер по тестированию помог проверить все функции контактов, и все последние функции были нормальными.
Среда перед запуском снова повторяет шаги тестовой среды, и при проверке функций нет отклонений от нормы.
Онлайн-проверка: выберите для сжатия таблицу данных модуля записи вызовов, не чувствительную к пользователям, выберите сжатие 1 таблицы в 1 библиотеке, обратите внимание на состояние чтения и записи данных в этой таблице и обратите внимание на жалобы пользователей.
После 1 недели непрерывного наблюдения данные записи разговоров этих часов могут быть прочитаны и записаны в обычном режиме, и в течение этого периода не было получено никаких аномальных отзывов от любого пользователя.
3. Объем онлайн-контактов огромен, как обеспечить стабильность работы сервиса при сжатии?
В основном мы идем на компромиссы в соответствии со следующими идеями:
- Выберите таблицу контактных данных для сжатия и оцените время, затраченное на одну таблицу.
- Выберите одну базу данных, выполните одновременное сжатие нескольких таблиц и понаблюдайте за использованием ЦП. Администратор баз данных считает, что максимальное значение ЦП не может превышать 55%, и постепенно регулирует количество одновременных сжатий на основе этого стандарта, чтобы обеспечить стабильность ЦП на уровне около 55% и, наконец, получить максимальное количество таблиц, поддерживаемых одной базой данных для сжатия одновременно.
- Комбинируя первый и второй шаги, мы можем рассчитать приблизительное время, необходимое для сжатия всех таблиц данных всех библиотек.После синхронизации с командой проекта и соответствующими ответственными лицами следуйте инструкциям по выполнению сжатия.
Влияние сжатия данных на окончательную базу данных онлайн-контактов выглядит следующим образом:
Шесть, напишите в конце
В этой статье представлены проблемы, связанные с облачными сервисами при развитии бизнеса и массового хранения данных, а также некоторый опыт облачных сервисов в подтаблице под-базы данных, сжатие данных базы данных, в надежде предоставить ссылку.
Сжатие данных InnoDB подходит для следующих сценариев:
Предприятиям с большим объемом бизнес-данных и нехваткой места на дисках баз данных;
Он подходит для бизнес-сценариев, когда больше читают и меньше пишут, и не подходит для предприятий, которые предъявляют высокие требования к производительности и QPS;
- Он подходит для большого количества данных строкового типа в структуре таблицы бизнес-данных.Таблица данных этого типа обычно может быть эффективно сжата.
В конце концов:
При выборе баз данных и таблиц для бизнеса необходимо полностью оценить рост объема данных, так как работа по миграции данных, вызванная последующим расширением базы данных, сильно ударит по костям.
- Будьте в восторге от онлайн-данных, и решение необходимо применять онлайн только после повторной автономной проверки.
Автор: платформа vivo для команд разработки продуктов