Приветствую всех вОблако Tencent + сообщество, получить больше крупной технической практики Tencent по галантерее~
Эта статья написанаЛи ЮсенОпубликован вКолонка «Облако + сообщество»
Ли Юсен,Облако Tencent PostgreSQLГлавный архитектор, архитектор команды базы данных Tencent, ответственный за проектирование архитектуры, исследования и разработку основной базы данных платежной торговой системы WeChat, основной член сообщества PostgreSQL-x2 и обладатель ряда национальных патентов на изобретения. Занимается разработкой ядра PG и проектированием архитектуры более 10 лет.
До 2015 года платежный бизнес WeChat развивался быстро, и для безопасной и эффективной поддержки основного бизнеса платежной торговой системы WeChat требовалась база данных.Эта важная задача легла на PostgreSQL собственной разработки команды базы данных Tencent.
В июле 2016 года Tencent Cloud выпустилаApsaraDB для PostgreSQL, предоставляет две версии самостоятельно разработанной Tencent оптимизированной для ядра версии и версии сообщества, а также предоставляет два решения архитектуры распределенного кластера (внутреннее кодовое имя распределенного кластера PostgreSQL-XZ). В настоящее время облачная база данных PostgreSQL стабильно работает в основных подразделениях Tencent, таких как Tencent Big Data Platform, Guangdiantong и Tencent Video.
Распределенный кластер PostgreSQL собственной разработки Tencent PostgreSQL-XZ
Tencent PostgreSQL-XZ локализован из версии сообщества PostgreSQL-XC, которая может поддерживать горизонтальное расширение кластеров баз данных. Хотя PostgreSQL-XC очень мощный, он по-прежнему имеет очевидные узкие места в производительности, масштабируемости, безопасности, эксплуатации и обслуживании.После многих лет накопления Tencent PostgreSQL значительно улучшился и укрепился в этих аспектах. Как основная база данных для платежей WeChat, Tencent PostgreSQL позиционируется как безопасный, эффективный, стабильный и надежный кластер баз данных. Далее будет представлена оптимизация и улучшение собственной разработки PostgreSQL Tencent, представленной Tencent PostgreSQL-XZ.
1. Оптимизация системы управления транзакциями
PostgreSQL-XC имеет очевидный недостаток в самом решении системы управления транзакциями, то есть механизм управления транзакциями станет узким местом системы, а GTM (Global Transaction Manager) будет ограничивать расширение системы. Как показано на рис. 1, каждый запрос к CN (координаторному узлу) будет обращаться к GTM за необходимой информацией gxid (глобальный идентификатор транзакции) и gsnapshot (глобальный снимок) и отправлять эту информацию в DN вместе с самим оператором SQL (узел данных). узел базы данных) для выполнения. Кроме того, в механизме управления PostgreSQL-XC только основной DN может получить gxid, а резервный DN не имеет собственного gxid, поэтому он не может предоставлять услуги только для чтения, что также является пустой тратой системы.
Рисунок 1
Tencent PostgreSQL-XZ улучшает механизм управления транзакциями.После улучшения CN больше не получает gxid и gsnapshot от GTM, а каждый узел использует свой локальный xid (идентификатор транзакции) и gsnapshot (снапшот), поэтому GTM не станет системой. Кроме того, резервный компьютер DN также может предоставлять услуги только для чтения, полностью используя простаивающие системные ресурсы. Как показано на рисунке 2, оптимизированная архитектура системы управления транзакциями выглядит следующим образом:
фигура 2
2. Реализация только для чтения и оптимизация резервной машины
Конечно, оптимизация системы управления транзакциями обеспечивает основу для резервных DN только для чтения, но исходный кластер не имеет возможности загрузки и планирования. В связи с этим мы также внесли множество нововведений, среди которых:
- Обычный CN и CN только для чтения разделены.
- Обычный CN хранит метаданные основного DN.
- Доступное только для чтения CN хранит метаданные об альтернативных DN.
- Использовать режим горячего резерва (защита от горячего резерва) для синхронизации журналов между DN.
Таким образом, кластер может обеспечить функцию резервного DN только для чтения с возможностью интеллектуальной загрузки, полностью используя системные ресурсы.
изображение 3
3. План расширения мощностей с минимальным перерывом в работе
Быстрый рост бизнеса неизбежно требует расширения ресурсов.Внедрение версии сообщества делает стоимость расширения высокой и требует долгосрочной остановки бизнеса. Поскольку в версии PostgreSQL-XC для сообщества черезDN=Hash(row) % nofdnСпособ определения узла хранения записи:
Другими словами, сначала вычислите хэш-значение для столбца распределения, а затем используйте это значение для деления по модулю количества узлов в кластере, чтобы определить, к какому узлу относится запись (как показано на рис. 4).
Это простое решение, но в практических приложениях оно требует длительного простоя для расширения емкости. Это связано с тем, что количество узлов будет увеличиваться после расширения, а данные не могут быть прочитаны и записаны в соответствии с исходной логикой распределения, а данные узла необходимо перераспределить. Для повторной балансировки данных требуется время простоя, ручная миграция и повторная балансировка для каждого узла. Для крупномасштабных торговых систем, поскольку исходные узлы хранят огромные объемы данных, процесс ребалансировки может длиться несколько дней. Поверьте, это совершенно невыносимо для бизнеса.
Рисунок 4
Поэтому мы вводим новый метод разделения таблиц—sharded table。ShardedtableРаспределение данных следующее (рисунок 5):
- Представьте абстрактный средний слой — карту осколков. Каждый элемент в карте сегментов хранит отношение сопоставления между shardid и DN.
- Каждая запись в таблице Sharded проходит
Hash(row) % #shardmap entryЧтобы определить, в каком сегменте хранится запись, запросите сохраненное DN карты сегментов. - Каждое DN хранит информацию об осколках, выделенную этому узлу, а затем оценивает видимость.
По приведенной выше схеме при расширении новых узлов вам нужно всего лишь сопоставить некоторые shardids в shardmap с вновь добавленными узлами и переместить туда соответствующие данные. Расширению также нужно только переключить отношения сопоставления в shardmap, и время сокращается с нескольких дней до нескольких секунд.
Рисунок 5
4. Решение для наклона данных
Неравномерность данных означает, что в системе распределенной базы данных из-за распределения физических узлов, хэшей или осколков некоторые DN имеют недостаточно физического пространства, в то время как другие имеют большое оставшееся физическое пространство. Например, если продавец используется в качестве ключа распространения, ежедневный объем данных JD.com определенно отличается от объема данных обычной компании электронной коммерции. Возможно данные крупного мерчанта за месяц заполнят физическое пространство DN.В настоящее время единственный способ отключить систему — это увеличить емкость. Следовательно, у нас должны быть эффективные средства для устранения перекоса данных и обеспечения того, чтобы система могла работать эффективно и стабильно, даже когда данные таблицы распределены неравномерно.
Сначала разделим DN системы на группы (как показано на рисунке 6 ниже), в каждой группе:
- содержит одно или несколько DN
- У каждой группы есть shardmap
- При построении сегментированной таблицы можно указать хранимую группу, то есть либо хранить в группе1, либо в группе2
- CN может получить доступ ко всем группам, и информация о режиме доступа всех таблиц также хранится в CN.
Изображение 6
Специально выделять пользователей с большим объемом данных в системе, создавать для них белый список и использовать другую логику распределения данных (как показано на рисунке 7 ниже): обычные пользователи используют логику распределения данных по умолчанию, то есть:
Shardid = Hash(merchantid) % #shardmap
Крупные продавцы используют настраиваемую логику распределения данных, а именно:
Shardid = Hash(merchantid) % #shardmap + fcreate_timedayoffset from 1970-01-01
Рисунок 7
Добавляя смещение даты в логику распределения большой группы продавцов, данные одного и того же пользователя равномерно распределяются между несколькими узлами в группе. Это эффективно решает проблему неравномерного распределения данных.
Вот пример (см. рисунок 8 ниже):
Рисунок 8
5. Рекордно эффективное решение для сортировки мощностью 9000 Вт
В сценарии запроса списка бизнес получит следующий запрос SQL:
В сценарии оплаты WeChat у продавца есть 300 Вт данных в день и более 9000 Вт данных в месяц, что означает, что PostgreSQL необходимо выполнить быструю сортировку для данных уровня данных 9000 Вт, а бизнес-логика требует вывода второго уровня. быстро получить и отсортировать результат.
С этой целью мы предоставляем схему определения таблицы, то есть для создания таблицы разделов кластера. Согласно вышеуказанным требованиям, вы можете использовать месячную таблицу, то есть одну таблицу в месяц, и построить индекс на поле сортировки final_time, чтобы каждый раздел можно было сканировать с помощью индекса.
Благодаря ряду оптимизаций плана выполнения, CN отодвигает порядок и ограничивает предложения смещения до DN; DN использует оператор Merge Append для агрегирования и вывода результатов выполнения каждой подтаблицы при выполнении соответствующего SQL. что выходные данные упорядочены, то есть сканирование индекса выполняется для подтаблицы, а Merge Append объединяет результаты каждой подтаблицы, чтобы гарантировать, что результаты самого узла отсортированы. CN также использует Merge Append для слияния результатов нескольких DN, чтобы убедиться, что все выходные результаты упорядочены, тем самым завершая весь процесс сортировки.
Вот результаты нашего теста производительности при сортировке:
При тестировании на модели с 24-ядерным ЦП и 64 ГБ памяти сортировка данных мощностью 9000 Вт может быть выполнена в течение не более 25 мс, а число запросов в секунду может достигать 5400.
6. Параллельная оптимизация
С развитием современного оборудования системных ресурсов становится все больше и больше, а многопроцессорная система и большой объем памяти стали стандартной конфигурацией системы.Полное использование этих ресурсов может эффективно повысить эффективность обработки и оптимизировать производительность. Tencent начала оптимизировать многоядерное выполнение PostgreSQL в конце 2014 года.
В настоящее время версия сообщества PostgreSQL 9.6 также будет включать некоторые функции распараллеливания, но она не так богата, как наша.Вот принцип и эффект распараллеливания PostgreSQL от Tencent:
- Система создает глобальный диспетчер разделяемой памяти, управление которым осуществляется с помощью алгоритма управления растровыми изображениями.
- Исполнители с определенными данными создаются при старте системы, и эти Исполнители используются для выполнения фрагментов плана выполнения
- Система создаст очередь планов, и все Исполнители будут ждать плана в очереди задач.
- Каждому Исполнителю соответствует очередь результата задачи, и Исполнитель вешает указатель результата в очередь результата при выводе результата
- Очередь плана, очередь результатов и результаты выполнения фрагмента плана хранятся в диспетчере общей памяти, чтобы все процессы могли получить доступ к этим структурам.
- Когда сессионный процесс Postgres получает sql, он определяет, можно ли его распараллелить и распределяет задачи, читает и возвращает, когда в очереди результатов есть результаты
Наш оптимизированный оператор:
- Seqscan
- Hash join
- Nestloop join
- Remote query
- Hash Agg
- Sort Agg
- Append
При тестировании модели с 24-ядерным процессором и 64 ГБ памяти результаты оптимизации каждого оператора следующие:
В целом производительность обычно в 10-12 раз выше, чем до оптимизации, и эффект от оптимизации более заметен.
7. Аварийное восстановление трех центров в двух местах и трех центров Tencent PostgreSQL-XZ
Аварийное восстановление в двух местах и в трех центрах является важной возможностью для баз данных финансового уровня, а также самым основным и важным требованием для безопасности финансовых бизнес-данных.Поэтому, чтобы обеспечить эффективные и стабильные возможности аварийного восстановления данных, мы также построена полная система для PostgreSQL-XZ.Возможность автоматического аварийного восстановления трех центров в двух местах. Конкретная структура развертывания трех центров в двух местах выглядит следующим образом:
Между узлами в одном городе применяется строгая синхронизация для обеспечения строгой согласованности данных; асинхронная синхронизация частных сетей применяется в разных местах.
В узле CAgent развертывается на каждой физической машине.Агент собирает информацию о состоянии машины и сообщает об этом, а также выполняет соответствующие функции аварийной сигнализации и выполнения переключения.
Каждый IDC развертывает по крайней мере один JCenter, который отвечает за сбор и отчетность о состоянии, сообщаемом каждым агентом, в кластер ZK. Только один из многих JCenter является основным.Главный JCenter не только сообщает о состоянии, но также выполняет оценку неисправности и переключение. После выхода из строя основного JCenter система автоматически решает и выбирает резервный JCenter для обновления основного через ZK.
JCenter и CAgent являются узлами управления и принятия решений трех центров в двух местах.
Что касается узлов базы данных, CN развертывает по крайней мере один узел в каждом IDC. В каждом центре развертывается один DN, один является основной машиной, а два других размещаются параллельно на основной машине в качестве резервных машин, одна является синхронной резервной машиной, а другая — асинхронной резервной машиной.
Когда хост выходит из строя и выходит из строя, JCenter отдает приоритет резервному хосту в том же городе, что и основной хост.
В настоящее время Tencent Cloud предоставилаApsaraDB для PostgreSQL, и предоставит две версии версии, оптимизированной для ядра, и версии сообщества, чтобы удовлетворить требования большего количества клиентов.
вопросы и ответы
Миграция с MySql на PostgreSql?
Связанное Чтение
Six Veins Sword от Mobike: техническая поддержка 25 миллионов ежедневных туристических услуг
Эта статья была разрешена автором для публикации в сообществе Tencent Cloud + Для получения дополнительных оригинальных текстов, пожалуйстанажмите
Найдите и подпишитесь на общедоступную учетную запись «Сообщество Yunjia», получите технические галантереи как можно скорее и ответьте на 1024, обратив внимание, чтобы отправить вам подарочный пакет технических курсов!
Огромный технический практический опыт, все вСообщество Юнцзя!