с чего бы это? в нормальных субд, например, оракл в принципе если запрос затрагивает более 25% строк — таблица full scan достается. но это не повод же блокировать всю таблицу.
а у mysql получается, что с дедлогами могут запросто завалится даже INSERT INTO… SELECT
mysql в финансах я бы не рискнул. у mysql мягко говоря странноватый подход к блокировкам, при full scan блокировки накладываются на все что вычитывает запрос, а не то что требуется заблокировать.
сказать вы можете, но кому интересны ваши слова? всем интересны тенденции и причины. а тенденция — бизнес массово мигрирует в облака ради экономии. даже не смотря на то что найдутся лапухи, которые сожгут бюджет по глупости. риски с глупцами есть, но дешевизна…
глупости. постройка чего-то типа data lake, где данные лежат на S3 сторидже за $30 терабайт может запросто стоить в несколько тысяч раз дешевле, чем лицензировать серьезную субд и жечь 24x7 виртуалку. то же самое какой-нить стриминг. SaaS сервис где ты платишь только за выкаченные/записанные месседжи запросто могут быть дешевле чем жечь 24x7 виртуалки
где-то к 19 годам приходит понимание, что против уборщицы с тряпкой игровой ПК беспомощен.
к 20 для чего люди ставят пожарную систему, к 24 годам что жечь 24х7 виртуалку невыгодно, на фоне SaaS.
нет. переподписки нет, запрос падает потому что не может получить свои законные 64G на Executor, который хоть и имеет 80G, но выполняет сразу несколько запросов.
Memory left in process limit: 9.51 GB
тому запросу еще 9.51 GB дозволялось скушать, но Executor уже съел свои 80GB лимита выполняя другие запросы. если убрать конкруентов, запрос замечательно исполняется.
как же так — в соседней теме я вам уже рассказывал, но вы предпочли слиться habr.com/ru/company/itsumma/blog/539328/#comment_22622646
на счет «100500 ущлов 8 CPU 64 Gb» (tm) это реально рекомендация клоудеры. их хренатень под названием kudu рекомендует 1000 таблетов на узел, т.е. если у тебя тысяча таблиц, с сотнями партиций и всякие dev, uat, pre-prod разделы, понадобится невообразимое кол-во мелких узлов. и врятли 100500 хватит
$8k было до поглащения hdp, сейчас они нам $6к в месяц уже насчитали. не знаю, может бедным странам на востоке скидки какие дают, нам видно скидки не полагаются. но все равно, на кой кастрированный клоудерой хадуп, не имеющего полноценного решения даже за $240к? то что клоудера продвигает в своей коробке все равно мусор. Импала это по сути интерфейс на медленный hdfs, как источник к BI не годиться. Импала все тянет в инмемори, чуть серьезней нагрузка и executors ноды валятся с Memory limit exceeded. но самое потрясающее, что нода координатор тянет себе в память весь датасет, какой надо отдать клиенту.
поэтому к клоудере приходится ставить нормальную субд для ad-hoc BI запросов.
вы видно не в теме, mapr помер, hdp ушел на дно и был поглощен полуживой клоудерой. у клоудеры акции в глубоком минусе, явно облака все перетягивают.
клоудера вымогает $6к за узел в месяц. месяц Карл. 10 узлов тянут на $2M за 3 года. при том, что к клоудере все равно какую-то полноценную субд надо будет закупать. это сравнимо со всякими oracle exadata, если не дороже. при этом нам, к примеру, пришлось выкидывать их сборку spark, свой hue собирать и многое другое. в тюнинг Импалы у нас думаю тысяча человекочасов вложено и все равно валится с ошибками памяти.
в мире полно бесплатного софта, начиная с ubuntu и firefox, до ngnix и mariadb.
странный ход от клоудеры конечно. и ценник убийственный. может конечно в краткосрочной перспективе удастся вытянуть денег с тех кто подсел на бесплатную сборку, но в долгосрочном это убивает интерес к хадуп, который и так уже не на взлете.
большинство будет ориентироваться на альтернативы хадуп экосистемы, что то типа k8s+spark.
у нас миграция с cloudera 5.x на 6.x заняла более года. когда мы будем готовы запустить что-то на кластере уже java 20 будет деприкатед, а клаудера будет мертва.
я проверял на винде, локально map-reduce и spark 2.4 работают на java 15. т.е. что-то делать сейчас на 8, что бы потом переделывать, смысла нет. следующий хадуп уже не запуститься на 8.
на жава большинство работает в серьезных канторах, соответственно не будут переделывать проекты, что бы пописать на груви или скале. а вот ради синтаксического сахарка с текстовыми блоками, var, рекордами — почему бы и нет. никто же не требует в одну ночь перевести весь проект, сервисов то много.
пока ты выявишь и углубишься в проблемы на 15, как раз и выйдет 17.
а у mysql получается, что с дедлогами могут запросто завалится даже INSERT INTO… SELECT
к 20 для чего люди ставят пожарную систему, к 24 годам что жечь 24х7 виртуалку невыгодно, на фоне SaaS.
Memory left in process limit: 9.51 GB
тому запросу еще 9.51 GB дозволялось скушать, но Executor уже съел свои 80GB лимита выполняя другие запросы. если убрать конкруентов, запрос замечательно исполняется.
habr.com/ru/company/itsumma/blog/539328/#comment_22622646
на счет «100500 ущлов 8 CPU 64 Gb» (tm) это реально рекомендация клоудеры. их хренатень под названием kudu рекомендует 1000 таблетов на узел, т.е. если у тебя тысяча таблиц, с сотнями партиций и всякие dev, uat, pre-prod разделы, понадобится невообразимое кол-во мелких узлов. и врятли 100500 хватит
поэтому к клоудере приходится ставить нормальную субд для ad-hoc BI запросов.
клоудера вымогает $6к за узел в месяц. месяц Карл. 10 узлов тянут на $2M за 3 года. при том, что к клоудере все равно какую-то полноценную субд надо будет закупать. это сравнимо со всякими oracle exadata, если не дороже. при этом нам, к примеру, пришлось выкидывать их сборку spark, свой hue собирать и многое другое. в тюнинг Импалы у нас думаю тысяча человекочасов вложено и все равно валится с ошибками памяти.
странный ход от клоудеры конечно. и ценник убийственный. может конечно в краткосрочной перспективе удастся вытянуть денег с тех кто подсел на бесплатную сборку, но в долгосрочном это убивает интерес к хадуп, который и так уже не на взлете.
большинство будет ориентироваться на альтернативы хадуп экосистемы, что то типа k8s+spark.
пока ты выявишь и углубишься в проблемы на 15, как раз и выйдет 17.