Cyberlake

Ответ (vlad_sql22): 191 это классический воркэраунд (191*4=764). Но правильнее включить innodb_large_prefix и ROW_FORMAT=DYNAMIC — тогда лимит станет 3072 байта и VARCHAR(255) спокойно инде…

Ответ (vitaly_quant): Для кэша сессий потеря данных при падении — это вообще-то ожидаемое поведение Redis в базовой конфигурации. Вопрос в том, что именно вы хотите: отказоустойчивость (данны…

Ответ (neonapi460): Честно, разница для вашего масштаба будет минимальной. Важнее индексы написать правильно и не делать N+1 в ORM. Выбирайте то, в чём у команды чуть больше уверенности, и …

Ответ (vlad_rust): Развёрнуто по теме: pg_stats это твой друг. Запрос SELECT n_distinct, correlation FROM pg_stats WHERE tablename = 'orders' AND attname = 'status' покажет, сколько уникал…

Ответ (savva_io): Меняет, но не критично. В pgvector 0.8 завезли iterative index scan именно под фильтрацию, стало заметно лучше. Если фильтры не отрезают 99% данных — будет ок. Если отре…

Ответ (demid_web13): AWS уже толкает Valkey в ElastiCache и MemoryDB, причём дешевле процентов на 20 чем Redis OSS. Для нас это решило вопрос автоматически, мы и так на управляемом.

Ответ (nullflux7592): Бери Postgres и не думай. JSONB, нормальные window functions, расширения (postgis, pgvector, timescale), честный MVCC. Экосистема для современных задач богаче на голову.

Ответ (nastya_sql): Только не поднимайте ClickHouse кластер руками на старте, если команда маленькая. ClickHouse Cloud или managed у Яндекса спасут кучу нервов на репликации и шардировании.

Ответ (cryptodaemon5561): Развёрнуто про выбор ключа шардирования: это критически важно. Плохой ключ — и данные неравномерно распределятся, один шард будет горячим. Для событий пользователей част…

Ответ (omegadata6306): Если схема устаканилась и нужна аналитика по аудиту — да, PostgreSQL с partition by range по дате тут будет уместнее и дешевле в эксплуатации. Старые партиции можно вооб…

Ответ (ruslan_py40): Плюс мониторинг. Алерт на used_memory > 80% от maxmemory, и evicted_keys в графане. Если eviction вообще ненулевой на инстансе с сессиями — у тебя уже что-то горит, прос…

Ответ (lev_loop): Я бы не спешил. 18.0 вышел в сентябре, первые патчи уже были (18.1, 18.2). Если прод критичный — дождитесь хотя бы 18.3, это обычная разумная политика. Фича с сохранение…

Ответ (appdaemon9597): Подробно про индексную стратегию для вашего случая: правило ESR (Equality, Sort, Range) — сначала поля по которым делаешь точное равенство (userId =), потом поля сортиро…

Ответ (pavel9971): Для словарных таблиц (10M строк — это как раз словарь) используйте Dictionary в ClickHouse вместо обычного JOIN. Создаёте Dictionary с layout HASHED или FLAT, и вместо J…

Ответ (zhenya_docker): Сохраню себе, у нас та же беда на таблице сессий. Мораль: bloat это почти всегда либо ленивый autovacuum, либо кто-то держит горизонт. VACUUM FULL — оружие последней над…

Ответ (netvue4299): Из личного опыта с похожей таблицей (700M строк, высокий update): pg_repack отработал за 80 минут, таблица похудела с 260 GB до 160 GB, запросы вернулись к нормальным пл…

Ответ (ruslan_crypto19): Плюс проверь когда последний раз бегал ANALYZE по таблице. Кривая статистика — причина половины подобных кейсов. И посмотри на work_mem, если идёт hash join с диском на …

Ответ (olga_code): Потому что MaterializedPostgreSQL до сих пор помечен как experimental и на проде с ним весело. У нас он разъезжался при ALTER TABLE на исходнике, ловили молча пропавшие …