Comments 19
Шо с кешем, шо без - очень мало.
Нет пула соединений? Сам ab тормозит?
PostgreSQL тоже умеет читать из памяти. Разница в 7 раз говорит о том что у вас чтото ну очень сильно не так, например памяти pg не дали. Более того много однотипных запросов легко оптимизируются именованными подготовленными запросами, для которых прослойка еще меньше.
Тяжела и неказиста жизнь go программиста
Это не скалируемое решение
Пропущена тема негативного кеша.
В вашей реализации нагрузка на базу снижается только для адекватных запросов (с вашего фронта, например). Но ничего не мешает вычислить пулл id, которых нет в базе (ну и в кеше соответственно) и начать досить ваш бэкенд такими запросами, кеш мисс 100%, база по прежнему задыхается.
Все так или иначе в зависимости от объема данных к этому приходят... Не очень понятно кто ваш клиент API.
Вообще, можете пойти дальше и отдавать заголовок Last-Modified, хранить максимально легковесный кэш параллельно (ну, или повесить индекс и дергать БД по max(update_at), если оно того позволяет - это и сам постгрес закэширует на отлично).
Если ваш клиент бразуер - отлично, там браузер сам разберется что хакэшировать и какие заголовки вам отправить - просто напишите мидлварь с доступом к проверку свежести данных.
Если ваш клиент другой сервис... ну, мало кто это делает, но было бы не плохо написать и там немного кода, чтобы добавить заголовок с меткой времени.
эмммм.. Сколько у вас запросов, что Вам понадобился кзш?
Может что-то с архитектурой не так?
Наш род прошел миллионы лет эволюции, чтобы автор на хабре написал статью с кликбейтным названием, про то как обернул мапу в структуру с несколькими простейшими методами, а затем поставил тег "Высоконагруженные системы"
Когда я слышу рядом слова кэш и высоконагруженные системы я представляю себе, что то типа redis(или своей реализации от автора), которая держит какие то нереальные показатели. Или же работу с кэшем в распределнных системах(к примеру когда у тебя несколько инстансов и между ними синки)
Опять же я жду реальных метрик, а не аналитики уровня "Ну если у вас много запросов на одного юзера то кэш решит вашу проблему"
И при этом фиг бы с ним, можно пережить, если бы это была реальная реализация красивого кэша, начиная с того чем автор закончил, вплоть до того что автор написал в то, что можно улучшить. Но даже этого нет
Очередной болван дропнул какой то нейрослоп и доволен
Ребят, откуда столько отрицательных комментариев?
Автор написал максимально просто, даже context не использовал. Просто что бы показать концепцию. Вы же сразу закидали «грязными тряпками».
P.s. согласен что отношение к разработке моб. систем и к высоконагруженным тем более тут опосредованное.
Алгоритм действий при решении проблемы обычно один - найти тех, кто уже решал подобные проблемы. Тема кеша закрыта на 99%. Не привязываясь к языку и архитектуре видно, что автор пошел по неверному пути, что, в свою очередь, говорит о его уровне.
Как закрытие задачи для говнокурсов - ок, но в проде это использовать недопустимо, сразу куча проблем всплывёт. Начиная от разных данных в БД и кеше, заканчивая раздутием памяти инстансов.
Хз зачем вообще эта статья. Я писал когда-то на джанго, cache.get/set обычное дело если без сторонних зависимостей.
Я не знаю нюансов на go, но in-memory кеш для сервера уже звучит сомнительно. Разве что там точно один процесс все соединения обрабатывает. Но тогда про какую высоконагруженность идет речь?
Короче статья уровня "как я округлил число с помощью math.round", очень полезно и интересно (нет)
Кеш по времени такое себе решение. Кеш нужно чистить по изменению данных в БД.
Кеш хранить на сервисе тоже плохое решение, у каждого сервиса, если к примеру это кубер, будет иметь свой кеш. Поэтому использование редиса это необходимомомть , а не прихоть.
На мой взгляд решение как временная заплатка "сомнительно, но ОК". А так все делать по нормальному
В целом, писать свой кеш и добавлять его на уровне приложения нет никакой необходимости при использовании RESTful API. Собственно сам выбор типа API зачастую зависит от того - нужно ли простое кеширование или нет. REST API можно банально NGINXом кешировать это минут за 10 настраивается.
Люблю запах велосипедов по утрам. Однажды мы писали кэш на го вместо использования рэдис. И когда все закончилось я посмотрел на скорость запросов. Они ускорились в семь раз. Но запах! Весь код был им пропитан. Это был запах… велосипедов!
бытует мнение что если так никто не делает то это неспроста)
И снова велосипед и снова он кривой ... )
Я написал кэш для API на Go за 120 строк кода — и PostgreSQL перестал быть узким местом (ускорение в 7 раз)