Các loại lưu trữ dữ liệu Crawlee: Tập dữ liệu, KVS, Hàng đợi yêu cầu
TL;DR
Crawlee sử dụng ba trừu tượng lưu trữ chính: Dataset cho các bản ghi kết quả theo hướng bổ sung, KeyValueStore cho các giá trị và hiện vật được đặt tên, và RequestQueue cho các yêu cầu đã lên lịch và loại trừ trùng lặp.
Lưu trữ có tên là lựa chọn an toàn hơn khi dữ liệu phải còn lại qua các lần chạy; lưu trữ mặc định không có tên thì thuận tiện cho các công việc tạm thời và có thể bị xóa khi khởi động.
Các loại lưu trữ nên tuân theo các mẫu truy cập, không phải sự tiện lợi. Kết hợp trạng thái thu thập, hiện vật nhị phân và các hàng kết quả trong một kho lưu trữ làm cho việc thử lại và lưu giữ trở nên khó khăn hơn.
Một trình thu thập dữ liệu sản xuất nên xác định các khóa bản ghi ổn định, việc ghi không thay đổi, lưu giữ và phục hồi trước khi mở rộng đồng thời.
Nstdata Crawl có thể cung cấp lớp thu thập quản lý trong khi lưu trữ Crawlee tổ chức các yêu cầu bên ứng dụng, hiện vật và các bản ghi đã được chấp nhận.
Các loại lưu trữ dữ liệu Crawlee là gì?
Các loại lưu trữ chính của Crawlee là Dataset, KeyValueStore và RequestQueue. Một Dataset lưu trữ các bản ghi kết quả thường được bổ sung trong quá trình thu thập. Một KeyValueStore lưu trữ các giá trị được truy cập bằng các khóa, bao gồm cấu hình, trạng thái thu thập hoặc các hiện vật lớn hơn. Một RequestQueue lưu trữ các URL hoặc yêu cầu để xử lý và ngăn chặn việc lên lịch trùng lặp theo quy tắc danh tính yêu cầu của hàng đợi.
Khi một nhóm muốn có sự thu thập quản lý trong khi duy trì mô hình lưu trữ bên ứng dụng riêng của mình, Nstdata Crawl có thể cung cấp lớp thu thập trang hoặc trang web theo giới hạn.
hướng dẫn lưu trữ chính thức của Crawlee cho Python phân biệt các giao diện lưu trữ cấp cao với các khách hàng lưu trữ mà lưu giữ dữ liệu của họ. Triển khai JavaScript sử dụng cùng một sự phân tách khái niệm, nhưng các nhóm nên đọc tài liệu cho ngôn ngữ và phiên bản mà họ đã chọn thay vì giả định rằng các API là giống nhau.
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Sử dụng Dataset cho các đầu ra của trình thu thập dữ liệu theo hướng bổ sung mà mã hạ nguồn cần lặp qua, xuất khẩu hoặc phân tích. Ví dụ bao gồm các bản ghi sản phẩm, siêu dữ liệu bài viết, kết quả trích xuất đã chấp nhận, và các phép đo chất lượng trang. Mỗi bản ghi nên chứa đủ nguồn gốc để đứng độc lập: URL chuẩn, thời gian lấy, trạng thái, băm nội dung, phiên bản sơ đồ, và kết quả xác thực.
Dataset không lý tưởng cho trạng thái singleton có thể thay đổi hoặc cho việc cập nhật lặp lại một hiện vật lớn dưới một khóa. Nếu một quy trình làm việc cần lưu trữ con trỏ mới nhất, cấu hình, hoặc ảnh chụp màn hình, KeyValueStore thường là trừu tượng rõ ràng hơn. Nếu nó cần lên lịch các URL với việc loại trừ trùng lặp, RequestQueue là lựa chọn đúng.
Khi nào bạn nên sử dụng KeyValueStore?
Sử dụng KeyValueStore cho các giá trị được truy xuất bằng một tên đã biết. Các ví dụ điển hình bao gồm cấu hình đầu vào, một điểm kiểm tra, một ảnh chụp chính sách robots, một ảnh chụp màn hình, HTML thô, hoặc một tóm tắt JSON của lượt chạy. Khóa nên là xác định và được ghi nhận để một quy trình phục hồi có thể tìm thấy nó mà không cần quét các bản ghi không liên quan.
KeyValueStore có thể chứa các giá trị có cấu trúc, nhưng nó không nên trở thành một thay thế không chỉ mục cho một tập dữ liệu kết quả. Định nghĩa lưu giữ một cách riêng biệt cho các hiện vật gỡ lỗi tạm thời và các chứng cứ tuân thủ bền vững. Các hiện vật lớn có thể cần lưu trữ đối tượng bên ngoài phụ thuộc vào khách hàng lưu trữ Crawlee đã chọn và môi trường triển khai.
Khi nào bạn nên sử dụng RequestQueue?
Sử dụng RequestQueue cho các yêu cầu mà trình thu thập dữ liệu vẫn cần xử lý. Hàng đợi hỗ trợ khám phá, ưu tiên và loại trừ trùng lặp, cho phép trình thu thập dữ liệu thêm liên kết mà không xử lý cùng một yêu cầu nhiều lần. Lưu trữ ngữ cảnh cụ thể của yêu cầu như nguồn khám phá, độ sâu, nhãn, số lần thử lại, và định danh doanh nghiệp trong dữ liệu người dùng của yêu cầu khi API được tài liệu hỗ trợ.
Danh tính yêu cầu cần thiết kế có chủ đích. Thứ tự chuỗi truy vấn, tham số theo dõi, đoạn, và điều hướng chính thống có thể tạo ra các URL khác nhau đại diện cho cùng một nội dung. Chỉ chuẩn hóa các tham số mà được biết là không thay đổi tài nguyên. Việc chuẩn hóa quá mức có thể kết hợp các trang nên giữ riêng biệt.
Chuyển đổi Trang Web thành Dữ liệu Có thể Sử dụng
Sử dụng Nstdata Crawl để chuyển đổi một URL thành đầu ra sạch cho AI, RAG và quy trình làm việc dữ liệu.
Sự khác biệt giữa lưu trữ có tên và không có tên là gì?
Lưu trữ có tên được thiết kế để có thể phát hiện và tái sử dụng trong suốt quá trình thực hiện, trong khi lưu trữ không có tên hoặc lưu trữ mặc định thường chỉ giới hạn cho một lần chạy và có thể bị xóa ngay khi khởi động theo cấu hình. Lưu trữ có tên thì phù hợp cho các công việc theo lịch trình, chuyển giao, điền lại và gỡ lỗi qua các lần khởi động lại quá trình. Lưu trữ không có tên thì thuận tiện cho các bài kiểm tra và các lần chạy tạm thời.
Thời gian tồn tại chính xác phụ thuộc vào khách hàng lưu trữ hoạt động và môi trường. Xác nhận hành vi xóa trước khi dựa vào lưu trữ mặc định cho việc phục hồi. Hướng dẫn hướng dẫn lưu trữ kết quả Crawlee chính thức cho JavaScript ghi lại hành vi lưu trữ cục bộ cho triển khai đó.
Để biết chi tiết về triển khai và các bản phát hành hiện tại, hãy sử dụng kho lưu trữ Crawlee chính thức thay vì sao chép hành vi lưu trữ từ một hướng dẫn chưa được cập nhật.
Ba loại lưu trữ này nên hoạt động cùng nhau như thế nào?
Một thiết kế sạch sẽ sử dụng RequestQueue cho công việc, KeyValueStore cho trạng thái chạy và các đối tượng, và Dataset cho các hàng kết quả đã được chấp nhận. Sự tách biệt này làm cho việc phục hồi trở nên dễ hiểu:
RequestQueue cho biết những gì đang chờ, đã xử lý, hoặc đủ điều kiện để thử lại.
KeyValueStore bảo tồn cấu hình, điểm dừng, và các đối tượng chẩn đoán.
Dataset chứa các bản ghi đã vượt qua các quy tắc chấp nhận của pipeline.
Do not push a page into Dataset simply because the request completed. Validate content type, canonical URL, required fields, and business rules first. A separate rejected-record dataset or diagnostic key can preserve failures without contaminating accepted data.
## How do you make Crawlee storage reliable in production?
Reliability begins with idempotency. Assign a stable business key or document ID so retries do not create uncontrolled duplicates. Store a content hash to detect changes. Version the schema and crawler configuration so a record can be interpreted after the code changes.
Define checkpoint boundaries. A crawler should know whether a request can be marked handled before result storage succeeds. If result persistence fails after a request is acknowledged, the pipeline can lose data. Use the failure and retry semantics documented by the active crawler and storage client.
Monitor queue depth, oldest pending request, handled rate, retry rate, dataset write failures, artifact size, and storage latency. Nstdata's guide to [scaling web scraping](https://www.nstdata.io/blog/scale-web-scraping) provides broader operational context, while its [web data pipeline guidance](https://www.nstdata.io/blog/price-monitoring-data-pipeline) shows why accepted business records should be separated from raw retrieval.
The [website URL discovery guide](https://www.nstdata.io/blog/website-url-discovery) is also useful when deciding which discoveries belong in RequestQueue and which should be rejected before scheduling.
## How can Nstdata Crawl work with Crawlee storage?
[Nstdata Crawl](https://www.nstdata.io/scraping) can serve as a managed acquisition service while a Crawlee application manages its own queue, artifacts, and result records. This pattern is useful when the application needs custom scheduling or business logic but does not want to operate every browser and routing component.
- Put authorized target requests and business context in RequestQueue.
- Store crawl configuration and diagnostic artifacts in KeyValueStore.
- Call the managed collection layer within bounded concurrency.
- Validate the returned page or task result.
- Push only accepted, attributable records to Dataset.
Use [Nstdata Crawl pricing](https://www.nstdata.io/pricing/crawl) to confirm the current billing model and include failed or rejected pages when calculating cost per accepted record. For current product behavior, consult the [Nstdata Crawl documentation](https://docs.nstdata.io/docs/crawl).
## What storage mistakes cause the most trouble?
Common mistakes include relying on default purge behavior without checking it, storing large binary artifacts as ordinary result rows, acknowledging requests before durable result writes, and using raw URLs as identity without canonicalization. Another frequent problem is keeping no schema version, which makes old records ambiguous after a deployment.
Security and privacy also apply to crawler storage. Do not place credentials, authentication cookies, or sensitive headers in RequestQueue user data or logs. Minimize personal data, define retention, and restrict access to artifacts that may contain sensitive page content.
## Conclusion
Crawlee storage types are simple when each one has a clear responsibility: RequestQueue schedules work, KeyValueStore holds named state or artifacts, and Dataset stores accepted rows. Define lifecycle, identity, and failure behavior before increasing concurrency. If browser and network acquisition are the main operational burden, pair application-side Crawlee storage with a managed collection layer such as Nstdata Crawl and keep the acceptance contract in your own system.
## Experience Nstdata — Start Your Free Trial Today
<a style="margin: 8px; display: inline-block; text-decoration: none; border-left-width: 0px;" href="https://app.nstdata.io/auth/register?utm_source=official&utm_medium=blog&utm_campaign=/crawlee-data-storage-types/">
<div style="font-weight:bold; max-width:400px; padding:12px 40px; background:#646AEE; border-radius:5px; border:2px solid #646AEE; color:#fff; font-size:18px;">
Try Nstdata for Free →
</div>
</a>
## FAQ
**Q: What are the three main Crawlee storage types?**
The three main types are Dataset, KeyValueStore, and RequestQueue.
**Q: Which Crawlee storage type should hold scraped records?**
Dataset should usually hold append-oriented scraped records that passed validation.
**Q: Which Crawlee storage type deduplicates URLs?**
RequestQueue manages scheduled requests and deduplicates them according to the request identity used by the implementation.
**Q: Are default Crawlee storages persistent?**
Default-storage lifecycle depends on the storage client and purge configuration, so teams must verify startup behavior before relying on it for recovery.
**Q: Can KeyValueStore hold screenshots or raw HTML?**
Có, KeyValueStore phù hợp cho các đối tượng có tên, tùy thuộc vào khả năng và giới hạn kích thước của backend lưu trữ đã chọn.
**H: Làm thế nào bạn ngăn chặn các bản ghi Dataset bị trùng lặp?**
Sử dụng các định danh bản ghi ổn định, URL chuẩn, hàm băm nội dung, và logic ứng dụng idempotent thay vì chỉ dựa vào hành vi thêm vào của Dataset.
Lena Zhou
Aug. 11th 2026
Thu thập toàn bộ trang web chỉ với một yêu cầu API
Tỷ lệ thành công 99,8% với kết xuất JavaScript
Nhận dữ liệu sạch, sẵn sàng cho LLM ở nhiều định dạng
Chuyển mọi trang web thành Markdown, HTML, JSON, liên kết, PDF và hơn thế nữa mà không cần quản lý hạ tầng thu thập dữ liệu.
