Про 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 использовать для изоляции внешних запросов (для чего он обычно и делается).
Какие-то слабые «эффективные менеджеры», не смогли объяснить инвестору и координатору, что вы саботировали все их идеи и по этой причине произошла такая задержка. И вас не смогли уволить (а для грамотного эффективного менеджера, отжимающего на себя финансовые потоки — это вообще самое важное действие).
Такое ощущение, что эти менеджеры реально хотели сделать проект лучше, но это уже не «эффективные», а просто непрофессиональные.
Интерфейс делать сложно. А вот использовать Dart-овую общую прослойку для state managment/api managment для Web и Mobile — вполне реально, мы так делаем. Есть и плюсы и минусы, конечно.
Про 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, а как на пульсаре по вашему опыту?
Такое ощущение, что эти менеджеры реально хотели сделать проект лучше, но это уже не «эффективные», а просто непрофессиональные.