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

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 заключается в равномерном распределении данных и нагрузки между большим количеством Segments с одинаковыми возможностями, что позволяет всем Segments одновременно начинать обработку задачи и завершать её параллельно.

  • Клиент (Client)

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

  • MatrixGate

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

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

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

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

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