Слом парадигмы вертикального масштабирования в реляционных СУБД

zamotivator — 25.12.2014 Наконец-то добрался до изучения
http://www.slideshare.net/kaigai/gpgpu-accelerates-postgresql
Особое внимание уделите слайду 44


Пришло время рассказать про один страх, который давно меня преследовал и которому я не находил решения.
Появление NoSQL систем далеко не в последнюю очередь обусловлено изменившейся парадигмой масштабирования.
До относительно недавнего времени масштабирование шло вертикально.
После того, как упёрлись в физические ограничения частоты процессора, масштабирование пошло в горизонтальном направлении.


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


Это очень важный водораздел, который принципиально меняет парадигму организации СУБД.
Давайте введём следующую метрику: "стоимость выполнения запроса в вватах".
Метрика может показать странной, но это наиболее коррелирующий с алгоритмической эффективностью просто измеримый критерий.
Если мы можем при помощи индекса прочитать лишь 10% записи таблицы - то мы потратим в 10 раз меньше ватт на выполнение запроса (на самом деле так не так линейно, но идею, безусловно, вы уловили)
Hadoop, Mongo и прочие full-scan системы крайне убоги с алгоритмической точки зрения и метрика "ватт/запрос" это отразит.
Классические реляционные СУБД, несмотря на хорошие показатели по нашей метрике, работают ХУЖЕ с точки зрения других метрик - именно потому, что они выращены и написаны в архитектуре вертикального масштабирования.
Данная презентация - это не просто "PostgreSQL научился использовать GPU".


Это слом парадигмы масштабирования классический реляционной СУБД.
Это революция.


Цитирую кусок из поста выше:
"Было: рост частоты процессора, размера памяти, размеров диска, пропускной способности сети
Стало: рост числа ядер, рост числа серверов, шардирование данных."


Вот "стало" - это слабые места реляционнок. Давайте их изучим немного внимательней.


- рост числа серверов и шардирование данных: с этим пока всё грустно. Если СУБД включает в себя несколько серверов, то система может выходить из строя по частям. Классические реляционные СУБД умеют лишь failover базы целиком - "всё или ничего" в терминах СУБД, а не её части. Однако, я не вижу принципиальных проблем использовать модель SciDB организации данных, естественно с некоторыми "но", но эти "но" поймут лишь разработчики СУБД, и я не буду про них тут писать (и это чисто инжереные проблемы, а не принципиальные)


- рост числа ядер [вместо роста тактовой частоты процессора]: вот это уже серьёзный bottleneck - ВСЕ реляционные СУБД были написаны в парадигме вертикального масштабирования, и выполнение плана запроса, как правильно, однопоточное.
При появлении многоядерных и многопроцессорных систем это быстренько сломали для сортировки и научились сортировать параллельно - потому что это было просто сделать
Потом научились использовать SSE и мультиплексирование строчек и обрабатывать данные bulk'ами - по пачке за раз, и это ускорило CPU-intensive операции, которые можно применять независимо для всех строчек.


В этом месте всё остановилось. Дальнейшие улучшения упирались в параллелизм join'ов, index'ов, scan'ов - где scan'ы и index'ы параллелить бесполезно просто потому, что у нас не параллелится диск И потому что до появления SSD это было ВРЕДНО, а вот с join'ами были серьезные архитектурные затыки, заложенные парадигмой вертикального масштабирования.


Я лично, когда искал способы ФУНДАМЕНТАЛЬНО ускорить выполнение запросов в реляционной СУБД смотрел в сторону именно вертикального масштабирования - JIT-компиляции планов выполнения запросов, что позволяет делать cross-function optimisation, что невозможно в классической модели интерпретатора, которую используют все текущие СУБД (кроме, кажется, Oracle, которые таскает с собой компилятор и компилирует хранимки - но это всё равно немного не тоже самое, что агрессивный инлайн и cross-function optimisation плана выполнения запроса - простой пример (A + B) * C на decimal числах, инлайн + cross-function optimisation даёт один сначала один цикл по BCD числам, вместо двух циклов (один на плюс и один на умножить) в первом приближении, во второе даёт loop unrolling, а в третьем делает эти операции на SSE).


Но речь не об этом.


Презентация, на которую я ссылаюсь в начале поста ЛОМАЕТ ПАРАДИГМУ организации выполения планов запросов, и это РЕВОЛЮЦИЯ, не больше и не меньше.
Это очень-очень важный шаг на пути к миру, где реляционные СУБД нового поколения, которой, безусловно, стал PostgreSQL (после появления этой функциональности) вытеснят full-scan системы вроде Hadoop или Mongo.
Мы видим революцию. Жаль, что мы ещё не осознаем до коцна, что именно происходит прямо на наших глазах.
Надеюсь, я вам помог это увидеть.

Оставить комментарий

Популярные посты:

• Архив