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

[metaclass]

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

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

Comments

[volodymir-k.livejournal.com]

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

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

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

[serbod.livejournal.com]

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

Например. Какая-то софтина генерирует гигабайт слабоструктурированного говна (текстовых логов) в сутки. Периодически с говна снимаются сливки - отбираются ключевые события и перекладываются в БД. Далее говно упаковывается в герметичные контейнеры (gzip) и хранится где-то в облаках. Периодически возникает необходимость это говно перетряхивать в разных целях - собрать статистику, поискать подробности по конкретным сессиям, итд..

Можно это говно сразу сортировать и пихать в СУБД. Но это долго, дорого и рискованно. Лучше использовать СУБД как индекс, кэш и стейт для кучи неструктурированного говна.