в навороченных схд несколько уровней кеширования. «горячие» блоки гуляют по ssd и прочим кешам. поэтому скорость чтения датафайла утром и ночью запросто различаются на порядок.
а как эти навороченные схд сочетаются с оптимизаторами субд? регулярно наблюдаю проблемы когда оптимизатор оракла собрал статистику в момент когда датафайлы активно использовались и сидели в кеше/ssd, а когда пришло время запускать ночной джоб блоки таблиц вытеснились на тормозные hdd. в результате то что оптимизатор считал, что вычитает за 2 минуты нестед-лупом, в реальности долбит хдд часами.
в отличие от индюшатины у меня образование и серьезный опыт. в том числе и жава и хадупах и многом другом. потому я прекрасно понимаю сколько написать. MERGE на таблички по 100 млн запустит хеш-джоин между основной таблицей и external, их фулсканы займут несколько секунд. а вот тащить 100 млн по jdbc в одном потоке точно дело не пары секунд и на несколько порядков более затратое дело, чем MERGE.
я же говорил что индюшатину за весту чую. pl/sql в такой задаче не нужен. у меня подобные задачи решаются созданием external table, когда приходит новый файл, делается create or replace directory, которая указывает на новый файл. дальше обычный MERGE между extranal table и основной. т.е. команда MERGE into main_table… WHEN NOT MATCHED THEN INSERT…
вот это, да. займет пару секунд. а вот вычитать в апп сервер по jdbc 100 млн строк что бы вычислить дельту уйдет вечность только на выкачивание. классика индюшатины, не слышавшей о MERGE.
боюсь болезнь именно у тебя. кстати, тот эпизод, когда весь отдел ухахатывался на твой тупизной, а ты не мог понять чего смеются. они смеялись вот по этому
Я нашему бывшему ораклисту (да, его позднее ушли попой в мороз) показывал фокус, когда даже с тормозным Ораклом оказывалось в несколько раз быстрее скачать весь dataset
весь приличный бизнес идет в бигдата, где за попытку вытянуть данные на апп сервер убивают на месте. все бигдаты обрабатывают данные там же, где данные хранятся.
человек с индуской внешностью лжет. ядро субд абсолютно всегда быстрее. скорость в nosql обеспечивается заметно более медленной обработкой, но в параллель. всякие хадупы много медленее ядра оракла, но из-за того что легко поднимают сотни и тысячи параллельных процессов на гораздо больше кол-ве узлов обгоняют. но в одном потоке, тащить данные по нетворку на апп сервер, это всегда медленее. апп сервер ничего не умеет, чего бы не умел pl/sql
нет, мальчик с хадупом и вот таких вот индюшат поучатель. сначала он был лист лонгов, потом понадобилось имя, потом баланс, потом юзеров таких параллельно тысяча.
вы индусы все одинаковы.
индюшачья классика. в проде этот кодер получает Error running child: java.lang.OutOfMemoryError: Java heap space и идет читать что такое субд и знакомиться с азами.
firebird версионник до сих пор не имеет лога. там при апдейте транзакция пишет прямо в датафайл новую версию строки, не трогая старую. по коммиту обновляет запись в заголовке, где указывает что новая версия закомичена. на IL snapshot транзакции стартовавшие после записи в заголовке видят уже новую версию, стартовавшие до старую версию. спустя какое-то время сборка мусора вычищает никому не нужные версии строк из файла данных.
в эпоху реалтайм аналитики с kafka + hadoop подсаживаться на пропретарные технологии, с которых никуда не переехать и которые будут вытягивать бабло по экспоненте глупо. во сколько раз вырастет цена, когда нагрузка вырастит хотя бы до 40к запросов? такие базы имеют смысл лишь под прототип с крошечной нагрузкой.
странный поток сознания. какую строчку ни возьми, если не полная чушь, то во многом. то что к nosql дают возможность 2pc транзакцию на несколько «документов» не значит, что это вытеснит более примитивные режимы. если взять происходящее во всяких багдата/хадупах, то хорошо видно что консистентность из базы не столь уж кого-то заботит и т.д. и т.п.
особенно повеселило восхищение майкрософтом, учитывая, что flashback query в оракле уже лет 8 доступны.
какой странный дизайн. зачем же выносить модель с yarn кластера, если было бы много эффективней прямо в спарковском датасете дергать какую-нибудь жава ML библиотеку посерьезней? например jppml дает вполне приличный набор ML алгоритмов.
Сейчас, когда система стабилизировалась, пришли к конфигурации с тремя средами – тест, препрод и прод (основная).
а тест и препрод такие же маленькие как в облаке были? 3 крошечные ноды, там же ничего объемное не протестируешь. тем более если если толкается и ярн и импала.
вообще изначально сайнтист тот кто сам алгоритм может разработать, а скормить очищенные данные одному из миллионов фрейморков это задача аналитика. но теперь любой аналитик освоивший три команды питона, которые тренируют модель, называют себя сайнтистами…
к чему эта клоунада? так сложно открыть документ тендера и посмотреть сколько закуплено на тот млрд? на млрд они купили 6 стоек по 96 дисков, диски по 12 тб.
все датацентры гугла и амазона живут на ширпотреб дисках, статистика отказов публикуется и доступна. разницы с ентерпрайз гугл не видит, но даже ентерпрайз SSD диски 1.5-2 раза дороже. ну будет не $2 млн, а $4 млн. все равно во многие разы дешевле купола
гуглы, амазоны и прочие лидеры ставят примерно в эти же хадупы. от того они и лидеры
у леново 15.36 TB ынтерпрайз ssd диски есть, стоят порядка $26k. даже с такими хадуп дешевле купола выходит
вот это, да. займет пару секунд. а вот вычитать в апп сервер по jdbc 100 млн строк что бы вычислить дельту уйдет вечность только на выкачивание. классика индюшатины, не слышавшей о MERGE.
не надо качать весь датасет, люди буду смеяться
вы индусы все одинаковы.
что-то я сомневаюсь что с таким подходом реально переключиться
особенно повеселило восхищение майкрософтом, учитывая, что flashback query в оракле уже лет 8 доступны.
а тест и препрод такие же маленькие как в облаке были? 3 крошечные ноды, там же ничего объемное не протестируешь. тем более если если толкается и ярн и импала.
zakupki.gov.ru/223/purchase/public/purchase/info/documents.html?regNumber=31806451184
ознакомься что закуплено на тот млрд
все датацентры гугла и амазона живут на ширпотреб дисках, статистика отказов публикуется и доступна. разницы с ентерпрайз гугл не видит, но даже ентерпрайз SSD диски 1.5-2 раза дороже. ну будет не $2 млн, а $4 млн. все равно во многие разы дешевле купола
у леново 15.36 TB ынтерпрайз ssd диски есть, стоят порядка $26k. даже с такими хадуп дешевле купола выходит
lenovopress.com/lp0612-pm1633a-enterprise-capacity-12gb-sas-ssd