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

[metaclass]

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

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

Comments

[falcrum.livejournal.com]

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

[vit-r.livejournal.com]

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

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

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

[vissarion.livejournal.com]

юнион быстрее ора

[insanegigolo.livejournal.com]

а по последнему пункту, что стоит почитать?

[vit-r.livejournal.com]

Kambal group. В первую очередь dimensional modeling

Если, конечно, интересно понять логику, а не любоваться полотнами SQL запросов.

[avnik.livejournal.com]

обычно -- хипстерское bigdata -- это то что вы описали, но втиснутое в бюджет в три раза меньше. И все беды там ровно от этого.

[maksenov.livejournal.com]

А что с юнионом-то не так? Ну даст он доп. сортировку если надо уникальные записи только, а это решается реструктуризацией запроса (например, один DISTINCT с кучей UNION ALL, хотя это должен утрясать оптимизатор). Тащемта, даже в очень сложных стандартных моделях (типа POSC Epicenter или PPDM) юнионы зверь достаточно редкий, и париться из-за этого вообще не стоит.

К статье - дык может просто не осилили? Поди для каких-нибудь редких запросов можно сделать materialized view или что-то в этом духе...

[vp.livejournal.com]

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

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

[kranov.livejournal.com]

>Переводим: NoSql, запись всего в кучу и последовательная обработка всего в лоб.
>Так получается? :)
там ничего не сказано, никаких монго хадуп риак, поэтому думаю там либо пачка mysql-й либо тесктовые файлы

[vinsent_ru]

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

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

[vit-r.livejournal.com]

Хипстерское - это два application сервера, load balancer и два database сервера (потому что инвестор платит) на полтора визита в минуту (ну не пошёл пользователь на наш замечательный сайт, что тут поделать?)

[kkirsanov.livejournal.com]

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

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

[alll]

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

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

[metaclass.livejournal.com]

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

[volodymir-k.livejournal.com]

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

[volodymir-k.livejournal.com]

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

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

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

[fas-tm.livejournal.com]

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

[metaclass.livejournal.com]

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

[alll]

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

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

[jakobz.livejournal.com]

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

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

[bagamut.livejournal.com]

параллельная обработка, кластеры же

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

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

[bagamut.livejournal.com]

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

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

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

[tzirechnoy.livejournal.com]

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

[tzirechnoy.livejournal.com]

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