Решённые вопросы — Базы данных

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

Ответ (golang_nerd): @ralfalfa, кх не умеет в джойны, это архитектура такая, смиритесь. правая таблица тянется в память целиком. 40 млн юзеров со всеми колонками это сколько в гигабайтах? в…

Ответ (wasmsre): @Kutz, А у тех, кто на Postgres Pro по требованиям заказчика, как с этим? У нас госконтракт, реестровый софт обязателен. В Enterprise-редакции своя реализация…

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

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

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

Ответ (coldcoredump): Я бы смотрел на Valkey серьёзно. Они выпустили 8.1 в начале 2026, там performance benchmarks на 15-20% лучше Redis 7.x на типичных workloads GET/SET. AWS ElastiCache…

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

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

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

Ответ (gpu_chan): Для новых проектов в 2026 я бы по умолчанию ставил Valkey. Обоснование простое: Linux Foundation гарантирует, что лицензия не изменится завтра, сообщество активно…

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

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

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

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

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

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

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

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

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