Comments 72
Вы ошибаетесь как насчет того, что мне зачем-то нужно куда-то прятаться, так и (особенно) насчет «видеть». Это просто показать на пальцах.
Мне известны все более-менее стандартные подходы. Я имел дело с масштабными проектами на плюсах, джаве, и руби (и чуть менее масштабными на скале, похапе, даже перле и хаскеле). С майсиквелом, постгресом и ораклом (и у меня даже где-то валяется сертификат оракла, потому что так было нужно тогдашнему работодателю). Я упирался в ограничения всех трёх СУБД, своими глазами видел, что происходит, когда клиентский код стартует транзакцию в базу, и тут отваливается сеть (причем в джаве получится не то, что в руби, а в постгресе — не то, что в майсиквеле).
Я лично решал задачу «сага поверх СУБД транзакции», потому что одной СУБД транзакции недостаточно. Мой код работает в разном финтехе (в том числе в банках). Когда мы внедряли первый ивентлог вместо СУБД — было много скептиков, но время нас рассудило.
И на основе всего вот этого багажа — я пришел к некоторым выводам. И поделился ими в тексте выше. Так что я хорошо всё вижу, а вот люди, которые ультимативно заявляют, что я вижу плохо — вызывают улыбку. Это же чистое «Пастернака не читал, но осуждаю».
Такие дела.
"Угадай автора по первому предложению."
только чтобы не следить самим за консистентностью данных
Напишите свою СУБД, концепции которые они должны поддерживать все описаны в интернете, спецификация SQL тоже открытая.
А так, конечно, бредовая статья, мне кажется кто-то должен это написать) (EventLog приравниваете к EventSource) Вы хоть гуглом пользуетесь прежде чем статьи публиковать?)
Пропитана ненавистью и противопоставлением себя "en masse". На это хочется сказать - любая контр культура, это часть культуры которой она себя противопоставляет ;)
В неидеальном (приложение упало в процессе совершения перевода денег со счета на счет) — придется развернуть записи из ивентлога для воссоздания состояния объекта «незаконченный платёж» в памяти перезапущенного приложения.
Так что, каждый раз, когда вы начинаете мыслить вместо категорияй данных — понятийным аппаратом «базы» (транзакции, джойны, и так далее)
На этом моменте люди из финтеха как минмум недоумевают) Смотрите, в базе данных, транзакции - набор SQL инструкций, но что важнее результат этих инструкций отслеживается и при возникновении ошибки, вся транзакция откатывается. Вот, люди просто платежи через транзакции проводят, и если сеть упала, то считайте что транзакции и не было (ее вызова и самого перевода), получается и восстанавливать ничего не надо)
Я говорю: СУБД нужна далеко не всегда и далеко не для всего. Комментаторы: напишите свою СУБД.
Ну да, довольно странно, что я себя противопоставляю этим людям, но я хотя бы смысл текста в состоянии ухватить, прежде чем пердеть в лужу.
И да, весь текст выше написан на основе опыта именно в финтехе.
Я вашу цитату привел что конкретно вы говорите, бизнес доверяет проверенным решениям (существцющим СУБД), а вы в статье пишете что из-за лени люди не поддерживают консистентность сами) это абсурд.
И что, вы в финтехе свои потоки данных писали, со своей консистентностью и транзакциями?)
Вы даже паттерны между которыми ставите знак равно не смогли нагуглить. Ещё так болезненно к критике относитесь) Что не совпадает с вашим описанием профиля)
Посмотрите другие статьи автора, тут смысла убеждать нет никакого. Можно только гадать: намеренный рейджбейт или незамутненное чсв
Я болезненно отношусь не к критике, а к глупости. Ивентсорс — это просто воспроизведение ивентлога, их никто давно не разделяет, среди тех, кто плотно с ними работает.
Если бы вы спросили, как в финтехе работают с ивентлогом, с самого начала, а не начали рассказывать про всемогущие транзакции, я бы даже ответил бы.
Но поезд ушел.
Я болезненно отношусь не к критике, а к глупости
И не можете удержать её в себе, пытаясь открыть что-то кто никто не понимает (конечно кроме вас)
Я не пытаюсь ничего открыть, всё это открыли десятилетия тому назад.
Если вам лично не хватает умишка, это не значит, что его не хватает всем. Кто-то поймет.
Вы за своим самомнением все прячетесь, но та же стена что защищает вас, видимо не даёт вам видеть
Вы ошибаетесь как насчет того, что мне зачем-то нужно куда-то прятаться, так и (особенно) насчет «видеть». Это просто показать на пальцах.
Мне известны все более-менее стандартные подходы. Я имел дело с масштабными проектами на плюсах, джаве, и руби (и чуть менее масштабными на скале, похапе, даже перле и хаскеле). С майсиквелом, постгресом и ораклом (и у меня даже где-то валяется сертификат оракла, потому что так было нужно тогдашнему работодателю). Я упирался в ограничения всех трёх СУБД, своими глазами видел, что происходит, когда клиентский код стартует транзакцию в базу, и тут отваливается сеть (причем в джаве получится не то, что в руби, а в постгресе — не то, что в майсиквеле).
Я лично решал задачу «сага поверх СУБД транзакции», потому что одной СУБД транзакции недостаточно. Мой код работает в разном финтехе (в том числе в банках). Когда мы внедряли первый ивентлог вместо СУБД — было много скептиков, но время нас рассудило.
И на основе всего вот этого багажа — я пришел к некоторым выводам. И поделился ими в тексте выше. Так что я хорошо всё вижу, а вот люди, которые ультимативно заявляют, что я вижу плохо — вызывают улыбку. Это же чистое «Пастернака не читал, но осуждаю».
Такие дела.
Вы ошибаетесь как насчет того, что мне зачем-то нужно куда-то прятаться
Ваша грубость и есть попытка спрятаться.
Дак если вы все это видели и знаете, покажите технически что вы правили в транзакциях и победили евентлогом (в это я очень слабо верю). А то у вас в статье все на словах, сейчас вы мне свой опыт пересказываете (зачем? Покажите мне недостаток подхода и его решение, причём если вы уже занимались этим) но в статье у вас откровенный сумбур, никаких технических подробностей и примеров, так же как и с вашим опытом - просто надо верить на слова и все)
Ваша грубость и есть попытка спрятаться.
Охренеть, конечно, диагнозы по аватарке начались.
покажите технически что вы правили в транзакциях и победили евентлогом (в это я очень слабо верю)
За пивком не сбегать? Я пишу то, что мне кажется полезным и интересным.
Покажите мне […]
Я уже очень давно не ставлю перед собой цель кого-то в чем-то убедить. Подавно мне не интересно убеждать лично вас. Меня после этой публикации стали читать на постоянной основе еще человек 8–10, вот для них этот текст и был написан.
недостаток подхода и его решение
Я показал, просто вы не увидели.
в статье у вас откровенный сумбур
Да-да, по русскому у меня тоже двойка.
просто надо верить на слова и все
Ну, у меня в принципе есть гитхаб. А в тексте есть ссылка на одно из тех самых технологических решений.
Если честно, мне кажется если вы хоть в 1 банк придёте и начнёте говорить что надо убирать транзакции и реляционные базы и заменять их на евентлоги и всякое самописное, самое лучшее что случится это у виска люди покрутят, но может и чего хуже ;)
Я никогда не предлагаю всё сломать, чтобы построить что-то новое. Поэтому «надо убирать […] и заменять на […]» — это не ко мне.
Что касается новых решений — ну не верите, что руководство двух европейских банков удалось переубедить — не верьте, мне-то что.
ну не верите, что руководство двух европейских банков удалось переубедить — не верьте, мне-то что.
Ну это опять просто слова ваши. Вы на техническом ресурсе не используете никакой технической доказательной базы ваших слов (например что евент лог лучше транзакций, где отражение этого лучше в техническом эквеваленте?) и делаете такие громкие заявления)
Да вы тоже ведь вроде бы не используете никакой доказательной базы для подкрепления обратного (кроме миллионов мух).
Потому что это не технический ресурс, а развлекательный, наверное.
Вы же на себя взвалили роль просвящения масс, которые вы так призираете судя из статьи, вот и неплохо было-бы подкрепить беспрестрастными технологиями свои посылы.
Ну и к вашему примеру - если муха противопоставляет себя другим мухам, она все еще ей остается.
Окститесь.
Я пишу развлекательные текстики для приятных лично мне людей, которые меня попросили их написать.
А если орёл противопоставляет себя другим мухам?
Ну вы хоть что-то от орла покажите, пока только ваши выпадки в ответ на критику вижу (поведене орла чтоли?)) да и технически ценного вы ничего не принесли сюда, только бесконечные разговоры не о чем, приходите и с умным видом пытаетесь доказать что вы умнее кого-то, но просто на словах так не получится)
технически ценного вы ничего не принесли сюда
А вот это не вам судить.
пытаетесь доказать
В сотый раз повторяю: я никому ничего не пытаюсь доказать, ваши диагнозы по юзерпику ошибочны.
Я доказываю свои решения не на форумах пустобрёхов, а в коллективе профессионалов.
Я прочитал вашу статью и что я технического должен подчерпнуть отсюда?
Что массы на столько глупы что идут на поводу, а вы не идете на поводу, у вас на все свое видение, а если видение свое то оно крутое (вот ваше самолюбие). И в статье вы, например, не приводите банкинг заграничный как пример успешного не использования транзакций (это видимо слишком мелкий аргумент что-бы упоминать об этом) все это вытягивается из вас в комментариях)
Да, пожалуй лучше с вашими профессионалами такое вам и обсуждать (им тоже технические подтверждения не нужны?), мне кажется сообществу не сильно нужна ваша борьба против общества. Она ваша, сил вам на этом пути конечно, интересно даже куда она вас заведёт)
В сотый раз повторяю: я никому ничего не пытаюсь доказать, ваши диагнозы по юзерпику ошибочны.
Вы всю статью льете желчь на общество, я "диагноз" ставлю по тому что вы пишете. Ощущение что у вас как в вашей любимой стейт машине - состояния туда сюда переключаются и одно про другое не помнит)
Стиль статьи для чтения тяжеловат, я сразу и не понял о чем речь)
Но с тезисами - что БД (особенно реляционная) необходима далеко не всегда, и надо сознательно выбирать места где её применять - полностью согласен.
Тоже встречал ситуацию когда для иерархии файлов со временем создания и изменения - хотели завести дополнительно бд, со сложными связями, тогда как в реализации я просто предложил взять всю информацию из файловой системы и заниматься дублированием источника правды.
Дядя Федя, ивент лог - основа реляционной базы данных, только называется он лог транзакций. А данные - текущий стейт этого лога. А сиквел - удобный и быстрый способ работы с этим стейтом.
Хочется вам придумывать свои велосипеды - придумывайте, ваше право.
Вот спасибо, век такой щедрости не забуду.
Непонятно, правда, о каких велосипедах речь, но я и не ждал, что текст поймут все.
Вот. Я тоже про велосипеды подумал.
И еще прикол, редис автору не нравится, ведь его нужно обхаживать и мониторить, а велосипед, он настолько суров, что в мониторинге не нуждается.
Не финтехом единым. ERP или её подобие есть на любом предприятии. Это core system.
Просто вспомните о том, что когда бизнес меняет приложения, то данные мигрируют в новую систему. Потому что данные - основной актив.
Библиотека (фреймворк) всё пишет в кликхаус, и экспортирует все ивенты, если кому-то надо сохранить что-то в СУБД
а когда кликхаус перестал быть СУБД?
«Миллионы мух не могут ошибаться» — так себе аргумент.
Аргумент "я- Д'артаньян" кажется ещё "так себее"
Прочитав текст и срач в комментариях, увидел подтверждение слов про то, что если десять человек прочитает один и тот же текст, каждый поймет по своему. Автору конечно бы принять это во внимание и если он хочет нести свет в массы. Vox populi — не всегда vox idioti.
По моему мнение главный посыл — не быть карголютистами)
Традиционный финтех это не про создание нового, а про перераспределение старого.
Имхо, свч автора не оправдано, так как он не создал ничего принципиально нового.
Для соответствия такому уровню чсв нужно быть создателем проекта уровня "изобретение денег" или выше.
Вы, автор, сделали какой-то большой проект, базирующийся на каких-то принципиально новых идеях? Нет, не сделали.
Впрочем, довольно забавно наблюдать, как автор болезненно реагирует на замечания о его огромном чсв.
Поэтому, конечно, пишите ещё!
он не создал ничего принципиально нового
Вы ясновидящий?
.... Это не забота разработчика, разруливать дедлоки
Как раз то дедлоки разруливаются именно и только на стадии разработки приложения. Иного способа не существует в природе. Поэтому механизм разрешения проблемы дедлока в любой СУБД это убивание одного из участников дедлока в пользу другого. Их всегда два.
Одним из способов антидедлоковой разработки может быть распознование попадания в виктимы (victim) дедлока и повторения транзакции. Есть и более элегантный способ.
Иного способа не существует в природе.
Инфа сотка? А я ведь триста раз и в тексте, и в комментариях, рассказал и показал этот другой способ. В реляционной СУБД он нереализуем из-за shared resource. Но в прикладном коде он прекрасно реализуем. И в Event Source хранилищах. И еще в миллионе иных мест.
Но обязательно придёт эксперт, рассказать, что автомобиль в принципе не умеет развивать скорость выше 100 км/ч потому что его запорожец не может.
Я имел в виду именно и только СУБД. И именно в СУБД дедлоков можно избежать полностью. Или на худой конец нивелировать их влияние распознованием и повтором неудачной работы.
Event Source не решает проблемы дедлоков в СУБД. Кроме того, как уже было сказано выше другими, в любой СУБД есть журнал транзакций по сути дела тот самым Event Source и даже больше потому что содержит информацию об UNDO неуспешных транзакций.
Для дедлока требуется минимум два ресурса.
Берем единый ивентлог и пишем все туда.
Дедлоков нет, шах и мат, кожаный мешок!
И максимум тоже два ресурса. Еще надо две транзакции in fly.
Ивентлог перпендикулярен проблеме дедлоков в СУБД. Или Вы все будете писать в ивентлог? Тогда причем здесь дедлоки? Причем здесь СУБД? Все мимо.
статью не читай, сразу отвечай (с)
именно об этом в ней и речь
А в чем проблема писать все в Event Source? Я даже недавно опубликовал текст о моём фреймворке, который пишет всё в ивентсорс и на некоторых задачах кроет реляционную базу как бык овцу.
Что значит "писать все"? Если писать все не в реляционную базу то причем здесь она, овца?
Если есть данные приложения, которые можно не хранить в реляционной базе без потери смысла и нарушения транзакционного механизма, то конечно их не надо писать в РБД. Что в этом удивительного?
Транзакционный механизм не нужен практически никогда.
Это костыль, который больше мешает, чем помогает.
"Практически никогда" звучит как иногда все таки нужен.
Кроме того думается что Ваше утверждение означает лукавую думку мол мы реализуем этот механизм в наших програмках без СУБД. Флажки введем разные и будем их проверять каждый раз. Да это возможно, слышу об этом много лет. Даже знаю примеры где такие флажки очень эффективно десятки лет используются.
Но это не означает что транзакций нет и они не нужны. Это означает что Вы отказываетесь от транзакционного механизма в СУБД и создаете свой. С другой стороны можно так программировать в СУБД что транзакции будут седены на нет. Пишите COMMIT после каждого SQL стэйтмента во всех программах и все, нет транзакций, нет дедлоков. Победа. Ура!
Какие еще нахрен флажки?
Я работаю в акторной модели, ивентлог тут триста раз упоминали, когда база нужна написано в тексте: хранить редкоизменяемые данные.
Вы просто в силу узости кругозора не понимаете, о чем тут идет речь. Так бывает.
А вот это уже наезд и клевета. Вы меня не знаете и про мой кругозор судить не можете.
За 40+ лет работы в ИТ на разных платформах я имел дело с многими разными БД и все они хранили далеко не только редкоизменяемые данные.
Мало ли что Вы можете написать в тексте, но Вы явно заблуждаетесь или не умеете работать с БД (есть такая присказка, начинающаяся со слов "плохому танцору...").
Я соглашусь только с тем (и это тоже написано в моих текстах здесь) что все пихать в БД не есть грамотно. И как я понимаю из Ваших текстов Вы против этого, на что есть другая присказка, начинающаяся и заканчивающаяся словами "Вместе с водой выплеснуть и ребенка". Вот вы примерно этим и занимаетесь, отвергая БД вообще. Флаг Вам в руки.
Наезд и клевета называются диффамацией.
Я могу судить о кругозоре по комментариям. Вы продолжаете спорить о базе и транзакциях, хотя они прозрачно элиминируются акторной моделью, о чем я и писал.
Костылями повышать нагрузоустойчивость базы — плохой сценарий, но люди продолжают так делать, потому что про другие подходы ничего не знают.
Опыт перпендикулярен кругозору.
Разные бизнес приложения требуют разных хранилищ данных с разными свойствами и функциональностью. БД (не только реляционные) с механизмами транзакций и сериализацией абсолютно показаны для банковских систем, продаже билетов на что угодно, в складском хозяйстве и т.д. и т.п.. Везде где бизнес действие состоит из нескольких шагов и только успешное завершение всех этих шагов может считаться успешным завершением всего бизнес действия.движения.
Ваш Event Source применим, например, для записи и хранения ходов в игре в шахматы. В этом случае бизнес действие состоит ровно из одного шага. Ставьте COMMIT после каждого SQL стейтмента и получите EventSource в БД.
Кстати Вы не от сюда случайно черпаете свои идеи:
https://www.ibm.com/docs/en/business-monitor/8.5.6?topic=overview-event-sources
Берем единый ивентлог и пишем все туда.
И получаем минус на балансе аккаунта после проигрывания ивентлога. Локи при переводе с аккаунта на аккаунт должны быть на оба аккаунта до загрузки их данных в логику перевода, которая делает проверки баланса, а не только на время записи.
Один ресурс в большинстве случаев можно сделать и без ивентлога, обычно это aggregate root, который изменяется.
Это база(!)