1. نظرة عامة
تهدف هذه السلسلة من الدروس التطبيقية حول الترميز (البرامج التعليمية العملية الذاتية) إلى مساعدة مطوّري Google App Engine (الإصدار العادي) على تحديث تطبيقاتهم من خلال إرشادهم خلال سلسلة من عمليات نقل البيانات. تتضمن معظم عمليات النقل هذه التوقف عن استخدام الخدمات المجمّعة لوقت التشغيل الأصلي، وذلك لأنّ الجيل التالي من بيئات التشغيل أكثر مرونة، ما يمنح المستخدمين مجموعة أكبر من خيارات الخدمة. هناك طريقة أخرى لتحديث التطبيق تشمل الترقية إلى منتج أحدث، وهذا هو موضوع هذا الدرس التطبيقي حول الترميز.
يكون مستخدمو App Engine الذين يصلون إلى Datastore من خلال مكتبات عملاء Cloud NDB أو Cloud Datastore جاهزين للاستخدام ولا يحتاجون إلى نقل بيانات أخرى. مع ذلك، تمثّل خدمة Cloud Firestore أحدث مخزن بيانات NoSQL وقابل للتوسّع ومتاح بدرجة كبيرة مع ميزات من قاعدة بيانات Firebase في الوقت الفعلي.
أنت في المكان المناسب إذا كنت مطوّر برامج وتشعر بأنه مجبر على استخدام Firestore للاستفادة من ميزاته، أو على الأقل إذا كان لديك اهتمام كافٍ لاستكشاف ما تتطلبه عملية نقل البيانات. يعلّمك هذا البرنامج التعليمي كيفية نقل بيانات تطبيق App Engine باستخدام Cloud Datastore إلى Cloud Firestore.
ستتعرَّف على كيفية
- التعرف على الاختلافات بين Datastore وFirestore
- نقل البيانات من Cloud Datastore إلى Cloud Firestore
المتطلبات
- مشروع Google Cloud Platform مع:
- المهارات الأساسية في لغة بايثون
- المعرفة العملية بأوامر نظام التشغيل Linux الشائعة
- معرفة أساسية حول تطوير ونشر تطبيقات App Engine
- ننصحك بإكمال الدرس التطبيقي حول ترميز الوحدة 3، بما في ذلك نقله إلى Python 3 قبل البدء في هذا الدرس (الوحدة 6).
- تطبيق للوحدة النمطية 3 في Cloud Datastore Python 3 App Engine صالح.
استطلاع
كيف ستستخدم هذا الدرس التطبيقي حول الترميز؟
2. الخلفية
أما أداة "مخزن البيانات" في App Engine، فقد أصبحت منتجها الخاص في العام 2013، وهو "مخزن البيانات في Google Cloud"، وأصبح بإمكان المطوّرين الوصول إليه خارج App Engine. في العام التالي، استحوذت Google على Firebase. وفي ذلك الوقت، اشتهرت بقاعدة بياناتها في الوقت الفعلي.
على مدار السنوات القليلة التالية، عملت فِرق Firebase و"تخزين البيانات في السحابة الإلكترونية" على دمج بعض ميزات Firebase في "مخزن البيانات". نتيجةً لذلك، تم إطلاق الجيل التالي من Cloud Datastore في عام 2017. تم تغيير علامتها التجارية لتصبح Cloud Firestore حتى تعكس اكتساب بعض ميزات Firebase.
أصبحت Cloud Firestore آلية تخزين NoSQL التلقائية لمشاريع Google Cloud. يمكن للتطبيقات الجديدة استخدام Cloud Firestore محليًا، بينما يتم تحويل قواعد بيانات "مخزن البيانات" الحالية إلى إصدار متقدّم من Firestore وتعمل الآن باسم "Firestore في وضع تخزين البيانات" للحفاظ على التوافق مع عمليات تخزين البيانات. ونتيجةً لذلك، لا يمكن للتطبيقات تشغيل Cloud Firestore إلا في أحد هذه الأوضاع، ولا يمكن تغييرها بعد ضبطها.
في الوقت الحالي، عندما ينشئ المستخدمون مشاريع جديدة ويختارون أحد حلول NoSQL، سيُطلب منهم اختيار Firestore في وضع Datastore أو Firestore في الوضع الأصلي. بعد أن يضيف المستخدمون كيانات Datastore، لا يمكنهم التغيير إلى Firestore، وبالمثل، عند تحديد وضع Firestore الأصلي، لن يمكنهم التبديل مرة أخرى إلى Datastore (أو بدلاً من ذلك، Firestore في وضع Datastore). لمزيد من التفاصيل، يمكنك الاطّلاع على الاختيار بين Cloud Firestore في وضع "Datastore" أو صفحة وضع Firestore الأصلية. لنقل تطبيق إلى Firestore، يجب إنشاء مشروع جديد، كما يجب تصدير Datastore ثم استيراده إلى Firestore. يهدف هذا البرنامج التعليمي إلى منح المطوّرين فكرة عن الاختلافات بين استخدام Cloud Datastore وCloud Firestore.
لا نتوقّع أن يُجري المستخدمون عملية النقل هذه، ولهذا السبب هي عملية نقل بيانات اختيارية. في حين أنّ هناك مزايا واضحة لاستخدام Cloud Firestore في الأصل، مثل مصادقة العميل ودمج قواعد Firebase وقاعدة بيانات Firebase في الوقت الفعلي، فإنّ خطوات نقل البيانات "غير ملائمة":
- ويجب استخدام مشروع مختلف عن مشروع تطبيقك الحالي.
- في حال أضاف أحد التطبيقات كيانات Datastore، لا يمكن تبديله إلى Firestore في الوضع الأصلي.
- وبالمثل، لا يمكن للمشروع الذي اختار Firestore في الوضع الأصلي العودة إلى Firestore في وضع "مخزن البيانات".
- لا تتوفّر أداة نقل يمكنها بث البيانات من مشروع إلى آخر.
- لا تتوفّر بعض ميزات "تخزين البيانات" المهمة من Firestore، بما في ذلك مساحات الاسم وسرعة الكتابة العالية (أكبر من 10 آلاف/ثانية).
- أدوات التصدير والاستيراد "أساسية" و"كل شيء أو لا شيء" والسيناريوهات.
- إذا كان تطبيقك يحتوي على العديد من كيانات Datastore، قد يستغرق تصديره عدة ساعات ثم استيراده إلى Firestore.
- وخلال هذا الوقت، لن يتمكّن التطبيق أو الخدمة من كتابة البيانات أو تحديثها.
- يتم احتساب أنشطة نقل البيانات ضمن الاستخدام العادي. فقد ترغب في توزيعها (عبر الحصص اليومية إن أمكن) لتقليل التكاليف.
- ونظرًا لتشغيل خدمتك الجديدة في مشروع مختلف، ستحتاج إلى نافذة لنشر تحديثات نظام أسماء النطاقات.
- يحتوي Datastore وFirestore على نماذج بيانات متشابهة ولكن مختلفة، لذلك يتطلّب نقل البيانات تحديث طريقة عمل التطبيق/الخدمة
- طلبات البحث الأصلية من Datastore هي الآن طلبات البحث في Firestore (التلقائية)
- طلبات البحث من النوع الواسع في Datastore هي طلبات البحث عن مجموعات في Firestore.
- المؤشرات وطريقة المعالجة مختلفة، إلخ.
يُرجى العِلم أنّه إذا كان لديك تطبيق بسيط نوعًا ما يمكنك نقله، أو الاستعداد لمحاكاة عملية نقل البيانات هذه، أو إذا كنت تتعرّف على مقارنة بين Datastore وFirestore، يُرجى المتابعة.
مستخدمو Python 2: يتم تقديم هذا الدرس التطبيقي الاختياري حول ترميز نقل البيانات في Python 3 فقط، ومع ذلك، نظرًا لأن Cloud Firestore تتوافق مع 2.x أيضًا، يمكن للمستخدمين دمج الاختلافات في الاستخدام. أحد الأمثلة على ذلك هو أنّ سجلات Firestore تستخدم سلاسل Unicode (بدلاً من سلاسل بايت)، لذا يجب استخدام مؤشر u''
للسلاسل الحرفية لسلسلة Python 2، ما يعني أنّ الدالة store_visit()
2.x ستبدو على النحو التالي:
def store_visit(remote_addr, user_agent):
doc_ref = fs_client.collection(u'Visit')
doc_ref.add({
u'timestamp': datetime.now(),
u'visitor': u'{}: {}'.format(remote_addr, user_agent),
})
بخلاف ذلك، يجب أن تعمل مكتبة العملاء بشكل مشابه. المشكلة الأخرى الوحيدة التي يجب مراعاتها هي أن مكتبة 2.x Cloud Firestore "مجمّدة" أمّا في ما يتعلّق بتطوير التطبيقات، فسيتم توفير ميزات أكثر/أحدث بشكل متزايد في مكتبة عملاء 3.x Firestore فقط.
لمتابعة عملية النقل هذه، في ما يلي الخطوات الأساسية لهذا البرنامج التعليمي:
- الإعداد/التمهيد
- إضافة مكتبة Cloud Firestore
- تحديث ملفات التطبيق
3- الإعداد/التمهيد
قبل أن نبدأ في الجزء الرئيسي من البرنامج التعليمي، لنقم بإعداد مشروعنا، ونحصل على الكود، ثم ننشر التطبيق الأساسي حتى نعرف أننا بدأنا بالتعليمات البرمجية.
1. إعداد المشروع
ننصحك بإعادة استخدام المشروع نفسه الذي استخدمته لإكمال الدرس التطبيقي حول الترميز الخاص بالوحدة 3. ويمكنك، بدلاً من ذلك، إنشاء مشروع جديد تمامًا أو إعادة استخدام مشروع حالي آخر. عليك التأكّد من أنّ المشروع يتضمّن حساب فوترة نشطًا وأنّه تم تفعيل App Engine (تطبيق).
2. الحصول على نموذج تطبيق أساسي
أحد المتطلّبات الأساسية لهذا الدرس التطبيقي حول الترميز هو أن يكون لديك تطبيق نموذجي للوحدة 3 صالح. إذا لم يكن لديك حساب، فأكمل الدليل التعليمي للوحدة 3 (الرابط أعلاه) قبل المضي قدمًا هنا. أما إذا كنت على دراية بمحتوياتها، فما عليك سوى البدء بالحصول على كود الوحدة 3 أدناه.
سنبدأ في بدء استخدام رمز الوحدة 3، سواء كنت تستخدم نموذجك الخاص أو رمزنا. يرشدك الدرس التطبيقي حول ترميز الوحدة 6 هذا إلى كل خطوة، وعند الانتهاء، يجب أن يكون عبارة عن رمز في نقطة FINISH. (هذا البرنامج التعليمي متاح فقط للغة Python 3).
- START: مستودع الوحدة 3
- إنهاء: مستودع الوحدة 6
- المستودع بالكامل (نسخة طبق الأصل أو تنزيل ملف ZIP)
يجب أن يبدو دليل ملفات الوحدة 3 (لديك أو الخاص بنا) على النحو التالي:
$ ls
README.md main.py templates
app.yaml requirements.txt
3- (إعادة نشر تطبيق الوحدة 3)
إليك الخطوات المتبقية لتنفيذ العمل المسبق الآن:
- التعرف مرة أخرى على أداة سطر أوامر
gcloud
(إذا كان ذلك ضروريًا) - (إعادة) نشر رمز الوحدة 3 في App Engine (إذا كان ذلك ضروريًا)
بعد تنفيذ هذه الخطوات بنجاح والتأكّد من أنّه يعمل، سنتابع في هذا البرنامج التعليمي، بدءًا من ملفات الإعداد.
متطلبات Python 2
- تأكَّد من أنّ
app.yaml
(لا يزال) يشير إلى الحِزم المجمّعة التابعة لجهة خارجية:grpcio
وsetuptools
. - يجب التأكُّد من استمرار
appengine_config.py
في استخدامpkg_resources
وgoogle.appengine.ext.vendor
لتوجيه التطبيق إلى موارد تابعة لجهات خارجية. - في القسم التالي الذي يُحدِّث
requirements.txt
، يجب استخدامgoogle-cloud-firestore==1.9.0
لأنّ هذا هو الإصدار النهائي المتوافق مع 2.x من مكتبة عملاء Python Firestore.- إذا كان
requirements.txt
يحتوي على إدخال لـgoogle-cloud-core
، اتركه كما هو. - يمكنك حذف "
lib
" وإعادة تثبيته باستخدام "pip install -t lib -r requirements.txt
".
- إذا كان
4. تحديث ملفات الإعداد (إضافة مكتبة Cloud Firestore)
بالإضافة إلى عملية الإعداد، يجب تعديل الإعدادات متبوعة بملفات التطبيق. بالنسبة إلى الطريقة الأولى، سيكون التغيير الوحيد في الإعدادات هو تبديل الحزمة الثانوية في ملف requirements.txt
، لذا سننفّذ هذا الإجراء الآن.
استبدِل سطر google-cloud-datastore
بـ google-cloud-firestore
في requirements.txt
لكي يظهر على النحو التالي:
Flask==1.1.2
google-cloud-firestore==2.0.2
ننصحك باستخدام أحدث إصدارات من كل مكتبة. كانت أرقام الإصدارات أعلاه هي الأحدث في وقت كتابة هذا التقرير. يتم تعديل الرمز في المجلد "FINISH repo" بشكل متكرر، وقد يكون له إصدار أحدث.
وليست هناك تغييرات أخرى على الإعدادات، لذا يظل app.yaml
وtemplates/index.html
كما هو.
5- تحديث ملفات التطبيق
هناك ملف تطبيق واحد فقط، main.py
، لذا تؤثر جميع التغييرات في هذا القسم في هذا الملف فقط.
1. عمليات الاستيراد
إنّ تبديل استيراد الحزمة هو تغيير بسيط من datastore
إلى firestore
:
- قبل:
from google.cloud import datastore
- بعد:
from google.cloud import firestore
2. الوصول إلى مركز الإطفاء
بعد تهيئة Flask، أنشئ عميل Firestore. أجرِ تغييرًا مشابهًا كما هو موضح أعلاه ولكن لإعداد العميل:
- قبل:
app = Flask(__name__)
ds_client = datastore.Client()
- بعد:
app = Flask(__name__)
fs_client = firestore.Client()
من خلال تنفيذ عملية نقل البيانات من Cloud NDB إلى Cloud Datastore، تكون قد بذلت مجهودًا كبيرًا للوصول إلى Cloud Firestore. باستخدام Datastore، يمكنك إنشاء سجلات البيانات في شكل كيانات تتكون من خصائص مشتركة وتجميعها حسب المفاتيح. سجلات البيانات في Firestore هي مستندات تتألف من أزواج المفتاح/القيمة ويتم تجميعها معًا في مجموعات. يتطلب النقل من "مخزن البيانات" التفكير في هذه الاختلافات لأنها ستحدث عند إنشاء سجلات البيانات بالإضافة إلى الاستعلام عنها. قد تختلف النتائج استنادًا إلى مدى تعقيد رمز تخزين البيانات.
بالنسبة إلى "مخزن البيانات"، يمكنك إجراء طلبات بحث استنادًا إلى نوع الكيان إلى جانب معايير الفلترة والترتيب. بالنسبة إلى Firestore، يُعد طلب البحث عن البيانات مشابهًا. لنلقِ نظرة على مثال سريع، على افتراض أنّ قيم طلب البحث التالية والعملاء (ds_client
أو fs_client
، على التوالي)، وعمليات الاستيراد:
from datetime import datetime
from firestore.Query import DESCENDING
OCT1 = datetime(2020, 10, 1)
LIMIT = 10
بالنسبة إلى Datastore، لنستعلم عن أحدث عشرة كيانات Visit
الأحدث من 1 تشرين الأول (أكتوبر) 2020 بترتيب تنازلي:
query = ds_client.query(kind='Visit')
query.add_filter('timestamp', '>=', datetime(2020, 10, 1))
query.order = ['-timestamp']
return query.fetch(limit=LIMIT)
نفعل الشيء نفسه مع Firestore من مجموعة Visit
:
query = fs_client.collection('Visit')
query.where('timestamp', '>=', datetime(2020, 10, 1))
query.order_by('timestamp', direction=DESCENDING)
return query.limit(LIMIT).stream()
نموذج طلب بحث التطبيق أبسط (لا توجد عبارة "WHERE"). وكمراجعة، إليك رمز تخزين البيانات في السحابة الإلكترونية:
- قبل:
def store_visit(remote_addr, user_agent):
entity = datastore.Entity(key=ds_client.key('Visit'))
entity.update({
'timestamp': datetime.now(),
'visitor': '{}: {}'.format(remote_addr, user_agent),
})
ds_client.put(entity)
def fetch_visits(limit):
query = ds_client.query(kind='Visit')
query.order = ['-timestamp']
return query.fetch(limit=limit)
بالانتقال إلى Firestore، ستجد أنه تم إنشاء مستندات جديدة مشابهة للكيانات وطلبات البحث كما هو موضح سابقًا.
- بعد:
def store_visit(remote_addr, user_agent):
doc_ref = fs_client.collection('Visit')
doc_ref.add({
'timestamp': datetime.now(),
'visitor': '{}: {}'.format(remote_addr, user_agent),
})
def fetch_visits(limit):
visits_ref = fs_client.collection('Visit')
visits = (v.to_dict() for v in visits_ref.order_by('timestamp',
direction=firestore.Query.DESCENDING).limit(limit).stream())
return visits
تظل الدالة الرئيسية root()
كما هي في ملف نموذج index.html
. تحقق جيدًا من التغييرات التي أجريتها، واحفظها وننشرها وتحقق منها.
6- الملخّص/تنظيف البيانات
نشر التطبيق
أعِد نشر تطبيقك باستخدام "gcloud app deploy
"، وتأكَّد من أنّه يعمل. يجب أن يتطابق رمزك الآن مع ما هو في مستودع الوحدة 6 (أو نسخة 2.x إذا كان هذا هو اختيارك المفضّل).
إذا انتقلت إلى هذه السلسلة بدون المشاركة في أيّ من الدروس التطبيقية السابقة حول الترميز، لن يتغيّر التطبيق نفسه. تسجِّل هذه الأداة جميع الزيارات إلى صفحة الويب الرئيسية (/
) وتبدو على هذا النحو بعد زيارتك للموقع مرات كافية:
تهانينا على إكمال هذا النقل الاختياري للوحدة 6. من المحتمل أن تكون هذه واحدة من عمليات النقل، إن لم تكن نهائية، التي يمكنك إجراؤها بقدر ما يتم تخزين بيانات App Engine. يمكنك بدلاً من ذلك نقل تطبيقك إلى حاويات على السحابة الإلكترونية إذا لم يسبق لك إجراء ذلك (يمكنك الاطّلاع على الوحدتين 4 و5، والدروس التطبيقية حول الترميز من خلال الرابطَين أدناه).
اختياري: إخلاء مساحة تخزين
ماذا عن تنظيف البيانات لتجنُّب تحصيل الرسوم منك إلى أن تكون مستعدًا للانتقال إلى الدرس التالي حول ترميز عملية نقل البيانات؟ بصفتك مطوِّرًا حاليًا، من المرجّح أنّك على اطّلاع على معلومات أسعار App Engine.
اختياري: إيقاف التطبيق
إذا لم تكن مستعدًا للانتقال إلى البرنامج التعليمي التالي حتى الآن، يمكنك إيقاف تطبيقك لتجنُّب تحصيل رسوم منك. عندما تكون مستعدًا للانتقال إلى الدرس التطبيقي التالي حول الترميز، يمكنك إعادة تفعيله. عندما يكون تطبيقك متوقفًا، لن يتلقّى أي زيارات مقابل تحصيل رسوم منك، ولكن يمكنك حذف معلومات أخرى يمكنك دفع رسوم مقابلها، وهي استخدام تطبيق Fire Store إذا تجاوز الحصة المجانية، لذا ننصحك بحذفه بما يكفي ليكون تحت هذا الحد الأقصى.
من ناحية أخرى، إذا كنت لا تتابع عمليات نقل البيانات وأردت حذف كل البيانات بالكامل، يمكنك إيقاف مشروعك.
الخطوات التالية
بالإضافة إلى هذا البرنامج التعليمي، هناك العديد من الدروس التطبيقية الأخرى حول ترميز وحدة الترحيل التي يمكنك استخدامها:
- الوحدة 7: قوائم انتظار مهام Drive Engine App Engine (مطلوبة إذا كنت تستخدم [push] قوائم انتظار المهام)
- إضافة مهام دفع
taskqueue
في App Engine إلى تطبيق الوحدة 1 - تحضير المستخدمين لنقل البيانات إلى Cloud Tasks في الوحدة 8
- إضافة مهام دفع
- الوحدة 4: النقل إلى التشغيل في السحابة الإلكترونية باستخدام Docker
- احتواء تطبيقك على حاويات لتشغيله على Cloud Run مع Docker
- تتيح لك عملية النقل هذه البقاء على Python 2.
- الوحدة 5: النقل إلى Cloud Run باستخدام Cloud Buildpack
- توفير حاويات في تطبيقك لتشغيله على Cloud Runs مع حِزم Cloud Buildpacks
- لست بحاجة إلى معرفة أي معلومات عن Docker أو الحاويات أو
Dockerfile
. - يتطلب نقل تطبيقك إلى Python 3 مسبقًا (Buildpacks لا تتوافق مع Python 2)
7. مراجع إضافية
المشاكل/الملاحظات في الدروس التطبيقية حول ترميز وحدة نقل بيانات App Engine
إذا وجدت أي مشاكل في هذا الدرس التطبيقي حول الترميز، يُرجى البحث عن مشكلتك أولاً قبل ملء النموذج. روابط للبحث وإنشاء مشاكل جديدة:
موارد نقل البيانات
يمكن العثور على روابط لمجلدات repo للوحدة 3 (START) والوحدة 6 (FINISH) في الجدول أدناه. ويمكن الوصول إليها أيضًا من المستودع لجميع عمليات نقل بيانات App Engine التي يمكنك استنساخ ملف ZIP أو تنزيله.
Codelab | Python 2 | Python 3 |
(الرمز) | ||
الوحدة 6 | (لا ينطبق) |
موارد App Engine
في ما يلي مراجع إضافية بشأن عملية النقل هذه:
- مراجع Python Cloud Datastore وCloud Firestore
- الانتقال إلى بيئة تشغيل الجيل التالي لكل من Python 3 وGAE
- عام