Yandex Database

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 15:48, 16 февраля 2019.
Yandex Database
YDB logo.png
Разработчики: Яндекс
Веб-сайт https://events.yandex.ru/lib/talks/6699

Yandex database (YDB) — с одной стороны платформа, на которой можно строить различные системы хранения и обработки данных, а с другой стороны это распределенная, отказоустойчивая newSQL база данных.[Источник 1]

Описание

Yandex database является newSQL базой данных. NewSQL берёт лучшее из двух миров: от NoSQL решений берут масштабируемость, отказоустойчивость и доступность, от традиционных локальный реляционных баз данных берут богатство функциональности, в том числе возможность выражать свои запросы к базе данных на языке SQL.

База данных обладает следующими свойстами

  • Строгая консистентность. Система для конечного пользователя выглядит как локальный сервер баз данных.
  • Схематизированные таблицы для хранения данных.
  • Распределенные ACID транзакции.
  • Доступ через YQL (диалект SQL от Яндекса).
  • OLTP база данных.
  • Мультиарендная база данных. Существуют механизмы, позволяющие разделять работу разных пользователей на одном и том же кластере так, чтобы они при этом не мешали работе друг друга.

Разрабатывалась примерно с 2013-2014 года для внутренних задач Яндекса.

На платформе YDB построен ряд систем

  • LogBroker (аналог/замена Apache Kafka)
  • Real-time Map Reduce (обработка потоков данных)
  • Хранение временных рядов в системе мониторинга

Внутри Яндекса YDB используется по больше части в интерактивных проектах, требующих отказоусточивости. Например, среди таких Яндекс.Коллекции, Яндекс.Messenger и другие.

Преимущества единого слоя хранения на основе YDB

  • Отделение слоя хранения от слоя вычислений
  • Общий слой хранения для сетевых дисков и баз данных
  • Относительно просто масштабировать облако
  • "Продвинутые" сервисы могут использовать raw device

Внутреннее устройство

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

  • Выходят из строя машины, диски и сеть
  • Для отказоустойчивости используется избыточность
  • Проблема распределенного консенсуса: Paxos, Raft и другие алгоритмы

Tablet

Tablet ("таблетка") - отказоустойчивый строительный блок, который инкапсулирует в себе отказоустойчивость. Система строится из таких отказоустойчивых блоков. Tablet представляет собой реплицированный конечный автомат, который получает команды с уровня выше и выполняет их. Состояние сохраняется на так называемой BlobStorage группе, которая обеспечивает отказоустойчивость. Tablet - протокол взаимодействия с BlobStorage (рисунок 1).

Рисунок 1 – Tablet как протокол взаимодействия с BlobStorage

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

Применение tablet

Все сложные распределенные системы так или иначе предлагают концепцию шарда (англ. shard). Таблетка не что иное как реализация шарда. Таблетки несут разные функции, например, используется как шард с данными, то есть содержит часть какого-то глобальной реляционной таблицы. Ещё таблетка может использоваться для системных задач, если необходимо хранить реестр пользовательских таблиц.

Tablet - лёгкая сущность, одна машина может управлять тысячами таблеток. С другой стороны таблетка может переноситься с машины на машину, за счёт чего обеспечивается балансировка нагрузки.

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

Архитектура состоит из нескольких слоёв (рисунок 2). Нижний слой - распределенное отказоустойчивое хранилище. Следующий - протокол таблетки. Имея эти два слоя платформу уже можно использовать для пользовательских задач. Например, RTMR (real-time map reduce) tablet реализована поверх протокола таблетки, потому что она сама умеет обрабатывать свои данные. Так как задача менеджмента данных внутри таблетки решается почти всеми таблетками, удобно иметь так называемую локальную базу данных. Локальная потому, что она находится в пределах одной таблетки. Эта база данных предоставляет разработчику концепцию реляционных таблиц. Операции внутри локальной базы данных транзакционные. Поверх слоя локальной базы строятся таблетки с понятной пользовательской функциональностью. Крайне важным является слой выполнения распределенных транзакций (англ. Distributed Transactions). Это необходимый слой для обеспечения консистентных изменений данных в нескольких таблетках. Более верхний слой - прокси. Пользователь взаимодействует с данной прокси, та в свою очередь переадресовывает запросы нужным компонентам.

Рисунок 2 – Архитектура YDB

BlobStorage Group

BlobStorage представляет собой набор BlobStorage Group. BlobStorage Group представляет собой распределенный отказоустойчивый массив, доступный по сети. Является хранилищем ключ-значение, которое отображает специальные идентификаторы в Blob - куски данных произвольного, но ограниченного размера. Blob является неизменяемым (immutable), то есть можно повторять операцию. Идентификаторы представляют собой сложные структуры, но являются частично упорядоченными, что позволяет реализовать концепцию лога.

Интерфейс доступа представляет из себя набор нескольких команд.

  • Put/Get - можно записать и прочитать по ключу
  • Block - блокировка, с помощью которой реализовывается кворум на группе
  • Garbage collection - сборка мусора

Внутри BlobStorage есть понятие PDisk (изображено на рисунке 3). PDisk (от physical disk) - компонент, абстрагирующий понятие блочного устройства. Предоставляет работу с кусками фиксированного размера и предоставляет на вышестоящие уровни лог, который разделяется VDisk (от virtual disk). VDisk в свою очередь пользуется интерфейсом PDisk.

Рисунок 3 – Узел хранения

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

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

Работа с данной группой происходит через BlobStorage Proxy (рисунок 4), которая берёт на себя взаимодействие с набором VDisk. Также существует механизм для борьбы с неработающим или перегруженным диском.

Рисунок 4 – BlobStorage Proxy

Каналы

Концепция каналов (рисунок 5) позволяет подключать несколько BlobStorage групп через разные каналы к таблетке. Это обеспечивает некоторую параллельность и позволяет строить разные гибридные схемы, например, когда часть данных на HDD, а часть на SSD.

Рисунок 5 – Канал, состоящий из HDD и SSD дисков

Slaves

Помимо таблеток существуют сущности, похожие на них, выступающие как slave (рисунок 6). Они получают все обновления таблеток и могут отвечать на некоторые пользовательские запросы чтения. С помощью них система обеспечивает лучшие гарантии на чтение за счет ослабления гарантий консистентности. При сбое таблетки slave является кондидатом в master.

Рисунок 6 – Slave

YDB в Яндекс.Облаке: сервисы для пользователей

  • Yandex Object Storage - масштабируемое хранилище объектов совместимое с Amazon S3
  • Network Block Store - отказоустойчивые блочные устройства, подключаемые по сети
  • Yandex Message Queue (в разработке) - сервис очередей сообщений, совместимый с Amazon SQS (Simple Queue Services)
  • Yandex Monitoring (в разработке) - сервис мониторинга

Мультиарендный кластер YDB в Облаке

Слой хранилища расположен на "железе" (рисунок 7). То есть процессы в YDB, которые работают с дисками, запускаются непосредственно на оборудовании. Выше есть слой, который расположен в виртуальных машинах, которые сгруппированы по базам данных. То есть для каждого сервиса заведена отдельная база данных.

Рисунок 7 – Мультиарендный кластер

Источники

  1. Yandex database // Доклад, Яндекс.Облако. [2019]. Дата обновления: 18.11.2018. URL: https://events.yandex.ru/lib/talks/6699 (дата обращения: 16.01.2019).