PostgreSQL vs MongoDB: история одной замены
В первой версии проекта всё было «по-взрослому»: реляционная база данных PostgreSQL, таблица chat_history с чёткой структурой (id, user_message, assistant_response, model, created_at). Казалось бы, что может быть надёжнее? Но я понял, что переход на MongoDB способен значительно улучшить производительность при работе с большими текстами, но с определёнными оговорками. Для нашего случая, когда проблема именно в сохранении больших ответов от LLM, MongoDB предлагает более прямое и эффективное решение. Дальше опишу ключевые различия PostgreSQL и MongoDB при работе с текстами. Понимание того, как каждая база данных обрабатывает большие данные, поможет увидеть, где можно выиграть в производительности.
PostgreSQL
- Механизм хранения. Использует TOAST (The Oversized-Attribute Storage Technique). Когда текст превышает ~2 КБ, он автоматически сжимается и перемещается в отдельные служебные TOAST-таблицы. В основной таблице остаётся только указатель.
- Накладные расходы. TOAST — это мощный, но тяжёлый механизм. Он требует дополнительных операций сжатия/распаковки и чтения из нескольких таблиц, что создаёт нагрузку на процессор и дисковую систему.
- Производительность при работе с большими текстами. Падает по мере разрастания текста. Производительность PostgreSQL ухудшается, как только в дело вступает TOAST (после 2 КБ).
- Лимиты. До 1 ГБ на колонку (конечно, не критично для нашего кейса).
- Обновления. PostgreSQL работает неэффективно — перезаписывает весь объект, а не только изменения.
MongoDB
- Механизм хранения. Хранит данные в бинарном формате BSON как единые, самодостаточные документы. В нашем случае это означает, что весь диалог (история + новый ответ) может быть одним документом.
- Накладные расходы. Отсутствует аналог TOAST. Чтение документа — это, как правило, одна операция ввода-вывода. Это упрощает работу и снижает нагрузку.
- Предсказуемая производительность при работе с большими текстами, пока документ не превышает лимит. MongoDB изначально проектировалась для работы с большими объёмами данных в одном документе.
- Лимиты. До 16 МБ на документ. Для подавляющего большинства диалогов с LLM этого более чем достаточно.
- Обновления. Позволяет эффективно обновлять часть документа (например, добавлять новое сообщение), не перезаписывая его целиком.
Что даст замена базы данных? Скорость записи и чтения станет выше. PostgreSQL режет большой ответ на чанки, сжимает их и раскладывает по TOAST-таблицам, а потом собирает его из разных частей. MongoDB просто сохранит диалог как единое целое. Это особенно заметно на больших объёмах данных. Благодаря этому код и вообще логика приложения станет проще, ведь не нужно думать о транзакциях для обновления диалога. Вся история — это один документ.
Что ещё важно: MongoDB в шесть раз эффективнее использует дисковое пространство при работе с JSON по сравнению с PostgreSQL. Нагрузка на процессор также будет ниже, так как не нужно постоянно сжимать и распаковывать большие объёмы текста.
Да, у MongoDB есть и ограничения, но они не так уж критичны для нашего конкретного проекта:
- Лимит. 16 МБ — это не так уж и мало, их хватит для хранения огромной истории переписки. Говорят, что все тексты Вильяма Шекспира в текстовом формате занимают около 5,5 МБ.
- Фрагментация. При интенсивной вставке и удалении очень больших документов (близких к лимиту) может возникать фрагментация дискового пространства. Однако судя по нашей архитектуре и тому, что я хочу получить, скорее всего, буду дополнять существующие документы, а не перезаписывать их целиком, так что эта проблема вряд ли нам грозит.
- Поиск по тексту. Если мне понадобится полнотекстовый поиск по ответам модели, MongoDB предоставит мощные инструменты (Atlas Search), построенные на Apache Lucene. Это эффективнее, чем LIKE-запросы в PostgreSQL.
Какую проблему решила замена БД
Естественной единицей информации в нашем приложении является не отдельное сообщение, а сессия чата (диалог). Пользователь общается с ассистентом, сообщения идут друг за другом, и для контекста нам нужно хранить их последовательно.
В реляционной модели мы вынуждены хранить каждое сообщение отдельной строкой в таблице chat_history, связывая их через session_id. Это работало, но выглядело как натягивание совы на глобус, плюс длинные тексты обрабатываются достаточно долго. Каждый запрос на получение истории требовал сборки диалога по кусочкам, что усложняло код.
sql
-- Было: каждое сообщение отдельной строкой
SELECT * FROM chat_history WHERE session_id = ? ORDER BY created_at;
MongoDB предложила гораздо более элегантное решение. Теперь одна сессия чата — это один документ в коллекции chat_sessions. Внутри документа — массив messages, где каждое сообщение хранится как вложенный документ со своим role (user/assistant), content и timestamp.
Взгляните на новую модель ChatHistory:
java
@Data
@NoArgsConstructor
@Document(collection = "chat_sessions")
public class ChatHistory {
@Id
private String id;
@Indexed(unique = true)
private String sessionId;
private List<ChatMessage> messages = new ArrayList<>(); // Вот оно!
private String model;
private LocalDateTime createdAt;
private LocalDateTime lastUpdatedAt;
@Data
@NoArgsConstructor
public static class ChatMessage {
private String role;
private String content;
private LocalDateTime timestamp;
}
// Вспомогательные методы для работы с сообщениями
public void addUserMessage(String content) { ... }
public void addAssistantMessage(String content) { ... }
}
Это не просто изменение схемы, это изменение парадигмы: теперь мы получаем сессию целиком. Один запрос к базе — и у меня в руках готовый объект ChatHistory со всей историей диалога. А методы addUserMessage и addAssistantMessage инкапсулируют логику добавления нового сообщения в массив и обновления времени.
Код сервиса стал чище и понятнее. Теперь я не собираю историю по кусочкам, а просто работаю с цельным объектом.
java
// Стало: получаем всю сессию и работаем с её массивом сообщений
ChatHistory session = getOrCreateSession(request.getSessionId(), request.getModel());
List<ChatHistory.ChatMessage> historyMessages = session.getLastMessages(MAX_HISTORY_MESSAGES);
// ... формируем запрос к API, добавляя сообщения из historyMessages
Конечно, я понимаю, что NoSQL — не серебряная пуля, но для сценария «документоориентированного» чата это решение кажется на удивление удачным и естественным.
Боремся с «тугодумством» и оптимизируем фронтенд
Вторая проблема проявилась, когда я начал активно тестировать проект с длинными промтами и ответами от LLM. Фронтенд на React начинал заметно подтормаживать, а иногда и вовсе зависать на несколько секунд. В чём же дело?
Каждый новый чанк вызывал обновление состояния messages в компоненте Chat. Это, в свою очередь, приводило к полному перерендеру всего дерева компонентов, включая MessageList и все дочерние сообщения. При длинном ответе, состоящем из тысяч чанков, React просто не успевал перерисовывать интерфейс 60 раз в секунду.
Решение 1: мемоизация с React.memo и useCallback
Первым делом применил стандартные, но очень эффективные инструменты React:
React.memo для компонентов. Обернуть компоненты MessageList и ModelSelector в React.memo. Это говорит React: «Перерисовывай меня только тогда, когда изменились мои props».
typescript
// frontend/src/components/MessageList.tsx
export default React.memo(MessageList);
// frontend/src/components/ModelSelector.tsx
export default React.memo(ModelSelector);
useCallback для функций. Все функции, передаваемые как props дочерним компонентам (например, onPromptGenerated, clearHistory), обернуть в useCallback. Это гарантирует, что ссылка на функцию не будет меняться при каждом рендере родителя и React.memo сможет корректно отработать.
typescript
// frontend/src/components/Chat.tsx
const clearHistory = useCallback(async () => { ... }, [sessionId, generateSessionId]);
const handlePromptGenerated = useCallback((prompt: string) => { ... }, []);
Решение 2: мемоизация значений с useMemo
Следующим шагом стала мемоизация тяжёлых вычислений. Самый показательный пример — рендер списка сообщений. Вместо того чтобы на каждом обновлении пробегаться по массиву messages и генерировать JSX, делаем это только при изменении самих сообщений или состояния expandedMessages.
typescript
// frontend/src/components/MessageList.tsx
const messageElements = useMemo(() => {
return messages.map((message) => {
// ... генерация JSX для каждого сообщения
});
}, [messages, expandedMessages, formatMessage]); // Пересоздаём только при изменении этих зависимостей
Решение 3: дебаунсинг сохранения в localStorage
Сохранение истории в localStorage — операция небыстрая и синхронная. Делать её после каждого чанка было бы самоубийством. Я применил простой дебаунсинг с setTimeout. Сохранение происходит только через 500 миллисекунд после того, как пользователь перестал печатать или стрим завершил отправку чанков.
typescript
useEffect(() => {
if (messages.length > 0) {
const timeoutId = setTimeout(() => {
saveMessagesToStorage(messages);
}, 500);
return () => clearTimeout(timeoutId);
}
}, [messages, saveMessagesToStorage]);
Эти нехитрые, но важные оптимизации полностью решили проблему с зависаниями. Интерфейс снова стал отзывчивым и плавным, даже когда ассистент выдавал многотысячные токены кода.
ИИ-анализ проекта, или как загружать код на ревью с умом
Самая интересная новая фича — это возможность загрузить папку с проектом и попросить ИИ проанализировать код. Но просто загрузить все файлы подряд — плохая идея. В папке node_modules могут быть тысячи файлов, а бинарники вроде картинок нам вообще не нужны.
Первое, что я сделал, — научил фронт читать и парсить файл .gitignore. Если он есть в загружаемом проекте, я создаю парсер, который понимает его правила. Это позволяет на лету отфильтровывать те файлы и папки, которые разработчик и так не хочет видеть в репозитории.
typescript
// Упрощённая версия класса-парсера
class GitIgnoreParser {
// ...
shouldIgnore(filePath: string): boolean {
// Сначала проверяем правила исключений (!)
// Потом проверяем основные паттерны
// ...
}
}
Затем реализовал свой чёрный список (DEFAULT_IGNORE_PATTERNS). В него попали:
- системные файлы:
.DS_Store,Thumbs.db; - папки зависимостей:
node_modules/,vendor/,target/; - папки сборки:
dist/,build/,.next/; - любые бинарники: картинки, видео, архивы, исполняемые файлы;
- файлы-блокировщики:
package-lock.json,yarn.lock(обычно они огромны и не несут смысла для анализа); - слишком большие файлы: установил лимит в 5 МБ на файл.
Наконец, добавил удобный интерфейс. После выбора папки пользователь видит красивое дерево файлов, где можно выбирать отдельные файлы или целые директории для анализа. Интерфейс показывает частичный выбор в папках (то самое неопределённое состояние чекбокса), размер файлов и их язык. Снизу отображается статистика по выбранным файлам и редактируемый шаблон промта, в который можно вставить как структуру проекта, так и содержимое выбранных файлов.
typescript
const generatePrompt = () => {
let prompt = promptTemplate;
if (includeFileTree) {
const treeLines = generateFileTreeText(fileTree);
prompt = prompt.replace('{{FILE_TREE}}', `Структура проекта:n${treeLines.join('n')}n`);
}
prompt = prompt.replace('{{FILE_CONTENTS}}', generateSelectedFileContents());
onPromptGenerated(prompt);
};
Нажатие кнопки «Создать промт» вставляет готовый текст в поле ввода, и можно сразу отправлять запрос ИИ на анализ своего кода. Мечта любого разработчика, который хочет получить ревью от нейросети, не копируя файлы вручную.
Заключение
Проект продолжает развиваться. Была заменена неудобная реляционная модель на естественную документную, интерфейс стал отзывчивым даже при самых «разговорчивых» нейросетях, и добавлена киллер-фича для анализа кода.
Что дальше? В планах — поддержка системных промтов, возможность сравнивать ответы разных моделей на один запрос и, конечно, исправление новых багов, которые обязательно появятся. Жду ваших звёздочек и пул-реквестов на GitVerse в ветке proj-selector!
