что бы получить опыт и осознать почему технологии бигдаты неизбежны с какого-то объема. если речь о хранилище то ты просто не зальешь за вменяемый промежуток времени данные с врубленными FK и индексами. а всякие скоринги и фрауд детекшены уже не нужны спустя несколько часов. потому сначала отключают FK и индексы при заливке, а потом переезжают на хадупы где индексов и FK нет в принципе, а валидация связей — часть ETL процесса интеграции данных в хранилище. если вырубать FK и вовсе не отслеживать зависимости то да, болото данных гарантированно.
но это про хранилища, тут же у меня скорее речь про oltp, где у mysql умудряются сталкивается транзакции, между которыми ничего общего.
давай. попробуй расстроить. я поржу.
в любой версионной субд есть row level блокирование и подобные ситуации, где сталкиваются транзакции не имеющие ничего общего не возможны. уровни изолированности транзакций и блокировки разводят транзакции затрагивающие общие данные, а в примере у каждой транзакции своя запись, не имеющая никакого отношения к другим транзакциям.
что бы воочию увидеть как mysql пытается поставить локи на незакомиченные записи соседней транзакции.
что касается индексов, то во первых в оракле мне не приходит в голову индексировать абсолютно каждое поле. во вторых повторюсь — дело в фуллскане, а не индексах. индекс лишь снижает вероятность, но не отменяют фулскан. например у меня лезли дедлоки на таблице с индексом, но записей было мало и mysql применял фуллскан не смотря на индекс. по идеи в запросах где вычитывается более половины записей таблицы тоже фулскан должен быть.
не выйдет в один проход ничего. это азы. что бы отправлять «сообщения», например о платежах на редюсер, тебе надо знать которые компании висят на одном адресе. т.е. у тебя будет 2 прохода, первый посчитает ключ, так что бы у сообщений компаний на одинаковом адресе он совпал и только вторым проходом уже группировать.
не увидел ничего там интересного. говорю, мы примерно такое налабали лет 5 назад. «сообщения» это были avro объекты в parquet файликах. теперь самоотверженно выпиливаем. не работает.
представь что тебе пришло требование теперь группировать по компаниям, зарегистрированным на одном адресе. все, с твоей структурой в один проход теперь ты нихера не посчитаешь.
+GDPR
просто надо опыт хоть немного иметь. и не на ноутбуке. может с лайками фейсбука это работает, но в серьезных бизнес задачах ентерпрайза такое работает хреново. во первых вся эта дребедень зависит от того что ты выберешь ключом. выбрал ты какой-нить номер клиента, все здорово. целый месяц. но на второй тебе говорят, слушай. у нас тут полно клиентов на одном адресе… ты еще не переписал все заново, а уже прилетает следующее маааленький вопрос от юристов: а что значит «Событие, однажды случившись, больше не изменяется»? вы может слышали, но GDPR требует как минимум анонимизировать всю историю…
по сути идея предлагает сделать недоделанный мап-редюс. в мап-редюсе хотя бы в параллель все читается.
подход уже успел взлететь и угаснуть. на практике отчет пойдет читать сообщения о транзакцияй их «внезапно» миллиард, в память не влезает и привед.
сейчас модно в кафку такие вот сообщения писать и от туда уже чем-то типа спарк вычитывать, находу в памяти агрегируя.
нет у них ничего. есть поделки на базе арм, в которых китайского кроме лейбла нет ничего. у России прямой аналог процессор Байкал. т.е. без белых людей из-за океана они ничего со своими армами сделать не смогут. у них нет ни спецов ни компетенция на что-то кроме адаптации разработок арм.
фундамент слегка разный. одни наукой занимаются, другие адаптацией чужих реализаций. теперь будет забавно посмотреть как не имея ни процев ни чипов обвязки будут выкручиваться?
я кластер не настраивал, этим занимается отдельные 1.5 человека. это вполне сравнимо с той командой DBA которые возились с десятком наверно инстансов относящихся к не OLTP задачам.
по неймноде я чуть ниже расписал. хадуп так не работает. zookeeper назначит главной одну из секондари неймнод и джоб ничего не заметит. даже в совсем трагической ситуации джоб не метиться как фейлед целиком, пометится лишь один из тасков редюсера. один из многих сотен. в худшем случае ярн рестартанет один-два редюсера.
у нас вылетала и главная неймнода и секондари. софту это хлопот вообще не доставляло. при файловере zookeeper просто назначает глвной другую неймноду и все. таски мап-редюс или спарка если стартанули, то им пофигу, если они пытаются стартануть прямо во время фаловера, ну пару раз фейлятся, ярн рестартанет.
но суть даже не в том что у хадупа все обложено всякими HA, зукиперами и автоматами на рестарт, а то что там вообще вся идеология строится на имутабл файликах. че-то там зафейливось — не трагедия. минут через 5 можно смело пробовать еще разок стартануть. в традиционных субд же такие фокусы не проходят.
вы говорили, что владение хадупом «очень даже платно». надеюсь я доступно это опроверг. кластер по меркам оракла огромный, по меркам хадупа конечно не из больших, но повторюсь, мы не гугл, для нас все дело в тех миллионах, что не ушли на оракловые лицензии.
на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу. если мапер стартовал, то блоки данных у него локальны и от неймноды ничерта уже не нужно. лично я наблюдал много больше проблем при вылетах датанод. инфраструктуру передали кому то внешнему и теперь у нас это не такая уж редкость когда целиком мап-редюс джоб фейлится и у ярна не выходит рестартануть. но к отказу и это не приводит, опять же во многом из-за того что у хадупа файлики имутабл бай дизайн. такие джобы рестартит наш шедулер и никто никогда особо даже такие инциденты на хадупе не замечает. лично у нас устойчивость системы выросла многократно. rac бы сравнимых издевательств не пережил бы однозначно. ни за какие деньги.
а на счет кол-ва у нас еще полно микрокластеров под игрушки, плюс у каждого девелопера все компоненты апликухи в докерах. от куду и импалы, до того самого спарка. на фоне оракла мягко говоря другой уровень. и снова в первую очередь не от того что оракл не могёт в докерах-шмокерах, а лицензионный бред и бабло.
я прав и это факт.
у нас CDH кластер на 600 cores и не платили ни копейки. денег там стоит исключительно супорт, мы супорт не брали. даже 200 ядер на оракле с rac, партишенингом, компрессией, датагвардом это миллионы баксов только лицензий. + еще супорт.
отказоустойчивость в хадупе бай дизайн. вылет любой ноды — штатная ситуация, есть понятие rack awareness. в оракле же rac не отменяет обязанности иметь датагвард, что скорее костыль.
map-reduce, да отходит, но у нас еще вовсю применяется главным образом из-за дубовости и надежности. если у канторы суровые SLA, быстрый спарк с его 100500 нюансов на тему поломанных кешей, меняющимися планами и кастрацией от клоудеры бывает не самый лучший выбор. в map-reduce нечему ломаться и время исполнения много проще предсказать.
платный. как минимум та вариация (greenplum), которая хоть как то соревнуется с хадупами и мап-редюсами.
а обычный постгрес совсем под аналитику не подходит. там нет колончатых структур и мусор в таблицах раздувает файлы данных. и партишенинг лишь в пг10 обещают завести, то что там есть пародия, не партишенинг.
аффтор вероятно студент и делает первые шаги в индустрии. студент так и не понял что популярность бигдата стека не от размера данных, а от бесплатности. те кто внедряют хорошо понимают что они не гугл. они внедряют хадупы в первую очередь, что бы не платить миллионы за лицензии. они не гугл, они просто считают деньги.
/устало/ не важно какой период ни в один момент истории страна не была в состоянии накормить свой народ и обеспечить базовыми товарами. при сталине голод выкашивал миллионы, при хруще начали экспортировать нефть и закупать зерно и продукты питания. в 1940 году вооруженные тракторами колхозники собрали меньший урожай, чем крестьяне руками в 1913 году. при этом на селе население примерно равное. при хруще довели производство сх техники до половины от всей планеты, но вся эта груда хлама так и не смогла увеличить сборы урожая. чем больше хлама производили заводы, тем больше неэффективная экономика импортировала буржуйского зерна. и так пока производство хлама не превратилось в полный абсурд и не сожрало остатки псевдоэкономики.
дух первооткрывателей развелся, оставив лишь привкус спирта и разрушенную страну, оставшуюся после таких прожектов без штанов.
теперь дети и внуки этих мудрых инженеров оказывают интим сервис по европе. «А я то в советские времена ооо!» (тм)
но это про хранилища, тут же у меня скорее речь про oltp, где у mysql умудряются сталкивается транзакции, между которыми ничего общего.
в любой версионной субд есть row level блокирование и подобные ситуации, где сталкиваются транзакции не имеющие ничего общего не возможны. уровни изолированности транзакций и блокировки разводят транзакции затрагивающие общие данные, а в примере у каждой транзакции своя запись, не имеющая никакого отношения к другим транзакциям.
что касается индексов, то во первых в оракле мне не приходит в голову индексировать абсолютно каждое поле. во вторых повторюсь — дело в фуллскане, а не индексах. индекс лишь снижает вероятность, но не отменяют фулскан. например у меня лезли дедлоки на таблице с индексом, но записей было мало и mysql применял фуллскан не смотря на индекс. по идеи в запросах где вычитывается более половины записей таблицы тоже фулскан должен быть.
dba.stackexchange.com/questions/238756/mysql-innodb-trying-to-lock-uncommitted-row-from-parallel-transaction-deadlock
при фулскане оно пытается наложить локи на все, даже на не незакомиченные записи.
представь что тебе пришло требование теперь группировать по компаниям, зарегистрированным на одном адресе. все, с твоей структурой в один проход теперь ты нихера не посчитаешь.
+GDPR
подход уже успел взлететь и угаснуть. на практике отчет пойдет читать сообщения о транзакцияй их «внезапно» миллиард, в память не влезает и привед.
сейчас модно в кафку такие вот сообщения писать и от туда уже чем-то типа спарк вычитывать, находу в памяти агрегируя.
по неймноде я чуть ниже расписал. хадуп так не работает. zookeeper назначит главной одну из секондари неймнод и джоб ничего не заметит. даже в совсем трагической ситуации джоб не метиться как фейлед целиком, пометится лишь один из тасков редюсера. один из многих сотен. в худшем случае ярн рестартанет один-два редюсера.
но суть даже не в том что у хадупа все обложено всякими HA, зукиперами и автоматами на рестарт, а то что там вообще вся идеология строится на имутабл файликах. че-то там зафейливось — не трагедия. минут через 5 можно смело пробовать еще разок стартануть. в традиционных субд же такие фокусы не проходят.
на скольку я помню вылет неймноды вообще эффекта на мап-редюс не оказывал ни разу. если мапер стартовал, то блоки данных у него локальны и от неймноды ничерта уже не нужно. лично я наблюдал много больше проблем при вылетах датанод. инфраструктуру передали кому то внешнему и теперь у нас это не такая уж редкость когда целиком мап-редюс джоб фейлится и у ярна не выходит рестартануть. но к отказу и это не приводит, опять же во многом из-за того что у хадупа файлики имутабл бай дизайн. такие джобы рестартит наш шедулер и никто никогда особо даже такие инциденты на хадупе не замечает. лично у нас устойчивость системы выросла многократно. rac бы сравнимых издевательств не пережил бы однозначно. ни за какие деньги.
а на счет кол-ва у нас еще полно микрокластеров под игрушки, плюс у каждого девелопера все компоненты апликухи в докерах. от куду и импалы, до того самого спарка. на фоне оракла мягко говоря другой уровень. и снова в первую очередь не от того что оракл не могёт в докерах-шмокерах, а лицензионный бред и бабло.
у нас CDH кластер на 600 cores и не платили ни копейки. денег там стоит исключительно супорт, мы супорт не брали. даже 200 ядер на оракле с rac, партишенингом, компрессией, датагвардом это миллионы баксов только лицензий. + еще супорт.
отказоустойчивость в хадупе бай дизайн. вылет любой ноды — штатная ситуация, есть понятие rack awareness. в оракле же rac не отменяет обязанности иметь датагвард, что скорее костыль.
map-reduce, да отходит, но у нас еще вовсю применяется главным образом из-за дубовости и надежности. если у канторы суровые SLA, быстрый спарк с его 100500 нюансов на тему поломанных кешей, меняющимися планами и кастрацией от клоудеры бывает не самый лучший выбор. в map-reduce нечему ломаться и время исполнения много проще предсказать.
а обычный постгрес совсем под аналитику не подходит. там нет колончатых структур и мусор в таблицах раздувает файлы данных. и партишенинг лишь в пг10 обещают завести, то что там есть пародия, не партишенинг.
теперь дети и внуки этих мудрых инженеров оказывают интим сервис по европе. «А я то в советские времена ооо!» (тм)