в узбекистане еще и алгоритмы изобретают? хорошие у вас урожаи.
бигдата в финтеке это в первую очередь data lake на файликах hdfs/s3, анализ с применением обучаемых алгоритмов хоть и идет следом, но математики там давно нет. весь science давно упрятан в ML фреймворки, от аналитика требуется лишь в нужной последовательности дернуть методы.
ощущение, что текст написан из узбекистана или еще более продвинутой страны, где бигдата в 2021 году еще хайп, а не обязательный инструмент любой фин организации. в наших краях думаю уже нет банка или финтеха без чего-то аля хадуп. и хранят/считают они там, что характерно свои структурированные фин данные, и не превращаются в болото, и выполняют GDPR, т.е. четко отслеживая, где и какие данные и когда они должны быть анонимизированны.
ощущение, что автор не видел реальных ентерпрайзов и насмотревшись чего-то смешного в узбекистане спроецировал на всю индустрию.
я статью не читал, но про сохранность все верно. в data lake запросто можно столкнутся с тем, что кусок данных вроде вчера был записан, а сегодня нету. и фиг расковыряешь как так вышло. из полновесной базы данных так просто данные не пропадут, она просигнализирует если с файлами данных что-то нехорошее произойдет и многие субд отслеживают целостность каждого блока в бд.
Вот статья на тему, весьма и весьма давняя: Concurrent Access Resolution on LUW and DB2 for z/OS.
я выше писал про этот смешной костыль. где там нечистый блокировочник? добавили еще более неконсистентную кашу чем обычный read committed — где тут уровень хотя бы mysql?
я клоню к тому что вам 66 и вы разговариваете с какими-то голосами в вашей голове.
факты и ссылки на исторические документы вам не интересны, думаю на этом лучше закончить. если честно мне вообще не интересно, что вы там путаете. мф ушел, подходы устарели. все что делалось на мф, сейчас делается ровно в противоположном ключе. никто не станет сейчас делать единый пул блокировок на CF узле, как это сделано на db/zOS. никто не будет строить кластер со сложной i/o подсистемой распаянной в железе.
вобщем все что вы можете рассказать уже не интересно. простите.
Смотрю я на Ваш комментарий и не вижу смысла пытаться дальше обсудить тему СУБД здесь. Вы абсолютно уверены в своей правоте, ОК.
мои слова ничего не значат, правоту определяет рынок. рынок решил, что db2 не нужен, версионные субд начиная с mysql и postgres, заканчивая ораклом и azure sql вытеснили блокировочники с рынка.
Было бы одно решение которое «на голову» превосходит все остальные существующие аналоги во всех существующих сценариях — было бы просто замечательно и большинство достаточно быстро перешло на это решение.
так и произошло, оракл сделал версионность, остальные быстро переняли. db2 не перенял и ушел на покой вместе с мф платформой. на плаву остались лишь те кто переняли.
вы спорите с какими-то голосами в вашей голове, постарайтесь сосредоточится на том что я утверждал. cost based optimizator делали для rs/6000 в середине 90х, когда ветка luw называлась db2 common server. во документ от 1996 года dsf.berkeley.edu/papers/sigmod96-magic.pdf
т.е. уже в середине 90х z/OS был в дали от прогресса, а прорывные вещи для db2 создавались на unix платформе.
потрясающее умение, вот только рынок хотя бы уровень mysql ожидает, а не грязное чтение. даже mysql выдает консистентный набор на момент старта запроса/транзакции.
mssql 2019 big data вокруг hadoop построен, совсем свежий продукт. его аналог в облаке azure synapsis — хадуп внутри и туда чуть не силой майкрософт загоняет.
бигдата. impala позволяет гонять sql запросы на тысячах hadoop узлах, всякие spark sql поверх delta lake табличек от databriks, там тоже зачастую речь идет о тысячах узлах и вполне sql интерфейсе. mssql 2019 big data — построен вокруг хадупа, т.е. на тысячи узлов рассчитан. все это не совсем реляционный, но sql.
что там актуально вот прямо сейчас не знаю, уже многие десятилетия фишки luw сильно выигрывает. тот же cost based optimizer делали для rs/6000, а в мф долго и мучительно портировали. всякие xml type с опозданием в мф завезли, сейчас уверен, что костыли в стиле Currently committed semantics не завезли в zOS версию.
что касается оракл, оракл лучший из версионников. одно это уже next level. в мире mysql, postgress, azure sql остаться блокировочником и плодить костыли типа Currently committed semantics — бесперспективное занятие. далее у оракла несопастовимо более навроченный язык pl/sql, начиная с пакетов и разделением на body и header. там отслеживание зависимостей в коде. у кода есть понятие invalid. всякие автономные транзакции и т.п. оракл блокирует ровно столько строк, сколько требует логика, нет костылей в виде lock escalation. в оракле более навороченный оптимизатор, есть bitmap index, есть тип хранения cluster, где джойнятся данные нескольких таблиц. можно очень долго продолжать
360 — 64, 86 — 70е, z(потомок 360) — 90е — вот и получилось что z может приспособится к 86, а не наоборот
глупости детектед. x86 спсобен заместить абсолютно любой МФ. точнее уже заместил. тогда как МФ в принципе не может масштабироваться до необходимого уровня. даже не столь уж крупный яндекс не построить на МФ, вообще никак. всякие высоконагруженные биржи, типа нью-йорксой. никакой МФ такие нагрузки не вытянет.
был бы уровень низкий, вы бы не остались последними с этим динозавром. тому что большие и успешные выкинули мф платформу есть совершенно объективные причины. и куцость блокировочного db2 одна из главных причин. db2 блокировочник и никому не интересен в эпоху облаков. а ничего, кроме еще более старых субд на мф нет.
хотя вру, наркоманы из ibm на полном серьезе предлагают в мф запускать hadoop. кстати показатель уровня…
зы. hadoop сегодня вполне замещает реляционные dwh, наши пользователи гоняют sql и не подозревают что там под низом давно уже не оракл, а hadoop. и что характерно, там много, много, много больше чем 60 гб
ну да, тут есть проблемы=) в основном «разработчики» не видят потери в архитектуре, потому что не представляют а как оно еще может быть. но объяснить можно, просто это долго(человеку надо рассказать целый курс по архитектурам) и от того не интересно
не интересно потому что нигде не работает, кроме глупых маркетинговых материалов. db2 z/os хранит блокировки в CF, все узлы долбят в этот единственный CF по sysplex. это не может работать и нигде не работает. зачем тратить время на рассказы, если ни в одном облаке такой смешной архитектуры с единой точкой долбления не встретишь?
в эпоху облаков полно субд способных масштабироваться на тысячи узлов, но ничего, даже отдалено похожего на архитектуры мф в облаках не встречается. потому и никому не интеремно, раз ушло на покой и было заменено даже на уровне идеи.
до zEnterprise, гибридной архитектуры объединяющей z, x86 и RISC. Задайте себе вопрос почему именно z смогла быть основой гибрида, а не х86 и не RISC(p).
ну это очевидно, что бы продавать ненужную никому платформу в нагрузку с полноценными x86.
когда z идет вместе с x86 есть шанс замедлить миграцию с устаревшей платформы на x86. впарить одинокий z уже не реально, слишком убогий там софт, полноценных баз данных нет от слова совсем. db2 z/os проигрывает даже своему luw собрату, который совершенно неконкуретноспособен в эпоху облаков. баз данных уровня oracle, casandra или hadoop нет на z платформе.
бигдата в финтеке это в первую очередь data lake на файликах hdfs/s3, анализ с применением обучаемых алгоритмов хоть и идет следом, но математики там давно нет. весь science давно упрятан в ML фреймворки, от аналитика требуется лишь в нужной последовательности дернуть методы.
ощущение, что автор не видел реальных ентерпрайзов и насмотревшись чего-то смешного в узбекистане спроецировал на всю индустрию.
как там java на э2к, есть прогресс по оптимизации?
что-то ссылка ведет на какую-то недописанную книгу. статья выросла в книгу и стала платной или я чего-то не понял?
я выше писал про этот смешной костыль. где там нечистый блокировочник? добавили еще более неконсистентную кашу чем обычный read committed — где тут уровень хотя бы mysql?
я клоню к тому что вам 66 и вы разговариваете с какими-то голосами в вашей голове.
факты и ссылки на исторические документы вам не интересны, думаю на этом лучше закончить. если честно мне вообще не интересно, что вы там путаете. мф ушел, подходы устарели. все что делалось на мф, сейчас делается ровно в противоположном ключе. никто не станет сейчас делать единый пул блокировок на CF узле, как это сделано на db/zOS. никто не будет строить кластер со сложной i/o подсистемой распаянной в железе.
вобщем все что вы можете рассказать уже не интересно. простите.
мои слова ничего не значат, правоту определяет рынок. рынок решил, что db2 не нужен, версионные субд начиная с mysql и postgres, заканчивая ораклом и azure sql вытеснили блокировочники с рынка.
так и произошло, оракл сделал версионность, остальные быстро переняли. db2 не перенял и ушел на покой вместе с мф платформой. на плаву остались лишь те кто переняли.
dsf.berkeley.edu/papers/sigmod96-magic.pdf
т.е. уже в середине 90х z/OS был в дали от прогресса, а прорывные вещи для db2 создавались на unix платформе.
потрясающее умение, вот только рынок хотя бы уровень mysql ожидает, а не грязное чтение. даже mysql выдает консистентный набор на момент старта запроса/транзакции.
что касается оракл, оракл лучший из версионников. одно это уже next level. в мире mysql, postgress, azure sql остаться блокировочником и плодить костыли типа Currently committed semantics — бесперспективное занятие. далее у оракла несопастовимо более навроченный язык pl/sql, начиная с пакетов и разделением на body и header. там отслеживание зависимостей в коде. у кода есть понятие invalid. всякие автономные транзакции и т.п. оракл блокирует ровно столько строк, сколько требует логика, нет костылей в виде lock escalation. в оракле более навороченный оптимизатор, есть bitmap index, есть тип хранения cluster, где джойнятся данные нескольких таблиц. можно очень долго продолжать
глупости детектед. x86 спсобен заместить абсолютно любой МФ. точнее уже заместил. тогда как МФ в принципе не может масштабироваться до необходимого уровня. даже не столь уж крупный яндекс не построить на МФ, вообще никак. всякие высоконагруженные биржи, типа нью-йорксой. никакой МФ такие нагрузки не вытянет.
хотя вру, наркоманы из ibm на полном серьезе предлагают в мф запускать hadoop. кстати показатель уровня…
зы. hadoop сегодня вполне замещает реляционные dwh, наши пользователи гоняют sql и не подозревают что там под низом давно уже не оракл, а hadoop. и что характерно, там много, много, много больше чем 60 гб
не интересно потому что нигде не работает, кроме глупых маркетинговых материалов. db2 z/os хранит блокировки в CF, все узлы долбят в этот единственный CF по sysplex. это не может работать и нигде не работает. зачем тратить время на рассказы, если ни в одном облаке такой смешной архитектуры с единой точкой долбления не встретишь?
в эпоху облаков полно субд способных масштабироваться на тысячи узлов, но ничего, даже отдалено похожего на архитектуры мф в облаках не встречается. потому и никому не интеремно, раз ушло на покой и было заменено даже на уровне идеи.
ну это очевидно, что бы продавать ненужную никому платформу в нагрузку с полноценными x86.
когда z идет вместе с x86 есть шанс замедлить миграцию с устаревшей платформы на x86. впарить одинокий z уже не реально, слишком убогий там софт, полноценных баз данных нет от слова совсем. db2 z/os проигрывает даже своему luw собрату, который совершенно неконкуретноспособен в эпоху облаков. баз данных уровня oracle, casandra или hadoop нет на z платформе.