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

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

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

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

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

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

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

3. داده‌های جدید را به‌طور هم‌زمان در Firestore منعکس کنید. از «توابع ابری» برای نوشتن داده‌های جدید در پایگاه داده 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 برای Android،‏ Apple، یا کارخواه‌های وب استفاده می‌کنید، یا از مدیریت دسترسی هویت (IAM) برای سرورها، مطمئن شوید که داده‌هایتان را در Cloud Firestore و همچنین Realtime Database ایمن می‌کنید. اصالت‌سنجی کاربر توسط Authentication برای هر دو پایگاه داده انجام می‌شود، بنابراین هنگام شروع استفاده از Cloud Firestore نیازی به تغییر پیاده‌سازی Authentication ندارید.

تفاوت‌های عمده‌ای که باید درنظر بگیرید

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

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

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

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

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

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

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

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

   • اسکریپت سفارشی بنویسید که داده‌هایتان را برای شما منتقل کند. هرچند نمی‌توانیم الگویی برای این اسکریپت ارائه دهیم، زیرا هر پایگاه داده نیازهای منحصربه‌فردی دارد، Cloud Firestore کارشناسان در کانال Slack ما یا در Stack Overflow می‌توانند اسکریپت شما را بازبینی کنند یا برای وضعیت خاص شما مشاوره ارائه دهند.
   • از کیت‌های توسعه نرم‌افزار سرور (Node.js،‏ Java،‏ Python، یا Go) برای نوشتن مستقیم داده‌ها در Cloud Firestore استفاده کنید. برای دستورالعمل‌های راه‌اندازی کیت‌های توسعه نرم‌افزار سرور، به شروع به کار مراجعه کنید.
   • برای تسریع انتقال داده‌های بزرگ، از نوشتن دسته‌ای استفاده کنید و حداکثر ۵۰۰ عملیات را در یک درخواست شبکه ارسال کنید.
   • برای ماندن در محدوده محدودیت‌های نرخ 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 را اعتبارسنجی کنید.