[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-upsert::ru":3,"gloss-cluster-upsert::ru":26,"gloss-next-upsert::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"upsert","data-infra","Upsert (вставка или обновление)","Upsert записывает строку, если её нет, и обновляет, если она есть, — одним оператором. Базы называют это по-разному: INSERT ... ON CONFLICT, MERGE, INSERT ... ON DUPLICATE KEY UPDATE, — но смысл один: сделать запись идемпотентной относительно ключа, чтобы повторение приводило к тому же конечному состоянию, а не к дубликату строки или ошибке. Именно поэтому upsert лежит в основании конвейеров данных и интеграций. Синхронизация, перечитывающая источник; потребитель вебхуков, который может получить одно событие дважды; пакетная задача, перезапущенная после частичного сбоя, — все они безопасны, если запись идёт по ключу и идемпотентна, и все они плодят дубликаты, если нет. Та же логика работает для ночной загрузки, намеренно перекрывающей предыдущее окно, — стандартный способ пережить опоздавшие записи. Поведение upsert определяют две детали. Нужен настоящий уникальный индекс по ключу конфликта: без него базе не с чем сверяться, а логика «проверить и вставить» на уровне приложения проигрывает гонку при конкурентности. И ветка обновления обязана явно перечислить перезаписываемые столбцы: слепая замена всех колонок затрёт поля, о которых источник не знает, — локально вычисленный статус или значение, которым владеет другая система. Массовые upsert дороже обычных вставок из-за обращений к индексам, поэтому объёмные загрузки иногда сначала складывают во временную таблицу и сливают один раз.","Upsert вставляет или обновляет одним идемпотентным оператором по ключу: почему на нём держатся конвейеры и что ломает отсутствие уникального индекса.",null,[11,14,17,20,23],{"slug":12,"name":13},"change-data-capture","Захват изменений данных (CDC)",{"slug":15,"name":16},"database-migration","Миграция базы данных",{"slug":18,"name":19},"delivery-semantics","Семантика доставки (delivery semantics)",{"slug":21,"name":22},"etl","ETL (извлечение, трансформация, загрузка)",{"slug":24,"name":25},"idempotency","Идемпотентность (Idempotency)",[27,31,34,37,40,44,47,50,51,54,58,61],{"slug":28,"category":5,"name":29,"updated_at":30},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"ann-search","ANN-поиск (приближённый поиск ближайших соседей)",{"slug":35,"category":5,"name":36,"updated_at":30},"backpressure","Обратное давление (backpressure)",{"slug":38,"category":5,"name":39,"updated_at":30},"batch-processing","Пакетная обработка (Batch Processing)",{"slug":41,"category":5,"name":42,"updated_at":43},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":45,"category":5,"name":46,"updated_at":30},"cache","Кэш (Cache)",{"slug":48,"category":5,"name":49,"updated_at":30},"cap-theorem","Теорема CAP (CAP theorem)",{"slug":12,"category":5,"name":13,"updated_at":30},{"slug":52,"category":5,"name":53,"updated_at":30},"chroma","Chroma",{"slug":55,"category":5,"name":56,"updated_at":57},"chunk-overlap","Перекрытие фрагментов","2026-08-24T03:30:02+00:00",{"slug":59,"category":5,"name":60,"updated_at":30},"columnar-storage","Колоночное хранение",{"slug":62,"category":5,"name":63,"updated_at":30},"connection-pooling","Пулинг соединений (Connection Pooling)"]