از Cloud Firestore با پایگاه داده بیدرنگ Firebase استفاده کنید

شما می‌توانید در برنامه خود از هر دو راهکار Firebase Realtime Database و Cloud Firestore استفاده کنید و از مزایای هر راهکار پایگاه داده برای رفع نیازهای خود بهره ببرید. به عنوان مثال، ممکن است بخواهید از پشتیبانی Realtime Database برای presence، همانطور که در Build Presence در Cloud Firestore ذکر شده است، استفاده کنید.

درباره تفاوت‌های بین پایگاه‌های داده بیشتر بدانید.

انتقال داده‌ها به Cloud Firestore

اگر تصمیم گرفته‌اید که بخشی از داده‌های خود را از Realtime Database به Cloud Firestore منتقل کنید، روند زیر را در نظر بگیرید. از آنجا که هر پایگاه داده نیازها و ملاحظات ساختاری منحصر به فردی دارد، هیچ مسیر مهاجرت خودکاری وجود ندارد. در عوض، می‌توانید این روند کلی را دنبال کنید:

1. ساختار داده‌ها و قوانین امنیتی را از Realtime Database به Cloud Firestore نگاشت کنید. هم Realtime Database و هم Cloud Firestore به احراز هویت Firebase متکی هستند، بنابراین نیازی به تغییر احراز هویت کاربر برای برنامه خود ندارید. با این حال، قوانین امنیتی و مدل داده‌ها متفاوت هستند و مهم است که قبل از شروع انتقال داده‌ها به Cloud Firestore، این تفاوت‌ها را به دقت در نظر بگیرید.

2. انتقال داده‌های تاریخی. همزمان با تنظیم ساختار داده جدید خود در Cloud Firestore ، می‌توانید داده‌های موجود را از Realtime Database به نمونه جدید Cloud Firestore خود نگاشت و منتقل کنید. با این حال، اگر از هر دو پایگاه داده در برنامه خود استفاده می‌کنید، نیازی به انتقال داده‌های تاریخی از Realtime Database ندارید.

3. داده‌های جدید را به صورت آنی در Firestore منعکس کنید. از توابع Cloud برای نوشتن داده‌های جدید در پایگاه داده Cloud Firestore جدید خود، همزمان با اضافه شدن به Realtime Database ، استفاده کنید.

4. Cloud Firestore عنوان پایگاه داده اصلی خود برای داده‌های منتقل شده قرار دهید. پس از انتقال برخی از داده‌های خود، Cloud Firestore به عنوان پایگاه داده اصلی خود استفاده کنید و استفاده از Realtime Database را برای داده‌های منتقل شده کاهش دهید. نسخه‌هایی از برنامه خود را که هنوز برای آن داده‌ها به Realtime Database متصل هستند و نحوه برنامه ریزی برای ادامه پشتیبانی از آنها در نظر بگیرید.

مطمئن شوید که هزینه‌های صدور صورتحساب را برای هر دو Realtime Database و Cloud Firestore در نظر گرفته‌اید.

داده‌های خود را نقشه‌برداری کنید

داده‌ها در Realtime Database به صورت یک درخت واحد ساختار یافته‌اند، در حالی که Cloud Firestore از سلسله مراتب داده‌های صریح‌تری از طریق اسناد، مجموعه‌ها و زیرمجموعه‌ها پشتیبانی می‌کند. اگر برخی از داده‌های خود را از Realtime Database به Cloud Firestore منتقل کنید، ممکن است بخواهید معماری متفاوتی را برای داده‌های خود در نظر بگیرید.

تفاوت‌های اساسی که باید در نظر گرفته شوند

اگر داده‌ها را از درخت Realtime Database موجود خود به اسناد و مجموعه‌های Cloud Firestore منتقل می‌کنید، تفاوت‌های عمده زیر را بین پایگاه‌های داده در نظر داشته باشید که ممکن است بر نحوه ساختاردهی داده‌ها در Cloud Firestore تأثیر بگذارد:

• پرس‌وجوهای کم‌عمق، انعطاف‌پذیری بیشتری در ساختارهای داده سلسله‌مراتبی ارائه می‌دهند.
• پرس‌وجوهای پیچیده، جزئیات بیشتری ارائه می‌دهند و نیاز به داده‌های تکراری را کاهش می‌دهند.
• مکان‌نماهای پرس‌وجو صفحه‌بندی قوی‌تری ارائه می‌دهند.
• تراکنش‌ها دیگر نیازی به ریشه مشترک برای تمام داده‌های شما ندارند و کارآمدتر هستند.
• هزینه‌های صورتحساب بین Realtime Database و Cloud Firestore متفاوت است. در بسیاری از موارد، Cloud Firestore ممکن است گران‌تر از Realtime Database باشد، به خصوص اگر به عملیات کوچک زیادی متکی هستید. کاهش تعداد عملیات روی پایگاه داده خود و جلوگیری از نوشتن‌های غیرضروری را در نظر بگیرید. درباره تفاوت‌های صورتحساب بین Realtime Database و Cloud Firestore بیشتر بدانید.

بهترین شیوه‌ها در عمل

مثال زیر برخی از ملاحظاتی را که ممکن است هنگام جابجایی داده‌ها بین پایگاه‌های داده در نظر بگیرید، نشان می‌دهد. می‌توانید از خواندن‌های سطحی و قابلیت‌های پرس‌وجوی بهبود یافته برای ساختارهای داده طبیعی‌تر از آنچه که ممکن است با Realtime Database استفاده کرده باشید، بهره ببرید.

یک برنامه راهنمای شهر را در نظر بگیرید که به کاربران کمک می‌کند تا مکان‌های دیدنی قابل توجه را در شهرهای مختلف جهان پیدا کنند. از آنجایی که Realtime Database فاقد خواندن سطحی است، ممکن است مجبور شده باشید داده‌ها را در دو گره سطح بالا به شرح زیر ساختار دهید:

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

Cloud Firestore خواندن سطحی دارد، بنابراین پرس‌وجو برای اسناد در یک مجموعه، داده‌ها را از زیرمجموعه‌ها دریافت نمی‌کند. در نتیجه، می‌توانید اطلاعات مهم را در یک زیرمجموعه ذخیره کنید:

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

حداکثر اندازه اسناد ۱ مگابایت است، که دلیل دیگری برای ذخیره مکان‌های دیدنی به عنوان یک زیرمجموعه است، که باعث می‌شود هر سند شهری کوچک بماند، نه اینکه اسناد با لیست‌های تو در تو حجیم شوند.

قابلیت‌های پیشرفته‌ی کوئری‌گیری Cloud Firestore نیاز به کپی کردن داده‌ها برای الگوهای دسترسی رایج را کاهش می‌دهد. برای مثال، صفحه‌ای را در برنامه‌ی راهنمای شهر در نظر بگیرید که تمام شهرهای پایتخت را بر اساس جمعیت نشان می‌دهد. در Realtime Database ، کارآمدترین راه برای انجام این کار، نگهداری یک لیست جداگانه از شهرهای پایتخت است که داده‌ها را از لیست cities کپی می‌کند، به شرح زیر:

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

در Cloud Firestore ، می‌توانید فهرستی از شهرهای بزرگ را به ترتیب جمعیت به صورت یک کوئری واحد بیان کنید:

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

درباره مدل داده Cloud Firestore بیشتر بخوانید و برای ایده‌های بیشتر در مورد نحوه ساختاردهی پایگاه داده Cloud Firestore خود، به راه‌حل‌های ما نگاهی بیندازید.

داده‌های خود را ایمن کنید

چه از Cloud Firestore Security Rules برای اندروید، اپل یا کلاینت‌های وب استفاده کنید و چه از مدیریت دسترسی به هویت (IAM) برای سرورها، مطمئن شوید که داده‌های خود را در Cloud Firestore و همچنین Realtime Database ایمن می‌کنید. احراز هویت کاربر برای هر دو پایگاه داده توسط Authentication انجام می‌شود، بنابراین هنگام شروع استفاده از Cloud Firestore نیازی به تغییر پیاده‌سازی Authentication خود ندارید.

تفاوت‌های اساسی که باید در نظر گرفته شوند

• SDK های موبایل و وب از Cloud Firestore Security Rules استفاده می‌کنند، در حالی که SDK های سرور از مدیریت دسترسی به هویت (IAM) برای ایمن‌سازی داده‌ها استفاده می‌کنند.
• Cloud Firestore Security Rules به صورت آبشاری اعمال نمی‌شوند، مگر اینکه از یک wildcard استفاده کنید. اسناد و مجموعه‌ها در غیر این صورت قوانین را به ارث نمی‌برند.
• دیگر نیازی به اعتبارسنجی جداگانه داده‌ها ندارید (همانطور که در Realtime Database انجام دادید).
• Cloud Firestore قبل از اجرای یک پرس‌وجو، قوانین را بررسی می‌کند تا مطمئن شود که کاربر به تمام داده‌های برگردانده شده توسط پرس‌وجو دسترسی مناسب دارد.

انتقال داده‌های تاریخی به Cloud Firestore

پس از اینکه داده‌ها و ساختارهای امنیتی خود را با مدل‌های داده و امنیتی Cloud Firestore تطبیق دادید، می‌توانید شروع به اضافه کردن داده‌های خود کنید. اگر قصد دارید پس از انتقال برنامه خود از Realtime Database به Cloud Firestore ، داده‌های تاریخی را جستجو کنید، یک خروجی از داده‌های قدیمی خود را به پایگاه داده جدید Cloud Firestore خود اضافه کنید. اگر قصد دارید از هر دو Realtime Database و Cloud Firestore در برنامه خود استفاده کنید، می‌توانید از این مرحله صرف نظر کنید.

برای جلوگیری از رونویسی داده‌های جدید با داده‌های قدیمی، بهتر است ابتدا داده‌های قدیمی خود را اضافه کنید. اگر داده‌های جدید را به طور همزمان به هر دو پایگاه داده اضافه می‌کنید، همانطور که در مرحله بعدی بحث خواهد شد، مطمئن شوید که اولویت را به داده‌های جدیدی که توسط Cloud Functions به Cloud Firestore اضافه شده‌اند، می‌دهید.

برای انتقال داده‌های تاریخی به Cloud Firestore ، این مراحل را دنبال کنید:

1. داده‌های خود را از Realtime Database صادر کنید یا از یک نسخه پشتیبان اخیر استفاده کنید .
   1. به بخش Realtime Database در کنسول Firebase بروید.
   2. از تب Data ، گره سطح ریشه پایگاه داده خود را انتخاب کنید و از منو، Export JSON را انتخاب کنید.

2. پایگاه داده جدید خود را در Cloud Firestore ایجاد کنید و داده‌های خود را اضافه کنید .

   هنگام انتقال برخی از داده‌های خود به Cloud Firestore ، استراتژی‌های زیر را در نظر بگیرید:

   • یک اسکریپت سفارشی بنویسید که داده‌های شما را برای شما منتقل کند. اگرچه ما نمی‌توانیم الگویی برای این اسکریپت ارائه دهیم، زیرا هر پایگاه داده نیازهای منحصر به فردی دارد، اما متخصصان Cloud Firestore در کانال Slack ما یا در Stack Overflow می‌توانند اسکریپت شما را بررسی کنند یا برای موقعیت خاص شما توصیه‌هایی ارائه دهند.
   • از SDK های سرور (Node.js، Java، Python یا Go) برای نوشتن مستقیم داده‌ها در Cloud Firestore استفاده کنید. برای دستورالعمل‌های مربوط به تنظیم SDK های سرور، به شروع به کار مراجعه کنید.
   • برای تسریع مهاجرت داده‌های بزرگ، از نوشتن‌های دسته‌ای استفاده کنید و تا ۵۰۰ عملیات را در یک درخواست شبکه واحد ارسال کنید.
   • برای اینکه از محدودیت‌های نرخ Cloud Firestore پیروی کنید، عملیات را برای هر مجموعه به ۵۰۰ نوشتن در ثانیه محدود کنید.

اضافه کردن داده‌های جدید به Cloud Firestore

برای حفظ برابری بین پایگاه‌های داده خود، داده‌های جدید را به صورت بلادرنگ به هر دو پایگاه داده اضافه کنید. Cloud Functions برای شروع نوشتن در Cloud Firestore هر زمان که کلاینت در Realtime Database می‌نویسد، استفاده کنید. مطمئن شوید که Cloud Firestore به داده‌های جدید دریافتی از Cloud Functions نسبت به هر نوشتنی که از انتقال داده‌های قبلی خود انجام می‌دهید، اولویت می‌دهد.

یک تابع ایجاد کنید تا هر بار که کلاینت داده‌ها را در Realtime Database می‌نویسد، داده‌های جدید یا در حال تغییر را در Cloud Firestore بنویسد. درباره محرک‌های Realtime Database برای Cloud Functions بیشتر بدانید.

Cloud Firestore پایگاه داده اصلی خود برای داده‌های منتقل شده قرار دهید.

اگر تصمیم گرفته‌اید از Cloud Firestore به عنوان پایگاه داده اصلی خود برای برخی از داده‌هایتان استفاده کنید، مطمئن شوید که هرگونه عملکرد انعکاس داده‌ای که تنظیم کرده‌اید را در نظر گرفته‌اید و Cloud Firestore Security Rules خود را تأیید می‌کنید.

1. اگر Cloud Functions برای حفظ برابری بین پایگاه‌های داده خود استفاده کرده‌اید، مطمئن شوید که عملیات نوشتن را در هر دو پایگاه داده در یک حلقه تکرار نمی‌کنید. تابع خود را به نوشتن در یک پایگاه داده واحد تغییر دهید، یا تابع را به طور کامل حذف کنید و شروع به حذف تدریجی قابلیت نوشتن برای داده‌های منتقل شده در برنامه‌هایی کنید که هنوز به Realtime Database گره خورده‌اند. نحوه مدیریت این موضوع برای برنامه شما به نیازهای خاص و کاربران شما بستگی دارد.

2. تأیید کنید که داده‌های شما به درستی ایمن شده‌اند. Cloud Firestore Security Rules یا تنظیمات IAM خود را تأیید کنید.