Гетерогенное изменение Autohome с SQL Server на TiDB

задняя часть TiDB

Автор: Технический колледж Autohome - Группа технической архитектуры

SQL Server + .Net — это стандартный стек технологий многих ранних Интернет-компаний.Хотя TiDB — это база данных, совместимая с протоколом и экологией MySQL, бизнес-сценарии, к которым применим TiDB, универсальны. Сегодня, когда популярны новые технологии с открытым исходным кодом, Autohome провела инновационную демонстрацию беспрепятственного перехода с SQL Server на TiDB.

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

1. Предыстория проекта

Сообщество Autohome было запущено в 2005 году. Оно является одним из старейших предприятий Autohome и за последние 14 лет накопило сотни миллионов постов и миллиарды ответов. В настоящее время ежедневно регистрируются десятки миллионов DAU и миллиарды посещений. , Средний ежедневный объем звонков составляет более 1 миллиарда раз. За этот период в нем произошли обновления и реконструкция архитектуры, обновление стека технологий и т. д., но его данные всегда хранятся в SQL Server. Поскольку данные продолжали расти, мы столкнулись с таким количеством узких мест в использовании базы данных SQL Server, что нам пришлось искать новую замену базе данных.

2. Узкие места при использовании SQL Server

С постоянным расширением бизнеса количество посещений и публикаций в сообществе Autohome продолжает расти, и все больше и больше проблем с базами данных.Вот две проблемы, которые необходимо решить быстро:

  1. Исторически сложилось так, что библиотека ответов сообщества Autohome использовала структуру подбазы данных и подтаблицы для решения таких проблем, как снижение производительности, когда одна таблица SQL Server слишком велика. На данный момент база данных ответов насчитывает более 100 баз данных и более 1000 таблиц (подрепозитории и таблицы в соответствии с идентификатором сообщения). Самой по себе проблемы нет, код пишется, куда данные писать, а где читать. Однако при разработке приложений и изменении требований мы обнаружили, что структура подбазы данных и подтаблицы трудно соблюдается при реализации определенных требований. Нам нужны данные логически в таблице.

  2. В последние годы, с ускоренным ростом бизнеса, количество данных росло как на дрожжах, при этом емкость жестких дисков ограничена, и количество жестких дисков, которые можно расширить на каждом сервере, также ограничено. И это дело вначале было очень сложным, с множеством смежных проектов.Даже сейчас мы с ним знакомы, нам все равно нужно обращать на это внимание каждый раз, когда мы меняем сервер, а сервер базы данных большой емкости стоит дорого. Нам нужно сделать расширение невидимым для приложения.

3. Исследование распределенной базы данных

3.1 Определите направление

В конце 2018 года компания создала группу виртуальной архитектуры для исследования новой базы данных для решения проблем, с которыми сталкивается сообщество Autohome. После различных анализов и тестов в начале этого года было определено направление на распределенные базы данных.Всего были исследованы три популярные распределенные базы данных: TiDB (PingCAP), Ignite (ASF-TLP) и CockroachDB. После бесчисленных тестов мы наконец выбрали TiDB по следующим причинам:

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

  2. Поддерживать хорошую техническую связь с официальными лицами TiDB;

  3. Компания TiDB находится в Пекине, любые вопросы можно решить лично;

  4. Архитектура дизайна TiDB лучше;

  5. Официальное сообщество более активно и документация богата;

  6. Официальные технические специалисты часто приезжают в компанию для общения.

Студенты отдела исследований и разработок TiDB приехали в Чжицзя для технического обмена

Выезжаем в TiDB на систематическое курсовое обучение

Ниже приводится официальное описание TiDB:

TiDB — это продукт конвергентной базы данных, ориентированный на онлайн-обработку транзакций и онлайн-аналитическую обработку (HTAP: гибридная транзакционная/аналитическая обработка) и другие важные характеристики. В то же время он совместим с протоколом MySQL и экологией, с удобной миграцией и чрезвычайно низкими затратами на эксплуатацию и обслуживание.

Из этого нетрудно сделать вывод, что TiDB эффективно решила наши болевые точки при применении SQL Server:

  • Горизонтальное масштабирование: узлы могут быть добавлены в любое время в текущем кластере, и узлы могут быть легко заменены.
  • Массивная поддержка данных: исходя из его характеристик и опыта, используемого в отрасли, можно легко обрабатывать один миллиард или даже десятки миллиардов данных.
  • Высокая доступность: по сравнению с режимом master-slave в SQL Server, TiDB основан на протоколе Raft, который может обеспечить 100-процентную согласованность данных и автоматическое восстановление после сбоя, когда доступно большинство реплик.
  • HTAP: сама TiDB поддерживает определенный уровень сценариев OLAP, а более сложный анализ OLAP можно выполнить с помощью проекта TiSpark. Для более глубоких приложений OLAP мы уже на пути к практике.

3.2 Практика приносит истинное знание

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

  1. Тест OLTP: 20 миллионов данных, тест 500 одновременных потоков, в тесте сценария OLTP 99% времени отклика TiDB находится в пределах 16 мс, что соответствует потребностям бизнеса. И когда объем данных становится все больше и больше, TiDB будет показывать все большие преимущества.В будущем вы также можете улучшить производительность чтения и записи, добавив узлы TiDB/PD/TiKV, как показано на следующем рисунке:

  2. Тест OLAP: тест 50G TPC-H, TiDB имеет большое преимущество в скорости по сравнению с MySQL:

    TPC Benchmark™H (TPC-H) — это тест поддержки принятия решений. Он состоит из набора бизнес-ориентированных специальных запросов и параллельных модификаций данных. Данные, выбранные для запроса и заполнения базы данных, имеют широкое значение для всей отрасли. Этот эталонный тест иллюстрирует систему поддержки принятия решений, которая анализирует большие объемы данных, выполняет запросы высокой сложности и дает ответы на ключевые вопросы бизнеса.

  3. Аномальный тест: мы протестировали производительность PD и TiKV в случае нештатного простоя, который мало влияет на бизнес и может обеспечить автоматическое восстановление после сбоя.

4. План миграции

4.1 Проблемы, которые необходимо решить перед миграцией

Перед реальной миграцией данных нам еще предстоит решить несколько практических проблем:

  • Некоторые типы полей SQL Server и TiDB различаются. Проконсультировавшись с соответствующими документами, создайте таблицу в TiDB после соответствующих различных полей один за другим, таких как точность DATETIME.

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

  • Как обеспечить согласованность данных при однократном импорте миллиардов данных и последующей добавочной синхронизации.

  • Если TiDB сталкивается с непредсказуемыми проблемами во время производства и не может быть решен в течение некоторого времени, мы должны немедленно переключиться на SQL Server, чтобы гарантировать, что это не повлияет на бизнес. Другими словами, данные, сгенерированные в TiDB, необходимо синхронизировать с SQL Server в режиме реального времени.

  • Из-за большого количества посещений время переключения должно контролироваться в секундах.

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

4.2 Общая схема архитектуры миграции

На следующем рисунке представлена ​​схема архитектуры всего нашего процесса миграции, включая полную синхронизацию, добавочную синхронизацию с SQL Server на TiDB и обратную синхронизацию с TiDB на SQL Server.

Теперь, что нужно определить, так это процесс миграции всего проекта, с общим направлением цель будет более ясна в реализации.

С точки зрения бизнес-формы и объема данных сообщества Autohome, офлайн-миграция более чем на десять часов совершенно неприемлема, мы можем завершить миграцию только во временном окне 1:00-3:00 утра, и чем короче время, тем лучше.

Поэтому мы выбираем решение онлайн-миграции.Онлайн-миграция немного сложнее.Процесс включает в себя подготовку полного объема данных, а затем синхронизацию инкрементных данных в режиме реального времени.После синхронизации данных продолжается (с задержкой в ​​​​секунды) , трафик чтения приложения обновляется последовательным обновлением. Переключитесь на TiDB.

Наблюдайте за нормальной работой приложения, выполните короткое завершение работы и отключите разрешение на запись SQL Server, а также убедитесь, что никакие данные не будут снова записываться в SQL Server, а затем трафик записи можно будет направить в TiDB. завершено.

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

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

Давайте подробно расскажем о внедрении полной суммы и инкрементной синхронизации.

5. Полная синхронизация

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

Yugong — это инструмент миграции и синхронизации данных Oracle, запущенный Alibaba, и автор alswl реализует на его основе поддержку источников данных SQL Server. Мы не будем вдаваться в детали метода использования Yugong здесь, заинтересованные студенты могут проверить его самостоятельно.

Внимательно прочитав проект Великого Бога и проведя соответствующие тесты, я обнаружил, что он не может удовлетворить наши потребности на 100%.

Поток данных Yugong — это стандартный процесс ETL, и существует три категории экстрактора, транслятора и приложения для реализации процесса ETL.

Давайте сначала поговорим об экстракторе, Первоначальный метод настройки Yugong заключается в записи таблицы библиотеки для экспорта в файл конфигурации, что слишком нереально для 1000+ таблиц. Здесь мы добавили новую функцию.Не настраивая имя экспортируемой таблицы, читать все пользовательские таблицы в базе данных и выполнять регулярное сопоставление через новый элемент конфигурации, чтобы определить, какие таблицы нуждаются в данных.Синхронизировать.

#查询表
SELECT name FROM sys.databases WITH (nolock) WHERE state_desc = 'ONLINE'

#查询开启CDC的表
SELECT name FROM %s.sys.tables t WITH (nolock) JOIN %s.[cdc].[change_tables] ct WITH (nolock) ON t.object_id = ct.source_object_id

Во-вторых, после слияния базы данных и таблиц автоматически увеличивающиеся идентификаторы первичных ключей каждой таблицы в исходном SQL Server конфликтуют, поэтому добавляется новая реализация RowDataMergeTranslator, функция которой заключается в чтении RowData в памяти и последующем преобразовании. данные строки, отбросить его исходный столбец первичного ключа и вместо этого использовать TiDB для его создания. И решите, какие таблицы должны реализовать эту функцию в соответствии с файлом конфигурации.

record.removeColumnByName(config.getDiscardKey());

Окончательный Applier не изменился, а обработанные данные напрямую записываются в TiDB.

С тех пор мы решили вопрос объединения библиотек и таблиц.

6. Инкрементальная синхронизация и проверка в реальном времени

При реализации этой части требований мы применили CDC SQL Server, а также добавили функцию отсрочки проверки корректности данных на основе инкрементной синхронизации. Для получения дополнительной информации о CDC я не буду повторяться здесь, вам просто нужно знать, что он может получать инкрементные данные, см.официальный документ ЦКЗ.

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

Как видно из приведенной выше блок-схемы, Producer считывает журнал CDC с SQL Server, преобразует его в сообщение, содержащее информацию таблицы, информацию столбца и данные строки, и доставляет его в Kafka. После того, как нижестоящие потребители извлекают сообщения, они преобразуют данные в SQL-операторы, совместимые с MySQL, и выполняют их в TiDB (здесь также объединены репозитории и таблицы), тем самым реализуя весь процесс инкрементной синхронизации данных.

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

После их реализации и перехода к этапу тестирования мы обнаружили проблему: более 1000 таблиц ответов соответствуют более чем 1000 таблицам журналов CDC, а одному производителю необходимо открыть более 1000 потоков. При опросе этих таблиц с заданным интервалом в 5 секунд ЦП сервера сразу переполняется, что приводит к большому количеству ожидающих потоков, и своевременность опроса журнала CDC не может быть гарантирована. Анализируя бизнес-запросы и запросы администраторов баз данных, мы знаем, что 95% ответов, генерируемых сообществом Autohome каждый день, сосредоточены в последних 5% сообщений. Другими словами, у нас есть только десятки таблиц, которым нужно так часто извлекать журналы CDC.Для других таблиц мы решили эту проблему, увеличив интервал опроса и развернув их в пакетном режиме.

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

  • Использование одной темы раздела и одной программы-потребителя гарантирует, что порядок добавочной синхронизации и проверки строго согласован, но производительность этого решения относительно низкая, а доступность не может быть гарантирована.

  • Мы добавляем версию строки в строку таблицы в SQL Server и синхронизируем отметку версии с TiDB. Значение сравнивается во время проверки, и если оно не соответствует, проверка будет отклонена. Эта схема потеряет некоторые проверочные образцы, но может повысить производительность и доступность за счет добавления разделов и потребителей.

7. План отката

Как мы упоминали ранее, когда проект переключается на TiDB, необходимо предотвратить возникновение непредвиденных проблем, и в любой момент можно вернуться к SQL Server, чтобы быть в безопасности.

TiDB BinlogДелает это на одном дыхании. Мы используем официальный Pump and Drainer, чтобы извлечь Binlog в Kafka, разобрать содержимое изменений данных, вычислить, какой базе данных и какой таблице изначально принадлежали данные в SQL Server по бизнес-идентификатору, а затем синхронизировать данные.

Разбор бинлога (протокол Protobuf)

Какие таблицы базы данных записываются идентификатором данных бизнес-решения

8. Миграция TiDB и трансформация бизнеса сообщества Autohome

Что касается трансформации бизнеса, то из-за исторического накопления есть много мест, которые необходимо изменить, которые распределены по различным проектам.Мы принимаем метод поиска реализации через интерфейс, поиск кода и DBA, чтобы помочь получить SQL чтобы гарантировать, что 100% релевантной информации охвачено.Только таким образом мы можем гарантировать, что не будет сбоя после выхода в Интернет.

  • Уровень доступа к данным добавляет поддержку синтаксиса MySQL.

  • Удалите хранимые процедуры в SQL Server.

  • Операторы и поддержка функций SQL Server и TiDB (MySQL) различны, поэтому они модифицируются, тестируются и оптимизируются один за другим.

  • В соответствии с принципом индекса TiDB и оператором отсортированного SQL перестройте индекс.

В то же время мы оптимизировали каждый кусок SQL после преобразования, чтобы можно было точно попасть в оптимальный индекс, чтобы 99% сервисов TP имели время отклика 12 мс и 99,9% объема данных уровня миллиарда , Время отклика составляет 62 мс.

9. Построение периферийной системы TiDB

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

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

  • Разработан инструмент для анализа медленного SQL в режиме реального времени — TiSlowSQL, который может предоставлять в реальном времени многомерные всепредставленные отчеты SQL, помогающие нам быстро обнаруживать ошибки на уровне кластера, вызванные медленным SQL.

  • Чтобы решить проблему единой точки мониторинга, мы разработали набор инструментов мониторинга для мониторинга основных компонентов TiDB, а затем перенесем систему мониторинга на облачную платформу Zhijia.

  • В Autohome University проходят регулярные технические тренинги, а внутри группы регулярно проводится технический обмен и обобщение опыта.

TiSlowsql - это также команда операций и обслуживания Autohome для участия в проекте Hackhathon. Пожалуйста, с нетерпением ждем последующих статей для конкретного контента!

X. Резюме и перспективы

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

  • Благодаря непрерывной оптимизации SQL текущий онлайн-TP99 стабилен и не сильно отличается от того, что было до миграции, что соответствует результатам тестирования. Он не знает о пользователях и услугах.

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

  • В ходе этой миграции мы накопили большой опыт в преобразовании SQL Server в TiDB и можем предоставить техническую поддержку другим командам по использованию распределенной базы данных TiDB, что позволит другим командам сэкономить время в процессе миграции.

  • В настоящее время мы находимся в официальном контакте с TiDB и готовы предоставить план миграции и независимую от бизнеса логику миграции сообществу с открытым исходным кодом.

Переход с SQL Server на TiDB, с традиционного реляционного на распределенный HTAP, с коммерческой авторизации на сообщество с открытым исходным кодом — это крупная технологическая трансформация в истории сообщества Autohome.

У Autohome есть много сценариев применения больших данных.Миграция с SQL Server на распределенную базу данных TiDB на этот раз заложила хорошую основу для переноса других предприятий на TiDB в будущем, а также установила хороший механизм регулярной связи с официальными лицами TiDB. Мы надеемся, что официальный TiDB будет продолжать быстро обновляться, как всегда, и мы также будем сотрудничать с официальным лицом TiDB для разработки некоторых более практических функций.

При сомнениях или опыте использования TiDB вы можете авторизоватьсяwww.asktug.comОбщайтесь со всеми~

Категории