Кривовато решили, но в целом работает. Самопальный шедуллер с шаред и эксклюзив блокировками на уровне целого DAG, пишем в дельту, а потом еще копия в parquets для пользователей impala. в импале делаем alter table set location на новую папку, у пользователей выглядит буд-то вся база страны примерно в единый момент поменялась. плюс эти паркеты в BI на Vertica грузят. вот они грузят как раз ночью.
страны европейские, т.е. часовой пояс примерно одинаковый, фишка именно в скоринге. это получается часть бизнес логики локальных систем, локальные системы принимают решения по этому скорингу, и бывает что им важно выслать письмо до 12:00 или выбрать кому первому звонить. врятли это уж прямо совсем критично, но без скорнинга могут встать некоторые процессы, а данные для решения нужны и из соседних стран.
да можно и здесь. а почему в ночное окно ? почему идемпотентны ? грамотная оркестрация ? очевидно же от того что у надстроек над файликами нет acid и если грузить в разгар дня, пользователи неконсистентную кашу увидят. вот потому вы делаете serializable вручную.
у нас потребности есть, но хадуп старый, я уже старый и давно понял, что выгодней халтурить на сторону, чем че-то новомодное проталкивать и потом все это тащить лидером. так вот, у нас десятки стран, сотни мутных систем и все они в своем ритме сбрасывают данные в хадуп, кроме всего прочего поверх этих данных считаются скоринги. вот тут и потребности в скорости и смывается грань с операционной системой, т.к. кусок логики скоринг забрал. а они у себя в отдельной стране нормальный скоринг не сделают, нужны данные хотя бы соседних стран. выходит или страны вытягивают друг у друга данные и делают микро dwh или идут в централизованную платформу
и типа никогда не приходилось приседать, что бы эмулировать этот acid ? пользователи всегда были согласны видеть транзакции, до того как клиент загружен ? наперника, как и все, использовали приемчики с закатом солнца в ручную.
да ладно, там 1-2 человека ковыряет по выходным. SuperServer же до сих пор костыль, где на каждое ядро процесс со своим независимым кешем, верно ? и до сих пор оно без настоящего лога транзакций, каждая транзакция обязана записать все блоки до фиксации коммита.
в чем смысл насиловать труп интербейз ? даже mysql/mariadb уже в иной эпохе был 10 лет назад. mariadb эмбедет вариант в связке с java работает очень давно, давно можно было бы переползти и забыть о вакуме и приколах многопоточности IB.
частности, Databricks, которая создала Delta Lake ... Delta Lake от Linux Foundation
текст ии генерировал.
расскажу страшную тайну, ни одна надстройка над файликами ACID не поддерживает. маркетолаги врут. delta, iceberg дают атомарность в пределах одной таблички, и честно пишут это даже в доках.
печально видеть как маркетинговый шит кушают и внедряют, не вникая даже в базис.
не стоит байки старичка воспринимать в серьез, на privet.com он умудрился CPU спутать даже не с ядрами, а с vCPU. то что он принял за сервера, почти наверняка просто докеры на мелкой машинке.
я бы не сказал. в техническом плане оракл с его UNDO log заметно красивей. mssql пишет версии строк от версионности в tempdb, который и так узкое место. ну и кластер RAC/Exadata. в техническом плане оракл пока красивей, но цена делает их обоих мало кому интересными вне облаков.
Кривовато решили, но в целом работает. Самопальный шедуллер с шаред и эксклюзив блокировками на уровне целого DAG, пишем в дельту, а потом еще копия в parquets для пользователей impala. в импале делаем alter table set location на новую папку, у пользователей выглядит буд-то вся база страны примерно в единый момент поменялась. плюс эти паркеты в BI на Vertica грузят. вот они грузят как раз ночью.
Сам же видишь определение в твоем источнике "a set of actions that transform the database"
требование на уровне всей базы, а в базе не одна табличка.
страны европейские, т.е. часовой пояс примерно одинаковый, фишка именно в скоринге. это получается часть бизнес логики локальных систем, локальные системы принимают решения по этому скорингу, и бывает что им важно выслать письмо до 12:00 или выбрать кому первому звонить. врятли это уж прямо совсем критично, но без скорнинга могут встать некоторые процессы, а данные для решения нужны и из соседних стран.
да можно и здесь.
а почему в ночное окно ? почему идемпотентны ? грамотная оркестрация ? очевидно же от того что у надстроек над файликами нет acid и если грузить в разгар дня, пользователи неконсистентную кашу увидят. вот потому вы делаете serializable вручную.
у нас потребности есть, но хадуп старый, я уже старый и давно понял, что выгодней халтурить на сторону, чем че-то новомодное проталкивать и потом все это тащить лидером. так вот, у нас десятки стран, сотни мутных систем и все они в своем ритме сбрасывают данные в хадуп, кроме всего прочего поверх этих данных считаются скоринги. вот тут и потребности в скорости и смывается грань с операционной системой, т.к. кусок логики скоринг забрал. а они у себя в отдельной стране нормальный скоринг не сделают, нужны данные хотя бы соседних стран. выходит или страны вытягивают друг у друга данные и делают микро dwh или идут в централизованную платформу
и типа никогда не приходилось приседать, что бы эмулировать этот acid ? пользователи всегда были согласны видеть транзакции, до того как клиент загружен ?
наперника, как и все, использовали приемчики с закатом солнца в ручную.
попахивает распилом, процессоров нет. на кой было тратить время ?
почитай Бернштейна, там и про acid есть.
https://wwwbayer.in.tum.de/lehre/WS2001/HSEM-bayer/philip-bernstein.pdf
про спарк ты фигню спорол - у delta lake атомарность достигается модификацией одного, единственного json, сколько там акшенов - пофиг.
p.s. и я в курсе что "Delta Lake от Linux Foundation" галлюцинация ии, потому и написал.
да ладно, там 1-2 человека ковыряет по выходным. SuperServer же до сих пор костыль, где на каждое ядро процесс со своим независимым кешем, верно ? и до сих пор оно без настоящего лога транзакций, каждая транзакция обязана записать все блоки до фиксации коммита.
в чем смысл насиловать труп интербейз ? даже mysql/mariadb уже в иной эпохе был 10 лет назад. mariadb эмбедет вариант в связке с java работает очень давно, давно можно было бы переползти и забыть о вакуме и приколах многопоточности IB.
судя по воде и
частности, Databricks, которая создала Delta Lake
...
Delta Lake от Linux Foundation
текст ии генерировал.
расскажу страшную тайну, ни одна надстройка над файликами ACID не поддерживает. маркетолаги врут. delta, iceberg дают атомарность в пределах одной таблички, и честно пишут это даже в доках.
печально видеть как маркетинговый шит кушают и внедряют, не вникая даже в базис.
это не серьезно, mysql на таких объемах всех уделает. это же бигдата движки с упором на кластер. наверника на кластере расклад будет другим.
а этот PAX тоже только с appendony=true ? не совсем понятно как полноценный DWH с таким ограничением предлагается строить
не стоит байки старичка воспринимать в серьез, на privet.com он умудрился CPU спутать даже не с ядрами, а с vCPU. то что он принял за сервера, почти наверняка просто докеры на мелкой машинке.
не должно быть, по идеи у старых жав jit переделывали под е2к, врятли 20ю жава прооптимизировали. странно, что разрыв небольшой
интересно, java не отстает в разы. у мцст какой-то прорыв в оптимизации жава случился ?
ссылка на тг кривая
сколько стоит лицензия на западе, хотя бы примерно (2 мастера 4 сегментов) ?
есть. гугли 1BRC challenge
Там не только транслятор, там оптимизатор. Самая увесистая штка в субд
я бы не сказал. в техническом плане оракл с его UNDO log заметно красивей. mssql пишет версии строк от версионности в tempdb, который и так узкое место. ну и кластер RAC/Exadata. в техническом плане оракл пока красивей, но цена делает их обоих мало кому интересными вне облаков.