بعد از scrape، همان داده را می‌توانید CSV بدهید، JSON در object storage نگه دارید، یا مستقیم در PostgreSQL upsert کنید. انتخاب اشتباه بعداً migration گران می‌شود. این مقاله راهنمای تصمیم است — نه «همیشه DB». pillar: وب‌اسکرپینگ؛ کیفیت رکورد: نرمال‌سازی.
- مصرف‌کننده بعدی (analyst، API محصول، warehouse) تعیین‌کننده است.
- CSV برای تحویل یک‌باره؛ JSON/JSONL برای pipeline؛ DB برای به‌روزرسانی مداوم.
- ۱M رکورد/روز در یک CSV واحد قرار ندهید.
CSV
مناسب: تحویل به مشتری، باز کردن در Excel، snapshot یک‌باره ۵٬۰۰۰ محصول، گزارش ad-hoc.
محدودیت: داده nested (مثلاً چند variant) سخت می‌شود؛ نوع ستون ضمنی است؛ ویرایش جزئی سخت؛ concurrency ضعیف. برای فارسی حتماً UTF-8 با BOM اگر مخاطب Excel ویندوز است.
JSON و JSONL
JSON فایل تکی برای export کوچک یا API response. JSONL (یک JSON per line) برای stream میلیونی: append آسان، partition روزانه روی S3/MinIO. برای developer workflow و nested field عالی است.
پایگاه داده (PostgreSQL و مشابه)
مناسب: محصول زنده، query فیلتر، relation (محصول–دسته)، upsert شبانه، dedupe با unique index. هزینه: backup، migration schema، connection pool برای API خواندن.
| معیار | CSV | JSON/JSONL | DB |
|---|---|---|---|
| حجم یک‌بار ~۵k | عالی | خوب | خوب |
| ~۱M رکورد/روز | نامناسب | خوب با partition | قوی با index |
| ساختار nested | ضعیف | عالی | JSONB یا جداول |
| به‌روزرسانی مداوم | بازنویسی فایل | append/partition | upsert |
| اشتراک با تیم تحلیل | ساده | متوسط | SQL/BI |
| پشت API محصول | ضعیف | متوسط | عالی |
| مقیاس و query | پایین | با warehouse | بالا |
سناریو ۱: ۵٬۰۰۰ محصول یک‌بار
تحلیل داخلی یا تحویل به مشتری — CSV یا JSON روی object storage کافی است. نیازی به نگه‌داری DB دائمی نیست مگر بعداً محصول شود.
سناریو ۲: روزانه ۱M رکورد
JSONL partition شده (مثلاً year=2026/month=03/day=19/) + بارگذاری به warehouse (BigQuery، ClickHouse) یا DB با batch insert. CSV تک‌فایل غیرعملی است.
سناریو ۳: API integration
اپ شما باید «آخرین قیمت» را با latency کم بدهد → PostgreSQL (یا مشابه) single source of truth، scrape شبانه upsert، API read-only. فایل CSV وسط راه فقط برای backup.
حتی اگر امروز CSV می‌دهید، schema JSON (فیلدهای نهایی بعد از normalize) را مستند کنید تا فردا migration به DB سریع باشد.
زمان‌بندی نوشتن فایل یا upsert با job زمان‌بندی‌شده هماهنگ است. خطای ذخیره را جدا از خطای fetch مدیریت کنید — resilience.
در عمل چه انتخابی کنیم؟
فقط analyst یک‌بار → CSV UTF-8. pipeline تیم dev + nested → JSONL. داشبورد/محصول/API → DB. اگر مطمئن نیستید، با JSONL partition شروع کنید و DB را وقتی query زنده لازم شد اضافه کنید.