Предыстория - введение компании
Eggplant Technology (Overseas SHAREit Group) — компанияГлобальная компания интернет-технологий, в основном занимаетсяИсследования и разработка программного обеспечения для мобильного Интернета, глобальные решения для монетизации мобильной рекламы, решения для трансграничных платежей и другие интернет-услуги.и другие дела. SHAREit — представительный продукт компании Eggplant Technology.Универсальный цифровой развлекательный контент и кроссплатформенная платформа для обмена ресурсами, с почти 2,4 миллиардами установленных пользователей. Как зарубежная компания, Eggplant Technology создала множество инструментов и приложений для контента в Юго-Восточной Азии, Южной Азии, на Ближнем Востоке и в Африке и круглый год входит в число самых загружаемых в Google Play.
Предыстория - бизнес-характеристики и выбор
Технология баклажанов имеет множество матриц продуктов, а формы продуктов относительно сложны, в том числеИнструменты, Контент, Игры, Реклама, ПлатежиЖдать. Для относительно сложных бизнес-сценариев мы выбрали различные базы данных в соответствии с различными бизнес-формами. В настоящее время шесть наиболее важных баз данных, используемых Eggplant Technology, включают:
- Саморазвитый стойкий КВ: Платформа функций, портрет пользователя, запись поведения и т. д.
- Redis Cluster: бизнес-кэш, информация о сеансе и т. д.
- Cassandra: библиотека контента
- MySQL: оттенок, метаданные, операционная платформа и т. д.
- ClickHouse: Анализ данных, отчеты в реальном времени
- TiDB: рост пользователей, системы APM, облачный биллинг и т. д.
Практика применения TiDB — болевые точки бизнеса и преимущества TiDB
Основываясь на болевых точках на уровне бизнеса, мы внедрили TiDB в несколько бизнес-сценариев: Во-первых, как зарубежная компания, Eggplant Technology представила рядобщедоступное облакоКак инфраструктуру, так и на уровне базы данных бизнес необходимо рассматривать в рамках многооблачной архитектуры.Адаптация бизнеса, миграция данных, совместимость баз данных и синхронизация данныхПроблема. Во-вторых, у Eggplant есть множество продуктов APP с высоким трафиком, и бизнес представляетБыстро растущийОднако традиционные базы данных DRS, такие как MySQL, требуют подбаз данных и подтаблиц, что препятствует быстрому развитию бизнеса. В-третьих, базы данных NoSQL, такие как Cassandra и HBase, не могут удовлетворитьРаспределенная транзакция, объединение нескольких таблици другие сложные сцены.
Некоторые из APM и других систем технологии баклажанов являются сценариями HTAP. Одни и те же бизнес-данные требуют как OLTP, так и OLAP. Мы надеемся, что набор баз данных может справиться с этим.
После появления TiDB TiDB продемонстрировала свои уникальные преимущества во многих аспектах, помогая Eggplant Technology создать устойчивую экосистему баз данных:
- Использование TiDBМежкластерная миграция и синхронизация данныхВозможность создания возможностей для расширения бизнеса в рамках многооблачной архитектуры и соответствия проекту бизнес-архитектуры в рамках многооблачной архитектуры.
- TiDB предоставляетАвтоматическая горизонтальная эластичностьВозможность расширения, чтобы бизнес не знал, и решить проблему подбазы данных и подтаблицы.
- TiDB обладает высокой совместимостью с MySQL и имеет низкие затраты на обучение и низкую стоимость миграции в сценариях с большой емкостью и высокой степенью параллелизма.
- Используйте возможности TiDB HTAP для удовлетворения двойных потребностей OLTP и OLAP в одном фрагменте данных.
Практика применения TiDB — применение сценария APM
баклажаныAPM (управление производительностью приложений)Система обеспечивает сбой приложения, производительность и другие проблемы.Отслеживание, анализ, канбан, исправлениеВозможность интеграции используется для поддержки различных быстрорастущих приложений APP. Первая особенность этой системы заключается в том, чтоМного информации, ежедневно генерируются десятки миллиардов данных, которые необходимо хранить в течение 30 дней; вторая особенность заключается в том, чтоСвоевременностьТребования относительно высоки. В некоторых более сложных ситуациях, таких как сбои и серьезные проблемы с производительностью, если своевременность не может быть удовлетворена, это напрямую повлияет на опыт пользователя и даже на доход от продукта; третья особенность - необходимость получить черезСистема рабочих заданий, обеспечивающая интеграцию отслеживания проблем и ремонтаспособность; четвертая характеристикаНа основе сценариев транзакций OLTP необходимо учитывать сценарии анализа OLAP..
Во-первых, проанализируйте поток данных раннего APM, от отчетов данных APP до сбора журналов и, наконец, в ClickHouse, весь поток данных представляет собой аналогичный процесс.пакетная обработкаПроцесс занимает около двух часов, общая своевременность слабая, и проблема не выявляется вовремя, что повлияет на пользовательский опыт. Кроме того, в этой системе есть два набора баз данных: MySQL и ClickHouse. Почему он разработан таким образом? Поскольку ClickHouse можно использовать дляАналитическая агрегация данных, MySQL в основном используется для построенияЗаявка на обработку, В то же время в поддержке два набора баз данных, и стоимость относительно высока.Давайте посмотрим на поток данных новой версии APM после введения TiDB.Вы можете увидеть отчеты APP, отображение канбана, сигнализацию, а затем обработку рабочих заданий.минутный уровеньОтображение версии просмотра квази-реального времени и тревога. Эта часть в основном использует возможности HTAP TiDB для отображения в Kanban посредством агрегированного анализа и для своевременного оповещения в центр аварийных сигналов. В то же время возможности OLTP TiDB используются для обновления строк доски Kanban. Таким образом, мы можем пройти процесс просмотра версий, мониторинга, отслеживания проблем и исправления с помощью набора баз данных TiDB.
Эволюция на базе ТиКВ — распределенный КВ собственной разработки
Все знают, что TiKV от TiDBуровень хранения, но и базу данных Key-Value.Далее поговорим о процессе баклажанной технологии построения распределенной системы KV на основе TiKV. Технология Eggplant в основном предоставляет инструменты и продукты для контента, а объем генерируемых данных очень велик.Хранилище KV должно поддерживать два сценария: одинГенерация данных в реальном времени, писать в режиме реального времени; другой дляМеханизм профилей и функций, чтобы быстро загружать большие пакеты данных, сгенерированных в автономном режиме, в онлайн-хранилище KV, чтобы обеспечить быстрый доступ для онлайн-бизнеса, то есть возможность массовой загрузки, которая требуется в реальном бизнесе.Пропускная способность в терабайтах в час.
На рисунке ниже показан распределенный KV, разработанный компанией Eggplant Technology на основе Rocksdb.Эта система удовлетворяет одновременно двум вышеперечисленным требованиям KV. Архитектура, показанная слева на рисунке, в основномРеализация возможности записи в реальном времени, данные сначала поступают из SDK на уровень сетевого протокола, затем на уровень топологии, затем на уровень сопоставления структуры данных и, наконец, в Rocksdb. Справа показан процесс пакетного импорта массовой загрузки. У вас может возникнуть вопрос, почему процесс записи в реальном времени слева не соответствует импорту данных TB на уровне часа? Есть две основные причины: во-первых, из-за усиления записи Rocksdb, особенно в сценариях с большими ключами, усиление записи Rocksdb очень серьезно. Другой момент заключается в том, что пропускная способность сети одного диска ограничена, что приводит к ограниченной нагрузке на одну машину или хранилище на одну машину. правильноВозможность импортировать целые партииКак это достигается? Он использует Spark для анализа данных, предварительного сегментирования и генерации SST на Parquet, загрузки SST на узел хранения Rocksdb и, наконец, загрузки его на уровень KV посредством загрузки и сжатия для онлайн-доступа к бизнесу до 100 мегабайт.
Эволюция на базе TiKV — Распределенный KV на базе TiKV
Поскольку Eggplant Technology разработала распределенный KV на основе Rocksdb, зачем ей использовать TiKV? Прежде всего, на техническом уровне, хотя распределенный KV собственной разработки работает в производстве более двух лет, поддерживая сотни ТБ данных, есть некоторые технические проблемы, такие какАвтоматическое эластичное масштабирование, строгая согласованность, транзакции и большие ключиТребуются дополнительные инвестиции в исследования и разработки. Во-вторых, вУровень талантов для кадрового резерва высококачественной базы данныхЕсть определенные недостатки. После многих исследований и общения со студентами отдела исследований и разработок TiKV мы обнаружили, что наши потребности и болевые точки совпали с планированием продукта TiKV, что побудило нас активно использовать TiKV. С помощью TiKV мы можем технически создавать продукты KV, которые разделяют хранение и вычисления. В-третьих, у TiKV активное сообщество с открытым исходным кодом, и мы можем использовать силу сообщества для совместной доводки продукта.
Архитектура на рисунке ниже — это распределенный KV, построенный компанией Eggplant Technology на основе TiKV. Левая часть в основном предназначена для решения процесса записи данных в реальном времени, от SDK до сетевого хранилища, до расчета данных и, наконец, до механизма хранения TiKV. Направление исследований, на которое мы ориентируемся, является правильной частьюВозможность полной массовой загрузкиВ отличие от самостоятельно разработанного распределенного KV, весь процесс генерации SST выполняется внутри TiKV, причина этого в том, что его можноМинимизируйте затраты на разработку кода и обслуживание Spark и упростите использование..
Эволюция на основе TiKV — выводы испытаний
Следующие две таблицы представляют собой результаты реальных тестов, основанных на возможностях массовой загрузки TiKV. В приведенной выше таблице для ЦП E5, 40 ядер Vcore и дисков, использующих NVMe, можно достичь максимума.256 МБпроизводительность одной машины. В приведенной ниже таблице показано испытание под давлением части онлайн-чтения при выполнении массовой загрузки.. Видно, что дрожание времени отклика задержки очень мало, будь то P99 или P99.99, оно находится вотносительно стабильныйстатус. Этот результат теста является демонстрационной проверкой, я считаю, что после нашей последующей оптимизации, будь то пропускная способность хранилища или задержка отклика, будет качественное улучшение.
Способность Bulk Load разработана и усовершенствована нами и студентами отдела исследований и разработок TiKV. Мы верим в силу открытости. Позже всю архитектуру, включая тестовые данные, выложим на GitHub. Если у вас есть соответствующие потребности, можете обратить внимание.