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

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

ну 1 млрд записей в каком-нибудь справочнике это тащемта уже биг, видимо. Впрочем, не сильно понимаю, как тут nosql поможет, скорее надо шардить по обычным реляционным серверам это дело.

[volodymir-k.livejournal.com]

ну и как ваши джойны будут работать по шардам?

[metaclass.livejournal.com]

Скорее всего, мирными средствами никак, придется на сервере приложений собирать. Или копаться в дебрях какого-нибудь оракла, который это просто обязан уметь, за большие деньги :)

[bagamut.livejournal.com]

а если все равно собирать надо так можно сразу бигдата собиралку поставить, там весь фокус что это все масштабируется, там же не просто один отчетик генерится, а тыщи их, параллельно

при этом и размер данных все время растет и и количество запросов растет

миллиард записей это мало, представь себе базу по покупкам и транзакциям какого нибудь Wallmart, миллионы покупателей, миллиарды транзакций, вошло, ушло и тп

[tzirechnoy.livejournal.com]

Мелкие редкоменяющиеся справочники можно разложыть по всем шардам, и менять административно. Крупные редкоменяющиеся отношэния можно разложыть по всем шарпдам, и менять регулярно или иметь спецыальную процэдуру обновления.

[permea-kra.livejournal.com]

да ващемто ни параллельный merge sort на кластере, ни параллельный merge join на нем же каким-то космическим рокет-сайнсом не являются, поэтому реляционность сама по себе шардингу не помеха. Там скорее проблема в том, что в распространенное бесплатное это пока не запилили, ну и сетка в таком кластере должна быть очень веселой, чтобы петабайты гонять.

[alll]

Ну, возможно тут игра на тонких различиях между "не понимаем, как вон то нам поможет" и "понимаем, что вот это нам не поможет" в условиях сильного давления эффекта Даннинга-Крюгера и маркетингового хайпа.

Мне отчего-то всегда казалось, что nosql нужен скорее для случаев, когда sql избыточен, ну там хуякхуяквпродакшен. Той же berkeleydb в обед сто лет и кого можно вот этим всем удивить, казалось бы.

[thetvv.livejournal.com]

С несколькими десятками миллиардов записей реляционные базы справляются запросто даже на одном инстансе. По крайней мере Oracle, постоянно работаю с этим.

IMHO до триллиона записей — это еще не биг, хотя, конечно, от данных зависит. ))

[anonim-legion.livejournal.com]

По секциям раскладывать.

О теме поста:

Мне предлагали работу Старшего Инженера в МТС. За 45 т.р.(~1500$), в декабре 2013 года. Мне кажется, для Старшего Инженера это маловато. Не сомневаюсь, что автор статьи, уважаемый билайновский программист, имеющий опыт работы в Голландии, Европе и на Луне имеет больше денег. Но он один - а данных много. Вот отсюда и возникает необходимость в БигДата.

Кстати, будь моя воля - я бы запретил оператору сотовой связи торговать аппаратурой связи.

[berezovsky.livejournal.com]

А чем опыт работы в Голландии отличается от опыта работы в Беларуси?

[anonim-legion.livejournal.com]

Я это к тому, что в сотовых компаниях сотрудникам платить не любят. А вот звезда... из Явропы... такому можно и заплатить. Опять же, он выражение Big Data знает.

[berezovsky.livejournal.com]

А-а-а, так там рак. Я просто боюсь хабры открывать.