شما می توانید از پایگاه داده بیدرنگ Firebase و Cloud Firestore در برنامه خود استفاده کنید و از مزایای هر راه حل پایگاه داده متناسب با نیازهای خود استفاده کنید. برای مثال، ممکن است بخواهید از پشتیبانی Realtime Database برای حضور، همانطور که در Build Presence در Cloud Firestore اشاره شده است، استفاده کنید.
درباره تفاوت های بین پایگاه های داده بیشتر بدانید.
انتقال داده ها به Cloud Firestore
اگر تصمیم گرفته اید که می خواهید برخی از داده های خود را از پایگاه داده بیدرنگ به Cloud Firestore منتقل کنید، جریان زیر را در نظر بگیرید. از آنجایی که هر پایگاه داده نیازها و ملاحظات ساختاری منحصر به فردی دارد، یک مسیر مهاجرت خودکار وجود ندارد. در عوض، می توانید این پیشرفت کلی را دنبال کنید:
ساختار داده و قوانین امنیتی را از پایگاه داده Realtime به Cloud Firestore ترسیم کنید. هم پایگاه داده Realtime و هم Cloud Firestore به احراز هویت Firebase متکی هستند، بنابراین نیازی به تغییر احراز هویت کاربر برای برنامه خود ندارید. با این حال، قوانین امنیتی و مدل دادهها متفاوت هستند و مهم است که قبل از شروع انتقال دادهها به Cloud Firestore، این تفاوتها را به دقت در نظر بگیرید.
انتقال داده های تاریخی همانطور که در حال تنظیم ساختار داده جدید خود در Cloud Firestore هستید، می توانید داده های موجود را از پایگاه داده بیدرنگ به نمونه جدید Cloud Firestore خود نقشه برداری کرده و منتقل کنید. با این حال، اگر از هر دو پایگاه داده در برنامه خود استفاده می کنید، نیازی به انتقال داده های تاریخی به خارج از پایگاه داده بیدرنگ ندارید.
انعکاس داده های جدید به Firestore در زمان واقعی. از توابع Cloud برای نوشتن داده های جدید در پایگاه داده جدید Cloud Firestore خود استفاده کنید که به پایگاه داده بیدرنگ اضافه می شود.
Cloud Firestore را پایگاه داده اصلی خود برای داده های منتقل شده قرار دهید. هنگامی که برخی از داده های خود را انتقال دادید، از Cloud Firestore به عنوان پایگاه داده اصلی خود استفاده کنید و استفاده از پایگاه داده بیدرنگ خود را برای داده های منتقل شده کاهش دهید. نسخههایی از برنامهتان را که هنوز برای آن دادهها به پایگاه داده بیدرنگ مرتبط هستند و اینکه چگونه میخواهید به پشتیبانی از آنها ادامه دهید، در نظر بگیرید.
مطمئن شوید که هزینههای صورتحساب را هم برای پایگاه داده بیدرنگ و هم برای Cloud Firestore در نظر گرفتهاید.
داده های خود را نقشه برداری کنید
داده ها در پایگاه داده بیدرنگ به صورت یک درخت واحد ساخته شده اند، در حالی که Cloud Firestore از سلسله مراتب داده های صریح تر از طریق اسناد، مجموعه ها و مجموعه های فرعی پشتیبانی می کند. اگر برخی از داده های خود را از پایگاه داده Realtime به Cloud Firestore منتقل می کنید، ممکن است بخواهید معماری متفاوتی را برای داده های خود در نظر بگیرید.
تفاوت های عمده ای که باید در نظر گرفت
اگر دادهها را از درخت پایگاه داده Realtime موجود خود به اسناد و مجموعههای Cloud Firestore منتقل میکنید، تفاوتهای عمده زیر را بین پایگاههای داده که ممکن است بر نحوه ساختار دادهها در Cloud Firestore تأثیر بگذارد را در نظر داشته باشید:
- پرس و جوهای کم عمق انعطاف پذیری بیشتری را در ساختارهای داده سلسله مراتبی ارائه می دهند.
- پرس و جوهای پیچیده جزئیات بیشتری را ارائه می دهند و نیاز به داده های تکراری را کاهش می دهند.
- مکان نماهای پرس و جو صفحه بندی قوی تری را ارائه می دهند.
- تراکنش ها دیگر نیازی به یک ریشه مشترک برای همه داده های شما ندارند و کارآمدتر هستند.
- هزینههای صورتحساب بین پایگاه داده Realtime و Cloud Firestore متفاوت است. در بسیاری از موارد، Cloud Firestore ممکن است گرانتر از پایگاه داده Realtime باشد، به خصوص اگر به بسیاری از عملیات کوچک متکی باشید. کاهش تعداد عملیات در پایگاه داده خود و اجتناب از نوشتن غیر ضروری را در نظر بگیرید. درباره تفاوتهای صورتحساب بین پایگاه داده Realtime و Cloud Firestore بیشتر بدانید.
بهترین شیوه ها در عمل
مثال زیر برخی از ملاحظاتی را که ممکن است هنگام جابجایی دادههای خود بین پایگاههای داده در نظر بگیرید، منعکس میکند. میتوانید از خواندنهای سطحی و قابلیتهای جستجوی بهبودیافته برای ساختارهای داده طبیعیتر از آنچه که ممکن است با پایگاه داده Realtime استفاده کردهاید، استفاده کنید.
یک برنامه راهنمای شهری را در نظر بگیرید که به کاربران کمک می کند نقاط دیدنی قابل توجه را در شهرهای سراسر جهان پیدا کنند. از آنجایی که پایگاه داده Realtime فاقد خوانش های سطحی است، ممکن است مجبور شده باشید داده ها را در دو گره سطح بالا ساختار دهید، به شرح زیر:
// /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 نیاز به تکرار دادهها را برای الگوهای دسترسی رایج کاهش میدهد. برای مثال، صفحهای را در برنامه راهنمای شهر در نظر بگیرید که تمام شهرهای پایتخت را به ترتیب جمعیت نشان میدهد. در پایگاه داده بیدرنگ، کارآمدترین راه برای انجام این کار، حفظ فهرست جداگانه ای از شهرهای پایتخت است که داده ها را از لیست cities
کپی می کند، به شرح زیر:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
در Cloud Firestore، میتوانید فهرستی از شهرهای پایتخت را به ترتیب جمعیت به صورت یک پرس و جو بیان کنید:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
درباره مدل دادههای Cloud Firestore بیشتر بخوانید و برای ایدههای بیشتر در مورد چگونگی ساختار پایگاه داده Cloud Firestore خود، نگاهی به راهحلهای ما بیندازید.
داده های خود را ایمن کنید
چه از قوانین امنیتی Cloud Firestore برای کلاینتهای اندروید، اپل یا وب استفاده میکنید، یا از مدیریت دسترسی هویت (IAM) برای سرورها استفاده میکنید، مطمئن شوید که دادههای خود را در Cloud Firestore و همچنین پایگاه داده بیدرنگ ایمن میکنید. احراز هویت کاربر توسط Authentication برای هر دو پایگاه داده انجام می شود، بنابراین نیازی به تغییر پیاده سازی Authentication هنگام شروع استفاده از Cloud Firestore نیست.
تفاوت های عمده ای که باید در نظر گرفت
- SDK های موبایل و وب از قوانین امنیتی Cloud Firestore استفاده می کنند، در حالی که SDK های سرور از مدیریت دسترسی به هویت (IAM) برای ایمن کردن داده ها استفاده می کنند.
- قوانین امنیتی Cloud Firestore آبشاری نمیشوند مگر اینکه از علامت عام استفاده کنید. اسناد و مجموعه ها در غیر این صورت قوانین را به ارث نمی برند.
- دیگر نیازی نیست که داده ها را جداگانه تأیید کنید (همانطور که در پایگاه داده بیدرنگ انجام دادید).
- Cloud Firestore قبل از اجرای یک پرس و جو قوانین را بررسی می کند تا مطمئن شود که کاربر دسترسی مناسب برای تمام داده های بازگردانده شده توسط پرس و جو را دارد.
داده های تاریخی را به Cloud Firestore منتقل کنید
هنگامی که داده ها و ساختارهای امنیتی خود را با داده ها و مدل های امنیتی Cloud Firestore ترسیم کردید، می توانید شروع به اضافه کردن داده های خود کنید. اگر قصد دارید پس از اینکه برنامه خود را از پایگاه داده بیدرنگ به Cloud Firestore منتقل کردید، داده های تاریخی را پرس و جو کنید، صادراتی از داده های قدیمی خود را به پایگاه داده جدید Cloud Firestore خود اضافه کنید. اگر قصد دارید از پایگاه داده Realtime و Cloud Firestore در برنامه خود استفاده کنید، می توانید از این مرحله صرف نظر کنید.
برای جلوگیری از بازنویسی داده های جدید با داده های قدیمی، ممکن است بخواهید ابتدا داده های تاریخی خود را اضافه کنید. اگر دادههای جدیدی را همزمان به هر دو پایگاه داده اضافه میکنید، همانطور که در مرحله بعد بحث شد، مطمئن شوید که به دادههای جدیدی که توسط توابع ابری به Cloud Firestore اضافه شدهاند اولویت میدهید.
برای انتقال داده های تاریخی به Cloud Firestore، این مراحل را دنبال کنید:
- داده های خود را از پایگاه داده بیدرنگ صادر کنید یا از یک نسخه پشتیبان اخیر استفاده کنید .
- به بخش Realtime Database در کنسول Firebase بروید.
- از تب Data ، گره سطح ریشه پایگاه داده خود را انتخاب کنید و از منو Export JSON را انتخاب کنید.
پایگاه داده جدید خود را در Cloud Firestore ایجاد کنید و داده های خود را اضافه کنید .
هنگام انتقال برخی از داده های خود به Cloud Firestore، استراتژی های زیر را در نظر بگیرید:
- یک اسکریپت سفارشی بنویسید که داده های شما را برای شما پورت می کند. در حالی که ما نمیتوانیم الگویی برای این اسکریپت ارائه کنیم، زیرا هر پایگاه داده نیازهای منحصربهفردی دارد، کارشناسان Cloud Firestore در کانال Slack ما یا در Stack Overflow میتوانند اسکریپت شما را بررسی کنند یا برای شرایط خاص شما مشاوره ارائه دهند.
- از SDK های سرور (Node.js، جاوا، پایتون یا Go) برای نوشتن مستقیم داده ها در Cloud Firestore استفاده کنید. برای دستورالعملهای مربوط به راهاندازی SDKهای سرور، به شروع به کار مراجعه کنید.
- برای تسریع انتقال داده های بزرگ، از نوشتن دسته ای استفاده کنید و حداکثر 500 عملیات را در یک درخواست شبکه ارسال کنید.
- برای اینکه تحت محدودیتهای نرخ Cloud Firestore باقی بمانید، عملیات را به 500 نوشتن در ثانیه برای هر مجموعه محدود کنید.
داده های جدید را به Cloud Firestore اضافه کنید
برای حفظ برابری بین پایگاه های داده خود، داده های جدید را به هر دو پایگاه داده در زمان واقعی اضافه کنید. از توابع Cloud برای شروع نوشتن در Cloud Firestore هر زمان که مشتری در پایگاه داده Realtime می نویسد، استفاده کنید. مطمئن شوید که Cloud Firestore به دادههای جدیدی که از توابع ابری میآیند، بر هر نوشتهای که از انتقال دادههای تاریخی خود انجام میدهید، اولویت میدهد.
هر بار که مشتری دادهها را در پایگاه داده Realtime مینویسد، یک تابع برای نوشتن دادههای جدید یا تغییر در Cloud Firestore ایجاد کنید. درباره محرک های پایگاه داده بیدرنگ برای توابع ابری بیشتر بیاموزید.
Cloud Firestore را پایگاه داده اصلی خود برای داده های منتقل شده قرار دهید
اگر تصمیم گرفتهاید از Cloud Firestore بهعنوان پایگاه داده اصلی خود برای برخی از دادههای خود استفاده کنید، مطمئن شوید که همه عملکردهای انعکاسی دادهای را که تنظیم کردهاید در نظر گرفتهاید و قوانین امنیتی Cloud Firestore خود را تأیید کنید.
اگر از توابع Cloud برای حفظ برابری بین پایگاههای داده خود استفاده کردهاید، مطمئن شوید که عملیات نوشتن را در هر دو پایگاه داده در یک حلقه تکرار نمیکنید. تابع خود را برای نوشتن در یک پایگاه داده واحد تغییر دهید، یا تابع را به طور کامل حذف کنید و شروع به حذف تدریجی عملکرد نوشتن برای داده های منتقل شده در برنامه هایی کنید که هنوز به پایگاه داده بیدرنگ متصل هستند. نحوه مدیریت این مورد برای برنامه خود به نیازهای خاص و کاربران شما بستگی دارد.
بررسی کنید که داده های شما به درستی ایمن هستند. قوانین امنیتی Cloud Firestore یا تنظیمات IAM خود را اعتبارسنجی کنید.