зерно у сша массово начали закупать в 1963 именно за счет нефтедоходов. это как больной диабетом. может укол инсулина и не огромную долю в расходах больного занимает, но критическую. если обваливается доход в скв и больной не может купить инсулин, то все. занавес. у ссср была чудовищная зависимость по зерну, нефтегазовому оборудованию, электронике. без экспорта нефтегаза в ссср просто голод был бы.
зы. комуняки той трубы не строили, трубы для ссср делали в ФРГ, т.к. у передового ссср не было технологий даже трубы…
и кстати тоже трубы отгружали в счет будущих нефтегазовых доходов.
детальный расклад с тракторами руководству давало ЦСУ ссср, причем очень красиво — в сравнении с сша давало. весь абсурд экономики ссср хорошо был виден в цифрах ЦСУ без бигдаты.
рентная экономика как раз была в ссср, где экспорт нефтегаза обеспечивал критический импорт. как только цены на нефть обвалились начался голод и вся экономика ссср сложилась. нефтегазовое оборудование, точные станки, зерно обеспечивал нефтегаз. пропали нефтегазовые доходы в скв и ссср пошел на дно. современная РФ много меньше зависит. как минимум накормить население и без нефтегаза сможет. кончится нефть, продадут топливные сборки для аэс. там тоже абсолютные лидеры. плюс не последние по термоядерным исследованиям, добрую треть итеэр «ленивые» русские построили.
так что граждане окраины вам не повезло, РФ это надолго.
бигдата может помочь лишь с оптимизацией, но не с идеей. свободный предприниматель, не имея никаких данных, может рискнуть и построить электрокар с мотор-колесом, без всяких распредвалов, коробок передач и прочего. бигдата же может лишь помочь оптимизировать цепочки поставок, но не с идеями, что перевернут отрасль.
у ссср были те проблемы что никакие компьютеры не решили бы. не нужен был компьютер, что бы заподозрить что закупки зерна у классового врага за океаном не самое разумное планирование.
ерунда. ссср штамповал половину сельхоз техники на планете и чем больше ее штамповал, тем глубже увязал в импорт зерна. для того что бы увидеть, что выпуск хлама с болтами не дает больше сбора зерна никому не нужна была бигдата. это видно было по полкам магазинов и талонам. причем задолго до горби.
бигдата могла бы помочь ссср быстрее убить экономику просчитав более эффективное превращение ценных ресурсов в бесполезный хлам с болтами.
Ну вот, хоть что-то полезное по ссылке вычитали. Вот только никакого отношения эта конвертация (которая и есть та самая эскалация) к описываемому случаю страничной блокировки не имеет.
не имеет и тебе доступно разжевал почему. уровни изоляции и эскалация абсолютно не пересекающиеся понятия. т.е. вот тут ты несешь дважды пургу
С каким-нибудь read committed, например, вы тут получите блокировку на странице данных
а вот тут трижды
Все-таки читать про блокировки. Подсказка для поиска: страничная блокировка при вставке в кучу без блокировки ключей.
в mysql нет страничных блокировок, при вставке ставится next-key lock только если есть ключи. но в моем примере нет ключей.
прежде чем нести пургу, хотя ознакомься хотя бы какие типы блокировок сущетсвуют в mysql.
матчасть я выучил 20 лет назад, 15 лет как сертифицированный ocp. так что дальнейшее разжевывание лишь за деньги. конвертация row level блокировки в page lock приводит блокировке посторонних строк, не имеющих отношения к транзакции. эскалация никакого отношения к уровням изолированности не имеет.
С каким-нибудь read committed, например, вы тут получите блокировку на странице данных
RC требует блокировать лишь необходимые транзакции строки. получить блокировку целой страницы можно исключительно в результате эскалации, которая к уровням изолированности транзакций параллельна.
ты путаешь эскалацию блокировок с уровнями изолированности. эскалация блокировок никакого отношения не имеет ни к уровням изолированности, ни к mysql. mysql утверждает что у него row level блокировки. но врут.
RC с row level блокировками не должен накладывать какие либо блокировки на данные, не имеющие никакого отношения к этой транзакции. то что на странице посторонние данные, не нужные транзакции не повод их блокировать.
чего не ясного? уровни изоляции описывают допустимые коллизии транзакций, обращающиеся к одним и тем же наборам данных. ключевое — одни и те же наборы, я же показываю что у mysql все на столько плохо, что коллизии возникают даже у транзакций, что обрабатывают разный набор данных. уровни изоляции тут не причем.
что бы получить опыт и осознать почему технологии бигдаты неизбежны с какого-то объема. если речь о хранилище то ты просто не зальешь за вменяемый промежуток времени данные с врубленными FK и индексами. а всякие скоринги и фрауд детекшены уже не нужны спустя несколько часов. потому сначала отключают FK и индексы при заливке, а потом переезжают на хадупы где индексов и FK нет в принципе, а валидация связей — часть ETL процесса интеграции данных в хранилище. если вырубать FK и вовсе не отслеживать зависимости то да, болото данных гарантированно.
но это про хранилища, тут же у меня скорее речь про oltp, где у mysql умудряются сталкивается транзакции, между которыми ничего общего.
давай. попробуй расстроить. я поржу.
в любой версионной субд есть row level блокирование и подобные ситуации, где сталкиваются транзакции не имеющие ничего общего не возможны. уровни изолированности транзакций и блокировки разводят транзакции затрагивающие общие данные, а в примере у каждой транзакции своя запись, не имеющая никакого отношения к другим транзакциям.
что бы воочию увидеть как mysql пытается поставить локи на незакомиченные записи соседней транзакции.
что касается индексов, то во первых в оракле мне не приходит в голову индексировать абсолютно каждое поле. во вторых повторюсь — дело в фуллскане, а не индексах. индекс лишь снижает вероятность, но не отменяют фулскан. например у меня лезли дедлоки на таблице с индексом, но записей было мало и mysql применял фуллскан не смотря на индекс. по идеи в запросах где вычитывается более половины записей таблицы тоже фулскан должен быть.
не выйдет в один проход ничего. это азы. что бы отправлять «сообщения», например о платежах на редюсер, тебе надо знать которые компании висят на одном адресе. т.е. у тебя будет 2 прохода, первый посчитает ключ, так что бы у сообщений компаний на одинаковом адресе он совпал и только вторым проходом уже группировать.
не увидел ничего там интересного. говорю, мы примерно такое налабали лет 5 назад. «сообщения» это были avro объекты в parquet файликах. теперь самоотверженно выпиливаем. не работает.
представь что тебе пришло требование теперь группировать по компаниям, зарегистрированным на одном адресе. все, с твоей структурой в один проход теперь ты нихера не посчитаешь.
+GDPR
просто надо опыт хоть немного иметь. и не на ноутбуке. может с лайками фейсбука это работает, но в серьезных бизнес задачах ентерпрайза такое работает хреново. во первых вся эта дребедень зависит от того что ты выберешь ключом. выбрал ты какой-нить номер клиента, все здорово. целый месяц. но на второй тебе говорят, слушай. у нас тут полно клиентов на одном адресе… ты еще не переписал все заново, а уже прилетает следующее маааленький вопрос от юристов: а что значит «Событие, однажды случившись, больше не изменяется»? вы может слышали, но GDPR требует как минимум анонимизировать всю историю…
по сути идея предлагает сделать недоделанный мап-редюс. в мап-редюсе хотя бы в параллель все читается.
подход уже успел взлететь и угаснуть. на практике отчет пойдет читать сообщения о транзакцияй их «внезапно» миллиард, в память не влезает и привед.
сейчас модно в кафку такие вот сообщения писать и от туда уже чем-то типа спарк вычитывать, находу в памяти агрегируя.
нет у них ничего. есть поделки на базе арм, в которых китайского кроме лейбла нет ничего. у России прямой аналог процессор Байкал. т.е. без белых людей из-за океана они ничего со своими армами сделать не смогут. у них нет ни спецов ни компетенция на что-то кроме адаптации разработок арм.
зы. комуняки той трубы не строили, трубы для ссср делали в ФРГ, т.к. у передового ссср не было технологий даже трубы…
и кстати тоже трубы отгружали в счет будущих нефтегазовых доходов.
так что граждане окраины вам не повезло, РФ это надолго.
у ссср были те проблемы что никакие компьютеры не решили бы. не нужен был компьютер, что бы заподозрить что закупки зерна у классового врага за океаном не самое разумное планирование.
бигдата могла бы помочь ссср быстрее убить экономику просчитав более эффективное превращение ценных ресурсов в бесполезный хлам с болтами.
не имеет и тебе доступно разжевал почему. уровни изоляции и эскалация абсолютно не пересекающиеся понятия. т.е. вот тут ты несешь дважды пургу
а вот тут трижды
в mysql нет страничных блокировок, при вставке ставится next-key lock только если есть ключи. но в моем примере нет ключей.
прежде чем нести пургу, хотя ознакомься хотя бы какие типы блокировок сущетсвуют в mysql.
RC требует блокировать лишь необходимые транзакции строки. получить блокировку целой страницы можно исключительно в результате эскалации, которая к уровням изолированности транзакций параллельна.
вы придется заслужить «пониманием базовой матчасти» (тм)
RC с row level блокировками не должен накладывать какие либо блокировки на данные, не имеющие никакого отношения к этой транзакции. то что на странице посторонние данные, не нужные транзакции не повод их блокировать.
но это про хранилища, тут же у меня скорее речь про oltp, где у mysql умудряются сталкивается транзакции, между которыми ничего общего.
в любой версионной субд есть row level блокирование и подобные ситуации, где сталкиваются транзакции не имеющие ничего общего не возможны. уровни изолированности транзакций и блокировки разводят транзакции затрагивающие общие данные, а в примере у каждой транзакции своя запись, не имеющая никакого отношения к другим транзакциям.
что касается индексов, то во первых в оракле мне не приходит в голову индексировать абсолютно каждое поле. во вторых повторюсь — дело в фуллскане, а не индексах. индекс лишь снижает вероятность, но не отменяют фулскан. например у меня лезли дедлоки на таблице с индексом, но записей было мало и mysql применял фуллскан не смотря на индекс. по идеи в запросах где вычитывается более половины записей таблицы тоже фулскан должен быть.
dba.stackexchange.com/questions/238756/mysql-innodb-trying-to-lock-uncommitted-row-from-parallel-transaction-deadlock
при фулскане оно пытается наложить локи на все, даже на не незакомиченные записи.
представь что тебе пришло требование теперь группировать по компаниям, зарегистрированным на одном адресе. все, с твоей структурой в один проход теперь ты нихера не посчитаешь.
+GDPR
подход уже успел взлететь и угаснуть. на практике отчет пойдет читать сообщения о транзакцияй их «внезапно» миллиард, в память не влезает и привед.
сейчас модно в кафку такие вот сообщения писать и от туда уже чем-то типа спарк вычитывать, находу в памяти агрегируя.