Какие варианты хранения данных подходят для базы вопросов и ответов
Что проверяют
Умеете ли вы выбирать хранилище от сценариев, а не от моды: как база будет искать, кто её читает и какого она размера. Для ML-инженера следом почти всегда идёт вопрос про поиск похожих вопросов и RAG: где хранить эмбеддинги и как их обновлять.
Как отвечать
Сначала уточните сценарии: точный поиск по тегам, полнотекстовый, семантический, выгрузка датасетов для обучения. Потом разложите хранилища по ролям:
- PostgreSQL как источник истины: вопросы, ответы, теги, авторы, голоса, связи и транзакции. Метаданные с гибкой структурой ложатся в
jsonb, полнотекстовый поиск черезtsvectorи GIN-индекс, нечёткий черезpg_trgm; - pgvector: эмбеддинги в той же базе, индекс HNSW или IVFFlat, поиск ближайших соседей с фильтрами обычным SQL. На сотнях тысяч и миллионах векторов этого обычно хватает;
- отдельная векторная база (Qdrant, Milvus, Weaviate): когда векторов десятки миллионов, нужен шардинг или сложная фильтрация под нагрузкой;
- Elasticsearch или OpenSearch: BM25, морфология русского языка, гибридный поиск вместе с векторами. Это индекс, который строится из основной базы, а не место хранения;
- объектное хранилище и Parquet: снимки для обучения и оценки моделей, версионирование через DVC, Delta Lake или Iceberg;
- Redis: кэш популярных ответов, не хранилище.
Главный тезис: за правду отвечает одна база, всё остальное производное и пересобирается из неё. Для эмбеддингов храните имя и версию модели: при смене модели векторы пересчитываются целиком, смешивать старые и новые нельзя.
Где спотыкаются
Выбирают MongoDB или Cassandra «ради масштабируемости» для базы на сто тысяч вопросов. Реляционная база справится и сохранит связи между вопросами, ответами и голосами.
Кладут всё только в векторную базу. Нет транзакций и удобных связей, а исходные тексты живут лишь в полезной нагрузке векторов.
Забывают, что семантический поиск плохо находит точные термины и коды ошибок. Для базы вопросов почти всегда нужен гибридный поиск: BM25 плюс векторы.