Я понимаю ваш оптимизм и желание попробовать новое. Как говорится, велкам. ;)
Но лично мне вы не продали идею со смешанным хранением данных в memory/drive. Мои эксперименты показали, что важные сервисы, связанные с деньгами должны быть persistence only. Их можно обкладывать кешами различной природы и сложности, но за понимание важности durability, иногда, приходится расплачиваться условно "потом и кровью".
А если вспомнить, что ограничение в 1-2К фин. операций, это же при условии апдейта одного объекта. А такой кейс крайне специфичен, с одной стороны. С другой, при апдейте непересекающихся объектов, лимит вырастает до 10-15К. А я не знаю фин.систем, где бы было недостаточно 10-15К. Хотя допускаю, что они есть. ;)
Насколько я понял, вы сделали аля in-memory database с поддержкой ledger dsl, где история лежит в обычной rdbms.
Соответственно, у этого решения есть свои плюсы и минусы.
Плюсы - скорострельность по исполнению фин операций. Что логично, если все в памяти.
Минусы - давно известны для любого in-memory решения.
как дешево обеспечить конкурентный доступ к объектам. насколько я понял, у вас это решено через однопоточность (как в redis, tarantool, voltdb и т.д.)
в целом к однопоточности вопросов нет, до тех пор пока данных не становится сильно больше чем помещается в memory для одного сервера. что в этом случае делать, тоже уже давно известно, нужно часть данных скидывать в обычную rdbms. и вот тут начинаются разные сложности. уверен, кто эксплуатировал подобные решения, смогут рассказать много историй из своего опыта.
Мое имхо, с учетом современного железа, потюненный Postgres дает плюс минус 50K TPS.
Финансовых транзакций, примерно 10-15К.
Есть еще задержки от блокировки объектов из-за конкуренции, тогда скорость падает до 1-2К при плохом раскладе. Вполне допускаю что есть игроки для кого 1-2K фин. операций - это мало, и им нужны альтернативы, допустим в виде qazna ;)
Анти‑Agile акцентирует внимание на том, чтобы в начале проекта были зафиксированы четкие требования, что минимизирует вероятность изменений в будущем.
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
В Agile команды работают над небольшими итерациями и могут менять направление в зависимости от фидбэка. В анти‑Agile акцент делается на планировании всей работы заранее.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Agile поощряет изменения и адаптацию, тогда как анти‑Agile требует строгого следования заранее установленным процессам и графикам.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile подразумевает, что команды сами определяют, как работать, тогда как в анти‑Agile каждая команда имеет четко определенные роли и обязанности.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Сертификат пользователя («фактор владения», расположен в хранилище сертификатов компьютера пользователя, можно сделать не экспортируемым)
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
Я понимаю, что сейчас мода на бд-кластеры. Примерно как kafka, пихают везде где только можно.
Абсолютное большинство проектов, которые я видел за последние лет 5, совсем не требовали кластерных бд. Не было таких бизнес-требований. Это с одной стороны.
С другой, часть кластеров не обеспечивала своей первичной функции - доступность кластера при недоступности одной из нод. Т.е. кластер развернули, но не протестили, или протестили, но не осилили пофиксить проблему.
С третьей, большинство проектов разворачивали кластер на одной, ну или на двух физических железках. Очевидно, при падении железки все ноды кластера тоже падают. Понимания, что для кластеров нужно минимум три физических железки есть у очень редких спецов.
Я понимаю ваш оптимизм и желание попробовать новое. Как говорится, велкам. ;)
Но лично мне вы не продали идею со смешанным хранением данных в memory/drive. Мои эксперименты показали, что важные сервисы, связанные с деньгами должны быть persistence only. Их можно обкладывать кешами различной природы и сложности, но за понимание важности durability, иногда, приходится расплачиваться условно "потом и кровью".
А если вспомнить, что ограничение в 1-2К фин. операций, это же при условии апдейта одного объекта. А такой кейс крайне специфичен, с одной стороны. С другой, при апдейте непересекающихся объектов, лимит вырастает до 10-15К. А я не знаю фин.систем, где бы было недостаточно 10-15К. Хотя допускаю, что они есть. ;)
Насколько я понял, вы сделали аля in-memory database с поддержкой ledger dsl, где история лежит в обычной rdbms.
Соответственно, у этого решения есть свои плюсы и минусы.
Плюсы - скорострельность по исполнению фин операций. Что логично, если все в памяти.
Минусы - давно известны для любого in-memory решения.
как дешево обеспечить конкурентный доступ к объектам. насколько я понял, у вас это решено через однопоточность (как в redis, tarantool, voltdb и т.д.)
в целом к однопоточности вопросов нет, до тех пор пока данных не становится сильно больше чем помещается в memory для одного сервера. что в этом случае делать, тоже уже давно известно, нужно часть данных скидывать в обычную rdbms. и вот тут начинаются разные сложности. уверен, кто эксплуатировал подобные решения, смогут рассказать много историй из своего опыта.
Мое имхо, с учетом современного железа, потюненный Postgres дает плюс минус 50K TPS.
Финансовых транзакций, примерно 10-15К.
Есть еще задержки от блокировки объектов из-за конкуренции, тогда скорость падает до 1-2К при плохом раскладе. Вполне допускаю что есть игроки для кого 1-2K фин. операций - это мало, и им нужны альтернативы, допустим в виде qazna ;)
Ночные остановки сейчас мало связаны с отчетами.
Сейчас остановки из-за обязательных операций, типа начислить проценты, начислить пени, и .т.д. Они не выполняются мгновенно на большой выборке.
Но в большинстве случаев - сейчас конечный пользователь про это не знает. Переводы с карты на карту работают 24/7 для конечных пользователей.
зачем kafka, если у вас есть таблица outbox_payments, которая выполняет по сути роль кафки?
да нет никаких чудес, идемпотентность - это только один нюансов.
надежная платежная логика основана на локах. есть некоторые частные случаи, когда можно обойтись без локов, в обмен на ... (и тут разные опции).
Я видел множество инсталляций SQL Server, которые были развернуты неспециалистами, и просто работали.
Я видел множество инсталляций Postgres, которые были развернуты неспециалистами, и просто работали.
Но почти не видел инсталляций Oracle (Express не беру в расчет), имхо как раз Oracle требуется внимание спеца, начиная с этапа развертывания.
Единственное справедливое утверждение:
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Вся преимущество GraphQL в федерации.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Неделя войны микрорепа vs монорепа объявляется открытой!
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
Я бы сказал, наоборот.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
Расскажите, какие есть способы контроля целостности ПО на устройстве пользователя, которым может доверять удаленный сервис?
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
ITIL и COBIT?
Это что.... ;)))
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
не надо.
достаточно проверять валидность подписи, и валидность сертификата(-ов), включая полномочия.
Выше странный спор, что выгоднее.
Все равно, что спорить, что выгоднее: своя машина, каршеринг или такси.
В зависимости от контекста, может быть выгоднее любая из опций. Это относительно легко считается и принимается решение.
Я понимаю, что сейчас мода на бд-кластеры. Примерно как kafka, пихают везде где только можно.
Абсолютное большинство проектов, которые я видел за последние лет 5, совсем не требовали кластерных бд. Не было таких бизнес-требований. Это с одной стороны.
С другой, часть кластеров не обеспечивала своей первичной функции - доступность кластера при недоступности одной из нод. Т.е. кластер развернули, но не протестили, или протестили, но не осилили пофиксить проблему.
С третьей, большинство проектов разворачивали кластер на одной, ну или на двух физических железках. Очевидно, при падении железки все ноды кластера тоже падают. Понимания, что для кластеров нужно минимум три физических железки есть у очень редких спецов.
🤦♂️
Строго говоря, XML тоже не всегда читается из clob поля в том же виде что и был при записи. Когда это принципиально важно, приходится писать в blob.
А если используется blob, то и json туда же можно писать.
Да, postgres не сможет из такого поля условия применять. Но, как всегда, приходится выбирать....
Говорят, если SM перевести на Kotlin DSL, то и разрабы улетают в космос вместе со стульями