قُصاصات

البنية التحتية (Infrastructure) هي مجموع المكونات والموارد التي تعمل معا كقاعدة لتشغيل مشروعك، كالسيرفرات المطلوبة للتشغيل أو لتخزين البيانات، والشبكات والـ IPs وإعداداتها، أو الـ Domains وإعدادات الـ DNS وغيرها.

كل جزء من أجزاء الـ Infrastructure تحصل عليه من أحد مزودي الخدمة، وإدارة هذه الموارد أو المكونات تتم عادة بالدخول إلى لوحة تحكم خاصة بكل مزود خدمة وإنشاء الموارد أو تعديلها.

فأدخل مثلا إلى لوحة تحكم مزود خدمة السيرفرات لإنشاء بعض السيرفرات والـ Firewalls وإعدادات الشبكة فيما بينها، ثم أدخل إلى مزود خدمة الـ DNS لتعديل إعدادات الـ DNS، ثم إلى مزود خدمة الإيميلات والـ SMTP… وهكذا

الـ Transaction هو مجموعة من الـ Queries المتتالية، تُجمّع وتنفَّذ كوحدة واحدة (Logical Unit of Work).

تنفِّذ البرامج غالبا مجموعة من العمليات المرتبطة بعضها ببعض على قاعدة البيانات، فعملية تحويل مبلغ مالي من حساب لآخر في برنامج للحوالات المالية قد تجري كالآتي:

 1import time
 2
 3
 4start_time = time.time()
 5longProcess()
 6end_time = time.time()
 7
 8
 9if end_time - start_time < 5:
10    doSomething()

هذا الكود بسيط جدا، وقد يعمل بشكل طبيعي لسنوات طويلة، لكنه قد يتعطل فجأة يوما ما ويسبب مشاكل كبيرة جدا!!

تنقسم قواعد البيانات من حيث طريقة تخزين البيانات على مستوى الجداول إلى نوعين:

1. Row-oriented Database
2. Column-oriented Database

هذا التقسيم متعلق بآلية التخزين في الـ Storage System.

التخزين في الـ Row-Oriented Databases

يتم تخزين القيم الخاصة بنفس الـ Entity على صف واحد بحيث تكون كلها متتالية، وهذا هو الافتراضي في قواعد البيانات المعروفة كـ PostgreSQL و SQLite.

من الإعدادات المفيدة في MariaDB / MySQL، هي إعدادات الـ Slow Query Log،

وهي من الطرق التي تستخدم (بدون أدوات مراقبة خارجية) لمعرفة الـ Queries البطيئة في قاعدة البيانات،

يمكنك تحديد عدد الثواني التي إذا تجاوزها وقت تشغيل الـ Query يعتبر بطيئا.

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

بروتوكول HTTP يستخدم Request-Response model، مما يعني أن السيرفر لا يستطيع إرسال بيانات إلى الـ Client ما لم يقم الـ Client أولا بإرسال Request.

لكن يمكن استخدام SSE (Server Sent Events) لإرسال البيانات من السيرفر للـ Client، لا يزال الـ Client بحاجة إلى إرسال Request أولا، لكن يتم استخدام Keep-Alive لإبقاء الاتصال مفتوحا، والسيرفر سيرسل البيانات دون انهاء الـ Response، في الصورة السابقة تجد أنه قد تم إرسال أكثر من رسالة من السيرفر إلى الـ Client في أوقات مختلفة، كلها تعتبر Response واحدة لكن تم تقسيما وإرسالها بالتدريج،

اقوم اليوم ببعض التجارب المتعلقة ببروتوكول HTTP لفهمه بشكل أعمق،

حاولت إرسال الـ Request باستخدام netcat عبر TCP مباشرة دون استخدام HTTP Client.

الصورة المرفقة توضح الفرق بين نسخة HTTP 1.0 و HTTP 1.1.

في النسخة 1.0 ستضطر لإرسال كل HTTP Request باتصال TCP جديد، بينما في النسخة 1.1، يمكن إرسال أكثر من HTTP Request على نفس الاتصال مما يزيد من سرعة العملية (ستختصر الوقت والموارد اللازمة لفتح اتصال جديد).