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

[metaclass]

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

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

Comments

[vinsent_ru]

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

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

[kkirsanov.livejournal.com]

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

Бигдаты на столько биг, что их оптимизировать бессмысленно. :)

[fas-tm.livejournal.com]

>>И считался там один отчетик, имено так - жабаскриптом в лоб перебором
если дать дураку стеклянный хуй, он обязательно его разобъет.
Носикль это такой молоток который умеет бить только по одному гвоздю. Все остальное - кровавое месиво из пальцев.
В вашем примере CouchDB и Postgres ни при чем :)