Все полезное уже есть в asp.net - output cache решает проблему с cache stampede из коробки. При желании к нему можно прикрутить и redis, то тогда работать будет значительно медленнее. Можно redis storage заменить на fusion cache, но тогда вся суть будет в том, что ответ сервера будет также храниться в памяти.
Если мы берем не кэширование ответов asp.net, а кэш объектов, то MemoryCache может кэшировать объект без сериализации куда-либо, выдавая один и тот же экземпляр по запросу. FusionCache будет каждый раз сериализовывать.
FusionCache действительно содержит много кода и готовых решений, но найти сценарий где это превзойдет output cache или прямое использование MemoryCache - крайне сложно.
конечно через redis самый популярный вариант и кэширования и сброса для l1, но это все работает не очень хорошо.
Почему сброс через redis плох:
не работает при массовом обновлении данных как из приложения, так и вне приложения через прямое выполнение sql. Для сброса надо получать ключи, а при массовом обновлении redis не знает какие ключи были обновлены. То есть вам все равно нужен будет какой-то механизм для сброса ключей при обновлении данных в базе.
Если у вас уже есть база, в которой по сути встроен механизм для сброса, то зачем дополнительный сервер?
возникает вопрос почему redis так популярен, что его пихают во все сценарии, причин этому несколько:
Все хотят быть как бигтех, даже те кто никогда не станет бигтехом. У бигтеха скорее всего найдется сценарий где redis применим, а типичном saas на 10 000 - 100 000 запросов в час - нет.
Те кто рекомендуют использовать redis (Microsoft, amazon и итд) сами продают redis как сервис, им выгодно чтобы разработчики делали кэширование в redis.
если output cache добавлять до response compression, то будут кэшироваться в памяти уже сжатые ответы. Естественно в этом случае обязательно vary by accept encoding как на клиенте, так и на сервере
Но чаще всего asp.net не публикуется напрямую в интернет, а прячется за прокси, и уже на прокси делается сжатие
Хорошая библиотека, но она, по большей части, просто оборачивает memorycache и redis. redis в принципе не сильно полезен для кэширования, поэтому и не стал включать в статью.
Проприетарный криптопрошный PFX. Документации по нему нет, нужно заниматься сложным реверс-инжинирингом, есть некоторые статьи про конвертирование стандартного PKCS12 в формат КриптоПро, но обратная операция достаточно затруднительна — всё вдоль и поперек обмазано хитро считающимися контрольными суммами.
Внезапно я недавно сделал код, который достает закрытый ключ из сертификата такого формата. Если кому-то будет интересно могу написать статью.
PFX по Р 1323565.1.041— 2022. Транспортный ключевой контейнер. Нет реализации на C#, но структура и логика создания описана в стандарте. Кстати, такой контейнер понимает также криптопровайдер VipNet CSP.
Если у вас не напрямую из базы читали в dwh, а вы сначала из твоей системы отдавали по api данные в другую, а уже оттуда данные попадали в dwh, то тут могла бы помочь интеграция с этой системой на уровне данных. Тем более, судя по всему, там etl типа airflow
То есть целевая модель такая:
Вы выставляете в базе вьюху, которая отдает нужные данные одной таблицей
Обкладываете её индексами
Другая система подключается к вашей с правами только на чтение этой вьюхи
PROFIT!
Вы экономите огромное количество ресурсов на сериализацию данных
Но вы писали что другую систему изменить нельзя (единственный специалист по airflow занят на другой задаче), то просто поменяйте структуру у себя
То есть в вашу базу напрямую не ходили внешние приложение? Тогда почему вы не могли структуру вашей базы поменять?
Про покрывающие индексы стоит говорить если вы запросы в программе сделали с нудными полями. А у вас include, который все равно в select все потащит.
Покрывающий индекс при чтении выгоден всегда. Потому что обычны идекс скан - это поиск записи в индексе (одно логическое чтение), а потом получение записи из кучи (второе логическое чтение). Если вы сделаете «широкий индекс» при выборке относительно небольшого количества строк, то index only наверное всегда выиграет у index scan. Но вы получите большой импакт при записи, так как индексы надо будет обновлять и перестраивать.
Поэтому как общий подход делать все через index only я не могу рекомендовать, но для особо экстремальных случаев помогает даже покрывающий индекс , в котором все поля кроме одного включены.
В базах данных есть view, их как раз и нужно использовать при интеграции с другими системами на уровне данных. Причем Вы могли прямо в текущей базе сделать нормальную модель и отдать потребителям view.
Это у вас НЕДОСТАТОЧНАЯ нормализация данных, как и в таблице коммуникантов. Недостаточная нормализация как раз увеличивает объемы, ухудшает возможности оптимизации с помощью индексов и приводит к конфликтам рассогласованности данных.
Вы неверно употребляете термин «нормалмзация». Нормализация это отсутствие связей между не ключевыми полями в таблице и строгая связь с ключевым полем. У вас это просто ошибка моделирования.
Есть хороший инженерный коэффициент - 6. Или более наукообразно - 2Пи. Система должна выдерживать шестикратное превшение нагрузки над «рабочими» значениями. То есть во время тесты вы должны были в 6 раз увеличить объемы данных для тестирования, если у вас проблема упирается именно в объем или rps, если система упирается в частоту запросов.
1) почему вы продолжали использовать include, а не вписали проекции только тех значений что нужны конкретно для dwh? Вряд ли там все поля таблицы используются
2) как следствие пункта выше: почему не пытались сделать покрывающие индексы и свести все к index only scan?
3) почему не применили filtered indexes, вы бы могли для целей dwh сделать индекс c where, чтобы из индекса убирать автоответчики ?
Кроме того можно было сделать в индексе where по дате, чтобы отсекать данные старше 90 дней и перестраивать индекс по ночам, причем конкурентно, чтобы не мешать другим. Получился бы всего один ddl запрос
4) возможно стоило попробовать перенести op_data в jsonb поле в самой activity, тогда и читать пришлось бы меньше (вероятно) и размер возвращемого датасета снизился бы (точно). Делать key-value хранилище в таблицах бд - не самое эффективное решение. В крайнем случае сделать json_agg (два array_agg на key и value)в запросе.
Сделал тест такого варианта https://habr.com/ru/articles/963120/ Очень сильно проигрывает транзакциям в БД, даже без реализации отката при потере связи.
Рукопашные транзакции могут оказаться быстрее если время обработки значительное, но мы тогда приходим к архитектуре с очередями в базе и асинхронной обработке.
Сохранить синхронность и сделать рукопашные транзакции, чтобы уменьшить ожидания на блокировках, в большинстве случаев приведет к замедлению. А если нужно просто уменьшить степень конкурентности, то проще блокировку сделать advisory lock, взять блокировку таблицы или очередь как в этом посте.
В принципе любюй протокол палится своими заголовками. Даже VLESS, судя по описанию легко поддается определению. А не палится он за счет того, что маскируется под http2 с веб-сокетами. Даже не маскируется, он просто свою полезную нагрузку передает через h2+ws. Странно что об этом не сразу догадались.
Насколько я понимаю TLS пока еще никто читать не научился, потому что если научится, то это конец всей безопасности в вебе. Поэтому определить что внутри h2+ws траффика идет VPN туннель пока не могут.
А вот заблокировать ваш сайт и выписать штраф за рекламу ВПН для обхода блокировок - вполне. Странно что администрация хабра спит.
Все полезное уже есть в asp.net - output cache решает проблему с cache stampede из коробки. При желании к нему можно прикрутить и redis, то тогда работать будет значительно медленнее. Можно redis storage заменить на fusion cache, но тогда вся суть будет в том, что ответ сервера будет также храниться в памяти.
Если мы берем не кэширование ответов asp.net, а кэш объектов, то MemoryCache может кэшировать объект без сериализации куда-либо, выдавая один и тот же экземпляр по запросу. FusionCache будет каждый раз сериализовывать.
FusionCache действительно содержит много кода и готовых решений, но найти сценарий где это превзойдет output cache или прямое использование MemoryCache - крайне сложно.
конечно через redis самый популярный вариант и кэширования и сброса для l1, но это все работает не очень хорошо.
Почему сброс через redis плох:
не работает при массовом обновлении данных как из приложения, так и вне приложения через прямое выполнение sql. Для сброса надо получать ключи, а при массовом обновлении redis не знает какие ключи были обновлены. То есть вам все равно нужен будет какой-то механизм для сброса ключей при обновлении данных в базе.
Если у вас уже есть база, в которой по сути встроен механизм для сброса, то зачем дополнительный сервер?
возникает вопрос почему redis так популярен, что его пихают во все сценарии, причин этому несколько:
Все хотят быть как бигтех, даже те кто никогда не станет бигтехом. У бигтеха скорее всего найдется сценарий где redis применим, а типичном saas на 10 000 - 100 000 запросов в час - нет.
Те кто рекомендуют использовать redis (Microsoft, amazon и итд) сами продают redis как сервис, им выгодно чтобы разработчики делали кэширование в redis.
если output cache добавлять до response compression, то будут кэшироваться в памяти уже сжатые ответы. Естественно в этом случае обязательно vary by accept encoding как на клиенте, так и на сервере
Но чаще всего asp.net не публикуется напрямую в интернет, а прячется за прокси, и уже на прокси делается сжатие
Хорошая библиотека, но она, по большей части, просто оборачивает memorycache и redis. redis в принципе не сильно полезен для кэширования, поэтому и не стал включать в статью.
Аллокации не коде методов Merge, а в самих асинхронных итераторах.
Звучит как попытка угадать будущее, которая в общем провальна
Потому что архитектура не очень видимо
У нас недавно всплыла проблема, но как на днях выяснили что разработчик накосячил.
Нет ли у вас проблем с проверкой открепленной подписи по ГОСТу с помощью Bouncy Castle?
Спасибо огромное за вашу статью
Внезапно я недавно сделал код, который достает закрытый ключ из сертификата такого формата. Если кому-то будет интересно могу написать статью.
Можно ссылочку на стандарт?
Если у вас не напрямую из базы читали в dwh, а вы сначала из твоей системы отдавали по api данные в другую, а уже оттуда данные попадали в dwh, то тут могла бы помочь интеграция с этой системой на уровне данных. Тем более, судя по всему, там etl типа airflow
То есть целевая модель такая:
Вы выставляете в базе вьюху, которая отдает нужные данные одной таблицей
Обкладываете её индексами
Другая система подключается к вашей с правами только на чтение этой вьюхи
PROFIT!
Вы экономите огромное количество ресурсов на сериализацию данных
Но вы писали что другую систему изменить нельзя (единственный специалист по airflow занят на другой задаче), то просто поменяйте структуру у себя
То есть в вашу базу напрямую не ходили внешние приложение? Тогда почему вы не могли структуру вашей базы поменять?
Про покрывающие индексы стоит говорить если вы запросы в программе сделали с нудными полями. А у вас include, который все равно в select все потащит.
Покрывающий индекс при чтении выгоден всегда. Потому что обычны идекс скан - это поиск записи в индексе (одно логическое чтение), а потом получение записи из кучи (второе логическое чтение). Если вы сделаете «широкий индекс» при выборке относительно небольшого количества строк, то index only наверное всегда выиграет у index scan. Но вы получите большой импакт при записи, так как индексы надо будет обновлять и перестраивать.
Поэтому как общий подход делать все через index only я не могу рекомендовать, но для особо экстремальных случаев помогает даже покрывающий индекс , в котором все поля кроме одного включены.
Про работу над ошибками:
В базах данных есть view, их как раз и нужно использовать при интеграции с другими системами на уровне данных. Причем Вы могли прямо в текущей базе сделать нормальную модель и отдать потребителям view.
Это у вас НЕДОСТАТОЧНАЯ нормализация данных, как и в таблице коммуникантов. Недостаточная нормализация как раз увеличивает объемы, ухудшает возможности оптимизации с помощью индексов и приводит к конфликтам рассогласованности данных.
Вы неверно употребляете термин «нормалмзация». Нормализация это отсутствие связей между не ключевыми полями в таблице и строгая связь с ключевым полем. У вас это просто ошибка моделирования.
Есть хороший инженерный коэффициент - 6. Или более наукообразно - 2Пи. Система должна выдерживать шестикратное превшение нагрузки над «рабочими» значениями. То есть во время тесты вы должны были в 6 раз увеличить объемы данных для тестирования, если у вас проблема упирается именно в объем или rps, если система упирается в частоту запросов.
Выглядит как «из пушки по воробьям».
1) почему вы продолжали использовать include, а не вписали проекции только тех значений что нужны конкретно для dwh? Вряд ли там все поля таблицы используются
2) как следствие пункта выше: почему не пытались сделать покрывающие индексы и свести все к index only scan?
3) почему не применили filtered indexes, вы бы могли для целей dwh сделать индекс c where, чтобы из индекса убирать автоответчики ?
Кроме того можно было сделать в индексе where по дате, чтобы отсекать данные старше 90 дней и перестраивать индекс по ночам, причем конкурентно, чтобы не мешать другим. Получился бы всего один ddl запрос
4) возможно стоило попробовать перенести op_data в jsonb поле в самой activity, тогда и читать пришлось бы меньше (вероятно) и размер возвращемого датасета снизился бы (точно). Делать key-value хранилище в таблицах бд - не самое эффективное решение. В крайнем случае сделать json_agg (два array_agg на key и value)в запросе.
что из написанного вам непонятно? С чем из написанного вы не согласны?
Да, не точно написал. Vacuum не блокирует, но сильно замедляет запросы, так как читает и записывает множество страниц таблицы.
Разве не так сейчас вебсокеты работают https://datatracker.ietf.org/doc/html/rfc8441
Это если http2, но сейчас вроде все серверы и клиенты это поддерживают.
Сделал тест такого варианта https://habr.com/ru/articles/963120/
Очень сильно проигрывает транзакциям в БД, даже без реализации отката при потере связи.
Рукопашные транзакции могут оказаться быстрее если время обработки значительное, но мы тогда приходим к архитектуре с очередями в базе и асинхронной обработке.
Сохранить синхронность и сделать рукопашные транзакции, чтобы уменьшить ожидания на блокировках, в большинстве случаев приведет к замедлению. А если нужно просто уменьшить степень конкурентности, то проще блокировку сделать advisory lock, взять блокировку таблицы или очередь как в этом посте.
Сделал тест варианта с явными блокировками https://habr.com/ru/articles/963120/
В принципе любюй протокол палится своими заголовками. Даже VLESS, судя по описанию легко поддается определению. А не палится он за счет того, что маскируется под http2 с веб-сокетами. Даже не маскируется, он просто свою полезную нагрузку передает через h2+ws. Странно что об этом не сразу догадались.
Насколько я понимаю TLS пока еще никто читать не научился, потому что если научится, то это конец всей безопасности в вебе. Поэтому определить что внутри h2+ws траффика идет VPN туннель пока не могут.
А вот заблокировать ваш сайт и выписать штраф за рекламу ВПН для обхода блокировок - вполне. Странно что администрация хабра спит.