Comments 11
Принцип локальности данных не очень дружит с облаками, увы.
Ну, сейчас сеть то пошустрее чем когда хадуп сделали, да и компы получше.
Или вы конкретно про запуск того же спарка на виртуалке от облачного провайдера с налогом на копирование данных?
Я бы не назвал это просто налогом, аппаратно данные не локальны в облаках. Одно дело, когда каждый вычислитель имеет доступ к своим данным по дешевому и быстрому PCI, не мешая другим вычислителям. Получаем практически линейное горизонтальное масштабирование, дух захватывало от таких перспектив. Другое дело реальность, когда хранение данных коммунально, вычислители конкурируют за производительность хранилок и систем коммутации пакетов. Это медленнее, дороже аппаратно, но гибко и может быть реализовано в короткие сроки, в часы, а не месяцы.
Сам я являюсь разработчиком, и ежедневно взаимодействую с различными СУБД – в основном, с пресловутой PostgreSQL.
"Пресловутый - широко известный своими сомнительными, отрицательными качествами". Вроде с постгрес в этом плане всё ок.
Спасибо! Сам не сталкивался с Hadoop-кластерами, а узнать тонкости работы как-то руки не доходили. А тут как-раз статейка весьма подробная.
"Когда нужно обеспечить возможность запроса данных на Hadoop кластер в SQL-формате, и при этом такие запросы тяжелые и не частые (например, перестраивать витрину данных раз в сутки, либо руками выполнять аналитические запросы)."
Вот это представление устарело примерно на 10 лет, к сожалению
А какой ответ на этот вопрос вам кажется актуальным сейчас?
в hadoop экосистеме есть высокопроизводительные процессинговые движки данных. Самые первые это Presto и Impala 2013г, Doris 2017г, Trino и Starrocks 2020г.
Любой из этих движков работает ультрапроизводительно в хадуп окружении.
Hadoop в том виде в котором он описан в статье - умер.
Саммари по перечисленным движкам от чата гпт:
За последние годы Hadoop-экосистема перестала быть чисто «OLAP-only». Появление высокопроизводительных движков (Trino/Presto/Impala, и особенно встроенных аналитических СУБД вроде Doris/StarRocks) позволило обеспечить интерактивный, низколатентный SQL-сервинг над большими данными. Тем не менее, полная замена реляционных СУБД для OLTP-нагрузок эти решения не дали: транзакции, массовые мелкие обновления и сложная DB-логика по-прежнему остаются прерогативой традиционных RDBMS.
Я заглянул в ваш профиль, увидел, что ваша специализация как раз хранилища данных, очень был бы признателен за развернутый ответ по теме: для чего использовать реляционные субд, для чего - hadoop, spark и пр.
Если не сложно, именно тезисно, какая технология с какой нагрузкой лучше всего справляется.
От реляционных СУБД к экосистеме Hadoop