что прилетело то и записали. интересно, что потом партнер с успешной экспертизой говорит, когда аудит у клиента в такой неконтролируемой помойке найдут персональные данные и натянет по полной за хранение?
блокировочный read committed ставит shared блокировку лишь на одну единственную запись из огромной выборки необходимой для чтения, соответственно параллельным транзакциям ничего не мешает апдейтить записи, что уже были считаны.
ознакомьтесь с основами.
Read committed, чтение фиксированных данных. Этот уровень изоляции используется по умолчанию в большинстве реляционных баз, в том числе и в PostgreSQL, и в Oracle. Он гарантирует, что вы никогда не прочитаете «грязные» данные. То есть другая транзакция никогда не видит промежуточных этапов первой транзакции. Преимущество в том, что это очень хорошо подходит для маленьких коротких запросов. Мы гарантируем, что у нас никогда не будет ситуации, когда мы видим какие-то части данных, недописанные данные. Например, увеличиваем зарплату целому отделу и не видим, когда только часть людей получили прибавку, а вторая часть сидит с неиндексированной зарплатой. Потому что если у нас будет такая ситуация, логично, что наша аналитика сразу «поедет».
в целом написана ерунда. read committed из стандарта ANSI не гарантирует консистентность данных на момент старта запроса. такие гарантии дают оракл и постгрес т.к. на самом деле у них более строгий read committed, чем требует стандарт. тот же mssql на read committed может прочесть одну и ту же запись несколько раз, если по мере чтения запись куда-то переезжала (например из одной партиции в другую). по той же причине может пропустить запись. и такая лажа, как минимум по мнению майкрософт, соответствует стандарту. sqlperformance.com/2014/04/t-sql-queries/the-read-committed-isolation-level
Не всегда получается задуманное, например пока ракеты с ножками смогли снизить стоимость запуска спутников в космос только в два раза, хотя Маск надеялся в десять.
стоимость пуска, если и снизилась то исключительно от того, что НАСА покрывает убытки от пусков частных спутников. каждый пуск транспортника уже в $280 млн обходится, в то время как древний и одноразовый прогресс те же 2.6 тонн к мкс доставляет за $60 млн.
прочитал, но так и не понял главного. куда спарк экзекьюторы писать будут? каждый на свою машину?
еще в тренде на k8s интересно чем конечный результат от спарка предполагается смотреть? что-то типа hive или impala ведь понадобится.
я такое видел, когда от многих тысяч баз данных hive metastore поплохело (GC + out of memory). но все легко решилось выделением ему побольше памяти.
в этом плане врядли, есть реальные проблемы. просто 30+ узлов уже на дефолтных настройках не поедут.
Эти ребята многое делают для развития спарка, я как-то априори склонен им скорее доверять.
делают, но паркет со схемой и эволюцей схемы появился до них и до их настройки над паркетом.
Ну, мне кажется что это скорее не бонус, а наоборот, фундамент. Все-таки, как вы себе представляете update, если транзакций нет?
да легко. как у них работает — у них при апдейте пары срок в фолдере паркетов ищутся паркетники, где нужно заменить строки. найденные файлы целиком копируются, с модификациями. после этого в папочке лога добавится json. вот появление этого json и означает фиксацию транзакции. мягко говоря не самая захватывающая фишка. DWH мир уже давненько не пишет терабайты в единой транзакции, а давно заливают в параллель и делают что-то типа exchange partition.
по моему и статья бредовая. схема — она у паркетов, что под низом у delta lake, а то что delta lake тоже имеет схему и schema evolution, так это скорее следствие того, что delta lake надстройка над паркетом.
а по транзакциям, транзакции тут вторичны. главная фишка delta lake то что он дает возможность делать update/delete/merge на файлки лежащие на hdfs. транзакции идут как бонус к невероятному к update на hdfs.
у дурова просто блокчейн, транзакции никто не контролирует. у цукенберга ноды контролирует консорциум. спецслужбы в теории смогут просить консорциум банить и откатывать транзакции.
тем что либра это консорциум жадных капиталистов. т.е. фсб или цру придется убедить консорциум банить транзакции. а там уже не только американцы, а те что американцы бабло зарабатывают далеко не только в сша.
у тебя там мелочь, которой «банк», если у него в тот день хорошее расположение духа, может позволит попользоваться. серьезную сумму за бугор российский «банк» не позволит перевести.
не понятно как такое может масштабироваться. имхо основная сложность больших энтерпрайзов не в размере, а то что данные идут с разных систем, разработанных или полученных вместе покупками конкурентов, которые одни и те же понятия по разному оформляют. если каждый источник сгружает данные так как ему удобно то потом каждый потребитель должен будет изобретать какие-то свои мапинги из источника в свои понятия, что бы получить что-то осмысленное. на большом кол-ве источников это быстро превратится в ад. опять же, у источника бизнес процессы меняются. источник добавил колонку is_deleted, теперь тучи потребителей должны переколбашивать свои etl. а что если они не готовы сейчас этим заняться?
то что data owner должен сам рисовать выгрузки я согласен, но без каких-то централизованных структур в крупной организации никак. data owner должен интегрировать свои данные во что-то централизованное, корректно замапив свои понятие на некие общие.
угу, а в рекламе втирали то что облака круты потом у что когда не надо ресурсы можно освобождать и не платить. а теперь вот оказывается, что облако круто, но есть нюанс :)
Тогда от PostgreSQL вы вообще бежите как черт от ладана?
да. убер хорошо расписал как все хреново там где нет полноценного undo. собственно enterprisedb — основной вкладчик в постгрес, признает преимущество undo и уже года 3 пилит undo для постгрес
1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу
вот это не прям сразу дает на порядок большую производительность. потому что одно дело пару блоков в лог записать и освободить транзакцию, другое дело держать транзакцию пока каждый блок по всему диску не разложишь. и дело не в том что это транзакция дольше висит, а то что она 100500 соседних транзакций на более длительный срок задерживает.
б) некоторые озвученные применения подразумевают немаленький rps, а огнептах при этом справляется. Странно да?
пару лет назад Таблойд с sql.ru гонял тесты с 256 параллельными тредами. ФБ просто вставал колом. он отрепортил с десяток чудовищных проблем и наглядно показал, что такие нагрузки никто на ФБ не практикует
Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?
плохо то что транзакция остается активной, когда конкуренты с логом уже следующую могут обрабатывать.
Impala быстро, но не надежно. чуть больше польpователей и привед out of memory. чуть крупней датасет и привед out of memory. зато да, заметно быстрее spark sql
ознакомьтесь с основами.
в целом написана ерунда. read committed из стандарта ANSI не гарантирует консистентность данных на момент старта запроса. такие гарантии дают оракл и постгрес т.к. на самом деле у них более строгий read committed, чем требует стандарт. тот же mssql на read committed может прочесть одну и ту же запись несколько раз, если по мере чтения запись куда-то переезжала (например из одной партиции в другую). по той же причине может пропустить запись. и такая лажа, как минимум по мнению майкрософт, соответствует стандарту.
sqlperformance.com/2014/04/t-sql-queries/the-read-committed-isolation-level
стоимость пуска, если и снизилась то исключительно от того, что НАСА покрывает убытки от пусков частных спутников. каждый пуск транспортника уже в $280 млн обходится, в то время как древний и одноразовый прогресс те же 2.6 тонн к мкс доставляет за $60 млн.
еще в тренде на k8s интересно чем конечный результат от спарка предполагается смотреть? что-то типа hive или impala ведь понадобится.
в этом плане врядли, есть реальные проблемы. просто 30+ узлов уже на дефолтных настройках не поедут.
делают, но паркет со схемой и эволюцей схемы появился до них и до их настройки над паркетом.
да легко. как у них работает — у них при апдейте пары срок в фолдере паркетов ищутся паркетники, где нужно заменить строки. найденные файлы целиком копируются, с модификациями. после этого в папочке лога добавится json. вот появление этого json и означает фиксацию транзакции. мягко говоря не самая захватывающая фишка. DWH мир уже давненько не пишет терабайты в единой транзакции, а давно заливают в параллель и делают что-то типа exchange partition.
а по транзакциям, транзакции тут вторичны. главная фишка delta lake то что он дает возможность делать update/delete/merge на файлки лежащие на hdfs. транзакции идут как бонус к невероятному к update на hdfs.
то что data owner должен сам рисовать выгрузки я согласен, но без каких-то централизованных структур в крупной организации никак. data owner должен интегрировать свои данные во что-то централизованное, корректно замапив свои понятие на некие общие.
да. убер хорошо расписал как все хреново там где нет полноценного undo. собственно enterprisedb — основной вкладчик в постгрес, признает преимущество undo и уже года 3 пилит undo для постгрес
вот это не прям сразу дает на порядок большую производительность. потому что одно дело пару блоков в лог записать и освободить транзакцию, другое дело держать транзакцию пока каждый блок по всему диску не разложишь. и дело не в том что это транзакция дольше висит, а то что она 100500 соседних транзакций на более длительный срок задерживает.
пару лет назад Таблойд с sql.ru гонял тесты с 256 параллельными тредами. ФБ просто вставал колом. он отрепортил с десяток чудовищных проблем и наглядно показал, что такие нагрузки никто на ФБ не практикует
плохо то что транзакция остается активной, когда конкуренты с логом уже следующую могут обрабатывать.