На сегодня я вижу очень много разговоров о кэшах. Я понимаю когда было время php-подобных. Был коннект-дисконект. Эра pgbouncer-ов и redis-ов. Но сейчас у нас хорошие языки типа go, elexir, с++ и т.д. У нас персистентный пул коннектов. Почему все забывают что в самом ПГ, очень мощная система кэширования. Навряд ли вы сможете написать лучше кэш, чем это сделано в ПГ. В 99% вам просто нужно добавить необходимое количество ОЗУ и правильно конфигурировать ПГ. SSD диски сейчас коренным образом переломили ситуацию. А по цене они почти сравнялись с HDD(серверные варианты). Все эти пляски с бубном как правило возникают из-за того что непонимают внутреннего устройства ПГ. У нас ЭТП, пошли именно этим путем и пока все удачно. В проде уже 3 года.
Хорошее у тебя замечание. Но смотри, какая фишка. Тот же pgsql использует собственную внутреннюю реализацию кеша. Но все равно при каждом запросе у тебя будет выполняться анализ запроса. Если бы это выглядело схемой, то это выглядело примерно так с кешем в pgsql: клиент -> go-сервис -> pgsql -> go-сервис -> клиент А вот так бы, если у тебя кеш в go-сервисе: клиент -> go-сервис -> клиент Запроса в БД нет. Получения и маппинга данных тоже нет.
@@VITEK467 С этой точки зрения согласен. Так же еще кейс имеет место быть когда несколько инстансов бэкенда. Но в большинстве случаев это решается постгресом.) И не оспоримым плюсом является, то что с ПГ тебе не надо продумывать стратегию инвалидации кеша.
Спасибо! Прошу разобрать эту тему отдельно!
Отличный стиль повествования, доступно и понятно. Спасибо!)
Спасибо большое за информацию!
Спасибо за видео, было полезно!
Очень круто, но обещанной ссылки на гитхаб не вижу, точнее обновления в вашей репе :)
Супер! А маркдаун можно заполучить?
Прикрепите ссылку на git please
На сегодня я вижу очень много разговоров о кэшах. Я понимаю когда было время php-подобных. Был коннект-дисконект. Эра pgbouncer-ов и redis-ов. Но сейчас у нас хорошие языки типа go, elexir, с++ и т.д. У нас персистентный пул коннектов. Почему все забывают что в самом ПГ, очень мощная система кэширования. Навряд ли вы сможете написать лучше кэш, чем это сделано в ПГ. В 99% вам просто нужно добавить необходимое количество ОЗУ и правильно конфигурировать ПГ. SSD диски сейчас коренным образом переломили ситуацию. А по цене они почти сравнялись с HDD(серверные варианты). Все эти пляски с бубном как правило возникают из-за того что непонимают внутреннего устройства ПГ. У нас ЭТП, пошли именно этим путем и пока все удачно. В проде уже 3 года.
Что означает ПГ и ЭТП?
@@Max-nr1bv ПГ - postgres, ЭТП - электронная торговая площадка
Пг(pg) скорее всего постгрес,про этп также не понял
Хорошее у тебя замечание. Но смотри, какая фишка. Тот же pgsql использует собственную внутреннюю реализацию кеша. Но все равно при каждом запросе у тебя будет выполняться анализ запроса.
Если бы это выглядело схемой, то это выглядело примерно так с кешем в pgsql:
клиент -> go-сервис -> pgsql -> go-сервис -> клиент
А вот так бы, если у тебя кеш в go-сервисе:
клиент -> go-сервис -> клиент
Запроса в БД нет. Получения и маппинга данных тоже нет.
@@VITEK467 С этой точки зрения согласен. Так же еще кейс имеет место быть когда несколько инстансов бэкенда. Но в большинстве случаев это решается постгресом.) И не оспоримым плюсом является, то что с ПГ тебе не надо продумывать стратегию инвалидации кеша.