Типы хранения данных Crawlee: Набор данных, KVS, Очередь запросов
TL;DR
Crawlee использует три основные абстракции хранения: Dataset для записей результатов, ориентированных на добавление, KeyValueStore для именованных значений и артефактов, и RequestQueue для запланированных и дедублицированных запросов.
Именованное хранилище является более безопасным выбором, когда данные должны сохраняться между запусками;Unnamed default storage удобно для временных задач и может быть очищено при запуске.
Типы хранения должны соответствовать паттернам доступа, а не удобству. Смешивание состояния обхода, двоичных артефактов и строк результатов в одном хранилище усложняет повторные попытки и удержание.
Продуктивный краулер должен определить стабильные ключи записей, идемпотентные записи, удержание и восстановление перед масштабированием параллельности.
Nstdata Crawl может обеспечить управляемый уровень приобретения, в то время как хранилище Crawlee организует запросы, артефакты и принятые записи на стороне приложения.
Какие типы хранения данных в Crawlee?
Основные типы хранилища Crawlee - это Dataset, KeyValueStore и RequestQueue. Dataset хранит записи результатов, которые обычно добавляются во время обхода. KeyValueStore хранит значения, адресованные по ключам, включая конфигурацию, состояние обхода или более крупные артефакты. RequestQueue хранит URL-адреса или запросы для обработки и предотвращает дублирование запланированных задач в соответствии с правилами идентичности запросов в очереди.
Когда команде нужен управляемый уровень приобретения при сохранении своей модели хранения на стороне приложения, Nstdata Crawl может обеспечить уровень сбора страниц или ограниченных сайтов.
Официальное руководство по хранилищу Crawlee для Python различает интерфейсы хранения высокого уровня и клиентов хранения, которые сохраняют свои данные. JavaScript-версия использует то же концептуальное разделение, но командам следует читать документацию для выбранного языка и версии, а не предполагать, что API идентичны.
Попробуйте Nstproxy Crawl - Начните Бесплатно Уже Сегодня
Когда следует использовать Dataset?
Используйте Dataset для выходных данных краулера, ориентированных на добавление, которые следующему коду необходимо перебрать, экспортировать или анализировать. Примеры включают записи продуктов, метаданные статей, принятые результаты извлечения и измерения качества страниц. Каждая запись должна содержать достаточно информации о происхождении, чтобы быть самостоятельной: канонический URL, временная метка получения, статус, хеш-содержимое, версия схемы и результат проверки.
Dataset не является идеальным для изменяемого состояния синглтона или для многократного обновления большого артефакта под одним ключом. Если рабочий процесс требует сохранения последнего курсора, конфигурации или скриншота, KeyValueStore обычно является более ясной абстракцией. Если он нуждается в планировании URL с дедубликацией, RequestQueue является правильным выбором.
Когда следует использовать KeyValueStore?
Используйте KeyValueStore для значений, извлеченных по известному имени. Типичные примеры включают входящую конфигурацию, контрольную точку, снимок политики robots, скриншот, необработанный HTML или JSON-резюме выполнения. Ключ должен быть детерминированным и документированным, чтобы процесс восстановления мог его найти без сканирования несоответствующих записей.
KeyValueStore может содержать структурированные значения, но не должен становиться неиндексированной заменой набора результатов. Определите срок хранения отдельно для временных артефактов отладки и долговечного подтверждения соблюдения. Большие артефакты могут потребовать внешнего хранения объектов в зависимости от выбранного клиента хранения Crawlee и среды развертывания.
Когда следует использовать RequestQueue?
Используйте RequestQueue для запросов, которые краулер еще должен обработать. Очередь поддерживает открытие, приоритезацию и дедубликацию, позволяя краулеру добавлять ссылки без повторной обработки одного и того же запроса. Храните специфический для запроса контекст, такой как источник открытия, глубина, метка, количество повторных попыток и бизнес-идентификатор в данных пользователя запроса, где поддерживается задокументированное API.
Идентичность запроса требует преднамеренного дизайна. Порядок строки запроса, параметры отслеживания, фрагменты и канонические редиректы могут создать различные URL-адреса, представляющие одно и то же содержимое. Нормализуйте только те параметры, о которых известно, что они не изменяют ресурс. Слишком агрессивная нормализация может объединить страницы, которые должны оставаться раздельными.
Преобразуйте веб-страницы в пригодные для использования данные
Используйте Nstdata Crawl для преобразования URL в чистые выходные данные для ИИ, RAG и рабочих процессов данных.
Как различаются именованные и неименованные хранилища?
Именованное хранилище предназначено для обнаружения и повторного использования в разных запусках, в то время как неименованное или стандартное хранилище часто ограничено одним запуском и может быть очищено при запуске в соответствии с конфигурацией. Именованные хранилища подходят для запланированных задач, передачи, дополнения и отладки между перезапусками процессов. Неименованные хранилища удобны для тестов и временных запусков.
Точный жизненный цикл зависит от активного клиента хранилища и окружения. Подтвердите поведение очистки, прежде чем полагаться на стандартное хранилище для восстановления. официальное руководство по хранилищу результатов Crawlee для JavaScript документирует поведение локальной сохранности для этой реализации.
Для подробностей реализации и актуальных релизов используйте официальный репозиторий Crawlee, а не копируйте поведение хранилища из устаревшего учебника.
Как должны работать вместе три типа хранилищ?
Чистый дизайн использует RequestQueue для работы, KeyValueStore для состояния запуска и артефактов, а Dataset для принятия строк результатов. Это разделение делает восстановление понятным:
RequestQueue показывает, что ожидает, обрабатывается или подходит для повторной попытки.
KeyValueStore сохраняет конфигурацию, контрольные точки и диагностические артефакты.
Dataset содержит записи, которые соответствуют правилам приемки конвейера.
Не помещайте страницу в Dataset только потому, что запрос завершился. Сначала проверьте тип содержимого, канонический URL, обязательные поля и бизнес-правила. Отдельный набор данных отклоненных записей или диагностический ключ может сохранить ошибки, не загрязняя принятые данные.
Как сделать хранение Crawlee надежным в производстве?
Надежность начинается с идемпотентности. Назначьте стабильный бизнес-ключ или идентификатор документа, чтобы повторные попытки не приводили к неконтролируемым дубликатам. Храните хэш содержимого для обнаружения изменений. Версионируйте схему и конфигурацию краулера, чтобы запись могла быть интерпретирована после изменения кода.
Определите границы контрольных точек. Краулер должен знать, можно ли пометить запрос как обработанный до успешного хранения результата. Если сохранение результата не удалось после подтверждения запроса, конвейер может потерять данные. Используйте семантику ошибок и повторных попыток, задокументированные активным краулером и клиентом хранения.
Следите за глубиной очереди, самым старым ожидающим запросом, скоростью обработки, уровнем повторных попыток, ошибками записи в набор данных, размером артефакта и задержкой хранения. Руководство Nstdata по масштабированию веб-скрейпинга предоставляет более широкий операционный контекст, в то время как его руководство по веб-данным из трубопровода показывает, почему принятые бизнес-записи следует отделять от сырых загрузок.
Руководство по обнаружению URL веб-сайтов также полезно при принятии решения о том, какие открытия должны находиться в RequestQueue, а какие следует отклонить до планирования.
Как может работать Nstdata Crawl с хранилищем Crawlee?
Nstdata Crawl может служить в качестве управляемого сервиса получения, в то время как приложение Crawlee управляет собственной очередью, артефактами и записями результатов. Этот шаблон полезен, когда приложению требуется собственное планирование или бизнес-логика, но оно не хочет управлять каждым браузером и компонентом маршрутизации.
Разместите авторизованные целевые запросы и бизнес-контекст в RequestQueue.
Храните конфигурацию краулинга и диагностические артефакты в KeyValueStore.
Вызывайте управляемый уровень коллекции в пределах ограниченной параллельности.
Проверьте возвращаемую страницу или результат задачи.
Отправляйте только принятые, атрибутируемые записи в Dataset.
Используйте цены Nstdata Crawl, чтобы подтвердить текущую модель биллинга, и включите неудавшиеся или отклоненные страницы при расчете стоимости за принятую запись. Для текущего поведения продукта обратитесь к документации Nstdata Crawl.
Какие ошибки хранения вызывают наибольшие проблемы?
Распространенные ошибки включают в себя полагание на поведение очистки по умолчанию без его проверки, хранение крупных двоичных артефактов в качестве обычных строк результатов, подтверждение запросов до завершения записи долговременных результатов и использование сырых URL в качестве идентификаторов без канонизации. Другой частой проблемой является отсутствие версии схемы, что делает старые записи неоднозначными после развертывания.
Безопасность и конфиденциальность также применимы к хранению краулеров. Не размещайте учетные данные, файлы cookie аутентификации или конфиденциальные заголовки в пользовательских данных или логах RequestQueue. Минимизируйте личные данные, определите срок хранения и ограничьте доступ к артефактам, которые могут содержать конфиденциальное содержимое страниц.
Заключение
Типы хранилищ Crawlee просты, когда у каждого из них есть четко определенная ответственность: RequestQueue планирует работу, KeyValueStore хранит именованное состояние или артефакты, а Dataset хранит принятые строки. Определите жизненный цикл, идентичность и поведение при сбоях перед увеличением параллельности. Если браузеры и сеть представляют собой основную оперативную нагрузку, объедините хранилище Crawlee на стороне приложения с управляемым уровнем коллекции, таким как Nstdata Crawl, и сохраняйте контракт на прием в вашей системе.
Опыт Nstdata — начните бесплатную пробную версию сегодня
Три основных типа: Dataset, KeyValueStore и RequestQueue.
В: Какой тип хранения Crawlee должен хранить собранные записи?
Dataset обычно должен хранить записи, ориентированные на добавление, которые прошли валидацию.
В: Какой тип хранения Crawlee дублирует URL?
RequestQueue управляет запланированными запросами и устраняет дубликаты в соответствии с идентичностью запроса, используемой реализацией.
В: Являются ли хранилища по умолчанию персистентными?
Жизненный цикл по умолчанию зависит от клиента хранения и конфигурации очистки, поэтому командам необходимо проверить поведение при запуске перед тем, как полагаться на него для восстановления.
В: Может ли KeyValueStore хранить снимки экрана или сырой HTML?
Да, KeyValueStore подходит для именованных артефактов, при условии соблюдения возможностей и ограничений по размеру выбранного хранилища.
В: Как вы предотвращаете дублирование записей Dataset?
Используйте стабильные идентификаторы записей, канонические URL, хеши содержимого и идемпотентную бизнес-логику, а не полагайтесь только на поведение добавления записей Dataset.
Lena Zhou
Aug. 11th 2026
Сканируйте целые сайты одним API-запросом
Успешность 99,8% с рендерингом JavaScript
Получайте чистые данные для LLM в разных форматах
Преобразуйте любой сайт в Markdown, HTML, JSON, ссылки, PDF и другие форматы без управления инфраструктурой сканирования.
