Автор: Mobike / Отдел технологических исследований и разработок / Центр базовых платформ Дин Юаньцзе Ху Мин
задний план
Компания Mobike была создана в январе 2015 г. 22 апреля 2016 г. организация Earth Day официально запустила интеллектуальную службу совместного использования велосипедов.По состоянию на середину ноября 2017 г. она появилась в более чем 180 городах страны и за рубежом, эксплуатируя более 7 миллионов мотоциклов. предоставляет интеллектуальные туристические услуги для более чем 200 миллионов пользователей по всему миру с ежедневным объемом заказов более 30 миллионов, что делает его крупнейшей в мире интеллектуальной платформой для совместного использования велосипедов и мобильной платформой Интернета вещей. Mobike генерирует более 30 ТБ данных о велосипедах каждый день и располагает самыми полными большими данными о велосипедах в мире.Быстро растущий бизнес заставляет Mobike сталкиваться с огромными проблемами в расширении базы данных, эксплуатации и обслуживании.
Столкнувшись с быстро растущим параллелизмом и объемом данных, автономная база данных в конечном итоге выйдет из строя из-за ее неспособности поддерживать давление бизнеса. С момента официального запуска Mobike мы постоянно думали о будущем расширения базы данных, эксплуатации и обслуживания.В последние годы распространенным решением для расширения базы данных в отрасли является горизонтальное разделение таблицы базы данных с помощью промежуточного программного обеспечения и разделение данных в таблице по правилам разделены на несколько физических баз данных. При использовании такого промежуточного программного решения при расширении базы данных необходимо сначала остановить бизнес, затем реконструировать код, а затем выполнить миграцию данных. огромен, а промежуточное программное решение слишком сильно для бизнеса.Навязчивость, отсутствие поддержки распределенных транзакций между сегментами и неспособность гарантировать строго согласованные транзакции — все это обескураживает нас.
Mobike начал использовать TiDB в начале 2017 года. Начиная с самых ранних RC3, RC4, PreGA и заканчивая текущей официальной версией 1.0, компания шаг за шагом становилась свидетелем зрелости и стабильности TiDB. В настоящее время он поддерживает внутренний анализ Mobike в режиме реального времени и некоторые онлайн-бизнесы и планирует перевести больше онлайн-бизнесов на TiDB.
В настоящее время TiDB развернула в Mobike несколько кластеров с почти 100 узлами, несущими десятки терабайт различных данных.
Роль и основные сценарии применения TiDB в Mobike
В Mobike TiDB является основной платформой поддержки транзакций и хранения данных.Основной целью ее внедрения является решение онлайн-хранения массивных данных, крупномасштабного анализа и обработки данных в реальном времени.
На наш взгляд, основными преимуществами TiDB являются:
- Гибкое расширение. Благодаря возможностям расширения, подобным NoSQL, он может улучшить возможности поддержки бизнеса системы за счет горизонтального расширения в условиях постоянного роста объема данных и трафика доступа, а задержка ответа стабильна;
- Легко и просто использовать. Совместимость с протоколом MySQL, в основном из коробки, нет необходимости беспокоиться об умственной нагрузке и сложных затратах на обслуживание, связанных с традиционной схемой разбиения базы данных и таблиц, а пользовательский интерфейс удобен, а штатный технический персонал может поддерживать и управлять им на высоком уровне;
- Отвечайте быстро. Поскольку существует очень глубокое сотрудничество с командой PingCAP, любые проблемы могут быть сообщены непосредственно команде PingCAP в первый раз, и проблемы могут быть рассмотрены и решены быстро.
Ниже описаны сценарии применения TiDB:
Сценарий 1: Статистика успешности переключения журналов блокировки
Успешность переключения замков является одним из ключевых показателей мониторинга бизнеса Mobike.
Во время каждого процесса разблокировки и закрытия информация о пользователе и блокировке будет генерировать массивные журналы в ключевых бизнес-узлах. Благодаря сводке и анализу онлайн-журналов мы организуем поведение пользователя в два измерения людей и автомобилей. Очередь сообщений преобразуется, импортируется и хранятся в ТиБД. В этом процессе, добавляя разные теги к разным объектам, мы можем легко подсчитать вероятность успеха разблокировки каждой категории в соответствии с различными параметрами, такими как регион, версия приложения, тип терминала, пользователь и велосипед.
По нашим оценкам, объем этого бизнеса составляет десятки миллиардов в год, поэтому использование автономной библиотеки MySQL требует частого архивирования, особенно в случае узкого места автономной базы данных расширение сопряжено с большими проблемами. ограниченная рабочая сила, это полная катастрофа. Следовательно, для поддержки всей серверной базы данных Mobike мы должны найти простое и удобное в использовании решение, которое значительно снижает трудозатраты одного предприятия. Во-вторых, согласно нашему предыдущему опыту использования подбазы данных и подтаблицы, для этого типа бизнеса, который требует частого обновления структуры таблицы для операций DDL, когда объем данных слишком велик, базу данных легко вывести из строя. зависать, что не только влияет на доступность услуг, но и серьезно может привести к несогласованности данных. Наконец, мы надеемся, что независимо от того, насколько резко возрастет объем бизнеса в будущем и как изменятся бизнес-требования, бизнес-логику можно будет сохранить, а поддержку можно будет легко обновить.
При разработке схемы мы исследовали сравнение между подтаблицей подбазы данных MySQL и схемой TiDB.
Сначала мы оценили возможные сценарии:
- Когда запускается новый бизнес, онлайн-изменения должны происходить часто;
- Храните данные как можно дольше для статистического сравнения;
- Данные должны поддерживать частые связанные запросы и поддерживать временные потребности операционной группы;
- Он должен быть в состоянии поддерживать быстрый рост бизнеса или временный трафик, вызванный некоторыми особыми событиями.
Учитывая эти ситуации, есть некоторые проблемы в решении базы данных и таблиц MySQL.Во-первых, сложно часто менять структуру таблицы, в то время как TiDB может выполнять онлайн-DDL. Срок жизни данных относительно велик, и в начале проектирования можно построить относительно большой кластер, но гибкость относительно низкая.Для этой проблемы TiDB может гибко увеличивать или уменьшать узлы в соответствии с потребностями.Такая гибкость недоступна в Подбаза данных MySQL и подтаблица. Кроме того, данные должны поддерживать частые и сложные связанные запросы.Схема подтаблиц базы данных MySQL вообще не может этого сделать, и именно в этом заключается преимущество TiDB.Благодаря приведенному выше сравнительному анализу мы выбрали TiDB как успех скорость переключения журнала блокировки Вспомогательная база данных для статистических проектов.
В настоящее время сквозную задержку можно приблизительно контролировать на минутном уровне, то есть, если вероятность успешной разблокировки снижается, терминал мониторинга может немедленно определить это, а также запросить событие единичной ошибки пользователем и транспортным средством в фоновом режиме, чтобы помочь Эксплуатационный и обслуживающий персонал может быстро определить конкретное место неисправности.
Сценарий 2: Анализ данных в режиме реального времени
В сценариях анализа данных TiDB может синхронизировать различные типы данных из всех экземпляров MySQL онлайн в режиме реального времени и импортировать их в TiDB для хранения с помощью периферийного инструмента TiDB Syncer.
Требования к этому бизнесу очень просты: у нас есть десятки кластеров MySQL в сети, некоторые из которых являются подбазами данных и подтаблицами, а некоторые являются независимыми экземплярами. Эти изолированные данные должны быть собраны для анализа данных со стороны бизнеса. Вначале мы планировали синхронизировать эти библиотеки с Hive и исследовали два метода. Первый — синхронизировать весь объем каждый день. Это увеличит нагрузку на онлайн-библиотеку и накладные расходы на ресурсы Hive. Другой — инкрементная синхронизация.Этот метод очень сложен, т.к. HDFS не поддерживает обновление, и необходимо объединять ежедневную инкрементальную часть и предыдущую часть.Преимущество этого метода в том, что в случае относительно большого количества data , Инкрементная синхронизация быстрее и занимает меньше места, чем полная синхронизация.Недостатком является то, что она занимает значительную часть вычислительных ресурсов платформы Hadoop и влияет на стабильность системы.
Сама TiDB имеет много хороших инструментов, которые можно легко подключить к экосистеме MySQL. Здесь мы в основном используем инструмент синхронизации TiDB, который может легко синхронизировать экземпляры или кластеры MySQL с подбазами данных и подтаблицами MySQL с кластером TiDB. Поскольку сама TiDB может быть обновлена, в Hive проблем нет. В то же время есть проект TiSpark, после того как данные попадают в TiDB, очень сложные OLAP-запросы можно выполнять прямо через Spark. С помощью этой системы некоторые сложные онлайн-требования, выдвинутые операционным отделом, могут быть выполнены быстро и лаконично, что не может обеспечить такую производительность в реальном времени на платформе Hadoop.
В настоящее время кластер имеет десятки узлов и емкость хранилища в десятки терабайт. Благодаря естественной архитектуре высокой доступности TiDB система работает стабильно. В будущем масштаб кластера будет становиться все больше и больше, и он может можно расширить, просто добавив серверы x86. Внутренняя разработка, эксплуатация и обслуживание, деловые стороны и т. д. могут использовать возможности агрегации данных TiDB для агрегирования данных для агрегирования и анализа данных.
Сценарий 3: онлайн-бизнес OLTP в режиме реального времени
Как упоминалось выше, по сравнению с традиционным решением для подтаблиц подбазы данных гибкость и масштабируемость TiDB имеют более очевидные преимущества в онлайн-бизнесе в режиме реального времени.
Согласно нашим тестам, когда объем данных превышает 50 миллионов, TiDB имеет большое преимущество перед MySQL.В то же время уровень протокола хорошо совместим с MySQL и может использоваться напрямую без изменения бизнес-кода.Поэтому кластер TiDB очень полезно для онлайн-бизнеса в режиме реального времени с большим объемом данных.
В настоящее время Mobike в основном запустила два набора онлайн-сервисов OLTP, а именно кредитное отделение Modou и бизнес торгового центра Modou.
Моду кредитный бизнес
Кредитный рейтинг Mobike связан с поездкой пользователя. Когда пользователь сканирует код для разблокировки замка, пользователь сначала проверяет кредитный рейтинг пользователя, чтобы определить, соответствует ли он условиям поездки. После завершения поездки система оценит и изменить кредитный рейтинг в соответствии с поведением пользователя. Когда на велосипеде нельзя ездить, кредитный рейтинг будет увеличен после сообщения об ошибке и ее проверки, а кредитный рейтинг будет уменьшен после подтверждения сообщения о незаконной парковке. Система вычтет часть кредитных баллов пользователя в качестве наказания и архивировать запись о нарушении правил парковки. Когда кредитный рейтинг пользователя падает ниже 80, стоимость поездки значительно возрастает.
Modou Mall Business (Зал достижений Mobike в приложении)
Бизнес Magic Bean Mall — Зал достижений Mobike.После каждой поездки пользователя система будет выдавать монеты для экономии времени, зеленые монеты и монеты здоровья в различных количествах в зависимости от информации о поездке в виде очков.В зале достижений вы можете обменять соответствующие баллы на физические подарки.
Общие черты этих предприятий:
- 724365 онлайн требует очень надежной системы для обеспечения стабильной работы в любых условиях;
- Я не хочу удалять данные, я надеюсь сохранить полный объем данных все время;
- Обычно параллелизм очень велик в пиковый период, а во время активности параллелизм увеличивается в несколько раз;
- Даже если есть изменение бизнеса, бизнес не может быть приостановлен.
Поскольку это типичный OLTP-сценарий, вариантов не так много, а объем данных растет чрезвычайно быстро, данные этих баз данных могут легко достигать порядка десятков миллиардов за один год. После того, как у нас появился опыт использования TiDB в этих сценариях, мы обнаружили, что все функции TiDB очень подходят для этого масштабного сценария OLTP с высокой степенью параллелизма. Не буду здесь повторять функцию емкости/параллелизма TiDB, которая может быть расширена по желанию.Функция поддержки онлайн DDL особенно подходит для этих сервисов.Если есть необходимость в бизнес-изменениях, она не будет блокировать бизнес.Это функция, которая нужна нашему бизнесу для быстрой итерации.
В настоящее время эти два онлайн-кластера OLTP имеют десятки узлов и десятки миллиардов данных, которые очень стабильны после подключения к сети.Группа поддержки клиентов PingCAP также помогает нам в ежедневной эксплуатации и обслуживании кластеров.
Сценарий 4. Библиотека сбора журналов, например записи о незаконных парковках/разблокировка библиотеки SMS
По сравнению с традиционным решением развертывания кластеров MySQL для различных предприятий, TiDB имеет большие преимущества в масштабируемости и онлайн-анализе между базами данных.
Прежде чем развертывать TiDB, Mobike необходимо спланировать и спроектировать новый бизнес отдельно, а также спроектировать базу данных MySQL и план таблиц в соответствии с объемом данных, скоростью роста и параллелизмом бизнеса.Эти повторяющиеся предварительные работы неизбежно. С другой стороны, разные предприятия часто связаны между собой.Когда операционному отделу нужны агрегированные данные разных предприятий, это становится очень хлопотным, и необходимо построить временный центр агрегации данных, например, новый набор подбаз данных MySQL. и кластеризация подтаблиц или временное обращение к пространству Hive из большой группы данных усложняют работу по подготовке данных.
С TiDB разработка и предоставление данных таких сервисов становятся очень простыми.Каждый раз, когда появляется новый спрос, необходимо только увеличивать количество узлов TiKV в соответствии с объемом вновь добавляемых данных, потому что весь кластер становится относительно большим. , и одновременная нагрузка Способность очень сильна, и в принципе нет необходимости учитывать одновременную грузоподъемность. Особым преимуществом является то, что, поскольку у этих предприятий есть связанные предприятия, они помещаются в независимую базу данных, и для операций становится чрезвычайно удобно предоставлять определенные типы данных за определенный период времени.
На основе проекта TiSpark кластер Spark может напрямую считывать данные кластера TiDB.В некоторых сценариях, требующих предоставления данных в режиме реального времени для операций, больше нет необходимости предоставлять данные на платформу больших данных в соответствии с оригиналом, разработать решение ETL и связаться с отделом больших данных после работы Операционная логика. Вместо этого на основе существующих данных в TiDB прямо предлагаются сложные требования к анализу, и программы Spark могут быть разработаны для прямого онлайн-анализа. Таким образом, мы можем легко реализовать некоторые требования к анализу состояния в реальном времени, чтобы данные могли не только выполнять свою собственную работу, но и лучше помогать операционной группе.
Проблемы и оптимизации, возникшие во время использования
Прежде чем говорить о проблеме оптимизации, давайте посмотрим на архитектурную схему TiDB.Вся система условно разделена на несколько частей.
в:
- PD — это модуль управления всем кластером, отвечающий за: управление метаинформацией, планирование кластера и выделение глобально инкрементных непоследовательных идентификаторов.
- TiDB, уровень клиентского доступа, отвечает за синтаксический анализ SQL, оптимизацию плана выполнения и определение адреса TiKV, в котором хранятся данные, необходимые для вычислений через PD.
- TiKV — это слой хранения данных, нижний слой — это движок KV, основанный на RocksDB, на котором инкапсулированы протоколы MVCC и Raft для обеспечения безопасности и согласованности данных.
- TiSpark, уровень доступа Spark, отвечает за совместное соединение Spark и TiKV и может использовать преимущества кластера Spark при выполнении очень тяжелых сервисов OLAP.
В процессе его использования мы столкнулись со многими проблемами, но при полном общении и сотрудничестве между нами и технической командой PingCAP все они были решены относительно хорошо.Наиболее важные изоляция и оптимизация ресурсов выбраны ниже.
Базовой единицей хранения данных в ТиКВ является Регион, и каждый Регион последовательно хранит часть информации. Когда регион содержит данные из нескольких таблиц или когда несколько регионов являются горячими данными одновременно на компьютере, вероятно возникновение узких мест в ресурсах.
PD учитывал эту проблему в начале своего проектирования (HotRegionBalance был специально разработан), но его гранулярность планирования — это один регион, и все планирование основано на предположении, что потребление ресурсов каждым регионом одинаково, и связь между ними, и в то же время старайтесь, чтобы Регион равномерно распределялся по всем Магазинам.
Однако, когда в кластере одновременно размещается несколько библиотек или библиотека содержит несколько таблиц, вероятность возникновения узких мест в ресурсах значительно возрастает.
В ответ на эту проблему мы сотрудничали с технической командой PingCAP, чтобы оптимизировать TiDB следующим образом.
Оптимизация 1: разделение на основе таблиц
Целью этой модификации является решение проблемы взаимного влияния данных малых таблиц.
Когда новые данные таблицы вставляются в регион, TiKV вычисляет tableID в соответствии с диапазоном ключей текущего региона.Если он обнаружит, что вставленный ключ не находится в этом диапазоне ключей, он заранее разделит регион, что гарантирует, что каждый Регион содержит только одну табличную информацию.
Оптимизация 2: изоляция ресурсов на уровне таблицы
В то же время мы добавили отношение сопоставления между TableID и пространством имен, а также отношение сопоставления между NameSpace и TiKV Store в PD. Путем сохранения вышеуказанного отношения в eEtcd гарантируется безопасность отношения сопоставления.
Когда данные вставлены, TableID можно получить на уровне TiDB, а затем можно найти TiKV, в котором находится целевой регион, из PD, чтобы гарантировать, что вновь вставленные данные не будут помещены в другие TiKV.
Кроме того, мы также совместно разработали и внедрили планировщик NameSpace с командой PingCAP, который планирует неструктурированный регион обратно в TiKV, где он должен быть, чтобы гарантировать, что данные не будут мешать друг другу на уровне таблицы.
Оптимизация третья: инструменты управления
Последняя проблема связана с управлением пространством имен.
К счастью, TiDB сохраняет достаточную гибкость на ранней стадии разработки: благодаря исходному интерфейсу TiDB нам нужно только вызвать соответствующий API, чтобы получить TableID через имя таблицы.
В то же время мы добавили HTTP-интерфейс в консоль командной строки pc-ctl PD для управления и подтверждения соответствия между Table Name и Table ID.
постскриптум
Почти за год, прошедший с момента развертывания TiDB, в Mobike произошло десятикратное увеличение числа пользователей и десятикратного увеличения данных о ежедневных циклах.Опираясь на онлайн-возможности расширения емкости TiDB, мы выполнили несколько расширений базы данных и замен серверов, а также эти операции оказывают значительное влияние на бизнес.Это полностью прозрачно, и мы можем больше сосредоточиться на разработке и оптимизации бизнес-программ, не разбираясь в правилах шардинга базы данных.Для быстрорастущих стартапов это имеет сильное эталонное значение . Кроме того, наше глубокое участие в разработке TiDB и тесное взаимодействие с сообществом открытого исходного кода также позволило нам получить множество полезных отзывов, что значительно снизило стоимость обслуживания кода.
В будущем мы будем работать с PingCAP для дальнейшего обогащения инструментов управления несколькими кластерами, проведения более глубоких исследований и разработок, дальнейшего повышения производительности TiDB и применения TiDB для большего количества предприятий.