Предыстория и статус-кво

В последние годы традиционные службы реляционных баз данных на основе MySQL были трудно поддержать взрывной рост бизнеса Meituan, который побудил нас исследовать более разумные решения для хранения данных и практиковать новые методы работы и технического обслуживания. Когда распределенная база данных ярко светит, команда Meituan DBA вместе с командой хранения инфраструктуры, запустила проект распределенного базы данных в начале 2018 года.

Рисунок 1 Дисплей продукта Meituan Dianping

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

У Meituan много бизнес-направлений.Мы постепенно продвигаем запуск в соответствии с бизнес-характеристиками и важностью.На данный момент запущено 10 кластеров и около 200 физических узлов.Большинство из них - приложения типа OLTP.В настоящее время стабильно работают . Кластеры, которые были запущены изначально, уже обслуживали такие предприятия, как дистрибуция, путешествия, QuickPass и винные путешествия. Несмотря на то, что архитектура TiDB относительно ясна, а ее услуги относительно стабильны и бесперебойны, исходя из текущего объема данных Meituan и существующей стабильной системы хранения, продвижение новой системы обслуживания хранилища требует сопутствующих инструментов и систем. первоначальное исследование интеграции, еще предстоит пройти долгий путь. Отдельно будут представлены следующие аспекты:

Ломать от 0 до 1, сосредоточившись на том, что делать.
Как планировать и внедрить доступ к различным сценариям обслуживания и миграцию существующих услуг.
Введены некоторые типичные проблемы после перехода в Интернете.
Дальнейшие планы и перспективы на будущее.

2. Предварительные исследования и испытания

2.1 Позиционирование TiDB

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

Протокол, совместимый с MySQL: это обязательно.
Онлайн расширение: данные обычно имеют незначительные, фрагментацию для поддержки расщепления и автоматической миграции, а процесс миграции должен попытаться сделать ничего общего с бизнесом.
Сильная согласованная распределенная транзакция: транзакция может охватывать фрагментацию, выполнение между узлами, строгую и согласованную.
Поддержка вторичного индекса: это необходимо для совместимости с бизнесом MySQL.
Производительность: должны быть удовлетворены бизнес-характеристики MySQL, высокая параллельная производительность OLTP.
Межмашинное обслуживание: необходимо убедиться, что любое машинное помещение не работает, и услуга может быть автоматически переключена.
Двойная запись в компьютерных залах: Поддержка двойной записи в компьютерных залах является серьезной проблемой в области баз данных, важным ожиданием для распределенных баз данных и важным требованием для Meituan на следующем этапе.

Хотя некоторые традиционные решения в отрасли поддерживают сегментирование, они не могут автоматически разделять, мигрировать или поддерживать распределенные транзакции.Есть также некоторые решения, которые разрабатывают согласованные протоколы на традиционной MySQL, но они не могут обеспечить линейное расширение.В конце концов, мы решили работать с нами Спрос наиболее близок к TiDB. Он полностью совместим с синтаксисом и функциями MySQL, имеет гибкие функции онлайн-расширения и сжатия, поддерживает транзакции строгой согласованности ACID, может быть развернут в компьютерных залах для обеспечения аварийного восстановления в компьютерных залах, поддерживает многоузловую запись и может использоваться для бизнеса. как автономный MySQL.

2.2 Тест

Мы провели много исследований, испытаний и проверок официально заявленных выше упомянутых преимуществ.

Во-первых, нам нужно знать подробности расширения, переноса разделения регионов, сопоставления схемы с KV и принципа реализации распределенных транзакций. Что касается решения TiDB, мы ссылаемся на многие документы Google и читаем их, что помогает нам понять структуру хранения TiDB, алгоритм транзакций, безопасность и т. д., в том числе:

Spanner: глобально распределенная база данных Google
Large-scale Incremental Processing Using Distributed Transactions and Notifications
In Search of an Understandable Consensus Algorithm
Online, Asynchronous Schema Change in F1

Мы также проводили регулярные тесты производительности и функциональные тесты для сравнения с показателями MySQL.Одним из наиболее специальных тестов является доказательство того, что 3 копии развернуты в компьютерных комнатах, что действительно может гарантировать, что каждая компьютерная комната распространяется с копией, таким образом гарантируя, что любой компьютерный зал распределен, простои не приводят к потере более половины реплик. Мы тестировали по следующим пунктам:

Поддерживает ли Raft узлы Learner при расширении, чтобы гарантировать, что 2/3 копии не будут потеряны при выходе из строя одной компьютерной комнаты.
Надежен ли приоритет метки на ТиКВ, и может ли он гарантировать, что количество копий в каждой машинной комнате будет по-прежнему абсолютно средним, когда машины в машинной комнате неравномерны.
В реальном тесте одна компьютерная комната не работает, TiDB находится в условиях высокой параллелизма, количества запросов в секунду, времени отклика, количества ошибок и потери окончательных данных.
Вручную сбалансируйте регион с другим компьютерным залом, если он вернется автоматически.

По результатам испытаний все соответствует нашим ожиданиям.

3. Строительство экосистемы хранения

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

3.1 Уровень доступа к услугам

В настоящее время существует два основных метода доступа к службам для MySQL: доступ к DNS и доступ к клиенту Zebra. На предварительном этапе исследования мы выбрали метод доступа DNS + компоненты балансировки нагрузки.Если узел TiDB-Server не работает, это можно узнать по балансировке нагрузки за 15 с, что просто и эффективно. Структура бизнеса представлена на следующем рисунке:

Рис. 2. Схема бизнес-архитектуры

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

3.2 Мониторинг тревоги

В настоящее время Meituan использует платформу Mt-Falcon для мониторинга сигналов тревоги. Путем настройки различных подключаемых модулей на Mt-Falcon можно реализовать индивидуальный мониторинг различных компонентов. Кроме того, он также объединит Puppet для определения разрешений разных пользователей и распределения файлов. Пока мы пишем скрипт плагина, необходимые файлы, установка и контроль разрешений могут быть завершены. Архитектура мониторинга показана на следующем рисунке:

Рис. 3. Схема архитектуры мониторинга

TiDB имеет богатые метрики мониторинга, используя популярные Prometheus + Grafana, кластер имеет более 700 метрик. Как видно из официальной схемы архитектуры, каждый компонент будет проталкивать свою метрику в PushGateWay, а Prometheus для захвата данных будет обращаться напрямую к PushGateWay.

Так как нам нужна конвергенция компонентов, родной набор TiDB Prometheus на кластер не способствует агрегации, анализу и настройке мониторинга, а аларм реализован на Mt-Falcon лучше, поэтому не надо создавать еще один на AlertManager. Поэтому нам нужно найти способ суммировать мониторинг и сигнализацию на Mt-Falcon, включая следующие способы:

Вариант 1: Модифицировать исходный код и пушить метрики напрямую в Falcon.Поскольку метрики разбросаны по разным частям кода, а код TiDB итерируется слишком быстро, нецелесообразно тратить силы на постоянную корректировку точек мониторинга.
Вариант 2: PushGateWay агрегирован и может быть захвачен напрямую, но PushGateWay — это единая точка, которую непросто поддерживать.
Вариант 3: Прямой захват через локальный API каждого компонента (TiDB, PD, TiKV), преимущество в том, что время простоя компонента не повлияет на другие компоненты, а реализация относительно проста.

В итоге мы выбрали третий вариант. Сложность этого решения заключается в том, что оно должно преобразовывать формат данных Prometheus в формат, распознаваемый Mt-Falcon, поскольку Prometheus поддерживает четыре типа данных: Counter, Gauge, Histogram и Summary, в то время как Mt-Falcon поддерживает только базовый Counter и Gauge, тогда как Mt-Falcon имеет меньше выражений для расчета, поэтому его нужно преобразовать и вычислить в скрипте мониторинга.

3.3 Пакетное развертывание

TIDB использует Anbible для автоматического развертывания. Быстрая итерация - это особенность TIDB. Проблемы могут быть решены быстро, но он также вызывает непредвиденный проект и версию TIDB, которая будет обновляться слишком быстро. Наши изменения в Anisible только добавят новый код, а не существующий код. Следовательно, несколько версий кластеров могут быть развернуты и поддерживаются онлайн одновременно. Если каждый кластер имеет аналимный каталог, он приведет к тому, что пустая трата пространства.

Используемый нами метод обслуживания заключается в том, что на машине с центральным управлением каждая версия имеет каталог Ansible, и каждая версия поддерживается разными файлами инвентаризации. Здесь нужно указать PingCAP, что Ansible рассматривает только развертывание в одном кластере, а большое количество развертываний будет немного проблематичным.Как и некоторые зависимые файлы конфигурации, они не могут быть настроены индивидуально в соответствии с кластером (согласно официально, PingCAP в настоящее время создает сайт на основе Cloud TiDB.Платформа HTAP будет предоставлять такие функции, как пакетное развертывание и мультиарендность, и эта проблема будет лучше решена в будущем).

3.4 Платформа автоматизированной эксплуатации и обслуживания

С увеличением количества онлайн-кластеров на повестке дня стоит создание платформы для эксплуатации и обслуживания, и Meituan использует TiDB и MySQL в основном таким же образом, поэтому большинство компонентов на платформе MySQL должны быть построены на TiDB. Платформа. Типичные базовые компоненты и решения: модуль аудита SQL, DTS, решения для резервного копирования данных и т. д. Платформа автоматизированной эксплуатации и обслуживания отображается, как показано на следующем рисунке:

Рис. 4 Отображение автоматизированной платформы управления и обслуживания

3.5 Синхронизация восходящих и нисходящих разнородных данных

TiDB является частью системы онлайн-хранилища, и ее также необходимо интегрировать в существующий поток данных компании, поэтому для ее подключения требуются некоторые инструменты. PingCAP официально входит в стандартную комплектацию соответствующих компонентов.

В настоящее время компания представляет собой относительно тяжелую комбинацию mysql и hive, и TIDB необходимо решить 2 проблемы по замене части MySQL:

MySQL to TiDB
- Миграция MySQL на TiDB требует переноса данных и инкрементной синхронизации в реальном времени, то есть DTS, Mydumper + Loader решает проблему синхронизации существующих данных, а для решения проблемы инкрементной синхронизации предоставляется официальный инструмент DM.
- MySQL широко использует автоматически увеличивающиеся идентификаторы в качестве первичных ключей. Когда подбаза данных и подтаблица MySQL объединяются в TiDB, необходимо решить проблему самоувеличивающихся конфликтов идентификаторов. Это решается удалением автоинкрементного ID и созданием собственного уникального первичного ключа на стороне TiDB. В новой версии DM также предусмотрена функция автоматической обработки первичных ключей в процессе слияния подтаблиц.
Hive to TiDB & TiDB to Hive
- Решение Hive to TiDB относительно простое, что отражает преимущества высокой совместимости между TiDB и MySQL Оператор вставки можно корректировать без корректировки, и его можно просто преобразовать на основе Hive to MySQL.
- TiDB to Hive должен быть основан на официальных компонентах Pump + Drainer. Drainer может использовать Kafka, MySQL и TiDB. Сначала мы рассматриваем возможность использования решения на рис. 5 для синхронизации с Hive с использованием режима вывода Drainer Kafka.

Рис. 5 Схема схемы TiDB to Hive

4. Использование взлома в Интернете

Для начального онлайн-бизнеса мы более осторожны. Основным принципом является: автономный бизнес -> непрофильный бизнес -> основной бизнес. TIDB был освобожден более двух лет, и претерпел много тестирования на ранней стадии. У нас также есть глубокое понимание тестирования и использования других компаний. Можно ожидать, что TIDB будет относительно стабильным онлайн , но есть еще несколько небольших проблем. В целом, нет проблем в ключевых точках, таких как безопасность и согласованность данных. Некоторые другие функционирующие проблемы и проблемы настройки параметров также были быстро и правильно решены. Вот большой комплимент одноклассников PingCap. Ответ на проблему очень быстро, и сотрудничество с нашими внутренними исследованиями и развитием Meituan также очень гармонично.

4.1 Автономный бизнес с большим объемом записи и высоким показателем QPS при чтении

Самый крупный бизнес, который мы запустили, ежедневно записывает сотни гигабайт, и на начальном этапе мы тоже столкнулись с множеством проблем.

Деловая сцена:

Стабильная запись, от 100 до 200 строк на транзакцию, запись данных 6 Вт в секунду.
Ежедневный объем записи превышает 500G и в будущем будет постепенно увеличиваться до 3T в день.
Чтение задания каждые 15 минут, 5000 запросов в секунду (низкая частота).
Время от времени запросов (низкая частота большая).

MySQL раньше использовался в качестве хранилища, но MySQL достиг узких мест по емкости и производительности, и в будущем емкость бизнеса увеличится в 10 раз. Первоначальные исследования и тестирование ClickHouse соответствовали требованиям к мощности. Тест показал, что нет проблем с запуском низкочастотного SQL, но большой одновременный запрос высокочастотного SQL не может удовлетворить спрос. -частотный SQL в ClickHouse был бы излишним, и в конце концов решили использовать TiDB.

Во время теста были смоделированы и записаны реальные данные одного дня, которые очень стабильны.Требованиям могут соответствовать как высокочастотные, так и низкочастотные запросы.После целевой оптимизации производительность OLAP SQL в четыре раза выше, чем у MySQL. Но после выхода в интернет одна за другой были обнаружены некоторые проблемы, типичные из них следующие:

4.1.1 Задержка записи в TiKV

Нижний уровень TiKV имеет 2 RocksDB в качестве хранилища. Вновь записанные данные записываются на слой L0.Когда количество слоев L0 RocksDB достигает определенного числа, оно замедляется, а если оно выше, происходит зависание для самозащиты. Конфигурация ТиКВ по умолчанию:

level0-slowdown-writes-trigger = 20
level0-stop-writes-trigger = 36

Существует 2 возможные причины появления слишком большого количества файлов L0:

Объем написанного велик, и Договор не может быть завершен.
Снимки не создаются все время, что привело к выпуску накопленных копий. ROCKSDB-RAFT создает большое количество файлов l0. Дисплей мониторинга показан на следующем рисунке:

Рис. 6 Возникновение TiKV. Экран наблюдения за остановкой записи.

Мы решили проблему с задержкой записи, выполнив следующие действия:

Замедление частоты Raft Log Compact (увеличение raft-log-gc-size-limit, raft-log-gc-count-limit)
Делайте снимки быстрее (общая производительность, включая производительность оборудования)
max-sub-уплотнения изменены на 3
максимальное количество фоновых заданий изменено на 12
Уровень 0 3 Триггеры настроены на 16, 32, 64

4.1.2 Удалить большой объем данных, сборщик мусора не успевает

В настоящее время GC TiDB является однопоточным для каждого экземпляра kv.Когда объем данных, удаляемых бизнесом, очень велик, скорость GC будет низкой, а скорость GC может не успевать за записью .

В настоящее время решается увеличением количества ТиКВ.Давно нужно менять GC на многопоточное исполнение.Официал это понял и скоро выйдет.

4.1.3 Время отклика вставки становится все медленнее и медленнее

На начальном этапе запуска бизнеса время отклика на вставку 80 строк (длительность 80 по экземпляру) составляет около 20 мс.По мере увеличения времени выполнения обнаруживается, что время отклика постепенно увеличивается до 200 мс+. За это время было исследовано множество возможных причин, и было обнаружено, что из-за быстрого увеличения количества регионов в Raftstore стало больше дел, и это была однопоточная работа.Каждому региону требовалось сердцебиение. регулярно, что привело к снижению производительности. Индикатор продолжительности ожидания предложения tikv-raft продолжает увеличиваться.

Решения проблемы:

Временное решение.
Увеличьте период сердцебиения с 1 с до 2 с, эффект будет более очевидным, дисплей мониторинга показан на следующем рисунке:

Рис. 7. Сравнение до и после оптимизации времени отклика вставки

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

4.1.4 Усеченное табличное пространство не может быть полностью освобождено

После DBA Truncate большой таблицы были обнаружены два явления: во-первых, восстановление пространства происходит медленно, а во-вторых, в конце оно не восстанавливается полностью.

Из-за базового механизма RocksDB многие данные попадают на уровень 6 и могут не очищаться. Эта необходимость открывать cdynamic-level-bytes оптимизирует стратегию сжатия и улучшит скорость восстановления пространства.
Поскольку Truncate использует интерфейс delete_files_in_range и отправляет его в TiKV для удаления файлов SST, здесь удаляются только непересекающиеся части, а степень детализации для оценки того, пересекаются ли они, — это регион, поэтому большое количество SST не может быть удалено вовремя.
Независимый от региона SST может решить проблему пересечения, но также приводит к проблеме использования диска и задержке разделения.
Рассмотрите возможность использования интерфейса RocksDB DeleteRange, но подождите, пока интерфейс стабилизируется.
Последняя версия 2.1 оптимизирована для прямого удаления пространства, занятого всей таблицей, с помощью интерфейса DeleteFilesInRange, а затем очистки небольшого количества остаточных данных, которые теперь разрешены.

4.1.5 Функция слияния открытых областей

Чтобы решить проблему слишком многих регионов, мы включали функцию слияния региона после обновления до версии 2.1, но время ответа TIDB 80 линий (продолжительность 80 по настоящему времени) до сих пор не вернулась к оригиналу и осталось в 50 мс. Расследование показало, что слой KV вернул время отклика, все еще очень быстро, и он близок к начальной, поэтому проблема находится в слое TIDB. Поведение разработчиков и позиционирования PingCap при генерации плана выполнения несовместим с версией 2.0, которая была оптимизирована.

4.2 Онлайн OLTP, бизнес чувствителен ко времени отклика

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

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

Таким образом, многие филиалы филиалов и бизнес, который вот-вот сможет разработать схемы филиалов, которым неудобно быть разветвленными, берут на себя инициативу найти нас, что согласуется с нашим позиционированием TIDB. Эти сервисы характеризуются небольшими и частыми операторами SQL, высокой согласованностью, и обычно некоторые данные имеют свойства времени. Некоторые проблемы были обнаружены после тестирования и в Интернете, но в основном есть решение.

4.2.1 После истечения времени выполнения SQL JDBC сообщает об ошибке

Бизнес иногда сообщает о сбое проверки привилегий.

Это связано с тем, что компания установила QueryTimeout в JDBC.Если SQL выполняется дольше этого времени, будет выдан QueryTimeout.kill queryкоманда, и TiDB требуется разрешение Super для выполнения этой команды, а бизнес не имеет разрешения. На самом деле, для того, чтобы убить собственный запрос, дополнительных разрешений не требуется, пока эта проблема решена:GitHub.com/обычное порно/упомянутое…Больше не нужно разрешение супер, было на линии в 2.0.5.

4.2.2 Иногда неточные планы выполнения

Фаза физической оптимизации TiDB опирается на статистику. В версии 2.0 сбор статистики выполняется вручную и оптимизирован для автоматического срабатывания при выполнении определенных условий:

Коэффициент модификации данных достигает tidb_auto_analyze_ratio.
Таблица не менялась ни минуты (в текущей версии это условие убрано).

Однако до выполнения этих условий статистическая информация неверна, что приведет к отклонениям в физической оптимизации.На этапе тестирования (версия 2.0) такой случай: бизнес-данные имеют атрибуты времени, а бизнес-запросы имеют условие 2 А , например: время + бизнес-идентификатор, но статистическая информация каждое утро может быть неточной, данные дня уже доступны, но статистическая информация не учитывается. В этом случае оптимизатор предложит использовать индекс столбца времени, но на самом деле индекс столбца идентификатора продавца более оптимизирован. Эту проблему можно решить, добавив Hint.

Было внесено большое количество оптимизаций в статистику и планирование выполнения статистики и плана выполнения, а также стабилизирована статистика обновления запроса обратной связи, которая также используется для обновления гистограмм и скетча счетчика-минимума, который, как ожидается, будет 2,1 GA. .

5. Краткий обзор

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

Далее мы ускорим использование TiDB в большем количестве бизнес-систем, а также включим TiDB в стратегический выбор баз данных нового поколения Meituan. В настоящее время мы инвестировали 3 студента DBA и ряд экспертов по вычислительным системам хранения на полную ставку, от нижнего хранилища, расчета среднего уровня, доступа к бизнес-уровню до выбора решения для хранения и проповеди, всестороннего и более глубокого глубина сотрудничества.

В долгосрочной перспективе, в сочетании с растущим масштабом бизнеса Meituan, мы официально будем сотрудничать с PingCAP для создания более сильной экосистемы:

Titan: Titan — это следующий большой шаг для TiDB, а также механизм хранения нового поколения, которого мы очень ждем. одна строка и максимальная емкость хранилища, поддерживаемая одной машиной TiKV, что значительно повышает рентабельность для крупномасштабных развертываний.
Облако TiDB (на основе Docker и K8s): облачные вычисления являются общей тенденцией. PingCAP также относительно рано появился в этой области. В августе этого года был открыт исходный код оператора TiDB. Cloud TiDB не только реализует высокоавтоматизированную работу и обслуживание базы данных , но и основанный на аппаратной изоляции Docker, что является идеальной многопользовательской архитектурой для базы данных. Мы общались с официальными одноклассниками, и их частные облачные решения также имеют значительное количество POC в Китае, что также является направлением, которое ценит Meituan.
Платформа HTAP TIDB: на основе исходного вычислительного двигателя сервера TIDB Pingcap также построил двигатель TisPark Computing Engine и сообщается с ними, что они разрабатывают механизм хранения на основе столбцов, что формирует двигатели строки нижнего уровня и колонны, Полная гибридная база данных (HTAP) верхних двух вычислительных двигателей, эта архитектура не только значительно сохраняет количество копий основных бизнес-данных во всем бизнес-цикле компании, но и экономит много затрат на рабочую силу, технологические расходы, а также Машины сходящимися технологическими стеками. Стоимость, а также решая эффективность OLAP, которая наносила его в течение многих лет. Позже мы также рассмотрим подключение некоторых реальных и квази-реальных временных систем и запросов в TIDB.

Последующие решения для физического резервного копирования, множественная запись в компьютерных залах и т. д. также являются сценариями, которые мы будем постепенно продвигать.Короче говоря, мы твердо верим, что в будущем будет все больше и больше сценариев использования TiDB в Meituan, и развитие будет становиться лучше и лучше.

В настоящее время TiDB отплыл в Meituan на уровне бизнеса и технического сотрудничества.Meituan Dianping объединит усилия с PingCAP, чтобы начать углубленную практику и исследование базы данных нового поколения. В последующем будет серия статей об исследовании и улучшении исходного кода TiDB командой Meituan-Dianping Architecture Storage, так что следите за обновлениями.

об авторе

Ин Ган, исследователь Meituan Dianping, эксперт по базам данных. Он работал в Baidu, Sina, Qunar и т. д. и имеет 10-летний опыт работы в области автоматизации эксплуатации и обслуживания баз данных, оптимизации производительности баз данных, технической поддержки крупномасштабных кластеров баз данных и оптимизации архитектуры. Владеет основными системами SQL и NoSQL, в настоящее время занимается инновациями и внедрением бизнеса компании в области NewSQL.

Ли Кун, который присоединился к Meituan в начале 2018 года, является экспертом по базам данных в Meituan. У него многолетний опыт проектирования и обслуживания архитектуры, а также автоматизированной разработки на основе MySQL, Hbase и Oracle. В настоящее время он в основном отвечает за продвижение и реализация распределенной базы данных Blade, а также платформы и периферийных компонентов.

Чанг Чун, американский эксперт группы по обзору баз данных, работал в BOCO, где к сети, шесть лет опыта MySQL DBA отрасли, накопил богатый опыт разработки схемы базы данных и оптимизации производительности, автоматизации разработки. В настоящее время TiDB сосредоточена на преобразовании и выходе на бизнес-сцену миссии США.