предисловие
Zhihu, что на классическом китайском означает «знаете ли вы?», — это китайский Quora, сайт вопросов и ответов, на котором сообщество пользователей создает, отвечает, редактирует и систематизирует различные вопросы.
Являясь крупнейшей платформой для обмена знаниями в Китае, в настоящее время у нас 220 миллионов зарегистрированных пользователей, 30 миллионов вопросов и более 130 миллионов ответов на веб-сайтах.
По мере роста пользовательской базы размер данных нашего приложения недостижим. Мы храним около 1,3 триллиона строк данных в нашем приложении Moneta (хранит сообщения, которые пользователи уже прочитали).
Ежемесячно генерируется примерно 100 миллиардов строк данных, и эта цифра будет расти, а через два года это число достигнет 3 триллионов. Поддерживая хорошее взаимодействие с пользователем, мы столкнулись с серьезными проблемами при масштабировании серверной части.
В этой статье я обсудим, как сохранить время ответа на запрос в таком большом количестве данных, и TIDB - это с открытым исходным кодом MySQL совместимая база данных гибридной транзакции / анализа (HTAP), как поддержать нас в реальном времени Наши данные.
Я расскажу, почему мы выбрали TiDB, как мы его использовали, чему научились, передовой опыт и некоторые мысли на будущее.
Наши болевые точки
В этом разделе представлена архитектура нашего приложения Moneta, идеальная архитектура, которую мы пытаемся построить, и масштабируемость базы данных как наша главная проблема.
Требования к системной архитектуре
Служба Post Feed Zhihu является ключевой системой, через которую пользователи получают контент, размещенный на сайте.
Бэкенд-приложение Moneta сохраняет посты прочитанного пользователем и отфильтровывает эти посты в постах рекомендуемой страницы.
Приложения Moneta имеют следующие характеристики:
1. Нужны данные высокой доступности
Лента постов — это первый экран, который появляется, и он играет важную роль в привлечении пользовательского трафика на Zhihu.
2. Обработка огромных данных записи
Например, в часы пик записывалось более 40 000 записей в секунду, а количество записей увеличивалось почти на 3 миллиарда записей в день.
3. Долгосрочное хранение исторических данных
В настоящее время в системе хранится примерно 1,3 трлн записей. По мере ежемесячного накопления около 100 миллиардов записей и роста, исторические данные достигнут 3 триллионов записей примерно через два года.
4. Обработка запросов с высокой пропускной способностью
В часы пик система обрабатывала в среднем 12 миллионов сообщений в секунду запросов.
5. Ограничьте время ответа на запросы до 90 мс или меньше
Это происходит даже для запросов с длинным хвостом, выполнение которых занимает больше всего времени.
6. Допускайте ложные срабатывания
Это означает, что система может вызвать множество интересных сообщений для пользователей, даже если некоторые из них будут ошибочно отфильтрованы.
Учитывая вышеуказанные факты, нам нужна архитектура приложений со следующими возможностями:
1. Высокая доступность
Когда пользователи открывают рекомендательную страницу Zhihu, это плохо для пользователей, когда они находят много сообщений, которые они уже прочитали.
2. Отличная производительность системы
Наши приложения имеют высокую пропускную способность и жесткие требования ко времени отклика.
3. Простота расширения
По мере роста бизнеса и расширения приложений мы хотим, чтобы наша система легко масштабировалась.
исследование
Чтобы построить идеальную архитектуру с перечисленными выше функциями, мы интегрировали в предыдущую архитектуру три ключевых компонента:
1. Прокси
Это перенаправляет запросы пользователей на доступные узлы и обеспечивает высокую доступность системы.
2. Кэш
Это временно обрабатывает запросы в памяти, поэтому нам не всегда нужно обрабатывать запросы в базе данных. Это может повысить производительность системы.
3. Хранение
До использования TiDB мы управляли нашими бизнес-данными в автономном MySQL. При стремительном росте объемов данных автономных систем MySQL уже недостаточно. Затем мы выбрали решение сегментирования MySQL и Master High Availability Manager (MHA), но это решение было нежелательным, когда нашу базу данных ежемесячно заполняло 100 миллиардов новых записей.
Недостатки MySQL Sharding и MHA
Сегментирование MySQL и MHA не являются хорошим решением, потому что и сегментирование MySQL, и MHA имеют свои недостатки.
Недостатки шардинга MySQL:
Код приложения становится сложным и трудным в обслуживании. Изменение существующего ключа сегмента обременительно. Обновление логики приложения влияет на доступность приложения.
Недостатки МГА:
1. Нам необходимо реализовать настройку Virtual IP (VIP) путем написания скриптов или использования сторонних инструментов.
2. MHA отслеживает только первичную базу данных.
3. Чтобы настроить MHA, нам нужно настроить беспарольную безопасную оболочку (SSH). Это может привести к потенциальным рискам безопасности.
4. MHA не обеспечивает балансировку нагрузки чтения для подчиненных серверов.
5. MHA может отслеживать доступность только главного сервера (но не подчиненного главного сервера).
Пока мы не обнаружили TiDB и не перенесли данные из MySQL в TiDB, масштабируемость базы данных оставалась слабым местом всей системы.
В официальном аккаунте ведущий архитектор отвечает «чистой архитектурой» и получает подарок-сюрприз.
Что такое TIDB?
Платформа TiDB представляет собой набор компонентов, которые при совместном использовании становятся базой данных NewSQL с возможностями HTAP.
Архитектура платформы TiDB
Внутри платформы TiDB основные компоненты следующие:
1. Сервер TiDB — это уровень SQL без сохранения состояния, который обрабатывает SQL-запрос пользователя, обращается к данным на уровне хранения и возвращает соответствующие результаты приложению. Он совместим с MySQL и работает поверх TiKV.
2. Сервер TiKV — это уровень хранилища распределенных транзакций типа «ключ-значение», где данные сохраняются. Он реплицируется с использованием консенсусного протокола Raft для обеспечения строгой согласованности данных и высокой доступности.
3. Кластер TiSpark также расположен на TiKV. Это подключаемый модуль Apache Spark, его можно использовать с платформой TiDB для поддержки запросов бизнес-аналитики (BI) сложной онлайн-аналитической обработки и запросов специалистов по данным (OLAP).
4. Сервер Placement Driver (PD) — это кластер метаданных, поддерживаемый etcd, для управления и планирования TiKV.
В дополнение к этим основным компонентам TiDB имеет экосистему инструментов, таких как сценарии Ansible для быстрого развертывания, Syncer для миграции с MySQL и миграции данных TiDB.
И TiDB Binlog для сбора логических изменений, внесенных в кластер TiDB, и предоставления добавочных резервных копий. Репликация в нисходящий поток (TiDB, Kafka или MySQL).
К основным функциям TiDB относятся:
1. Горизонтальная масштабируемость.
2. Синтаксис, совместимый с MySQL.
3. С прочной согласованностью распределенных транзакций.
4. Облачная архитектура.
5. Минимальное извлечение, преобразование, загрузка (ETL) с использованием HTAP.
6. Отказоустойчивость и восстановление плота.
7. Изменения онлайн-схемы.
Как мы используем TiDB
В этом разделе я покажу вам, как запустить TiDB в архитектуре Moneta вместе с показателями производительности для приложений Moneta.
Наша архитектура TiDB
Архитектура TIDB в приложении Moneta Zhihu
Мы развернули TiDB в системе, и общая архитектура приложения Moneta стала такой:
1. Верхний уровень: масштабируемые клиентские API и прокси-серверы без сохранения состояния. Эти компоненты легко расширяются.
2. Средний уровень: Компоненты мягкого состояния и иерархический кэш Redis в качестве основной части. Когда служба прерывается, эти компоненты могут самостоятельно восстанавливать службу, восстанавливая данные, сохраненные в кластере TiDB.
3. Нижний уровень: кластер TiDB хранит все данные с отслеживанием состояния. Его компоненты обладают высокой доступностью, и он может самостоятельно восстанавливать свои службы в случае сбоя узла.
В этой системе все компоненты самовосстанавливаемы, и вся система имеет глобальный механизм мониторинга сбоев. Затем мы используем Kubernetes для оркестрации всей системы, чтобы обеспечить высокую доступность всего сервиса.
Индикатор производительности TIDB
Поскольку мы применили TiDB в нашей производственной среде, наша система отличается высокой доступностью и простотой масштабирования, а производительность системы была значительно улучшена. Например, примите набор показателей производительности для приложения Moneta в июне 2019 года.
Запись 40 000 строк данных в секунду в часы пик:
Строки данных, записываемых в секунду (тысячи)
Проверяйте 30 000 запросов и 12 миллионов сообщений в секунду в часы пик:
Строки данных, записываемых в секунду (тысячи)
Время отклика 99-го процентиля составляет около 25 миллисекунд, а время отклика 999-го процентиля составляет около 50 миллисекунд. На самом деле среднее время отклика намного меньше этих цифр, даже для запросов с длинным хвостом, которые требуют стабильного времени отклика.
Время отклика по процентилю раздела 99
999-й процентиль времени отклика
что мы узнали
Наш переход на TiDB не был гладким, и здесь мы хотели бы поделиться некоторыми извлеченными уроками.
Импорт данных быстрее
Мы используем TiDB Data Migration (DM) для сбора инкрементных файлов Binlog MySQL, а затем используем TiDB Lightning для быстрого импорта данных в кластер TiDB.
Сяол, программист на официальном счете, ответил «Java», чтобы получить вопросы собеседования Java и неожиданный подарочный пакет ответов.
Нас удивило то, что импорт этих 1,1 трлн записей в TIDB занял четыре дня. Если мы логически записываем данные в систему, это может занять месяц или больше. Если у нас будет больше аппаратных ресурсов, мы сможем быстрее импортировать данные.
Уменьшить задержку запросов
После завершения миграции мы протестировали небольшой объем читающего трафика. Когда приложение Moneta впервые заработало, мы обнаружили, что задержка запросов не соответствует нашим требованиям. Чтобы решить проблемы с задержкой, мы работали с инженерами PingCap над настройкой производительности системы.
За это время мы накопили ценные данные и знания в области обработки данных:
1. Некоторые запросы чувствительны к задержке запроса, некоторые нет. Мы развертываем отдельную базу данных TiDB для обработки запросов, чувствительных к задержкам. (Другие запросы, не чувствительные к задержке, обрабатываются в разных базах данных TiDB.)
2. Таким образом, большие запросы и запросы, чувствительные к задержкам, обрабатываются в разных базах данных, и выполнение первых не повлияет на вторые.
3. Для запросов, у которых нет идеального плана выполнения, мы пишем подсказки SQL, чтобы помочь механизму выполнения выбрать наилучший план выполнения.
4. Мы используем низкую точечную метку Memestamp Oracle (TSO) и подготовленные утверждения для уменьшения сетевых круглых поездок.
Ресурсы для оценки
Прежде чем мы попробовали TiDB, мы не анализировали, сколько аппаратных ресурсов нам нужно для поддержки того же объема данных на стороне MySQL.
Чтобы снизить затраты на обслуживание, мы развернули MySQL в топологии «один главный — один подчиненный». Напротив, протокол Raft, реализованный в TiDB, требует как минимум трех реплик.
Следовательно, нам нужно больше аппаратных ресурсов для поддержки бизнес-данных в TiDB, и нам нужно заранее подготовить машинные ресурсы.
Как только наш центр обработки данных будет настроен правильно, мы сможем быстро завершить оценку TiDB.
Ожидания от TiDB 3.0
Это та же архитектура, которая знает приложения для защиты от спама и Moneta. Мы попробовали TIDB 3.0 (TIDB 3.0.0-RC.1 и TIDB 3.0.0-RC.2) или TIDB 3.0 (TIDB 3.0.0-RC.1 и TIDB 3.0.0-RC.2) в приложениях для защиты от спама. для производственных данных.
①Titan сокращает задержку
Приложения для защиты от спама страдают от серьезной задержки запросов и записи.
Мы слышали, что TiDB 3.0 представит Titan, механизм хранения ключей и значений, чтобы уменьшить усиление записи в RocksDB (базовом механизме хранения в TiKV) при использовании больших значений. Чтобы попробовать эту функцию, мы включили Titan после выпуска TiDB 3.0.0-rc.2.
На приведенных ниже графиках показаны задержки записи и запросов по сравнению с RocksDB и Titan соответственно:
Запись и запрос задержки в RocksDB и Titan
Статистика показывает, что после включения титана, пишите, и задержка запросов резко снизилась. Это действительно удивительно! Когда мы видим статистику, мы не можем поверить своим глазам.
Разбиение разбиения Улучшает производительность запроса
Мы также используем функцию секционирования таблиц TiDB 3.0 в нашем приложении для защиты от спама. Используя эту функцию, мы можем вовремя разделить таблицу на несколько разделов.
Когда приходит запрос, он будет выполняться в разделе, охватывающем целевой диапазон времени. Это значительно повышает производительность нашего запроса.
Давайте рассмотрим, что произойдет, если мы в будущем внедрим TiDB 3.0 в Moneta и антиспамовые приложения.
③TiDB 3.0 в приложении Moneta
TiDB 3.0 имеет такие функции, как пакетный обмен сообщениями в gRPC, многопоточный Raftstore, управление планами SQL и TiFlash. Мы считаем, что это добавит блеска приложению Moneta.
④ Сообщения в GRPC и Multi-Threaded RaftStore
Пропускная способность записи Moneta превышает 40 000 транзакций (TPS) в секунду, а TIDB 3.0 может отправлять и получать сообщения RAFT пакетами, а также может обрабатывать логику Region RAFT в нескольких потоках. Мы считаем, что эти функции значительно улучшат возможности нашей системы.
⑤Управление планом SQL
Как упоминалось выше, мы пишем множество SQL-подсказок, чтобы оптимизатор запросов мог выбрать наилучший план выполнения.
В TiDB 3.0 добавлена функция управления планами SQL, которая может привязывать запросы к конкретным планам выполнения непосредственно на сервере TiDB. Используя эту функцию, нам не нужно изменять текст запроса, чтобы ввести подсказку.
⑥TiFlash
На TiDB DevCon 2019 я впервые услышал, что TiFlash — это механизм расширенной аналитики TiDB.
Он использует технологию хранения, ориентированной на столбцу для реализации высоких коэффициентов сжатия данных и прилагают алгоритмы консистенции расширения в репликации данных для обеспечения безопасности данных.
Так как у нас огромные объемы данных записываются с высокой пропускной способностью, поэтому мы не можем каждый день копировать данные в ETL Hadoop для анализа. Но что касается TiFlash, мы надеемся, что сможем легко проанализировать наш огромный объем данных.
⑦ TiDB 3.0 в приложении для защиты от спама
Приложения для защиты от спама имеют более высокую скорость записи по сравнению с огромным историческим объемом данных приложений Moneta.
Однако он запрашивает только данные, сохраненные за последние 48 часов. В этом приложении данные растут на 8 миллиардов записей и 1,5 ТБ в день.
Поскольку TiDB 3.0 может отправлять и получать сообщения Raft пакетами и может обрабатывать логику Region Raft в несколько потоков, мы можем управлять приложениями с меньшим количеством узлов.
Раньше мы использовали семь физических узлов, а теперь нам нужно только пять. Эти функции повышают производительность, даже если мы используем стандартное оборудование.
Что дальше
TiDB — это база данных, совместимая с MySQL, поэтому мы можем использовать ее так же, как MySQL.
Благодаря горизонтальной масштабируемости TiDB теперь мы можем свободно масштабировать нашу базу данных, даже если нам нужно справиться с более чем триллионом записей.
До сих пор мы использовали довольно много программного обеспечения с открытым исходным кодом в наших приложениях. Мы также многое узнали о решении системных проблем с помощью TiDB.
Мы решили участвовать в разработке инструментов с открытым исходным кодом и участвовать в долгосрочном развитии сообщества. Благодаря нашим совместным усилиям с PingCAP TiDB станет более мощным.
Наконец
Я собрал копию здесь: материалы, связанные с Mybatis, документы Mysql, карты мозга, серия семейных ведер Spring, систематические материалы Java (включая основные знания Java, темы интервью и последние 20 лет реальных вопросов в Интернете, электронные книги и т. д. .) Нуждающиеся друзья могут подписаться на официальный аккаунт [Программа Юань Сяован], чтобы получить его.