VOL41: Change Data Capture at Pinterest
أهلًا وسهلا بكم في العدد الواحد والأربعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الواحد والأربعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Change Data Capture at Pinterest
Uber's Docstore Architecture
Core Web Vital
Demystifying SQL Unique Constraints
Introduction Into Caching in .NET
Change Data Capture at Pinterest
في عالم النهاردة واللي بيعتمد على البيانات بشكل كبير، الشركات محتاجة تعالج وتحلل البيانات بشكل لحظي عشان تاخد قرارات صح. وتقنية الـ Change Data Capture (CDC) ظهرت كحل سحري واعتمدت عليها Pinterest في قواعد بياناتها .
الـ CDC بتساعد المؤسسات إنها تتابع وتلتقط التغييرات اللي بتحصل في قواعد البيانات بتاعتها بكفاءة وعشان كده في المقال ده، هنكتشف يعني إيه CDC، وليه هي مهمة، وإزاي Pinterest قدروا يطبقوا حلول الـ CDC بشكل عام لكل قواعد البيانات بتاعتهم.
يعني إيه Change Data Capture؟
الـ CDC عبارة عن مجموعة من أنماط التصميم اللي بتستخدم لتحديد وتتبع التغييرات في قاعدة البيانات، زي الإضافات (inserts)، والتحديثات (updates)، وعمليات الحذف (deletes).
التقنية دي بتسمح للتطبيقات إنها تستجيب للتغييرات دي في وقت لحظي Realtime، وده بيخليها جزء أساسي في تكامل البيانات (Data Integration)، وكذلك في الـ (replication)، وعملية المزامنة الخاصة بقواعد البيانات وبعضها.
ليه الـ CDC مهمة؟
معالجة البيانات بشكل لحظي (Realtime): الـ CDC بتمكّننا من معالجة البيانات لحظة بلحظة عن طريق انها بتلتقط التغييرات أول بأول. وده مهم للتطبيقات اللي بتحتاج معلومات محدثة الـ
Fraud Detection Systemsأو الـRecommendation Engines.تكامل البيانات (Data Integration): من خلال التقاط التغييرات أول بأول، الـ CDC بتسهّل تكامل البيانات بين أنظمة مختلفة. وده مفيد في البيئات اللي فيها تطبيقات متعددة بتحتاج توصل لنفس البيانات وتعالجها وممكن تكون ليها قواعد بيانات مختلفة ولكن هي محتاجة نفس البيانات.
تقليل الحمل على الـ Source Systems: بدل ما نعمل تحميل كامل للبيانات ونعملها كلها Loading وبعدين ننقلها كلها .. فالـ CDC بتسحب التغييرات اللي حصلت، وده بيقلل الحمل على الأنظمة المصدرية وبيحسّن الأداء.
الـ Audit & Compliance: الـ CDC بتوفر طريقة موثوقة لتتبع التغييرات اللي حصلت وده مناسب جدًا للـ Auditing والـ Compliance، فبتضمن إن كل التعديلات متسجلة وقابلة للتتبع.
رحلة Pinterest في تنفيذ الـ CDC
خلونا دلوقتي نشوف رحلة Pinterest وازاي قدروا يطبقوا وينفذوا الـ CDC في قواعد البيانات بتاعتهم وإنهم يبنوا حاجة Generic تتماشى مع الـ System بتاعهم ونشوف ايه التحديات اللي قابلوها واتصرفوا معاها ازاي.
تحديات الـ CDC السابقة
في الماضي، فرق مختلفة في Pinterest نفذت حلول CDC منفصلة عشان يلبوا احتياجات محددة خاصة بيهم. ورغم إنها كانت فعّالة لغرضها، إلا إن الحلول دي سببت عدم رضا للمستخدمين بسبب التباينات اللي ظهرت، وعدم وضوح المسؤوليات مين مسئول عن ايه، ومشاكل من ناحية الموثوقية أو الـ Reliability.
بناء Generic CDC
عشان فريق Pinterest يحل التحديات دي، قرروا إنهم يبنوا حل CDC Generic ويكون معتمد على Debezium™ من Red Hat. الحل ده بيهدف إلى:
ضمان أنظمة موثوقة (Reliable)، بزمن استجابة منخفض يعني Low-Latency، وتكون قابلة للتوسع Scalable، مع ضمان معالجة البيانات على الأقل مرة واحدة وده اللي بنسميه At Least Once Processing.
دعم الـ Distributed Databases بشكل كبير.
تنفيذ Load Balancing قوي وتقليل التأثير على قواعد البيانات الأساسية.
توفير إمكانيات للـ Configuration والـ Observability متقدمة للمستخدمين.
Pinterest CDC Architecture
البنية التحتية لقواعد البيانات في Pinterest بتتميز بالتوزيع العالي Highly Distribution، وكل وحدة موزعة بنسميها shard. بعض قواعد البيانات الكبيرة ممكن يكون فيها حوالي 10,000 shard. وعلى الرغم من إن Debezium Connector المفتوح المصدر، زي MySQL Connector، بيشتغل بشكل سلس مع shard واحدة فقط.
فالتحدي كان في توافقه مع قواعد البيانات الموزعة بتاعة Pinterest خصوصًا إن هم عندهم Distributed Architecture.
Uber's Docstore Architecture
شركة Uber بتستعمل Docstore وهو عبارة عن قاعدة البيانات الموزعة بتاعتهم واللي مبنية على MySQL و Docstore بتخزن عشرات الـ PetaBytes من البيانات وبتخدم عشرات الملايين من ال Requests في الثانية.
ودي واحدة من أكبر محركات قواعد البيانات عند Uber واللي بتستخدمها كتير من الـ Microservices في كل القطاعات التجارية أو اللي بنسميها Business Verticals عندهم.
والكلام ده من ساعة ما بدأت في 2020، عدد المستخدمين وحالات الاستخدام بتاعت Docstore في ازدياد، وكمان حجم الطلبات والبيانات في زيادة.
Motivation
شركة Uber كانت بتستعمل الـ Schemaless Types من قواعد البيانات , واللي خلتها بعد كده تقابل شوية تحديات كبيرة والي خلتها تتجه لاستعمال Cassandra كـ Database وتبقى كـ General Purpose Database لمعظم الـ Business Verticals.
ولكن مع حجم الـ Scale بتاع Uber كان الـ Operations على Cassandra كبيرة جدًا ومش فعالة بالنسبة ليهم من ناحية الكفاءة بتاعتها والـ Scale بتاع Uber ، بالاضافة كمان لان Cassandra بتدعم الـ Eventual Consistency وده Consistency Level بالنسبة لـ Uber مكنش أفضل حاجة من ناحية المتطلبات بتاعتهم خصوصا ان هم بيطمحوا لتحقيق الـ Strict Serializability Consistency Level.
ومن ثم ظهر الحاجة لتصميم Docstore واللي مبني على MySQL.
Docstore
قاعدة البيانات دي بتتميز بعدة مميزات من ضمنها انها بتوفر الـ Strict Serializability Consistency Model على مستوى الـ Partition وده كان من ضمن المتطلبات اللي Uber عاوزة تحققها وبالتالي نقدر نستنج هنا ان Uber بتضحي بالـ Availability في سبيل الـ Consistency من ناحية نظرية الـ CAP Theorem.
كمان نقدر نـ Scale Horizontally واللي اتاح الفرصة لـ Uber انها بالشكل ده قاعدة البيانات تكون بتدعم وبتخدم عدد كبير من الـ Heavy Workloads اللي عندهم.
ومش بس كده ده كمان بتوفر مميزات كتير بتحسن من انتاجية المطورين زي الـ Transactions / Materialized Views / CDC بالإضافة للمرونة في عمل الـ Modeling للبيانات وكذلك وفرة من الـ Query Support اللي الـ Clients ممكن يكونوا محتاجينها.
Docstore Architecture
هنلاقي أن Docstore متقسمة بشكل رئيسي لثلاث أجزاء أو طبقات Layers:
1- الـ Stateless Query Engine Layer
2- الـ Stateful Storage Engine Layer
3- الـ Control Plane
وللتذكير Stateless من اسمها يعني مش مسئولة عن الاحتفاظ بأي State نهائيًا أو معلومات ، بينما الـ Stateful فهي بتحتفظ بالـ State أو بعض المعلومات عشان تستفيد منها في أداء شغلها.
Core Web Vital
عمرك سألت نفسك كيف نحكم على أي موقع بأنه Optimized (سريع وسلسل وبيحمل في أقل وقت ممكن)؟ من هنا ظهر ال CORE WEB VITAL من خلال فريق عمل Google علشان يقيسوا أداء تجربة
المستخدم للموقع من خلال 3 مقاييس أساسية وهما و CLS و LCP و INP.
محددات الأداء الرئيسية
(LCP): اختصار ل Largest Contentful Paint ودي بتقيس الوقت الي بياخذه تحميل وعرض أكبر عنصر في الصفحة بداية من الضغط علي لنك الموقع حتى عرض وظهور العنصر ده علي الشاشة .
(CLS): اختصار ل Cumulative Layout Shift ودا عبارة عن مقياس بيعبر عن مدى ثبات محتوى الموقع اثناء تحميل باقي العناصر .
(INP): اختصار ل Interaction to Next Paint وده بيقيس الوقت اللي بياخذه الموقع بداية من تفاعل المستخدم (زي الضغط أو الكتابة) حتى استجابة الموقع وتحديث الصفحة .
Largest Contentful Paint
تعال نمسكهم واحد واحد, الأول وهو الـ LCP وهو مسئول عن قياس سرعة تحميل الصفحة
وهذا عن طريق قياس الوقت اللازم لتحميل أكبر عنصر في الصفحة سواء نص أو صورة أو فديو ولازم يكون أقل من 2.5 ثانية عشان نقول إنه optimized . وهو مكون من مجموع 4 عناصر أساسية وهي :
(Time to First Byte (TTFB
Resource load delay
Resource load duration
Element render delay
LCP = Time to First Byte (TTFB) + Resource load delay + Resource load duration + Element render delay
أولاً الـ Time to First Byte (TTFB) وهو الوقت الي بياخذه ال browser علشان يستلم أول byte من بداية ضغط ال user علي link الموقع , و الثاني هو Resource load delay وهو الوقت الي بياخذه الموقع علشان يحمل المكونات وملفات الموقع زي ملفات ال css والفونت وهكذا وثالث مكون وهو الـ Resource load duration وهذا وقت الي بيتحمل فيه العنصر نفسه وآخر حاجة هو Element render delay وهو الوقت الي بيتأجل فيه عرض العنصر لحين اكتمال تحميل باقي العناصر زي ملفات ال js مثلا .
ومن هنا بنلاحظ إنه مش شرط تقليل حجم عنصر ال LCP بالضرورة يساهم في تقليل ال LCP ودا لأنه في بعض الحالات بيحصل ترحيل للوقت ده ل ال Element Render Delay مثل ماهو موضح في الصورة رقم 3 وده بيحصل في حالات قليلة جدًا لأنه نسبة ال Element Render Delay بتكون أقل من 10 % .
خصم الـ 50% مستمر ولحد نهاية السنة بمناسبة مفاجآت اقرأ-تِك وشكلها الجديد ، فتقدروا دلوقتي تشتركوا في اقرأ-تِك (بـ 30 جنيه) بس شهريًا 😉 والحقوا الخصم ده لانه مش بيتكرر الا في المناسبات الجميلة اللي زي دي بس 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
Demystifying SQL Unique Constraints
المقال ده هيكون جزء من مجموعة مقالات هنبدا نتكلم فيها عن ال Constraints وبانوعها وايه ممكن يسبب Violation ليهم وفي طرقنا نبدأ نتكلم شوية عن ازي نحافظ علي ال Data Integrity للبيانات الي بنتعامل معاها بحيث ان ده ميكونش سبب ل Logical Errors في ال Reports.
ما هي ال SQL Constraints
الـ SQL Constraints هي قواعد تُطبق على أعمدة الجداول في قواعد البيانات عشان نضمان سلامة البيانات وصحتها، وهي جزء مهم من تصميم قواعد البيانات لأنها بتساعد في اننا نتحكم في نوع البيانات المدخلة وحمايتها من الأخطاء.
الأنواع الأساسية من الـ SQL Constraints
NOT NULL: ودي بنستخدمها لو احنا عندنا Column معين او اكتر محتاجين ميتضفش فيه اي NULL Values
UNIQUE: ودي بنستخدمها عشان نتاكد ان الدتا بتاعتنا Unique ومفيش اي دتا متكررة اكتر من مرة وهنا ممكن نقول ان Column معين لازم ميبقاش فيه تكرار او ان بيانات اكتر من Column سوا مينفعش يتكرروا
PRIMARY KEY: هنا دي بتجمع مابين ال NOT NULL AND UNIQUE سوا وبنستخدمها عشان يبقي عندنا عمود / مجموعة اعمدة معينة القيم بتاعته / بتاعتهم سوا فريدة وبالتالى يكون identifier for each row
Foreign KEY: ده بنستخدمه بحيث يبقي عمود معين يربط بين الجدول الاساسي بتاعنا وجدول تانى ، زي مثلا ان يبقي عندي عمود للاصناف بستخدمه عشان اربط ما بين جدول المبيعات وجدول الاصناف
CHECK: ودي بستخدمها لو انا حبه احط شرط معين زى مثلا ان مينفعش يبقي عمود السن فيه بينات شخص سنه اقل من سن معين
DEFAULT: وده بضيفه مثلا بحيث اقول لو مفيش داتا للعمود ده ممكن اخلي القيمه بتاعته ب 1 بحيث انه ميبقاش ب NULL
SQL UNIQUE Constraint
وده بيكون ليه أهمية كبيرة للـ Business لأنه بيتضمن إدخال قيم فريدة في الأعمدة المحددة، وده هيساعدنا في منع الأخطاء وتعزيز التكامل والدقة في البيانات. وبيتم استخدامه بشكل شائع لضمان عدم تكرار البيانات المهمة التي قد تؤثر على العمليات التجارية أو التحليل.
وده مثال بسيط ازاي بنخلي عمود واحد من اعمدة الجدوال UNIQUE ، هنا انا قولتله انى عايزه ال ID يكون UNIQUE بحيث ان مبقاش فيه شخصين ممكن يكون ليهم نفس ال ID
ولو لاحظنا هنلاقي انى برضو قولتله انى محتاجه ال ( ID, LastName ) يكونوا NOT NULL بحيث مينفعش تسجل بينات شخص انا معرفش ال ID OR LastName بتاعه.
Introduction Into Caching in .NET
التخزين المؤقت (Caching) هو تقنية مهمة جدا لتحسين أداء التطبيقات، خصوصًا في تطبيقات الويب التي تتطلب استرجاع البيانات بشكل سريع وفعال. باختصار، Caching هو عملية تخزين البيانات مؤقتًا في الذاكرة بحيث يمكن الوصول إليها بسرعة في المستقبل بدون الحاجة لاسترجاعها من المصدر الأصلي (زي قاعدة البيانات أو خدمة خارجية). باستخدام Caching، يمكن تحسين أداء التطبيق بشكل كبير وتقليل وقت الاستجابة، مما يعزز تجربة المستخدم.
ما هو Caching؟
التخزين المؤقت يعني تخزين البيانات في الذاكرة لفترة قصيرة بحيث يمكن الوصول إليها بسرعة عند الحاجة مرة تانية. لو في حاجة لقراءة نفس البيانات أكثر من مرة، عادةً ما يكون الوصول إليها من الذاكرة أسرع بكتير من استرجاعها من قاعدة بيانات أو مصدر خارجي. في .NET، فيه أكثر من طريقة لتطبيق التخزين المؤقت، منها MemoryCache و DistributedCache.
أنواع Caching في .NET
في .NET، عندك خيارين أساسيين للتخزين المؤقت:
MemoryCache
هو عبارة عن تخزين مؤقت في الذاكرة المحلية. يتم استخدامه في التطبيقات اللي شغالة على جهاز واحد. البيانات المخزنة في الذاكرة بتكون موجودة فقط في نفس الجهاز أو الخادم.
DistributedCache
بيتم استخدامه في التطبيقات التي تحتاج إلى تخزين البيانات بشكل موزع على أكتر من خادم. ده مفيد جدًا لو كنت شغال في بيئة تستخدم أكثر من خادم أو في بيئة سحابية (مثل Azure أو AWS).
كيفية إضافة Caching في .NET
1. إضافة خدمة Caching
أول حاجة لازم تضيف خدمة التخزين المؤقت في الـ Startup.cs. في حالة استخدام MemoryCache أو الـ Distributed Cache، هتضيفها كده:
ده هيخلي التطبيق جاهز لاستخدام التخزين المؤقت.
2. تخزين البيانات في Cache
دلوقتي بعد ما ضيفنا خدمة الـ Caching، هنستخدمها لتخزين البيانات في الذاكرة. في MemoryCache، بنقدر نستخدم GetOrCreate لتخزين واسترجاع البيانات.
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
