[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-data-retention-policy::ru":3,"gloss-cluster-data-retention-policy::ru":20,"gloss-next-data-retention-policy::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"data-retention-policy","data-infra","Политика хранения данных","Политика хранения данных — это определённый, обычно автоматизированный набор правил, устанавливающий, как долго различные категории данных хранятся, прежде чем быть перенесёнными в более дешёвое хранилище или окончательно удалёнными, вместо того чтобы накапливаться бесконечно по умолчанию. Почему это важно для разработчиков AI\u002FSaaS-продуктов: политика хранения находится на пересечении контроля затрат, комплаенса и доверия к продукту — неограниченный рост данных незаметно раздувает затраты на хранение и (для всего, что индексируется, например векторных эмбеддингов) на запросы со временем; такие регуляции, как GDPR, предоставляют пользователям законное право на удаление своих персональных данных по запросу, и продукт должен быть технически способен это выполнить, а не просто обещать; а специфичные для AI категории данных — сырые промпты\u002Fcompletion'ы LLM, потенциально содержащие чувствительный пользовательский ввод, загруженные документы, поданные в RAG-пайплайны, сгенерированные изображения\u002Fаудио — часто несут обязательства по хранению или ожидания пользователей, существенно отличающиеся от обычных логов приложения компании. Проектировать политику хранения постфактум, когда за годы неструктурированные данные накопились в десятке систем без чёткого владения, — существенно более сложная задача, чем закладывать её с самого начала. Как это работает: правила хранения обычно реализуются через сочетание политик жизненного цикла объектного хранилища (автоудаление или автопереход в другой класс хранения объектов старше N дней — механизм, описанный в разделе про объектное хранилище\u002FS3), запланированных задач базы данных, которые удаляют или архивируют старые строки по истечении заданного TTL, и — критически важно для комплаенса — определённого процесса каскадного распространения запроса на удаление по всем системам, хранящим копию данных пользователя, включая производные данные вроде векторных эмбеддингов, сгенерированных из его документов, закэшированных ответов LLM, содержащих его ввод, и любых резервных копий. Важный и распространённый нюанс: «удалить строку пользователя» — не то же самое, что «удалить данные пользователя» в системе, где векторный поиск, кэширование и резервные копии потенциально хранят независимые копии или производные исходного контента — по-настоящему GDPR-совместимый процесс удаления должен учитывать всё это, а не только основную запись в базе данных. Практический пример: AI-SaaS определяет политику хранения, где сырые загруженные документы удаляются из объектного хранилища через 30 дней после отмены подписки, сгенерированные AI-результаты хранятся 1 год для справки клиента, и — что критически важно — запрос «удалить мой аккаунт» запускает каскадную задачу, которая удаляет строку пользователя, его документы из S3, его эмбеддинги из пространства имён векторного хранилища и очищает любые закэшированные ответы LLM, привязанные к его контенту, причём весь этот каскад логируется для целей комплаенс-аудита, вместо того чтобы полагаться на единственный оператор `DELETE`, затрагивающий только основную таблицу базы данных.","Политика хранения данных определяет, как долго разные типы данных хранятся, прежде чем автоматически архивироваться или удаляться навсегда.",null,[11,14,17],{"slug":12,"name":13},"multi-tenancy","Мультиарендность (Multi-Tenancy)",{"slug":15,"name":16},"object-storage","Объектное хранилище (Object Storage)",{"slug":18,"name":19},"s3","S3",[21,25,28,31,34,38,41,44,47,50,54,57],{"slug":22,"category":5,"name":23,"updated_at":24},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ann-search","ANN-поиск (приближённый поиск ближайших соседей)",{"slug":29,"category":5,"name":30,"updated_at":24},"backpressure","Обратное давление (backpressure)",{"slug":32,"category":5,"name":33,"updated_at":24},"batch-processing","Пакетная обработка (Batch Processing)",{"slug":35,"category":5,"name":36,"updated_at":37},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":39,"category":5,"name":40,"updated_at":24},"cache","Кэш (Cache)",{"slug":42,"category":5,"name":43,"updated_at":24},"cap-theorem","Теорема CAP (CAP theorem)",{"slug":45,"category":5,"name":46,"updated_at":24},"change-data-capture","Захват изменений данных (CDC)",{"slug":48,"category":5,"name":49,"updated_at":24},"chroma","Chroma",{"slug":51,"category":5,"name":52,"updated_at":53},"chunk-overlap","Перекрытие фрагментов","2026-08-24T03:30:02+00:00",{"slug":55,"category":5,"name":56,"updated_at":24},"columnar-storage","Колоночное хранение",{"slug":58,"category":5,"name":59,"updated_at":24},"connection-pooling","Пулинг соединений (Connection Pooling)"]