الانطلاق اجتماعيًا مع قاعدة بيانات Azure Cosmos

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

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

وكمهندسين أو مطورين، ربما تساءلت عن كيفية تخزين هذه الشبكات لبياناتك وربطها. أو ربما تم تكليفك بإنشاء أو تصميم شبكة اجتماعية جديدة لسوق متخصص معين. وهنا يظهر السؤال المهم: كيف يتم تخزين كل هذه البيانات ؟

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

إذن، كيف تخزن هذه البيانات وأين ؟

قد يكون لديك خبرة في قواعد بيانات SQL أو لديك فكرة النمذجة العلائقية للبيانات. يمكنك البدء في رسم شيء كما يلي:

بنية بيانات طبيعية وجميلة تماما... هذا لا يتدرج

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

لماذا لا SQL الخيار الأفضل في هذا السيناريو ؟ دعونا نلقي نظرة على هيكل أحد البنيات. في حال أردت إظهار المنشور في موقع ويب أو تطبيق، فسأضطر إلى إجراء استعلام باستخدام...من خلال ضم ثمانية جداول (!) فقط لعرض منشور واحدة. تخيل الآن مجموعة من المشاركات التي يتم تحميلها ديناميكيًا وتظهر على الشاشة، وقد ترى إلى أين أنا ذاهب.

يمكنك استخدام مثيل SQL هائل مع طاقة كافية لحل آلاف الاستعلامات مع العديد من الصلات لخدمة المحتوى الخاص بك. ولكن لماذا تفعل ذلك، عندما يكون هناك حل أبسط ؟

طريق NoSQL

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

{
    "id":"ew12-res2-234e-544f",
    "title":"post title",
    "date":"2016-01-01",
    "body":"this is an awesome post stored on NoSQL",
    "createdBy":User,
    "images":["https://myfirstimage.png","https://mysecondimage.png"],
    "videos":[
        {"url":"https://myfirstvideo.mp4", "title":"The first video"},
        {"url":"https://mysecondvideo.mp4", "title":"The second video"}
    ],
    "audios":[
        {"url":"https://myfirstaudio.mp3", "title":"The first audio"},
        {"url":"https://mysecondaudio.mp3", "title":"The second audio"}
    ]
}

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

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

يمكن التعامل مع التعليقات على منشور على أنه مشاركات أخرى مع خاصية أصلية. (هذا التدريب العملي يبسط تعيين الكائن.)

{
    "id":"1234-asd3-54ts-199a",
    "title":"Awesome post!",
    "date":"2016-01-02",
    "createdBy":User2,
    "parent":"ew12-res2-234e-544f"
}

{
    "id":"asd2-fee4-23gc-jh67",
    "title":"Ditto!",
    "date":"2016-01-03",
    "createdBy":User3,
    "parent":"ew12-res2-234e-544f"
}

ويمكن تخزين جميع التفاعلات الاجتماعية على كائن منفصل كعدادات:

{
    "id":"dfe3-thf5-232s-dse4",
    "post":"ew12-res2-234e-544f",
    "comments":2,
    "likes":10,
    "points":200
}

إن إنشاء الخلاصات هو مجرد مسألة إنشاء مستندات يمكنها الاحتفاظ بقائمة بمعرفات المنشورات بترتيب صلة محدد:

[
    {"relevance":9, "post":"ew12-res2-234e-544f"},
    {"relevance":8, "post":"fer7-mnb6-fgh9-2344"},
    {"relevance":7, "post":"w34r-qeg6-ref6-8565"}
]

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

يمكن إنشاء تدفقات الخلاصة باستخدام العمليات الخلفية لـ Azure App Services: Webjobs. بمجرد إنشاء منشور، يمكن تشغيل معالجة الخلفية باستخدام قوائم انتظارتخزين Azure ووظائف الويب التي يتم تشغيلها باستخدام Azure Webjobs SDK، وتنفيذ نشر المنشور داخل التدفقات استنادا إلى منطقك المخصص.

يمكن معالجة النقاط و الإعجابات عبر منشور بطريقة مؤجلة باستخدام نفس التقنية لإنشاء بيئة متناسقة في نهاية المطاف.

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

{
    "id":"234d-sd23-rrf2-552d",
    "followersOf": "dse4-qwe2-ert4-aad2",
    "followers":[
        "ewr5-232d-tyrg-iuo2",
        "qejh-2345-sdf1-ytg5",
        //...
        "uie0-4tyg-3456-rwjh"
    ]
}

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

لحل هذه المشكلة، يمكنك استخدام نهج مختلط. كجزء من مستند إحصائيات المستخدم يمكنك تخزين عدد المتابعين:

{
    "id":"234d-sd23-rrf2-552d",
    "user": "dse4-qwe2-ert4-aad2",
    "followers":55230,
    "totalPosts":452,
    "totalPoints":11342
}

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

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

نمط "السلم" وازدواجية البيانات

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

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

ستقوم بحلها عن طريق تحديد السمات الرئيسية للمستخدم الذي تظهره في التطبيق الخاص بك لكل نشاط. في حال كنت تعرض منشورًا مرئيًا في تطبيقك وتعرض فقط اسم المنشئ وصورته، فلماذا تخزن جميع بيانات المستخدم في السمة "createdBy"؟ في حال قمت فقط بعرض صورة المستخدم لكل تعليق، فأنت لا تحتاج حقًا إلى بقية معلومات المستخدم. هذا هو المكان الذي أصبح فيه شيء أسميه "نمط السلم" متورطًا.

لنأخذ معلومات المستخدم كمثال:

{
    "id":"dse4-qwe2-ert4-aad2",
    "name":"John",
    "surname":"Doe",
    "address":"742 Evergreen Terrace",
    "birthday":"1983-05-07",
    "email":"john@doe.com",
    "twitterHandle":"\@john",
    "username":"johndoe",
    "password":"some_encrypted_phrase",
    "totalPoints":100,
    "totalPosts":24
}

من خلال النظر إلى هذه المعلومات، يمكنك اكتشاف المعلومات المهمة وغير المهمة بسرعة، وبالتالي إنشاء "سلم":

أصغر خطوة تسمى UserChunk، وهو الحد الأدنى من المعلومات التي تحدد هوية المستخدم ويتم استخدامها لنسخ البيانات. من خلال تقليل حجم البيانات المكررة إلى المعلومات التي "ستظهرها" فقط، فإنك تقلل من إمكانية حدوث تحديثات هائلة.

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

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

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

{
    "id":"dse4-qwe2-ert4-aad2",
    "name":"John",
    "surname":"Doe",
    "username":"johndoe"
    "email":"john@doe.com",
    "twitterHandle":"\@john"
}

ووظيفة ستبدو مثل :

{
    "id":"1234-asd3-54ts-199a",
    "title":"Awesome post!",
    "date":"2016-01-02",
    "createdBy":{
        "id":"dse4-qwe2-ert4-aad2",
        "username":"johndoe"
    }
}

عندما ينشأ تحرير حيث تتأثر سمة قطعة، يمكنك بسهولة العثور على المستندات المتأثرة. استخدم فقط الاستعلامات التي تشير إلى السمات المفهرسة، مثل SELECT * FROM posts p WHERE p.createdBy.id == "edited_user_id"، ثم قم بتحديث القطع.

مربع البحث

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

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

لماذا هذه العملية بهذه السهولة ؟

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

لمزيد من المعلومات حول Azure الذكاء الاصطناعي Search، يمكنك زيارة دليل Hitchhiker للبحث.

المعرفة الأساسية

بعد تخزين كل هذا المحتوى الذي ينمو وينمو كل يوم، قد تجد التفكير: ماذا يمكنني أن أفعل مع كل هذا التدفق من المعلومات من المستخدمين ؟

الجواب واضح: ضعه في العمل وتعلم منه.

ولكن ماذا يمكنك أن تتعلم ؟ تتضمن بعض الأمثلة السهلة تحليل المشاعر ، أو توصيات المحتوى بناء على تفضيلات المستخدم ، أو حتى مشرف محتوى آلي يتأكد من أن المحتوى المنشور بواسطة شبكتك الاجتماعية آمن للعائلة.

الآن بعد أن الارتباط، ربما تعتقد أنك بحاجة إلى بعض الدكتوراه في علوم الرياضيات لاستخراج هذه الأنماط والمعلومات من قواعد البيانات والملفات البسيطة، لكنك ستكون مخطئًا.

Azure التعلم الآلي، هي خدمة سحابية مدارة بالكامل تتيح لك إنشاء مهام سير عمل باستخدام الخوارزميات في واجهة سحب وإفلات بسيطة، أو ترميز الخوارزميات الخاصة بك في R، أو استخدام بعض واجهات برمجة التطبيقات التي تم إنشاؤها بالفعل وجاهزة لاستخدامها مثل: Text Analytics أو Content Moderator أو Recommendations.

لتحقيق أي من هذه السيناريوهات التعلم الآلي، يمكنك استخدام Azure Data Lake لاستيعاب المعلومات من مصادر مختلفة. يمكنك أيضا استخدام U-SQL لمعالجة المعلومات وإنشاء إخراج يمكن معالجته بواسطة التعلم الآلي من Azure.

هناك خيار آخر متاح وهو استخدام خدمات Azure الذكاء الاصطناعي لتحليل محتوى المستخدمين؛ ليس فقط يمكنك فهمها بشكل أفضل (من خلال تحليل ما يكتبونه باستخدام واجهة برمجة تطبيقات تحليلات النص)، ولكن يمكنك أيضا اكتشاف المحتوى غير المرغوب فيه أو الناضج والعمل وفقا لذلك مع واجهة برمجة تطبيقات Computer Vision. تتضمن خدمات Azure الذكاء الاصطناعي العديد من الحلول الجاهزة التي لا تتطلب أي نوع من معرفة التعلم الآلي لاستخدامها.

تجربة اجتماعية على نطاق الكوكب

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

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

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

يقوم Azure Cosmos DB بتشغيل استعلاماتك (بما في ذلك التجميعات) عبر جميع أقسامنا بشفافية، لذلك لا تحتاج إلى إضافة أي منطق مع نمو بياناتك.

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

ماذا يحدث إذا تحسنت الأمور ؟ لنفترض أن المستخدمين من بلد/منطقة أخرى أو قارة أخرى يلاحظون النظام الأساسي الخاص بك ويبدأون في استخدامه. يا لها من مفاجأة عظيمة !

لكن انتظر! سرعان ما تدرك أن تجربتهم مع منصتك ليست مثالية. إنهم بعيدون جدًا عن منطقتك التشغيلية لدرجة أن زمن الانتقال مروع. من الواضح أنك لا تريدهم أن يستقيلوا. إلا إذا كان هناك طريقة سهلة لتوسيع نطاق العالمية الخاصة بك ؟ هناك!

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

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

Conclusion

تلقي هذه المقالة بعض الضوء على بدائل إنشاء الشبكات الاجتماعية تماما على Azure مع خدمات منخفضة التكلفة. فهو يحقق نتائج من خلال تشجيع استخدام حل تخزين متعدد الطبقات وتوزيع البيانات يسمى "سلم".

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

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

لمعرفة المزيد حول حالات استخدام Azure Cosmos DB، راجع حالات استخدام Azure Cosmos DB الشائعة.