Share via

ترحيل مئات التيرابايت من البيانات إلى Azure Cosmos DB

  • مقالة

ينطبق على: NoSQL MongoDB كاساندرا العفريت الجدول

يمكن أن Azure Cosmos DB تخزن تيرابايت من البيانات. يمكنك تنفيذ ترحيل بيانات واسع النطاق لنقل حمل العمل الإنتاج إلى Azure Cosmos DB. توضح هذه المقالة التحديات التي ينطوي عليها نقل البيانات واسع النطاق إلى Azure Cosmos DB وتعرفك على الأداة التي تساعد في مواجهة التحديات وتنقل البيانات إلى Azure Cosmos DB. في دراسة الحالة هذه، استخدم العميل واجهة برمجة تطبيقات Azure Cosmos DB ل NoSQL.

قبل ترحيل حمل العمل بالكامل إلى Azure Cosmos DB، يمكنك ترحيل مجموعة فرعية من البيانات للتحقق من صحة بعض الجوانب مثل اختيار مفتاح القسم وأداء الاستعلام ونمذجة البيانات. بعد التحقق من صحة إثبات المفهوم، يمكنك نقل حمل العمل بالكامل إلى Azure Cosmos DB.

أدوات ترحيل البيانات

تختلف إستراتيجيات ترحيل Azure Cosmos DB حالياً استناداً إلى اختيار واجهة برمجة التطبيقات وحجم البيانات. لترحيل مجموعات البيانات الأصغر - للتحقق من صحة نمذجة البيانات وأداء الاستعلام واختيار مفتاح القسم وما إلى ذلك - يمكنك استخدام موصل Azure Cosmos DB الخاص ب Azure Data Factory. إذا كنت على دراية بـSpark، يمكنك أيضاً اختيار استخدام موصل Azure Cosmos DB Spark لترحيل البيانات.

التحديات التي تواجه الترحيلات واسعة النطاق

الأدوات الموجودة لترحيل البيانات إلى Azure Cosmos DB لها بعض القيود التي تصبح واضحة بشكل خاص على نطاقات كبيرة:

  • قدرات محدودة الحجم: من أجل ترحيل تيرابايت من البيانات إلى Azure Cosmos DB في أسرع وقت ممكن، واستهلاك معدل النقل المقدم بالكامل بشكل فعال، يجب أن يكون لدى عملاء الترحيل القدرة على التوسع إلى أجل غير مسمى.

  • عدم وجود تتبع التقدم والتحقق من الإشارة: من المهم تتبع تقدم الترحيل والتحقق من الإشارة أثناء ترحيل مجموعات البيانات الكبيرة. وإلا، أي خطأ يحدث أثناء الترحيل سيوقف الترحيل، ويجب بدء العملية من الصفر. لن يكون من المجدي استئناف عملية الترحيل برمتها عندما يكون 99 في المائة منها قد اكتمل بالفعل.

  • عدم وجود قائمة انتظار الأحرف غير المستخدمة: ضمن مجموعات البيانات الكبيرة، في بعض الحالات قد تكون هناك مشكلات مع أجزاء من البيانات المصدر. بالإضافة إلى ذلك، قد يكون هناك مشاكل عابرة مع العميل أو شبكة الاتصال. يجب ألا تتسبب أي من هاتين الحالتين في فشل الترحيل بأكمله. على الرغم من أن معظم أدوات الترحيل لديها قدرات إعادة محاولة قوية تحمي من المشكلات المتقطعة، إلا إنها ليست كافية دائماً. على سبيل المثال، إذا كان أقل من 0.01٪ من مستندات البيانات المصدر أكبر من 2 ميغابايت في الحجم، فإنه يؤدي بكتابة المستند إلى الفشل في Azure Cosmos DB. من الناحية المثالية، من المفيد استمرار أداة الترحيل في هذه المستندات "الفاشلة" إلى قائمة انتظار أخرى للأحرف غير المستخدمة، والتي يمكن معالجتها بعد الترحيل.

يتم إصلاح العديد من هذه القيود لأدوات مثل Azure Data factory، خدمات ترحيل البيانات Azure.

أداة مخصصة مع مكتبة المنفذ المجمع

يمكن حل التحديات الموضحة في القسم أعلاه باستخدام أداة مخصصة يمكن تحجيمها بسهولة عبر مثيلات متعددة وهي مرنة أمام الإخفاقات العابرة. بالإضافة إلى ذلك، يمكن إيقاف الأداة المخصصة واستئناف الترحيل عند نقاط التفتيش المختلفة. يوفر Azure Cosmos DB بالفعل مكتبة المنفذ المجمعة التي تتضمن بعض هذه الميزات. على سبيل المثال، مكتبة المنفذ المجمعة بالفعل وظيفة لمعالجة الأخطاء عابرة ويمكن توسيع نطاق مؤشرات الترابط في عقدة واحدة تستهلك حوالي 500 K وحدة طلب لكل عقدة. تقوم مكتبة المنفذ المجمع أيضاً بتقسيم مجموعة البيانات المصدر إلى دفعات صغيرة يتم تشغيلها بشكل مستقل كشكل من أشكال نقاط التفتيش.

تستخدم الأداة المخصصة مكتبة المنفذ المجمع وتدعم التوسع عبر عملاء متعددين وتتبع الأخطاء أثناء عملية الابتلاع. لاستخدام هذه الأداة، يجب تقسيم بيانات المصدر إلى ملفات مميزة في تخزين مجمع البيانات Azure (ADLS) بحيث يمكن لعمال الترحيل المختلفين التقاط كل ملف واستيعابه في Azure Cosmos DB. تستخدم الأداة المخصصة مجموعة منفصلة تخزن بيانات التعريف حول تقدم الترحيل لكل ملف مصدر فردي في ADLS وتتعقب أي أخطاء مقترنة بها.

توضح الصورة التالية عملية الترحيل باستخدام هذه الأداة المخصصة. يتم تشغيل الأداة على مجموعة من الأجهزة الظاهرية، ويستفسر كل جهاز ظاهري عن مجموعة التتبع في Azure Cosmos DB للحصول على إيجار على أحد أقسام البيانات المصدر. بمجرد الانتهاء من ذلك، يتم قراءة قسم البيانات المصدر بواسطة الأداة وإدخالها في Azure Cosmos DBباستخدام مكتبة المنفذ السائبة. بعد ذلك، يتم تحديث مجموعة التتبع لتسجيل تقدم إدخال البيانات وأي أخطاء تمت مواجهتها. بعد معالجة قسم بيانات، تحاول الأداة الاستعلام عن القسم المصدر التالي المتوفر. يستمر في معالجة قسم المصدر التالي حتى يتم ترحيل جميع البيانات. تتوفر الشفرة المصدرية للأداة في إعادة امتصاص الجزء الأكبر من Azure Cosmos DB.

إعداد أداة الترحيل

تحتوي مجموعة التعقب على مستندات كما هو موضح في المثال التالي. سترى مثل هذه الوثائق واحدة لكل قسم في البيانات المصدر. يحتوي كل مستند على بيانات التعريف لقسم البيانات المصدر مثل موقعه وحالة الترحيل والأخطاء (إن وجدت):

{ 
  "owner": "25812@bulkimporttest07", 
  "jsonStoreEntityImportResponse": { 
    "numberOfDocumentsReceived": 446688, 
    "isError": false, 
    "totalRequestUnitsConsumed": 3950252.2800000003, 
    "errorInfo": [], 
    "totalTimeTakenInSeconds": 188, 
    "numberOfDocumentsImported": 446688 
  }, 
  "storeType": "AZURE_BLOB", 
  "name": "sourceDataPartition", 
  "location": "sourceDataPartitionLocation", 
  "id": "sourceDataPartitionId", 
  "isInProgress": false, 
  "operation": "unpartitioned-writes", 
  "createDate": { 
    "seconds": 1561667225, 
    "nanos": 146000000 
  }, 
  "completeDate": { 
    "seconds": 1561667515, 
    "nanos": 180000000 
  }, 
  "isComplete": true 
}

المتطلبات الأساسية لترحيل البيانات

قبل بدء ترحيل البيانات، هناك بعض المتطلبات الأساسية التي يجب مراعاتها:

حجم البيانات التقريبي:

قد لا يتم تعيين حجم البيانات المصدر إلى حجم البيانات في Azure Cosmos DB. يمكن إدراج بعض المستندات العينة من المصدر للتحقق من حجم البيانات الخاصة بهم في Azure Cosmos DB. اعتماداً على حجم المستند عينة، يمكن تقدير حجم البيانات الإجمالي في Azure Cosmos DB بعد الترحيل.

على سبيل المثال، إذا كان كل مستند بعد الترحيل في Azure Cosmos DB حوالي 1 كيلوبايت وإذا كان هناك حوالي 60 مليار مستند في مجموعة البيانات المصدر، فهذا يعني أن الحجم المقدر في Azure Cosmos DB سيكون قريباً من 60 تيرابايت.

حاويات ما قبل الإنشاء مع وحدات طلب كافية:

على الرغم من أن Azure Cosmos DB يقوم بتحجيم التخزين تلقائياً، إلا إنه ليس من المستحسن البدء من أصغر حجم حاوية. الحاويات الصغيرة لديها أقل توافر لمعدل النقل، ما يعني أن الترحيل سيستغرق وقتاً أطول بكثير لإكمال. بدلاً من ذلك، من المفيد إنشاء حاويات بحجم البيانات النهائي (كما هو مقدر في الخطوة السابقة) والتأكد من أن ترحيل حمل العمل يستهلك معدل النقل المخصص بالكامل.

في الخطوة السابقة. وبما أن حجم البيانات يقدر بحوالي 60 تيرابايت، فإن حاوية لا تقل عن 2.4 مليون وحدة طلب مطلوبة لاستيعاب مجموعة البيانات بأكملها.

تقدير سرعة الترحيل:

بافتراض أن عبء العمل المتعلق بالترحيل يمكن أن يستهلك كامل معدل النقل المقدم، فإن ما يتم توفيره في جميع أنحاء المشروع سيوفر تقديراً لسرعة الترحيل. متابعة للمثال السابق، يلزم وجود 5 وحدات طلب لكتابة مستند 1 كيلوبايت إلى Azure Cosmos DB API لحساب NoSQL. 2.4 مليون وحدة طلب تسمح بنقل 480,000 وثيقة في الثانية (أو 480 ميغابايت/ثانية). هذا يعني أن الترحيل الكامل لـ60 تيرابايت سيستغرق 125,000 ثانية أو حوالي 34 ساعة.

في حال أردت إتمام الترحيل خلال يوم واحد، يجب زيادة معدل النقل المخصص إلى 5 ملايين وحدة معالجة.

إيقاف الفهرسة:

وبما أنه ينبغي إتمام عملية الترحيل في أقرب وقت ممكن، فمن المستحسن تقليل الوقت ووحدات البحث عن المهاجرين التي أنفقت على وضع فهارس لكل من الوثائق التي تم تناولها. تفهرس Azure Cosmos DB تلقائياً جميع الخصائص، فمن المفيد للحد من الفهرسة إلى عدد قليل من المصطلحات المحددة أو إيقاف تشغيله تماماً لمسار الترحيل. يمكنك إيقاف تشغيل نهج فهرسة الحاوية عن طريق تغيير indexingMode إلى لا شيء كما هو موضح أدناه:

  { 
        "indexingMode": "none" 
  }

بعد اكتمال الترحيل، يمكنك تحديث الفهرسة.

عملية الترحيل

بعد إكمال المتطلبات الأساسية، يمكنك ترحيل البيانات بالخطوات التالية:

  1. أولاً استيراد البيانات من المصدر إلى Azure Blob Storage. لزيادة سرعة الترحيل، من المفيد التوازي عبر أقسام المصدر المتميزة. قبل بدء الترحيل، يجب تقسيم مجموعة البيانات المصدر إلى ملفات بحجم 200 ميغابايت.

  2. يمكن توسيع نطاق مكتبة المنفذ الأكبر، لاستهلاك وحدات الطلب 500,000 في جهاز ظاهري لعميل واحد. نظرا لأن معدل النقل المتاح هو 5 ملايين وحدة طلب، يجب توفير 10 أجهزة ظاهرية Ubuntu 16.04 (Standard_D32_v3) في نفس المنطقة حيث توجد قاعدة بيانات Azure Cosmos DB. يجب إعداد هذه الأجهزة الظاهرية باستخدام أداة الترحيل وملف الإعدادات الخاصة به.

  3. تشغيل خطوة قائمة الانتظار على أحد الأجهزة الظاهرية للعميل. تنشئ هذه الخطوة مجموعة التعقب التي تقوم بمسح حاوية ADLS وإنشاء مستند تعقب التقدم لكل من ملفات القسم الخاصة بمجموعة البيانات المصدر.

  4. بعد ذلك، قم بتشغيل خطوة الاستيراد على جميع الأجهزة الظاهرية للعميل. يمكن لكل عميل أن يأخذ ملكية قسم مصدر ويُدخِل بياناته في Azure Cosmos DB. بمجرد الانتهاء من ذلك وتحديث حالته في مجموعة التتبع، يمكن للعملاء بعد ذلك الاستعلام عن القسم المصدر التالي المتاح في مجموعة التتبع.

  5. تستمر هذه العملية حتى يتم إدخال مجموعة كاملة من أقسام المصدر. بمجرد معالجة جميع أقسام المصدر، يجب إعادة تشغيل الأداة على وضع تصحيح الأخطاء على نفس مجموعة التعقب. هذه الخطوة مطلوبة لتعريف أقسام المصدر التي يجب إعادة معالجتها بسبب أخطاء.

  6. قد تكون بعض هذه الأخطاء بسبب مستندات غير صحيحة في البيانات المصدر. وينبغي تحديد هذه الخطوات وإصلاحها. بعد ذلك، يجب إعادة تشغيل خطوة الاستيراد على الأقسام الفاشلة لإعادة إعادة تشغيلها.

بمجرد اكتمال الترحيل، يمكنك التحقق من صحة أن عدد المستندات في Azure Cosmos DB هو نفس عدد المستندات في قاعدة البيانات المصدر. في هذا المثال، الحجم الإجمالي في Azure Cosmos DB تحول إلى 65 تيرابايت. بعد الترحيل، يمكن تشغيل الفهرسة بشكل انتقائي ويمكن خفض وحدات الطلب إلى المستوى المطلوب من خلال عمليات حمل العمل.

الخطوات التالية

  • تعرف على المزيد من خلال تجربة نماذج التطبيقات التي تستهلك مكتبة المنفذ المجمع في .NET وJava.
  • تم دمج مكتبة المنفذ المجمع في موصل Azure Cosmos DB Spark، لمعرفة المزيد، راجع مقالة موصل Azure Cosmos DB Spark .
  • اتصل بفريق منتجات Azure Cosmos DB من خلال فتح تذكرة دعم ضمن نوع المشكلة "إرشادات عامة" ونوع المشكلة الفرعي "عمليات الترحيل الكبيرة (TB+)" للحصول على مساعدة إضافية في عمليات الترحيل واسعة النطاق.
  • هل تحاول القيام بتخطيط السعة للترحيل إلى Azure Cosmos DB؟ يمكنك استخدام معلومات حول مجموعة قاعدة البيانات الموجودة لتخطيط السعة.