Посмотрел недавно видео с HighLoad++, в частности доклад Григория Рубцова «Архитектура MySQL Cluster»
Краткие тезисы:
— Таблицы хранятся по нодам построчно (по ключу auto_increment).
— Данные дублируются на нескольких нодах одновременно
— Индексы тоже хранятся на нодах в виде таблиц со всем вытекающими: распределение между нодами построчно.
Что вытекает из этого? Что бы выполнить полноценный запрос sql с JOIN или несколькими условиями будут выполнены следующие действия:
— по ключу будет найдена нода, хранящая доп. условие;
— на данной ноде будет найдена необходимая запись.
И это для каждого условия, т.к. разные индексы одной записи судя по алгоритму распределения, описанному в докладе, могут оказаться на разных нодах.
Т.е. при одном дополнительном условии (к поиску по автоинкрементному ключу) будет выполнено вместо одного запроса три. При двух дополнительных условиях — пять запросов и т.д. Что косвенно подтверждается народом на форумах: производительность кластера из 4-х нод примерно соответствует одному классическому серверу MySQL.
Что ж это за решение, воскликните вы?!
Но давайте посмотрим с другой стороны. Будем, как говориться, смотреть на плюсы, а не минусы.
MySQL Cluster умеет хорошо делать:
— выборку по первичному ключу;
— резервирование (размазывание с избыточностью данных по нодам);
— отказоустойчивость (менеджер отслеживает состояния нод и реаигрует тем или иным образом).
Но разве это не сервер NoSQL, умеющий балансировку, избыточность и отказоустойчивость «из коробки»?
Правда для такой роли необходимо существенно переписывать софт (по крайней мере ту его часть, которая отвечает за работу с БД).
Хотя есть мнение что все крупные проекты либо уже работают с NoSQL либо обязательно перейдут на него, ибо иного пути эволюции человечество еще не придумало.
Получается MySQL кластер не так уж плох, если его использовать под нужным углом, главное вовремя осознать его NoSQL-сущность?
Краткие тезисы:
— Таблицы хранятся по нодам построчно (по ключу auto_increment).
— Данные дублируются на нескольких нодах одновременно
— Индексы тоже хранятся на нодах в виде таблиц со всем вытекающими: распределение между нодами построчно.
Что вытекает из этого? Что бы выполнить полноценный запрос sql с JOIN или несколькими условиями будут выполнены следующие действия:
— по ключу будет найдена нода, хранящая доп. условие;
— на данной ноде будет найдена необходимая запись.
И это для каждого условия, т.к. разные индексы одной записи судя по алгоритму распределения, описанному в докладе, могут оказаться на разных нодах.
Т.е. при одном дополнительном условии (к поиску по автоинкрементному ключу) будет выполнено вместо одного запроса три. При двух дополнительных условиях — пять запросов и т.д. Что косвенно подтверждается народом на форумах: производительность кластера из 4-х нод примерно соответствует одному классическому серверу MySQL.
Что ж это за решение, воскликните вы?!
Но давайте посмотрим с другой стороны. Будем, как говориться, смотреть на плюсы, а не минусы.
MySQL Cluster умеет хорошо делать:
— выборку по первичному ключу;
— резервирование (размазывание с избыточностью данных по нодам);
— отказоустойчивость (менеджер отслеживает состояния нод и реаигрует тем или иным образом).
Но разве это не сервер NoSQL, умеющий балансировку, избыточность и отказоустойчивость «из коробки»?
Правда для такой роли необходимо существенно переписывать софт (по крайней мере ту его часть, которая отвечает за работу с БД).
Хотя есть мнение что все крупные проекты либо уже работают с NoSQL либо обязательно перейдут на него, ибо иного пути эволюции человечество еще не придумало.
Получается MySQL кластер не так уж плох, если его использовать под нужным углом, главное вовремя осознать его NoSQL-сущность?
Комментариев нет:
Отправить комментарий