История версий
Требования

YMatrix

Быстрый старт

Развертывание

Моделирование данных

Подключение

Запись данных

Миграция

Запросы

Операции и обслуживание

Настройка производительности

Устранение неполадок

Справочник

Справочник по SQL

Часто задаваемые вопросы

Архитектура YMatrix

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

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

Эта архитектура гибкая и адаптируется к различным сценариям: она не только оптимизирована для сценариев IoT с временными рядами, но и поддерживает традиционные аналитические хранилища данных и задачи бизнес-аналитики (BI).

Каковы преимущества архитектуры YMatrix по сравнению со сложными стеками технологий данных?

Замена традиционных стеков технологий данных на гиперконвергентную архитектуру может показаться сложной задачей. Но зачем это нужно?

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

По сравнению со сложными стеками технологий данных, такими как экосистема Hadoop, архитектура YMatrix обладает следующими преимуществами:

  • Гиперконвергенция

    • Надежность: Сложный технологический стек обычно состоит из N отдельных систем обработки данных. При вероятности сбоя любого компонента P, стабильность всей системы приблизительно равна (1-P)^N, что означает, что каждый дополнительный компонент значительно снижает надежность. Гиперконвергентная архитектура, использующая одну систему, по своей природе является наиболее стабильной и надежной.
    • Экономичность: Благодаря гиперконвергенции, YMatrix может потреблять и управлять данными в рамках одной системы, не передавая их между несколькими распределенными системами, что исключает необходимость хранения данных в нескольких местах. Физические требования к оборудованию, например, дискам, минимальны, что обеспечивает низкие затраты на хранение.
    • Своевременность: В гиперконвергентной архитектуре данные не требуют передачи между несколькими системами, что обеспечивает низкую задержку и высокую оперативность.
    • Упрощенное управление: Гиперконвергентное решение делает всю экосистему данных проще в управлении — достаточно владеть только SQL для эксплуатации, не требуя знания множества продуктов и языков программирования.

  • Высокая доступность

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

  • Богатая экосистема инструментов

    • Совместима с экосистемой Postgres/Greenplum. Охватывает различные сценарии: миграция данных, запись, тестирование производительности, резервное копирование и восстановление.

  • Поддержка стандартного SQL

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

  • Полная поддержка транзакций ACID

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

Диаграмма гиперконвергентной архитектуры

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

Ниже приведена диаграмма, иллюстрирующая состав и функции внутренней гиперконвергентной архитектуры YMatrix:

Следующие разделы содержат подробный обзор компонентов гиперконвергентной архитектуры YMatrix:

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

  • Движки хранения и выполнения
    Это комбинации движков хранения и выполнения, которые можно выбирать при создании таблиц в YMatrix для разных сценариев. Каждая комбинация формирует микроядро.

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

  • Журналирование, транзакции, управление конкурентностью, блокировки, снепшоты
    Это стандартные компоненты ядра YMatrix, обеспечивающие общие функции, такие как контроль конкурентности, механизмы транзакций и восстановление после сбоев.

  • SQL
    Это стандартный SQL-интерфейс между YMatrix и клиентом.

  • Аутентификация, роли, аудит, шифрование, мониторинг, резервное копирование, восстановление, высокая доступность
    Это другие распространенные функции базы данных, поддерживаемые YMatrix.

Диаграмма архитектуры базы данных

Высокоуровневая архитектура базы данных YMatrix основана на классической архитектуре MPP (массово параллельной обработки) с некоторыми усовершенствованиями.

Ниже приведена диаграмма, описывающая основные компоненты системы базы данных YMatrix и их взаимодействие:

Следующие разделы содержат подробное описание различных компонентов системы базы данных YMatrix и их функций.

  • Узел Master

    • Отвечает за установление и управление сессионными соединениями с клиентами.
    • Отвечает за разбор SQL-запросов и формирование планов выполнения (Query Plan).
    • Распределяет планы выполнения на Segments, контролирует процесс выполнения запросов и собирает результаты для возврата клиентам.
    • Master не хранит бизнес-данные; он хранит только словарь данных — совокупность определений и атрибутов всех элементов данных, используемых в системе.
    • В кластере допускается только один Master; может использоваться конфигурация основной-резервной копии, при этом резервный узел называется Standby.

  • Узлы данных (Segments)

    • Отвечают за хранение данных и выполнение SQL-запросов.
    • Ключ к достижению оптимальной производительности YMatrix заключается в равномерном распределении данных и нагрузки между большим количеством Segment-узлов с одинаковыми возможностями, что позволяет всем Segment-узлам одновременно начинать выполнение задачи и завершать её параллельно.

  • Клиент (Client)

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

  • MatrixGate

    • MatrixGate (сокращённо mxgate) — высокоскоростной инструмент записи потоковых данных в YMatrix. Подробнее см. mxgate.

  • Сетевой уровень (Interconnect)

    • Сетевой уровень архитектуры базы данных, отвечающий за межпроцессное взаимодействие между Segments и инфраструктуру сети, поддерживающую это взаимодействие.

  • Служба управления состоянием данных (Cluster Service)

    • Служба Cluster Service обеспечивает высокую доступность базы данных, управляя информацией о состоянии узлов. YMatrix реализует эту службу с помощью кластера etcd: при сбое узла базы данных etcd извлекает данные о состоянии узла из своей базы, определяет текущий исправный узел как новый главный и повышает его статус, обеспечивая доступность всего кластера.
      Например, если выходит из строя Master, его Standby узел повышается до роли Master; если выходит из строя Standby, это не влияет на общий кластер. Аналогично, если выходит из строя Primary узел, его Mirror узел повышается до Primary; если выходит из строя сам Mirror узел, это не влияет на кластер. Подробнее см. Восстановление после сбоев.
← Предыдущая
Введение
Следующая →
Тест:SSB