BigData - это когда вместо схемы мусор, а разработчики боятся джоинов?

[metaclass]

http://habrahabr.ru/company/beeline/blog/218669/
В статье вроде все не сильно страшно, но вот вопрос - откуда такая боязнь join-ов?
Если там таблица c размерностями мизерного размера и помещается вместе с индексами в кэш, то join на нее достаточно дешевый, чтобы на него было пофиг совершенно, по сравнению с вычитыванием каких-нибудь сотен миллионов записей из таблицы фактов.

Впрочем, если в реляционную БД попытаться засунуть неструктурированные данные и попытаться их нормализовать, а еще не дай бог попытаться поверх этого сделать иммутабельность, то запросы действительно вырождаются в десятиэтажные джоины (и все равно я особой проблемы в этом не вижу).

Comments

[falcrum.livejournal.com]

Чё джойны - там ещё юнион на юнионе бывает...

[vit-r.livejournal.com]

BigData - это когда продавец втирает менеджерам, что специалисты по базам не нужны, а можно просто купить их чудесные тулы. (А рядом стоятя продавцы железа и радостно кивают головами)

Впрочем, если в реляционную БД попытаться засунуть неструктурированные данные и попытаться их нормализовать

В Data Warehouse уже давно придумали, как данные нормализовать и как потом их в кубы собирать, чтобы джоины без проблем писались бухгалтерами менеджерами.

[vp.livejournal.com]

"...Нужна другая архитектура базы данных. Если вам нужны гибкие запросы, то проще всего хранить данные неструктурированно — потому что для каждого нового запроса придётся иначе строить новую оптимальную структуру. Обычные базы данных направлены на максимальное быстродействие в рамках ограниченных вычислительных ресурсов...."

Переводим: NoSql, запись всего в кучу и последовательная обработка всего в лоб.
Так получается? :)

[vinsent_ru]

был у меня один могильничек сервер с CouchDB. Документы там были простые, но на каждый документ приезжал еще апдейт, а эта тварь хранила и предыдущую версию. И считался там один отчетик, имено так - жабаскриптом в лоб перебором. Не я делал, в наследство досталось.
Посмотрел я на это дело да и перенес все в Postgres. Итог: отчет считается 2 минуты вместо 30, обьем на диске 1 гиг вместо 14 гиг в коуче за один и тот же период времени.

И я так понимаю, что никакими оптимизаторами запросов в модной бигдате даже и не пахло?

[alll]

> Если там таблица c размерностями мизерного размера и помещается вместе с индексами в кэш

Буквосчетание BigData в сабже какбэ намекает нам...

[volodymir-k.livejournal.com]

собственно и традиционные RDBMS про джойны так и говорят -- если маленький справочничек, то повезло и ок, а в общем случае две биг таблицы связывать -- пипец перформансу, нужен денорм

сейчас всё проекттирование схем вкурило тему разделение таблиц на мелкие и крупные -- см напр. memsql подход к шардированию

неструктурированные данные это конечно глупость и колхоз, я могу понять организационные этому причины, а технические -- нет

[jakobz.livejournal.com]

Я вот не понимаю такой штуки: есть же подход с OLTP и Data Warehouse-базами в SQL-тусе тыщу лет. У тебя задача хорошо ложится на map/reduce? Ну возьми ты этот DWH, вынь с него все справочники в кэш, потом делай select * from facts - и считай на каком-нибудь дотнете в один проход свой map/reduce. Один хер у тебя в диск это упрется, хоть на какой БД.

Зачем тут надо no-sql, если в обычных БД, если нужно, делается тоже самое?

[serguei tarassov [arbinada.com] (from livejournal.com)]

"Большие данные" как состояние отрасли (http://www.arbinada.com/main/node/1351)

[tzirechnoy.livejournal.com]

Пигдата -- это когда фирма покупает два рэйд-массива, с контрактом что если что -- то через сутки производитель притащит ещё, два бэкплэйна к ним, тожэ с контрактом, что если что, то производитель через сутки притащит ещё, два компа для обработки от HP, с контрактом, что если что, то производитель притащит ещё, два свитча для соединения всего этого, с уверениями, что такого за сутки в городе можно купить ещё и двух обезьян от известного HR-агенства, с обещанием, что если что, то через сутки можно нанять ещё.

[cghw9.livejournal.com]

ух ты, а что за разработчики которые боятся? на метан их надо пустить. или в криматорий.

[ng67.livejournal.com]

В славном городе Санкт-Питербурхе, есть не менее славная контора - Вычислительный центр коллективного пользования. Который на весь город печатает квитанции за квартплату, ее собирает и рассылает кому надо.
Так вот стоит там Oracle и MS SQL. С 1С впридачу. Причем 1С играет ключевую роль.
Объем базы 1С около 2 терабайт. Объем базы Oracle боюсь представить. И ничего. Все это крутится, работает. Каждый день перечисляются деньги, строятся отчеты (да, да из 1С!).
Кстати везде Windows, а вовсе не Linux.
Так что вот, дорогие товарищи, как оно все на самом деле...

[sergiej.livejournal.com]

да структурированы они! Проблема как правило в нескольких плоских таблицах с охренилиардами записей с кучей текста в каждой записи.
Вообще в корпоративе БигДата это пока ещё в основном анекдот, бизнес просто не знает что с ним делать.
Основной заказчик БигДаты на сегодня это аналитические отделы спецслужб. Падают к ним данные от сотен больших коммуникационных и околобанковских контор. Естественно для единобразности они денормализуются в плоские "логи" с космическим количеством записей. Ну вот и из этого нужно все записи где встречается конкретный номер/имей телефона/карточки/имя. Получается? Ок, а теперь попробуйте по "похожим" именам... а теперь ещё вот так или вот так...
если реляционка, то это "лайки" + джоины и они работать будут ДНЯМИ а времени - минуты. Общая задача это не найти иголку в стоге сена, а найти соломину ровно 10 сантиметров длиной и конкретно жёлто-зелёного оттенка. Реляционкой не решается эффективно, разложить стог на отдельные соломины в рядочек не помогает ну нифига.
Что скажет в этом месте программист? Ну так не делаете лайки а пишите специальный алгоритм - ну и вот MapReduce для этого и написали. Сначала применяли узко, в гуглах да АНБ всяких, а потом поняли что можно продавать ширше, назвали это для маркетинга "БигДата", чтобы конкретные пацаны заказывали - "ну у меня то БОЛШОЙ ДАТА - Мегабайтов 100!"

[sergiej.livejournal.com]

Hadoop clusters are growing, and some operations teams are challenged with upgrading as many as 5000 HDFS nodes, storing more than 100 petabytes of data. Rolling Upgrades make this significantly easier to manage.
дайвате господа ораклисты, продемонстрируйте скорость работы like '%Ivanov%' поверх 100 петабайт :)

[yuri-yurkevich.livejournal.com]

Для чего вообще нужны такие большие массивы данных и их аггрегация?

Для увеличения точности обзора, более эффективного принятия решений?

Дык накладные расходы когда-то начинают превышать пользу.