---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://ydb.tech/docs/ru/public-materials/publications/2026.md?version=main
sourcePath: ru/core/public-materials/publications/2026.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt

# Статьи 2026

## Миллиард записей и 8 Марта: как YDB спас праздник

<!-- source: ru/public-materials/_includes/tags.md -->
 <span class = "practice-tag tags-shape tags-color-text"> Practice </span>
<!-- endsource: ru/public-materials/_includes/tags.md -->

![](./_assets/2026/milliard-ydb.jpeg =700x400)

В [статье](https://habr.com/ru/companies/yandex/articles/1014784/) рассматривается процесс переработки системы синхронизации складских остатков и цен в ритейле Яндекс Еды: от порядка миллиарда строк на старте проекта до нескольких миллиардов записей о ценах и стоках на проде, и переход от кеша на PostgreSQL с периодическими тяжёлыми JSON-выгрузками от партнёров к распределённому хранилищу на YDB с топиками брокера сообщений, командами PATCH/SAVE и protobuf в колонке данных. Автор показывает, почему полные JSON-снимки и перезапись больших фрагментов в базе перестали масштабироваться, и как их заменили на поток изменений и дельты: зачем вместо широких таблиц и JSON взяли protobuf, как батчировать сообщения для брокера, как устроено наложение патчей и какие сроки актуализации данных требуют витрина, поиск и операционные сценарии вроде заказов к праздникам.

Статья будет полезна для специалистов, которые проектируют или эксплуатируют высоконагруженные системы с большим объёмом данных, а также сталкиваются с миграцией с монолита и тяжёлых SQL/JSON-решений к распределённым хранилищам, таким как YDB. В материале показано сравнение подходов «до» и «после» и обоснование ключевых инженерных решений.
