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

[metaclass]

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

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

Comments

[falcrum.livejournal.com]

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

[vissarion.livejournal.com]

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

[maksenov.livejournal.com]

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

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

[vit-r.livejournal.com]

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

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

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

[insanegigolo.livejournal.com]

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

[avnik.livejournal.com]

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

[vp.livejournal.com]

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

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

[kranov.livejournal.com]

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

[bagamut.livejournal.com]

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

[serbod.livejournal.com]

NoSQL для CRUD (через tables API), простые SELECTы на сервере, сорты, джойны, юнионы и прочая групповуха на стороне клиента.

[vinsent_ru]

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

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

[kkirsanov.livejournal.com]

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

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

[fas-tm.livejournal.com]

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

[alll]

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

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

[metaclass.livejournal.com]

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

[volodymir-k.livejournal.com]

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

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

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

[serbod.livejournal.com]

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

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

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

[jakobz.livejournal.com]

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

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

[serbod.livejournal.com]

В SQL все относительно прекрасно, когда состав хранимых данных не меняется каждую неделю. =)

А еще в SQL запись в таблицу килобайта данных строки отжирает чуть ли не мегагерц тактов. Даже в prepared statement всякие params mapping, marshalling, блокировки, транзакции, проверки.. Если нужно просто строку байтов сохранить для потомства, то тут 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]

2 терабайта это небольшая база. У Билайна в данном случае речь идёт о десятках новых терабайтов в день, а вся база - петабайты. Найти в ней в стиле реляционном можно, но даже простой поиск без джоинов по индексированому полю будет бежать минуты.

[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 петабайт :)

[anonim-legion.livejournal.com]

А что, триграммый поиск уже не в моде?

[yuri-yurkevich.livejournal.com]

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

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

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

[serbod.livejournal.com]

Ежемесячные расходы на сбор и хранение "сырых" данных не превышают расходов на содержание одного не шибко ценного сотрудника. Зато польза от анализа и принятого решения может быть впечатляющей.

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