Распределенный SQL¶
Picodata включает в себя богатую функциональность по работе с реляционными данными. Пользователи могут создавать, наполнять данными хранилище БД и затем считывать данные посредством запросов в интерактивной консоли Picodata. В Picodata реализована поддержка распределенного (кластерного) SQL, т.е. возможность работать с шардированными таблицами.
Принципы работы¶
Принципы работы распределенного SQL согласуются с требованиями стандарта SQL (Structured Query Language, язык структурированных запросов) для хранения и управления данными в виде таблиц:
- Любая таблица представляет собой именованный набор строк
- Все строки таблицы имеют одинаковый набор именованных столбцов
- Каждому столбцу соответствует определенный тип данных
- У каждой таблицы есть первичный ключ — набор столбцов, значения в которых уникально определяют местоположение каждой строки в таблице
- Стандарт SQL не гарантирует какой-либо порядок строк при чтении из таблицы
Реализация распределенного SQL в Picodata¶
Picodata предоставляет функции планировщика и модуля исполнения SQL-запросов в рамках всего кластера. При выполнении распределенный запрос разбивается на части для опроса всех узлов, после чего собранные данные консолидируются и возвращаются пользователю.
Детали архитектуры планировщика доступны в отдельной PDF-презентации.
Схема выполнения запросов¶
На схеме ниже показан общий принцип работы распределенного SQL-запроса в кластере с одним роутером.
На схеме красным показан исходный пользовательский запрос, желтым — план запроса (IR, intermediate representation), зеленым — собранные фрагменты ответов, голубым — консолидированный ответ на пользовательский запрос в виде списка кортежей, обработанного функцией MapReduce.
Распределение данных¶
Распределенный SQL требует собственно распределения данных между различными репликасетами (шардами) кластера. Это достигается за счет использования встроенной библиотеки Vshard. Взаимодействие Picodata SQL и Vshard заключается в разделении функций:
- Picodata SQL работает с шардированными таблицами, отдельные строки (кортежи) которых распределяются по разным бакетам
- Vshard работает с распределением бакетов по репликасетам
У каждой распределенной таблицы в схеме данных всегда есть три признака:
- наличие имени тира, к которому принадлежит таблица. Принадлежность выражается в том, данные хранятся только на репликасетах из соответствующего тира.
- наличие столбца
bucket_id, связывающего каждую строку таблицы с определенным номером бакета - наличие ключа шардирования, состоящего минимум из одного столбца, по
которому производится расчет значения
bucket_id
Picodata SQL включает внутреннюю функцию по вычислению bucket_id на
основе хешей значений, которые передаются в распределенных запросах. В
шардированной таблице bucket_id хранит вычисленное значение (номер
бакета) от функции шардирования (на вход подается набор колонок, по
которым происходит шардирование, и количество бакетов в кластере). Для
запроса SELECT значение bucket_id нужно чтобы узел с ролью
vshard.router мог понять, на каком узле с ролью vshard.storage
расположены искомые данные. Соответственно, для запроса INSERT
требуется знать, на какой узел записывать данные. В общем случае, две
записи с одинаковыми значениями в столбцах, относящихся к
sharding_key, попадут в один бакет.
См. также: