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

شما می توانید از Firebase Realtime Database و Cloud Firestore در برنامه خود استفاده کنید و از مزایای هر راه حل پایگاه داده متناسب با نیازهای خود استفاده کنید. برای مثال، ممکن است بخواهید از پشتیبانی Realtime Database برای حضور استفاده کنید، همانطور که در 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 ...]
}

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

قابلیت‌های جستجوی پیشرفته 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 می کنید ندارید.

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

• SDK های موبایل و وب از Cloud Firestore Security Rules استفاده می کنند، در حالی که SDK های سرور از مدیریت دسترسی به هویت (IAM) برای ایمن کردن داده ها استفاده می کنند.
• Cloud Firestore Security Rules آبشاری نمی‌شوند مگر اینکه از علامت عام استفاده کنید. اسناد و مجموعه ها در غیر این صورت قوانین را به ارث نمی برند.
• دیگر نیازی نیست که داده ها را جداگانه تأیید کنید (همانطور که در 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، جاوا، پایتون یا Go) برای نوشتن مستقیم داده ها در Cloud Firestore استفاده کنید. برای دستورالعمل‌های مربوط به راه‌اندازی SDK‌های سرور، به شروع به کار مراجعه کنید.
   • برای تسریع انتقال داده های بزرگ، از نوشتن دسته ای استفاده کنید و حداکثر 500 عملیات را در یک درخواست شبکه ارسال کنید.
   • برای اینکه تحت محدودیت‌های نرخ Cloud Firestore باقی بمانید، عملیات را به 500 نوشتن در ثانیه برای هر مجموعه محدود کنید.

داده های جدید را به 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 خود را اعتبارسنجی کنید.

،

شما می توانید از Firebase Realtime Database و Cloud Firestore در برنامه خود استفاده کنید و از مزایای هر راه حل پایگاه داده متناسب با نیازهای خود استفاده کنید. برای مثال، ممکن است بخواهید از پشتیبانی Realtime Database برای حضور استفاده کنید، همانطور که در 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 ...]
}

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

قابلیت‌های جستجوی پیشرفته 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 می کنید ندارید.

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

• SDK های موبایل و وب از Cloud Firestore Security Rules استفاده می کنند، در حالی که SDK های سرور از مدیریت دسترسی به هویت (IAM) برای ایمن کردن داده ها استفاده می کنند.
• Cloud Firestore Security Rules آبشاری نمی‌شوند مگر اینکه از علامت عام استفاده کنید. اسناد و مجموعه ها در غیر این صورت قوانین را به ارث نمی برند.
• دیگر نیازی نیست که داده ها را جداگانه تأیید کنید (همانطور که در 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، جاوا، پایتون یا Go) برای نوشتن مستقیم داده ها در Cloud Firestore استفاده کنید. برای دستورالعمل‌های مربوط به راه‌اندازی SDK‌های سرور، به شروع به کار مراجعه کنید.
   • برای تسریع انتقال داده های بزرگ، از نوشتن دسته ای استفاده کنید و حداکثر 500 عملیات را در یک درخواست شبکه ارسال کنید.
   • برای اینکه تحت محدودیت‌های نرخ Cloud Firestore باقی بمانید، عملیات را به 500 نوشتن در ثانیه برای هر مجموعه محدود کنید.

داده های جدید را به 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 خود را اعتبارسنجی کنید.