Ну, не всегда нужно уметь масштабировать (да и далеко не все можно горизонтально масштабировать на kafka - то же число партиций). На PG вполне нормально получить несколько тысяч message-per-second на недорогом железе и при этом получить хорошие гарантии и избежать необходимости в CDC и прочих тонкостях взаимодействий СУБД и очередей. Как всегда, все упирается в НФТ
Ну, конкретно решение от Яндекс.Денег меня не всегда устраивает по возможностям, я бы скорее свое сделал (благо там делать особо нечего, два простых запроса и несколько сотен строк кода). Ну и я как-то подробно рассказывал, как делать очереди на Pg или другой БД с skip locked.
Зависит, конечно, от миграций. Если речь идет про "изменили структуру value, нужно избавиться от данных со старой версии структуры" (большинство миграций именно таких), то тут нужно протестировать логику миграции отдельной записи, это достаточно просто (остальное сделает уже migration tool). Для "добавить индекс" есть уже один раз написанный код, там тоже все довольно просто. А вот если какие-то сложные преобразования (объединение "таблиц", изменение связей), то для каждого сценария придумываем набор тестов на разных уровнях. Если честно, не вижу разницы между миграциями на FoundationDB и на PostgreSQL, в любом случае это же будет не update Payments set newPrice = price*2, а обновление небольшими блоками с привязкой к версии структуры.
Про kafka. Для описанных задач каждая из миллионов очередей - это про набор сообщений, которые нужно обрабатывать в порядке их появления, при этом возможность обработки события не гарантирована (и сама обработка не быстра). Например, если взять очередь событий для отправки на клиента, то я не могу взять "верхнее", выяснить что связь с клиентом сейчас отсутствует и выкинуть его, мне нужно или его обработать или остановить выборку всей партиции. И гарантии последовательности обработки в кафке именно для партиции, так что если нам нужно "10 mln последовательностей обработки", то нужно 10 mln партиций ( Поэтому и пришлось разделить сущности, когда упорядоченный набор событий живет в FDB, а список "нужно что-то обработать из этой очереди" - в kafka (и для событий в kafka порядок обработки уже не важен, поэтому партиции становятся, как правильно заметили, именно единицей параллелизма). Понятно, что для каждого отдельного кейса (события клиенту, события внутри Haydn, большие задачи типа отчетов) можно придумать какие-то свои специальные решения, но это будет сложнее для разработчиков, нежели "взять событие и обработал". А архитектура - это про управление сложностью )
Про Cadence - спасибо за замечание, все правильно. Я слышал, что и внутри Uber потихоньку переходят на temporal, но не знаю, как эти слухи соотносятся с действительностью.
В реальном финтехе, конечно, там не паттерн стратегия, а несколько стратегий и проксей, связанных через workflow. Иногда можно обойтись списком из нескольких стратегий, но это неудобно.
Хм, даже если это число (номер паспорта или ИНН), то битмэп будет очень большой и почти полностью пустой и не даст никакой информации, кроме "такой у нас уже есть". Разумный хэш будет компактнее и давать почти ту же линейную скорость поиска, так как внутри там тот же самый массив бакетов, достаточно большой. Если нужно еще быстрее, то можно прикрутить фильтр блюма.
Хм, так как там нет закрытых списков сертификатов на клиенте, то уязвимость через MitM точно есть. Кроме того, зловредное приложение на рутованном андроиде точно так же сможет смотреть трафик. Так как пароль хранится на устройстве, то для андроида с кривым security storage (а такие модели встречаются, хотя в РФ и весьма редко) можно подсмотреть его прямо в хранилище.
Это те вектора, что тривиально приходят в голову и только на основании статьи. Но так как при разработке приложения, похоже, про безопасность вообще не думали, то, подозреваю, там еще много разных дырок.
Можешь погуглить, это популярная тема. Если коротко, то при попытке взятия ACCESS EXCLUSIVE во время выполнения другой длинной транзакции все новые транзакции будут выстраиваться в очередь после выполнения AE, а она будет ждать завершения этой длинной транзакции. В худшем случае можно получить простой сроком в несколько минут (если такие длинные транзакции разрешены конкретными настройками, обычно разрешены).
Просто нужно уметь возможность на момент миграции отключать "длинные транзакции" (например те же отчеты или другие миграции на этой же таблице). Если есть возможность или необходимость - можно оценивать, какие вообще транзакции идут сейчас по данной таблице и откладывать миграцию DDL на момент "все тихо", но это уже сложное решение. Или принудительно делать rollback для всех транзакций, а потом уже делать ALTER TABLE
Но ALTER TABLE my_table ADD COLUMN"требует блокировки ACCESS EXCLUSIVE. В большинстве случаев это может быть не заметным, но если идет выполнение длинной транзакции, то данное требование приведет к весьма заметной недоступности таблицы.Поэтому указанный подход нужно использовать очень аккуратно и не стоит использовать в ответах на собеседовании.
А толку-то, если нормально сделано, то там у каждого пароля своя соль и используется нормальный алгоритм типа bcrypt или более поздний, который сложен и для GPU и даже для квантовых компьютеров. Ну а если базу делали какие-то новички, то там ничего не поможет (
Как это "одна и та же роль"? Это вообще из разных реальностей термины.
Кстати, а где в scrum guide запрет на внесение изменений в спринт? В последних редакциях такого запрета нет, есть только "не вносятся изменения, которые могут поставить под угрозу Sprint Goal" и явно сказано "Поэтому SprintBacklog обновляется на протяжении всего Sprint по мере появления новых знаний".
А обучение Скраму в ОТУСе по какой, вообще, редакции осуществляется?
А сколько очередей (топиков) одновременно удалось поднять на pulsar и на каком железе? У кафки проблемы начинаются где-то с 100K, а как на пульсаре по вашему опыту?
А чем API Gateway помогает для улучшения наглядности? И так в любом логе или трейсинге видно, кто и кого вызывает. API Gateway для внутренних сервисов скорее усложняет отладку. Гораздо лучше API Gateway использовать для изоляции внешних запросов (для чего он обычно и делается).
Ну, не всегда нужно уметь масштабировать (да и далеко не все можно горизонтально масштабировать на kafka - то же число партиций).
На PG вполне нормально получить несколько тысяч message-per-second на недорогом железе и при этом получить хорошие гарантии и избежать необходимости в CDC и прочих тонкостях взаимодействий СУБД и очередей.
Как всегда, все упирается в НФТ
Ну, конкретно решение от Яндекс.Денег меня не всегда устраивает по возможностям, я бы скорее свое сделал (благо там делать особо нечего, два простых запроса и несколько сотен строк кода). Ну и я как-то подробно рассказывал, как делать очереди на Pg или другой БД с skip locked.
Зависит, конечно, от миграций.
Если речь идет про "изменили структуру value, нужно избавиться от данных со старой версии структуры" (большинство миграций именно таких), то тут нужно протестировать логику миграции отдельной записи, это достаточно просто (остальное сделает уже migration tool).
Для "добавить индекс" есть уже один раз написанный код, там тоже все довольно просто.
А вот если какие-то сложные преобразования (объединение "таблиц", изменение связей), то для каждого сценария придумываем набор тестов на разных уровнях.
Если честно, не вижу разницы между миграциями на FoundationDB и на PostgreSQL, в любом случае это же будет не update Payments set newPrice = price*2, а обновление небольшими блоками с привязкой к версии структуры.
Про kafka.
Для описанных задач каждая из миллионов очередей - это про набор сообщений, которые нужно обрабатывать в порядке их появления, при этом возможность обработки события не гарантирована (и сама обработка не быстра). Например, если взять очередь событий для отправки на клиента, то я не могу взять "верхнее", выяснить что связь с клиентом сейчас отсутствует и выкинуть его, мне нужно или его обработать или остановить выборку всей партиции.
И гарантии последовательности обработки в кафке именно для партиции, так что если нам нужно "10 mln последовательностей обработки", то нужно 10 mln партиций (
Поэтому и пришлось разделить сущности, когда упорядоченный набор событий живет в FDB, а список "нужно что-то обработать из этой очереди" - в kafka (и для событий в kafka порядок обработки уже не важен, поэтому партиции становятся, как правильно заметили, именно единицей параллелизма).
Понятно, что для каждого отдельного кейса (события клиенту, события внутри Haydn, большие задачи типа отчетов) можно придумать какие-то свои специальные решения, но это будет сложнее для разработчиков, нежели "взять событие и обработал". А архитектура - это про управление сложностью )
Про Cadence - спасибо за замечание, все правильно. Я слышал, что и внутри Uber потихоньку переходят на temporal, но не знаю, как эти слухи соотносятся с действительностью.
В реальном финтехе, конечно, там не паттерн стратегия, а несколько стратегий и проксей, связанных через workflow. Иногда можно обойтись списком из нескольких стратегий, но это неудобно.
Хм, даже если это число (номер паспорта или ИНН), то битмэп будет очень большой и почти полностью пустой и не даст никакой информации, кроме "такой у нас уже есть". Разумный хэш будет компактнее и давать почти ту же линейную скорость поиска, так как внутри там тот же самый массив бакетов, достаточно большой.
Если нужно еще быстрее, то можно прикрутить фильтр блюма.
Хм, так как там нет закрытых списков сертификатов на клиенте, то уязвимость через MitM точно есть.
Кроме того, зловредное приложение на рутованном андроиде точно так же сможет смотреть трафик.
Так как пароль хранится на устройстве, то для андроида с кривым security storage (а такие модели встречаются, хотя в РФ и весьма редко) можно подсмотреть его прямо в хранилище.
Это те вектора, что тривиально приходят в голову и только на основании статьи.
Но так как при разработке приложения, похоже, про безопасность вообще не думали, то, подозреваю, там еще много разных дырок.
Если реально хочешь и не в крипте, то пиши в личку или в телеграмм @dphil
Можешь погуглить, это популярная тема.
Если коротко, то при попытке взятия ACCESS EXCLUSIVE во время выполнения другой длинной транзакции все новые транзакции будут выстраиваться в очередь после выполнения AE, а она будет ждать завершения этой длинной транзакции.
В худшем случае можно получить простой сроком в несколько минут (если такие длинные транзакции разрешены конкретными настройками, обычно разрешены).
А можно описать, а чем этот подход поможет?
Просто нужно уметь возможность на момент миграции отключать "длинные транзакции" (например те же отчеты или другие миграции на этой же таблице).
Если есть возможность или необходимость - можно оценивать, какие вообще транзакции идут сейчас по данной таблице и откладывать миграцию DDL на момент "все тихо", но это уже сложное решение.
Или принудительно делать rollback для всех транзакций, а потом уже делать ALTER TABLE
Но
ALTER TABLE my_table ADD COLUMN"требует блокировки ACCESS EXCLUSIVE. В большинстве случаев это может быть не заметным, но если идет выполнение длинной транзакции, то данное требование приведет к весьма заметной недоступности таблицы.Поэтому указанный подход нужно использовать очень аккуратно и не стоит использовать в ответах на собеседовании.И все клавиатуры из списка вредны для запястья, ни одной эргономичной.
И все без тачпада, так что придется руки часто переносить.
А толку-то, если нормально сделано, то там у каждого пароля своя соль и используется нормальный алгоритм типа bcrypt или более поздний, который сложен и для GPU и даже для квантовых компьютеров.
Ну а если базу делали какие-то новички, то там ничего не поможет (
Каким способом при переводе "purpose/why" превратилось в "некоторую компенсацию"?
Как это "одна и та же роль"? Это вообще из разных реальностей термины.
Кстати, а где в scrum guide запрет на внесение изменений в спринт? В последних редакциях такого запрета нет, есть только "не вносятся изменения, которые могут поставить под угрозу Sprint Goal" и явно сказано "Поэтому SprintBacklog обновляется на протяжении всего Sprint по мере появления новых знаний".
А обучение Скраму в ОТУСе по какой, вообще, редакции осуществляется?
А сколько очередей (топиков) одновременно удалось поднять на pulsar и на каком железе?
У кафки проблемы начинаются где-то с 100K, а как на пульсаре по вашему опыту?