Search
Write a publication
Pull to refresh

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 и пр.

Если не сложно, именно тезисно, какая технология с какой нагрузкой лучше всего справляется.

На OLPT пока особо и не стоит рассчитывать, за рядом исклоючений. А вот про низколатентной (простим чат гопоты за это) OLAP SQL давно решенная задача. Если хотите развернутый ответ, то можете начинать читать от самой первой публикации по очереди с конца

Sign up to leave a comment.

Articles