Комментарии (19)

1. 

   daniil_kulikov

   27.09.2025 08:18

   #28888302

   Не понял пункта про зависимости. В проектах число зависимостей зачастую как у соседа в Мурино. Неужели наличие ещё одной критичнее, чем прожорливость и скорость?

   А вообще, было бы любопытно глянуть на перфоманс кэшей без упора в железо. Чисто ради интереса

   
   

   1. 

      noavarice

      27.09.2025 08:18

      #28888330

      Про зависимости - проще администрировать один постгрес, чем постгрес и редис (настраивать, следить за обновлениями и уязвимостями и т.д.). Редис и постгрес более похожи, чем скажем постгрес и рэббит - можно очередь через БД реализовать и отказаться от рэббита, но это намного сложнее, чем отказаться от редиса и реализовать его функции в постгресе

      
      

      1. 

         Politura

         27.09.2025 08:18

         #28890498

         И сколько времени в год у вас тратится на администрирование редиса? Ну чтоб понимать, насколько именно проще без него. :)

   
   

   1. 

      avovana7 Автор

      27.09.2025 08:18

      #28888332

      Даниил, я бы раскрыл со стороны технологического ландшафта. Если у нас есть PostgreSQL и мы умеем её готовить, то доп сущность/СУБД привносит дополнительные издержки на поддержку/нужду в наработке экспертизы.

      Автор исходил из фокуса использования кэша для условно небольших проектов. Где PostgreSQL вполне может хватить. Тем более, если он уже есть.

      Про перформанс кэшэй без упора в железо - имеется ввиду как-то абстрагироваться от тестовых стендов?

1. 

   Dhwtj

   27.09.2025 08:18

   #28888366

   Можно и в приложении кешировать L1 write back cache, то есть на каждый инстанс свой. Пишешь в потокобезопасный вариант хешмапы и отгребаешь в БД его изменения батчами, что быстрее чем по одному. И быстрее чем редис: никаких сетевых запросов.

   Минус: при рестарте сервиса кеш сбрасывается. Больше памяти, потому что на каждый инстанс свой кеш.

   Второй минус при падении сервиса потеря данных что не успели записаться, нужно мягкое гашение сервиса. Если критично, то можно писать свой WAL fallback: критичные данные дублировать в append-only лог перед батчингом. Тоже надёжно и очень быстро.

   Но если жесткое IO и годный балансер чтобы не утопить свеже стартовавший (или вообще один инстанс) то штука хорошая

   Для балансера:

   - Readiness probe с задержкой после старта

   - Slow start в nginx/envoy — постепенно увеличивать трафик

   - Или прогрев кеша перед переключением в ready

   В C# удобно через IHostedService + Channel для батчинга. В Rust — tokio::sync::mpsc + graceful shutdown через токены

   
   

   1. 

      Dhwtj

      27.09.2025 08:18

      #28891570

      Вот с редис

      // Domain models
      public record User(int Id, string Name, DateTime CreatedAt);
      public record Product(int Id, string Name, decimal Price);
      public record Order(int Id, int UserId, DateTime OrderDate, decimal Total);
      
      // Base generic repository
      public interface IRepository<T> where T : class
      {
          Task<T?> GetById(int id);
          Task<T> Create(T entity);
          Task Update(T entity);
          Task Delete(int id);
      }
      
      // Generic SQL implementation
      public class SqlRepository<T> : IRepository<T> where T : class
      {
          private readonly IDbConnection _db;
          private readonly string _tableName;
      
          public SqlRepository(IDbConnection db)
          {
              _db = db;
              _tableName = typeof(T).Name + "s"; // User -> Users
          }
      
          public async Task<T?> GetById(int id) =>
              await _db.QuerySingleOrDefaultAsync<T>(
                  $"SELECT * FROM {_tableName} WHERE Id = @id", 
                  new { id });
      
          public async Task<T> Create(T entity) => 
              throw new NotImplementedException(); // специфично для каждой таблицы
      
          public async Task Update(T entity) =>
              throw new NotImplementedException(); // специфично для каждой таблицы
      
          public async Task Delete(int id) =>
              await _db.ExecuteAsync($"DELETE FROM {_tableName} WHERE Id = @id", new { id });
      }
      
      // Universal cache decorator
      public class CachedRepository<T> : IRepository<T> where T : class
      {
          private readonly IRepository<T> _inner;
          private readonly IDatabase _cache;
          private readonly string _keyPrefix;
      
          public CachedRepository(IRepository<T> inner, IConnectionMultiplexer redis)
          {
              _inner = inner;
              _cache = redis.GetDatabase();
              _keyPrefix = typeof(T).Name.ToLower();
          }
      
          public async Task<T?> GetById(int id)
          {
              var key = $"{_keyPrefix}:{id}";
              var cached = await _cache.StringGetAsync(key);
              if (cached.HasValue)
                  return JsonSerializer.Deserialize<T>(cached!);
      
              var entity = await _inner.GetById(id);
              if (entity != null)
                  await _cache.StringSetAsync(key, JsonSerializer.Serialize(entity), TimeSpan.FromMinutes(5));
      
              return entity;
          }
      
          public async Task<T> Create(T entity)
          {
              entity = await _inner.Create(entity);
              await InvalidateCache(GetId(entity));
              return entity;
          }
      
          public async Task Update(T entity)
          {
              await _inner.Update(entity);
              await InvalidateCache(GetId(entity));
          }
      
          public async Task Delete(int id)
          {
              await _inner.Delete(id);
              await InvalidateCache(id);
          }
      
          private async Task InvalidateCache(int id) =>
              await _cache.KeyDeleteAsync($"{_keyPrefix}:{id}");
      
          private int GetId(T entity) =>
              (int)entity.GetType().GetProperty("Id")!.GetValue(entity)!;
      }
      
      // Specific repositories (только для специфичной логики)
      public interface IUserRepository : IRepository<User>
      {
          Task<User?> GetByName(string name);
      }
      
      public class SqlUserRepository : SqlRepository<User>, IUserRepository
      {
          public SqlUserRepository(IDbConnection db) : base(db) { }
      
          public async Task<User?> GetByName(string name) =>
              await _db.QuerySingleOrDefaultAsync<User>(
                  "SELECT * FROM Users WHERE Name = @name", 
                  new { name });
      }
      
      // Кеширующий декоратор для User с дополнительным методом
      public class CachedUserRepository : CachedRepository<User>, IUserRepository
      {
          private readonly IUserRepository _inner;
          private readonly IDatabase _cache;
      
          public CachedUserRepository(IUserRepository inner, IConnectionMultiplexer redis) 
              : base(inner, redis)
          {
              _inner = inner;
              _cache = redis.GetDatabase();
          }
      
          public async Task<User?> GetByName(string name)
          {
              var key = $"user:name:{name}";
              var cached = await _cache.StringGetAsync(key);
              if (cached.HasValue)
                  return JsonSerializer.Deserialize<User>(cached!);
      
              var user = await _inner.GetByName(name);
              if (user != null)
                  await _cache.StringSetAsync(key, JsonSerializer.Serialize(user), TimeSpan.FromMinutes(5));
      
              return user;
          }
      }
      
      // DI Setup - автоматическая регистрация
      var builder = WebApplication.CreateBuilder(args);
      
      builder.Services.AddSingleton<IConnectionMultiplexer>(
          ConnectionMultiplexer.Connect("localhost:6379"));
      
      builder.Services.AddScoped<IDbConnection>(_ => 
          new NpgsqlConnection("Host=localhost;Database=mydb"));
      
      // Автоматическая регистрация всех репозиториев с кешированием
      builder.Services.Scan(scan => scan
          .FromAssemblyOf<SqlUserRepository>()
          .AddClasses(classes => classes.AssignableTo(typeof(IRepository<>)))
          .AsImplementedInterfaces()
          .WithScopedLifetime()
          .Decorate(typeof(IRepository<>), typeof(CachedRepository<>)));
      
      // Специфичные репозитории
      builder.Services.AddScoped<SqlUserRepository>();
      builder.Services.AddScoped<IUserRepository>(sp => 
          new CachedUserRepository(
              sp.GetRequiredService<SqlUserRepository>(),
              sp.GetRequiredService<IConnectionMultiplexer>()));
      
      var app = builder.Build();
      
      // Endpoints
      app.MapGet("/user/{id:int}", async (int id, IRepository<User> repo) => 
          await repo.GetById(id));
      
      app.MapGet("/product/{id:int}", async (int id, IRepository<Product> repo) => 
          await repo.GetById(id));
      
      app.MapGet("/order/{id:int}", async (int id, IRepository<Order> repo) => 
          await repo.GetById(id));
      
      app.Run();

      Вот со своим кешированием

      // Domain models
      public record User(int Id, string Name, DateTime CreatedAt);
      public record Product(int Id, string Name, decimal Price);
      public record Order(int Id, int UserId, DateTime OrderDate, decimal Total);
      
      // Repository interface
      public interface IRepository<T> where T : class
      {
          Task<T?> GetById(int id);
          Task<T> Save(T entity);
          Task Delete(int id);
      }
      
      // SQL backend
      public class SqlRepository<T> : IRepository<T> where T : class
      {
          private readonly IDbConnection _db;
          private readonly string _table;
      
          public SqlRepository(IDbConnection db)
          {
              _db = db;
              _table = typeof(T).Name + "s";
          }
      
          public async Task<T?> GetById(int id) =>
              await _db.QuerySingleOrDefaultAsync<T>(
                  $"SELECT * FROM {_table} WHERE Id = @id", new { id });
      
          public async Task<T> Save(T entity)
          {
              var id = GetId(entity);
              var props = typeof(T).GetProperties()
                  .Where(p => p.Name != "Id")
                  .Select(p => $"{p.Name} = @{p.Name}");
      
              var sql = $"UPDATE {_table} SET {string.Join(", ", props)} WHERE Id = @Id";
              await _db.ExecuteAsync(sql, entity);
              return entity;
          }
      
          public async Task Delete(int id) =>
              await _db.ExecuteAsync($"DELETE FROM {_table} WHERE Id = @id", new { id });
      
          private int GetId(T entity) =>
              (int)entity.GetType().GetProperty("Id")!.GetValue(entity)!;
      }
      
      // Cached decorator
      public class CachedRepository<T> : IRepository<T> where T : class
      {
          private readonly IRepository<T> _backend;
          private readonly IMemoryCache _cache;
          private readonly string _keyPrefix;
          private readonly TimeSpan _expiration = TimeSpan.FromMinutes(5);
      
          public CachedRepository(IRepository<T> backend, IMemoryCache cache)
          {
              _backend = backend;
              _cache = cache;
              _keyPrefix = typeof(T).Name.ToLower();
          }
      
          public async Task<T?> GetById(int id)
          {
              var key = $"{_keyPrefix}:{id}";
      
              return await _cache.GetOrCreateAsync(key, async entry =>
              {
                  entry.AbsoluteExpirationRelativeToNow = _expiration;
                  return await _backend.GetById(id);
              });
          }
      
          public async Task<T> Save(T entity)
          {
              entity = await _backend.Save(entity);
      
              var id = GetId(entity);
              var key = $"{_keyPrefix}:{id}";
              _cache.Set(key, entity, _expiration);
      
              return entity;
          }
      
          public async Task Delete(int id)
          {
              await _backend.Delete(id);
      
              var key = $"{_keyPrefix}:{id}";
              _cache.Remove(key);
          }
      
          private int GetId(T entity) =>
              (int)entity.GetType().GetProperty("Id")!.GetValue(entity)!;
      }
      
      // Program.cs
      var builder = WebApplication.CreateBuilder(args);
      
      // Memory cache
      builder.Services.AddMemoryCache(options =>
      {
          options.SizeLimit = 10000; // Max 10k entries
      });
      
      // DB connection
      builder.Services.AddScoped<IDbConnection>(_ => 
          new NpgsqlConnection(builder.Configuration.GetConnectionString("Default")));
      
      // Repositories with caching
      builder.Services.AddScoped<SqlRepository<User>>();
      builder.Services.AddScoped<IRepository<User>>(sp =>
          new CachedRepository<User>(
              sp.GetRequiredService<SqlRepository<User>>(),
              sp.GetRequiredService<IMemoryCache>()));
      
      builder.Services.AddScoped<SqlRepository<Product>>();
      builder.Services.AddScoped<IRepository<Product>>(sp =>
          new CachedRepository<Product>(
              sp.GetRequiredService<SqlRepository<Product>>(),
              sp.GetRequiredService<IMemoryCache>()));
      
      builder.Services.AddScoped<SqlRepository<Order>>();
      builder.Services.AddScoped<IRepository<Order>>(sp =>
          new CachedRepository<Order>(
              sp.GetRequiredService<SqlRepository<Order>>(),
              sp.GetRequiredService<IMemoryCache>()));
      
      var app = builder.Build();
      
      // Endpoints
      app.MapGet("/users/{id:int}", async (int id, IRepository<User> repo) => 
          await repo.GetById(id) is { } user ? Results.Ok(user) : Results.NotFound());
      
      app.MapPut("/users/{id:int}", async (int id, User user, IRepository<User> repo) =>
      {
          if (id != user.Id) return Results.BadRequest();
          return Results.Ok(await repo.Save(user));
      });
      
      app.MapDelete("/users/{id:int}", async (int id, IRepository<User> repo) =>
      {
          await repo.Delete(id);
          return Results.NoContent();
      });
      
      // Batch endpoint
      app.MapPost("/users/batch", async (List<User> users, IRepository<User> repo) =>
      {
          var tasks = users.Select(u => repo.Save(u));
          return Results.Ok(await Task.WhenAll(tasks));
      });
      
      app.MapGet("/products/{id:int}", async (int id, IRepository<Product> repo) => 
          await repo.GetById(id));
      
      app.MapGet("/orders/{id:int}", async (int id, IRepository<Order> repo) => 
          await repo.GetById(id));
      
      app.Run();

      Намного проще и быстрее чем с Redis:

      IMemoryCache:
      - Встроен в ASP.NET, не нужен отдельный сервер
      - Нет сериализации JSON
      - Нет сетевых задержек
      - GetOrCreateAsync() — атомарная операция из коробки

      Redis нужен когда:
      - Несколько серверов API (shared cache)
      - Переживание рестартов
      - Pub/Sub для инвалидации
      - Больше данных чем RAM одного сервера

      Для одного сервера IMemoryCache оптимальнее практически всегда.

      IMemoryCache: ~34 строки, работает сразу

      Redis: ~50 строк + Docker + конфиг + сериализация, дополнительные знания о продукте

      Что сломается без знаний:

      Забыл TTL → Redis съест всю память

      Неверная eviction policy → удалятся нужные ключи

      Нет persistence → потеря кеша при рестарте

      Connection pool → TimeoutException под нагрузкой

      IMemoryCache — включил и работает. Redis — нужно хотя бы пару статей прочитать про eviction и memory management.

1. 

   Pusk1

   27.09.2025 08:18

   #28889300

   Существует мнение, что для 90+% проектов можно обойтись без дополнительного кэширования. Postgre выдаёт десятки тысяч RPS на далеко не топовом железе, а средний слой часто намного менее прожорлив и легко горизонтально масштабируется. Неприменимо, если у вас 5 микросервисов выстроенных в ряд друг за другом.

1. 

   Allirey

   27.09.2025 08:18

   #28889422

   как раз вот postgres 18 вышел, с какими-то серьёзными улучшениями, так что нужны новые тесты.

1. 

   mr_bag

   27.09.2025 08:18

   #28889468

   Автор ТОЧНО понимает смысл кеширования? :)

1. 

   limejuice

   27.09.2025 08:18

   #28889824

   Чел у которого проекты не требуют кэша отказался от кэша.

1. 

   Politura

   27.09.2025 08:18

   #28890138

   А можно тот-же самый тест, но не на смешных 30млн записей в кэше, а хотя-бы на порядок увеличить? И еще, почему БД занят только обслуживанием кэша? Не порядок! Давайте параллельно в разные таблички еще писать/читать, всякие джойны делать по табличкам и тд. Ведь автор не хочет лишних зависимостей, хочет все в одной базе. Я даже согласен чтоб реплика на чтение была на отдельном серваке, все равно результаты простгреса будут смешные при таком сценарии.

   Для пет проекта можно что угодно делать, хоть в файлах все держать вместо СУБД. Для прода, с хорошей нагрузкой, надо все-таки думать как нагрузку снизить, иначе на операционных расходах можно деньги потратить с трудом заработанные.

   
   

   1. 

      Politura

      27.09.2025 08:18

      #28890506

      Только сейчас заметил, что в варианте Постгреса нет удаления. Видать с удалением результаты совсем проседают. Пишет, что если понадобится, будет удалять по крону... Как оно может НЕ понадобиться? Инвалидация кэша? Всегда растущая табличка? У каждого ключа вечно одно и то-же значение? Инвалидация кэша по крону? :)

   
   

   1. 

      Mausglov

      27.09.2025 08:18

      #28890554

      Смешных? На что вы их тратите, хотелось бы знать...

      
      

      1. 

         Politura

         27.09.2025 08:18

         #28890634

         Много активных пользователей, много серверов и много бизнеслогики. Тяжелые функции бизнес-логики народ любит кэшировать. При этом кэшируемые данные привязываются к какому-то объекту, при изменении которого данные в кэше должны сбрасываться.

1. 

   xadd

   27.09.2025 08:18

   #28890796

   Такой себе бенчмарк. Без prepare и с такими простыми запросами, там значительный ресурс cpu должен уходить на парсинг sql.

1. 

   melon

   27.09.2025 08:18

   #28890886

   Так Redis же однопоточный, поэтому и кушал только одно ядро в итоге. Попробуй valkey если хочешь утилизировать второе ядро и тогда отрыв будет ещё больше.

1. 

   SabMakc

   27.09.2025 08:18

   #28891716

   А потом оказывается, что для небольших (а то и для средних) приложений достаточно и SQLite...

1. 

   t0rr

   27.09.2025 08:18

   #28891940

   Первое, что бросилось в глаза - не учитывается нагрузка на постгрю в роли бд. Или под кэш отдельная СУБД будет?)

   Редис тем и хорош, что сопровождение его вообще не требуется - у меня есть инстансы, которые за 5 лет перезагружались только вместе с хостом. А на крайний случай, если что-то пошло не так - убил его нафиг и поднял новый.

1. 

   seekerhan

   27.09.2025 08:18

   #28894522

   Postgresql Просто для своей работы требует много ресурсов. Там же постоянно идут процессы сохранений на диск кеша базы в оперативной памяти. Вакуумы, аналайзы, другие внутренние процессы с перестроением индексов. Чтобы сравнение было честным. Нужно поднимать отдельную СУБД только с unlogged таблицами. И основную на другом сервере. Думаю, что при определенных условиях БД себя покажет лучше чем в этом тесте. Наверное, тут если не хватает производительности - нужно использовать redis, она сильно проще масштабируется. С кеш есть другие проблемы, связанные с целостностью данных, которые придётся решать дополнительно.