нет, я про первый кейс с дефолтным значением колонки. с тригерами тоже не понятно. а блокировки кто будет выставлять? копировальщик зачитает на момент t1, запишет в момент t3. между ними гарантирован лост апдейт. постгрес то не блокировочник. в яндексе об этом в курсе?
что-то не понял идеи костыля с новой колонкой. допустим три дня вы транзакциями по паре тысяч строк копируете из старой колонки в новую, а дальше то что? если не блокировать, в старой колонке за три дня данные уже совершенно иные.
как работать наверняка не знаю, знаю как не надо. вот например каша — пример как не надо, причем то что иерархические субд проиграли было известно еще в 80х.
если так хочется конкретики, ну есть она у меня. конкретно сейчас работаю со spark на датафреймах. как и каша можно использовать обычный sql, есть обычный жава/скала синтаксис. в отличие от каши там полноценный оптимизатор и относительно декларативная работа с датафреймами. т.е. фреймворк и его оптимизатор решает как и в какой последовательности полезть к данным. там все кластерные прибабахи сразу из коробки. причем датафреймы не лезут за данными сразу, т.е. если в каше код выполняется как написано, датафреймы в спарке не тянут данные пока клиент не потребовал нечто, что требует результат. т.е. я могу задефайнить датафрейм, отправить в «процессор», который задефайнит фильтры, агрегаты, потом отправить в другой «процессор», который с чем-то заджоинит, но за данными оно полезет только когда я попрошу первые строки. и оптимизатор будет оптимизировать итоговый датафрейм, со всеми фильтрами, джоинами и прочей логикой разбросанной по разным классам. при этом это все в jvm — запросто прилаживается любые жава либы, начиная с ML. при этом это фреймвок, ему относительно пофигу как данные хранятся. оно работает и на файликах хадуп и на монге, игнайт, kudu.
вообщем совершенно иной уровень, чем каша. и этот уровень все равно не дотягивает до того что у меня было в оракле. побеждает лишь ценой.
боюсь особый случай это вы. по факту все эти ERP из 80х вполне сегодня справляются абсолютно с любыми отраслями, от финансов и телекома, до медицины. и ведь получается все эти годы добавлять атрибут объекту пользуя все те же структуры таблиц, что и в 80х.
да, бывают разные приложения. бывают люди не имеющие базовых знаний лабают код, но это не оправдание так делать. не надо в рсубд на каждый чих колонку добавлять, даже если глупые люди где то так делают.
структуры таблиц крупнейших ERP наверно с 80х не менялись.
В системах NoSQL я могу к одному конкретному объекту добавить атрибут, не затронув остальные, и это очень круто, а в РСУБД нужно добавлять колонку в таблицу.
вам нужно на курсы какие-то сходить, начальные. не надо так делать, за такое и побить могут
cache вобрал все недостатки объектных и реляционных субд, потому проиграл еще в 90х. врядли в наше время можно найти проект на cache не из 90х.
суть современных реляционных субд — оптимизатор. т.е. сегодня план один, завтра таблички подросли и оптимизатор перестроит план. у cache же код не декларативный, доступ к данным зашивается насмерть. никакого смысла возвращаться в 90е с такой технологией нет.
чушь. спектрум зачастую не мог загрузить данные даже с магнитофона. даже «скачек» электричества при включение люсты в комнате создавали непреодолимые помехи загрузки, какое радио?
с трудом вериться, что вы использовали mysql. ведь используемые по дефолту последние десятилетия innodb таблички такие же версионные как и в оракле. при чем у mysql UNDO лог имеется на оракловый манер, а блокировщиком mysql никогда в своей истории не был. были myisam таблички, так там и транзакций не было.
посмотрел картинку, там оракл бессменный лидер, постгрес играет во втором дивизионе. если тренд продолжится, лет через 15 посгрес сможет бросить вызов аутсайдеру высшего дивизиона…
с чего это вдруг написанный оракловыми сотрудниками вдруг не принадлежит ораклу? то что какую-то часть кода выкладывают под gpl ничего не меняет. код жава все равно собственность оракла. gpl лишь дает право на форк другим.
я смотрю с точки зрения корпоративного, мне кажется у корпорации разве что ресурсы uat/dev среды реально как-то не на 100% использовать. у нас на проде почти всегда 100%, лишь очередь заданий меняется во времени. ваши спецы на администрирование затраты мне кажется вы не сильно снизят, вокруг хадупа тучи систем от ldap и kerberos, до кафки, сборов логов и прочего dev хозяйства. по любому нужны админы.
имхо вы можете кардинально ускорить разработки, через это может можно выгоду получать. я вижу что мы многое могли бы попробовать, но попробовать негде. если бы мы могли создать тестовый кластер размером с прод на пару часов, убедиться, что идея сработает это заметно бы ускорило многие наши процессы.
посчитал халуп кластер на 600 vcpu, 10 тб хдд, примерно нашего размера. вышло 10к евро в месяц. дороговато, учитывая что от админов MCS все равно не освобождает, а арендовать чисто железячки раз в 5 дешевле выйдет. вот если бы еще спецы по хадупу к облаку прилагались…
а еще интересно, что у гугла dataproc еще в двое дороже. у меня $24k на 600 vcpu dataproc получилось.
те кто работают в ИТ не путают линукс с субд. если бы вы работали, то были бы в курсе, что восхождение МС на серверах происходило в середине 90х. уже в то время оракл на x86 воевал лишь с mssql, предлагая версии на netware и windows NT. ibm там и рядом не валялся, в первую очередь потому, что никогда не мог соревноваться по простоте с ораклом и майкрософт, которые изначально на 86 предлагали полноценные 4G язык в субд. у db2 sql/pl появился много позже и во многом это и не дало занять хоть какую-то значимую долю на платформе, где требовалась именно простота
напомню что SCO голодранцы и банкроты были, но и без денег лет пять никто из юристов не был уверен, что SCO совсем ничего не добьется. с баблом и юристами IBM те же иски явно можно было продавить.
если так хочется конкретики, ну есть она у меня. конкретно сейчас работаю со spark на датафреймах. как и каша можно использовать обычный sql, есть обычный жава/скала синтаксис. в отличие от каши там полноценный оптимизатор и относительно декларативная работа с датафреймами. т.е. фреймворк и его оптимизатор решает как и в какой последовательности полезть к данным. там все кластерные прибабахи сразу из коробки. причем датафреймы не лезут за данными сразу, т.е. если в каше код выполняется как написано, датафреймы в спарке не тянут данные пока клиент не потребовал нечто, что требует результат. т.е. я могу задефайнить датафрейм, отправить в «процессор», который задефайнит фильтры, агрегаты, потом отправить в другой «процессор», который с чем-то заджоинит, но за данными оно полезет только когда я попрошу первые строки. и оптимизатор будет оптимизировать итоговый датафрейм, со всеми фильтрами, джоинами и прочей логикой разбросанной по разным классам. при этом это все в jvm — запросто прилаживается любые жава либы, начиная с ML. при этом это фреймвок, ему относительно пофигу как данные хранятся. оно работает и на файликах хадуп и на монге, игнайт, kudu.
вообщем совершенно иной уровень, чем каша. и этот уровень все равно не дотягивает до того что у меня было в оракле. побеждает лишь ценой.
структуры таблиц крупнейших ERP наверно с 80х не менялись.
вам нужно на курсы какие-то сходить, начальные. не надо так делать, за такое и побить могут
суть современных реляционных субд — оптимизатор. т.е. сегодня план один, завтра таблички подросли и оптимизатор перестроит план. у cache же код не декларативный, доступ к данным зашивается насмерть. никакого смысла возвращаться в 90е с такой технологией нет.
что такое Crunсh?
я бы доверился лишь первой тройке…
имхо вы можете кардинально ускорить разработки, через это может можно выгоду получать. я вижу что мы многое могли бы попробовать, но попробовать негде. если бы мы могли создать тестовый кластер размером с прод на пару часов, убедиться, что идея сработает это заметно бы ускорило многие наши процессы.
а еще интересно, что у гугла dataproc еще в двое дороже. у меня $24k на 600 vcpu dataproc получилось.