Как я сделал mmap-базу для 4 миллионов товаров и 700 тысяч посадочных страниц

В сфере искусственного интеллекта произошло заметное событие. ihar76 22 минуты назад Как я сделал mmap-базу для 4 миллионов товаров и 700 тысяч посадочных страниц Сложный 13 мин 586 Go * Разработка под e-commerce * Высоконагруженные системы * Мнение Из песочницы И почему самым неожиданным bottleneck оказался не поиск, не индексы и даже не база данных, а JSONЕсть проекты, которые начинаются с требования бизнеса. А есть проекты, которые начинаются с совершенно другого вопроса:А насколько далеко можно зайти, если убрать из системы всё лишнее? У меня получился второй вариант.

Есть интернет-магазин примерно с четырьмя миллионами товаров и сотнями тысяч посадочных страниц. На сайте есть фильтры, сортировки, пагинация и довольно большой набор URL, которые постоянно нужно обслуживать. Основная нагрузка при этом — чтение.

Технические детали

Сам характер запросов достаточно предсказуем. Нужно получить страницу магазина или категории, открыть посадочную страницу, применить несколько фильтров, пересечь условия, ограничить диапазон цены, отсортировать результаты и вернуть первые 20–60 товаров. В какой-то момент я решил не пытаться оптимизировать традиционную архитектуру по отдельности, а посмотреть, сколько вообще можно из неё убрать.

Так появились Makodb — mmap-based KV DB с индексами — и затем SilentJSON, специализированный JSON serializer/parser, построенный вокруг той же идеи: если структура данных и модель доступа известны заранее, не нужно каждый раз платить за универсальность. Это не попытка сделать новую PostgreSQL. Это очень специализированное хранилище под очень конкретный класс нагрузки.

Всё началось с довольно простой идеиЕсли у меня есть четыре миллиона товаров, мне не обязательно каждый раз прогонять запрос через всю привычную цепочку:HTTP -> application -> ORM -> SQL -> query planner -> index -> rows -> objects -> interfaces -> JSON -> HTTP Можно попробовать сделать путь значительно короче:HTTP -> индексы -> docID -> mmap -> готовые данные -> JSON -> HTTP Вторая схема выглядит даже скучно. И именно поэтому она мне понравилась. Почему не SQLСразу оговорюсь: я не считаю SQL плохим решением.

Отраслевые последствия

Если приложению нужны транзакции, сложные JOIN, произвольные запросы, аналитика, конкурентные записи и богатая семантика данных, я бы не стал писать такую систему самостоятельно. Но мой workload совсем другой. Я почти всегда заранее знаю, что именно нужно найти.

Например, запрос вида:category = 123 AND brand = 42 AND price >= 500 AND price <= 5000 ORDER BY price LIMIT 60 не обязательно превращать в универсальный SQL-запрос. Если структура запросов известна, часть работы можно сделать заранее. У меня есть отдельные индексы категории, бренда, цены и сортировки.

Категория может быть представлена как массив docID, бренд — ещё одним массивом, а цена — отсортированным числовым индексом. Дальше задача сводится к пересечениям этих структур.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.