مصطلحات مهمة في عالم الـ System Design 💯 (١٢)
.
.
في البوست اللي فات تكلمنا عن Scalability و Throughput و ACID.
النهارده هنرجع للـ Caching، لكن هنركز على نقطة مهمة: لما البيانات تتغير، إزاي نضمن إن التغيير يوصل للـ Cache والـ Database بالطريقة المناسبة؟
هل نكتب الداتا في الاتنين مباشرة؟ ولا نكتب في الـ Cache الأول ونحدّث الـ Database بعدين؟
الإجابة بتعتمد على الـ Caching Pattern اللي بنستخدمه...
———
📌 Write-Through Cache
في الـ Write-Through Cache، لما يحصل Write أو Update، التطبيق بيكتب البيانات في الـ Cache والـ Database في نفس العملية.
بمعنى:
Application → Cache → Database
الـ Cache بيستقبل التغيير، وبعدها يكتبه مباشرة في الـ Database.
الميزة هنا إن الـ Cache والـ Database بيكونوا متزامنين بشكل أفضل، لأن كل Write لازم يعدّي على الاتنين.
وده بيقلل احتمالية إن الـ Cache يحتوي على بيانات قديمة بعد عملية Update.
لكن فيه مقابل.
كل Write بيحتاج وقت إضافي، لأننا مش بنحدّث مكان واحد فقط. كمان ممكن نكتب بيانات في الـ Cache حتى لو مش هيتم قراءتها مرة تانية.
تخيل إن عندك Product Price بيتغير، والـ Application بيكتب السعر الجديد في الـCache والـDatabase فورًا.
كده أي Read بعد التحديث يقدر يجيب السعر الجديد من الـ Cache.
لكن لو عايزين سرعة أكبر في عمليات الكتابة، ومش مهم البيانات توصل للـDatabase في نفس اللحظة؟
هنا نستخدم Pattern مختلف.
———
📌 Write-Behind Cache
في الـ Write-Behind Cache، التطبيق بيكتب البيانات في الـCache أولًا، وبعدها الـCache يحدّث الـDatabase بشكل asynchronous.
بمعنى:
Application → Cache → Database Later
الـApplication يقدر يكمل شغله بسرعة، من غير ما يستنى عملية الكتابة في الـDatabase تخلص.
تخيل تطبيق بيستقبل عدد ضخم من تحديثات الـProduct Views.
بدل ما كل View تعمل Write مباشر على الـDatabase، نقدر نكتب الـUpdates في الـCache، وبعدها نجمعها ونبعتها للـDatabase على دفعات.
ده ممكن يحسّن أداء الكتابة ويقلل الضغط على الـDatabase.
لكن هنا فيه Risk مهم:
لو البيانات موجودة في الـCache ولسه ما اتكتبتش في الـDatabase، وحصل Cache Failure أو System Crash، ممكن نفقد التحديثات اللي متعملهاش Persist لسه.
عشان كده الـ Write-Behind Cache مناسب لبعض السيناريوهات اللي تقدر تستحمل تأخير الكتابة أو فقدان جزء من البيانات، لكنه مش مناسب تلقائيًا لكل العمليات الحساسة، زي التحويلات البنكية.
طيب، خلينا نفترض إن عندنا Cache كبير موزع على كذا Server.
إزاي نقرر كل Key هيتخزن على أنهي Server؟
لو استخدمنا توزيع بسيط، زي:
hash(key) % number_of_servers
فكل حاجة هتشتغل كويس لحد ما نضيف Server جديد.
ساعتها معظم الـKeys ممكن تتنقل لمكان مختلف، ونضطر نعيد توزيع كمية ضخمة من البيانات.
وهنا نحتاج الـ Consistent Hashing.
———
📌 Consistent Hashing
الـConsistent Hashing طريقة لتوزيع الـKeys على مجموعة من الـServers أو الـNodes، بحيث لما Node جديدة تدخل أو Node موجودة تخرج، أقل قدر ممكن من البيانات يحتاج يتنقل.
الفكرة إننا بنمثل الـNodes والـKeys على شكل دائرة اسمها Hash Ring.
كل Node بتتحط في مكان على الدائرة باستخدام Hash Function، وكل Key بيتحط هو كمان في مكان معين.
بعدها الـKey بيتخزن على أول Node نلاقيها وإحنا ماشيين في اتجاه معين على الـRing.
لو ضفنا Node جديدة، مش كل الـKeys هتتوزع من الأول.
غالبًا جزء صغير فقط من الـKeys هينتقل للـNode الجديدة.
ولو Node وقعت، الـKeys اللي كانت عليها تقدر تنتقل للـNode التالية حسب قواعد التوزيع.
وده مهم جدًا في الأنظمة الموزعة، خصوصًا مع:
- Distributed Caches
- Distributed Databases
- Load Distribution
- أنظمة فيها Nodes بتزيد وتقل باستمرار
الميزة الأساسية إننا نقدر نعمل Scaling للـCluster من غير ما نعيد توزيع كل البيانات في كل مرة.
لكن التنفيذ العملي محتاج ناخد بالنا من مشكلة اسمها Hotspots، لأن توزيع الـKeys مش دايمًا بيكون متساوي. عشان كده بنستخدم أحيانًا Virtual Nodes لتحسين توزيع البيانات والـLoad.
———
💡 الخلاصة
• الـ Write-Through Cache: الـWrite بيتكتب في الـCache والـDatabase مباشرة.
• الـ Write-Behind Cache: الـWrite بيتخزن في الـCache الأول، وبعدها يتكتب في الـDatabase بشكل asynchronous.
• الـ Consistent Hashing: توزيع الـKeys على Nodes مع تقليل البيانات اللي بتحتاج تتحرك لما الـCluster يتغير.
لكن فيه سؤال مهم:
هل تقسيم البيانات على Nodes مختلفة هو الحل الوحيد؟ ولا فيه طرق تانية لتقسيم البيانات حسب شكلها وطريقة استخدامها؟
———
#system_design
.
.
في البوست اللي فات تكلمنا عن Scalability و Throughput و ACID.
النهارده هنرجع للـ Caching، لكن هنركز على نقطة مهمة: لما البيانات تتغير، إزاي نضمن إن التغيير يوصل للـ Cache والـ Database بالطريقة المناسبة؟
هل نكتب الداتا في الاتنين مباشرة؟ ولا نكتب في الـ Cache الأول ونحدّث الـ Database بعدين؟
الإجابة بتعتمد على الـ Caching Pattern اللي بنستخدمه...
———
📌 Write-Through Cache
في الـ Write-Through Cache، لما يحصل Write أو Update، التطبيق بيكتب البيانات في الـ Cache والـ Database في نفس العملية.
بمعنى:
Application → Cache → Database
الـ Cache بيستقبل التغيير، وبعدها يكتبه مباشرة في الـ Database.
الميزة هنا إن الـ Cache والـ Database بيكونوا متزامنين بشكل أفضل، لأن كل Write لازم يعدّي على الاتنين.
وده بيقلل احتمالية إن الـ Cache يحتوي على بيانات قديمة بعد عملية Update.
لكن فيه مقابل.
كل Write بيحتاج وقت إضافي، لأننا مش بنحدّث مكان واحد فقط. كمان ممكن نكتب بيانات في الـ Cache حتى لو مش هيتم قراءتها مرة تانية.
تخيل إن عندك Product Price بيتغير، والـ Application بيكتب السعر الجديد في الـCache والـDatabase فورًا.
كده أي Read بعد التحديث يقدر يجيب السعر الجديد من الـ Cache.
لكن لو عايزين سرعة أكبر في عمليات الكتابة، ومش مهم البيانات توصل للـDatabase في نفس اللحظة؟
هنا نستخدم Pattern مختلف.
———
📌 Write-Behind Cache
في الـ Write-Behind Cache، التطبيق بيكتب البيانات في الـCache أولًا، وبعدها الـCache يحدّث الـDatabase بشكل asynchronous.
بمعنى:
Application → Cache → Database Later
الـApplication يقدر يكمل شغله بسرعة، من غير ما يستنى عملية الكتابة في الـDatabase تخلص.
تخيل تطبيق بيستقبل عدد ضخم من تحديثات الـProduct Views.
بدل ما كل View تعمل Write مباشر على الـDatabase، نقدر نكتب الـUpdates في الـCache، وبعدها نجمعها ونبعتها للـDatabase على دفعات.
ده ممكن يحسّن أداء الكتابة ويقلل الضغط على الـDatabase.
لكن هنا فيه Risk مهم:
لو البيانات موجودة في الـCache ولسه ما اتكتبتش في الـDatabase، وحصل Cache Failure أو System Crash، ممكن نفقد التحديثات اللي متعملهاش Persist لسه.
عشان كده الـ Write-Behind Cache مناسب لبعض السيناريوهات اللي تقدر تستحمل تأخير الكتابة أو فقدان جزء من البيانات، لكنه مش مناسب تلقائيًا لكل العمليات الحساسة، زي التحويلات البنكية.
طيب، خلينا نفترض إن عندنا Cache كبير موزع على كذا Server.
إزاي نقرر كل Key هيتخزن على أنهي Server؟
لو استخدمنا توزيع بسيط، زي:
hash(key) % number_of_servers
فكل حاجة هتشتغل كويس لحد ما نضيف Server جديد.
ساعتها معظم الـKeys ممكن تتنقل لمكان مختلف، ونضطر نعيد توزيع كمية ضخمة من البيانات.
وهنا نحتاج الـ Consistent Hashing.
———
📌 Consistent Hashing
الـConsistent Hashing طريقة لتوزيع الـKeys على مجموعة من الـServers أو الـNodes، بحيث لما Node جديدة تدخل أو Node موجودة تخرج، أقل قدر ممكن من البيانات يحتاج يتنقل.
الفكرة إننا بنمثل الـNodes والـKeys على شكل دائرة اسمها Hash Ring.
كل Node بتتحط في مكان على الدائرة باستخدام Hash Function، وكل Key بيتحط هو كمان في مكان معين.
بعدها الـKey بيتخزن على أول Node نلاقيها وإحنا ماشيين في اتجاه معين على الـRing.
لو ضفنا Node جديدة، مش كل الـKeys هتتوزع من الأول.
غالبًا جزء صغير فقط من الـKeys هينتقل للـNode الجديدة.
ولو Node وقعت، الـKeys اللي كانت عليها تقدر تنتقل للـNode التالية حسب قواعد التوزيع.
وده مهم جدًا في الأنظمة الموزعة، خصوصًا مع:
- Distributed Caches
- Distributed Databases
- Load Distribution
- أنظمة فيها Nodes بتزيد وتقل باستمرار
الميزة الأساسية إننا نقدر نعمل Scaling للـCluster من غير ما نعيد توزيع كل البيانات في كل مرة.
لكن التنفيذ العملي محتاج ناخد بالنا من مشكلة اسمها Hotspots، لأن توزيع الـKeys مش دايمًا بيكون متساوي. عشان كده بنستخدم أحيانًا Virtual Nodes لتحسين توزيع البيانات والـLoad.
———
💡 الخلاصة
• الـ Write-Through Cache: الـWrite بيتكتب في الـCache والـDatabase مباشرة.
• الـ Write-Behind Cache: الـWrite بيتخزن في الـCache الأول، وبعدها يتكتب في الـDatabase بشكل asynchronous.
• الـ Consistent Hashing: توزيع الـKeys على Nodes مع تقليل البيانات اللي بتحتاج تتحرك لما الـCluster يتغير.
لكن فيه سؤال مهم:
هل تقسيم البيانات على Nodes مختلفة هو الحل الوحيد؟ ولا فيه طرق تانية لتقسيم البيانات حسب شكلها وطريقة استخدامها؟
———
#system_design
❤2
دورة Pre-CyberSecurity 💯
.
.
دورة مصممة لتأهيل الطلبة لدخول مجال الأمن السيبراني عن طريق دراسة أساسيات الشبكات، أساسيات نظام اللينكس، أساسيات نظام الويندوز، وأساسيات مجال الأمن السيبراني، مع رسم خطة تأسيسية للمبتدئين ومشاركتهم أحدث المصادر التعليمية.
https://netriders.academy/all-courses/pre-cybersecurity
.
.
دورة مصممة لتأهيل الطلبة لدخول مجال الأمن السيبراني عن طريق دراسة أساسيات الشبكات، أساسيات نظام اللينكس، أساسيات نظام الويندوز، وأساسيات مجال الأمن السيبراني، مع رسم خطة تأسيسية للمبتدئين ومشاركتهم أحدث المصادر التعليمية.
https://netriders.academy/all-courses/pre-cybersecurity
❤1
انضم إلى #مجرة - مجتمع المطوّرين ومستجدّات التقنية!
اكتشف أحدث المقالات والأدوات وشارك خبراتك مع مطوّرين من كل مكان.
https://majara.dev/register?ref=alisamir
اكتشف أحدث المقالات والأدوات وشارك خبراتك مع مطوّرين من كل مكان.
https://majara.dev/register?ref=alisamir
❤3
أهم بدائل الـ localStorage 💡
.
.
أحيانًا في مشاريع الـ Front-End، هتحتاج تخزن بعض البيانات على جهاز المستخدم نفسه، بحيث يقدر يوصل لها بسرعة من غير ما يحتاج يتواصل مع السيرفر في كل مرة.
وهنا بيظهر دور الـ Client-Side Storage...
أبسط حاجة كلنا عرفناها في الأول هي الـ localStorage. سهلة جدًا والكود بسيط، وكمان عبارة عن key/value، بس الحقيقة إن localStorage مش دايمًا أحسن حل.
ليه؟ 👇
- الـ size محدود (تقريبًا 5MB).
- كل حاجة بتتخزن كـ string.
- مفيهاش أي نوع من الـ security (ممكن أي حد يقرأها).
- مش scalable لو بتتعامل مع data كبيرة.
علشان كده تعال ندردش شوية عن 4 بدائل للـ localStorage ممكن تساعدك في بعض السيناريوهات المختلفة...
———
📌 IndexedDB
- دي عبارة عن database كاملة داخل الـ browser.
- بتخليك تخزن structured data (objects، arrays…) مش مجرد strings.
- بتتعامل معاها عن طريق APIs أو libraries زي Dexie.js عشان تسهّل الموضوع.
- مناسبة جدًا لو عندك data كبيرة أو offline apps زي Note Apps أو Todo Apps.
- مناسبة للتعامل مع كميات أكبر من البيانات واستعلامات أكثر تعقيدًا.
———
📌 sessionStorage
- نفس فكرة الـ localStorage بالضبط لكن الفرق إنها بتتمسح أول ما الـ tab تتقفل.
- مناسبة لحاجات temporary زي بيانات مؤقتة خاصة بالـ tab أو خطوات form متعددة ودي حاجات مش مهمة علشان تحتفظ بها بعد ما المستخدم يقفل الصفحة.
- حجمها محدود زي الـ localStorage.
———
📌 Cookies
- أقدم وأشهر طريقة لتخزين البيانات في الـ browser.
- ميزتها إنها بتتبعت تلقائي مع كل HTTP Request للـ server.
- مناسبة جدًا للـ authentication (زي الـ JWT tokens أو session IDs).
- بس عيبها إنها صغيرة (حوالي 4KB) وأي data زيادة ممكن تقلل سرعة الـ requests.
- لازم تستخدمها للحاجات الخفيفة والمهمة بس.
———
📌 Service Workers + Cache API
- ده حل advanced شوية، بيستخدم الـ Service Workers مع الـ Cache API.
- بيخليك تخزن responses كاملة من الـ network (زي HTML, CSS, JS, Images).
- ممتاز للـ Progressive Web Apps (PWA) عشان تشتغل offline.
- تقدر تتحكم في caching strategy (مثلًا: Network First, Cache First…).
- مفيد جدًا للأداء (performance) وتحسين تجربة المستخدم.
———
فكر دايمًا قبل ما تستخدم localStorage: هل هو فعلًا الحل المناسب؟ ولا في بديل أفضل يساعدك من ناحية الأداء والأمان؟
———
#frontend
.
.
أحيانًا في مشاريع الـ Front-End، هتحتاج تخزن بعض البيانات على جهاز المستخدم نفسه، بحيث يقدر يوصل لها بسرعة من غير ما يحتاج يتواصل مع السيرفر في كل مرة.
وهنا بيظهر دور الـ Client-Side Storage...
أبسط حاجة كلنا عرفناها في الأول هي الـ localStorage. سهلة جدًا والكود بسيط، وكمان عبارة عن key/value، بس الحقيقة إن localStorage مش دايمًا أحسن حل.
ليه؟ 👇
- الـ size محدود (تقريبًا 5MB).
- كل حاجة بتتخزن كـ string.
- مفيهاش أي نوع من الـ security (ممكن أي حد يقرأها).
- مش scalable لو بتتعامل مع data كبيرة.
علشان كده تعال ندردش شوية عن 4 بدائل للـ localStorage ممكن تساعدك في بعض السيناريوهات المختلفة...
———
📌 IndexedDB
- دي عبارة عن database كاملة داخل الـ browser.
- بتخليك تخزن structured data (objects، arrays…) مش مجرد strings.
- بتتعامل معاها عن طريق APIs أو libraries زي Dexie.js عشان تسهّل الموضوع.
- مناسبة جدًا لو عندك data كبيرة أو offline apps زي Note Apps أو Todo Apps.
- مناسبة للتعامل مع كميات أكبر من البيانات واستعلامات أكثر تعقيدًا.
———
📌 sessionStorage
- نفس فكرة الـ localStorage بالضبط لكن الفرق إنها بتتمسح أول ما الـ tab تتقفل.
- مناسبة لحاجات temporary زي بيانات مؤقتة خاصة بالـ tab أو خطوات form متعددة ودي حاجات مش مهمة علشان تحتفظ بها بعد ما المستخدم يقفل الصفحة.
- حجمها محدود زي الـ localStorage.
———
📌 Cookies
- أقدم وأشهر طريقة لتخزين البيانات في الـ browser.
- ميزتها إنها بتتبعت تلقائي مع كل HTTP Request للـ server.
- مناسبة جدًا للـ authentication (زي الـ JWT tokens أو session IDs).
- بس عيبها إنها صغيرة (حوالي 4KB) وأي data زيادة ممكن تقلل سرعة الـ requests.
- لازم تستخدمها للحاجات الخفيفة والمهمة بس.
———
📌 Service Workers + Cache API
- ده حل advanced شوية، بيستخدم الـ Service Workers مع الـ Cache API.
- بيخليك تخزن responses كاملة من الـ network (زي HTML, CSS, JS, Images).
- ممتاز للـ Progressive Web Apps (PWA) عشان تشتغل offline.
- تقدر تتحكم في caching strategy (مثلًا: Network First, Cache First…).
- مفيد جدًا للأداء (performance) وتحسين تجربة المستخدم.
———
فكر دايمًا قبل ما تستخدم localStorage: هل هو فعلًا الحل المناسب؟ ولا في بديل أفضل يساعدك من ناحية الأداء والأمان؟
———
#frontend
❤3
دردشة سريعة عن الـ Vector Database 💯
.
.
لما تبحث في Google أو تسأل ChatGPT سؤال، أنت غالبًا مش بتدور على كلمات محددة، أنت بتدور على المعنى اللي ورا الكلام.
فمثلًا، لو بحثت عن:
"إزاي أحافظ على بطارية الموبايل؟"
فأنت متوقع إن النظام يفهم إن نتائج زي "نصائح لإطالة عمر البطارية" مرتبطة بسؤالك، حتى لو الكلمات مختلفة تمامًا.
وهنا بيظهر دور الـ Vector Database.
بعكس الـ Databases التقليدية، اللي غالبًا بتتعامل مع البيانات من خلال قيم وكلمات محددة، الـ Vector Database بتساعد الأنظمة على البحث ومقارنة البيانات بناءً على التشابه في المعنى.
وده أحد الأساسيات المهمة وراء تطبيقات الـ AI الحديثة، خصوصًا لما نحتاج نبحث داخل كميات كبيرة من البيانات بطريقة ذكية.
———
📌 يعني إيه Vector Database؟
الـ AI Models لما تيجي تمثل أي معلومة – سواء نص، صورة، أو صوت – مش بتخزنها بشكلها الخام. هي بتحولها لحاجة اسمها Embedding Vector.
الـ Vector ببساطة عبارة عن Array أرقام (زي [0.23, -0.44, 0.91, …]) والأرقام دي بتعبر عن المعنى.
مثال:
- كلمة "cat" و "dog" هتلاقي الـ Vectors بتوعهم قريبين جدًا في الـ Space.
- لكن كلمة "car" هتكون بعيدة عنهم.
بالتالي البحث هنا بيبقى مش بالكلمة نفسها، بالـ Similarity في المعنى.
———
📌 إيه المشكلة مع الـ Databases العادية؟
- الـ MySQL أو MongoDB بتوفر طرق مختلفة للبحث، ومنها الـ Keyword Search والـ Full-Text Search.
- لكن لو عايز تبحث عن حاجة بناءً على التشابه في المعنى، زي البحث عن "kitten" لما تسأل عن "cat"، فهنا الـ Vector Similarity Search بيكون أنسب.
———
📌 إيه وظيفة الـ Vector Database؟
1- تخزين الـ Vectors بشكل efficient.
2- بتوفرلك Similarity Search أو Nearest Neighbor Search بسرعة كبيرة جدًا.
3- تخليك تقدر تسأل بالـ natural language وتاخد نتيجة دقيقة بالمعنى.
———
📌 أمثلة عملية:
- الـ Recommendation Systems: زي Netflix أو Spotify لما يقترحوا حاجة شبه اللي بتحبها.
- الـ Semantic Search: تدور في Documents أو Emails عن "meeting" فيجيبلك حاجات ليها علاقة حتى لو الكلمة مش مكتوبة بالحرف.
- الـ Chatbots: زي ChatGPT لما يرد عليك من Knowledge Base باستخدام أقرب إجابة بالمعنى مش بالكلمة.
———
📌 أمثلة على Vector Databases:
- Pinecone
- Weaviate
- Milvus
- Qdrant
كمان فيه Extensions للـ Databases التقليدية زي PostgreSQL (pgvector).
———
الـ Vector Database مش بديل للـ SQL أو NoSQL، لكنها إضافة قوية جدًا للأنظمة اللي بتعتمد على الذكاء الاصطناعي.
هي السبب إن أي تطبيق ذكي النهارده يقدر يتعامل مع الـ Data بالمعنى مش بالكلمة.
———
#backend #ai #database
.
.
لما تبحث في Google أو تسأل ChatGPT سؤال، أنت غالبًا مش بتدور على كلمات محددة، أنت بتدور على المعنى اللي ورا الكلام.
فمثلًا، لو بحثت عن:
"إزاي أحافظ على بطارية الموبايل؟"
فأنت متوقع إن النظام يفهم إن نتائج زي "نصائح لإطالة عمر البطارية" مرتبطة بسؤالك، حتى لو الكلمات مختلفة تمامًا.
وهنا بيظهر دور الـ Vector Database.
بعكس الـ Databases التقليدية، اللي غالبًا بتتعامل مع البيانات من خلال قيم وكلمات محددة، الـ Vector Database بتساعد الأنظمة على البحث ومقارنة البيانات بناءً على التشابه في المعنى.
وده أحد الأساسيات المهمة وراء تطبيقات الـ AI الحديثة، خصوصًا لما نحتاج نبحث داخل كميات كبيرة من البيانات بطريقة ذكية.
———
📌 يعني إيه Vector Database؟
الـ AI Models لما تيجي تمثل أي معلومة – سواء نص، صورة، أو صوت – مش بتخزنها بشكلها الخام. هي بتحولها لحاجة اسمها Embedding Vector.
الـ Vector ببساطة عبارة عن Array أرقام (زي [0.23, -0.44, 0.91, …]) والأرقام دي بتعبر عن المعنى.
مثال:
- كلمة "cat" و "dog" هتلاقي الـ Vectors بتوعهم قريبين جدًا في الـ Space.
- لكن كلمة "car" هتكون بعيدة عنهم.
بالتالي البحث هنا بيبقى مش بالكلمة نفسها، بالـ Similarity في المعنى.
———
📌 إيه المشكلة مع الـ Databases العادية؟
- الـ MySQL أو MongoDB بتوفر طرق مختلفة للبحث، ومنها الـ Keyword Search والـ Full-Text Search.
- لكن لو عايز تبحث عن حاجة بناءً على التشابه في المعنى، زي البحث عن "kitten" لما تسأل عن "cat"، فهنا الـ Vector Similarity Search بيكون أنسب.
———
📌 إيه وظيفة الـ Vector Database؟
1- تخزين الـ Vectors بشكل efficient.
2- بتوفرلك Similarity Search أو Nearest Neighbor Search بسرعة كبيرة جدًا.
3- تخليك تقدر تسأل بالـ natural language وتاخد نتيجة دقيقة بالمعنى.
———
📌 أمثلة عملية:
- الـ Recommendation Systems: زي Netflix أو Spotify لما يقترحوا حاجة شبه اللي بتحبها.
- الـ Semantic Search: تدور في Documents أو Emails عن "meeting" فيجيبلك حاجات ليها علاقة حتى لو الكلمة مش مكتوبة بالحرف.
- الـ Chatbots: زي ChatGPT لما يرد عليك من Knowledge Base باستخدام أقرب إجابة بالمعنى مش بالكلمة.
———
📌 أمثلة على Vector Databases:
- Pinecone
- Weaviate
- Milvus
- Qdrant
كمان فيه Extensions للـ Databases التقليدية زي PostgreSQL (pgvector).
———
الـ Vector Database مش بديل للـ SQL أو NoSQL، لكنها إضافة قوية جدًا للأنظمة اللي بتعتمد على الذكاء الاصطناعي.
هي السبب إن أي تطبيق ذكي النهارده يقدر يتعامل مع الـ Data بالمعنى مش بالكلمة.
———
#backend #ai #database
❤6
Must-Know Data Structures and Algorithms 💯
https://qabilah.com/posts/must-know-data-structures-and-algorithms-dsa~295140141247234048
———
#software_engineering
https://qabilah.com/posts/must-know-data-structures-and-algorithms-dsa~295140141247234048
———
#software_engineering
Qabilah
Must-Know Data Structures and Algorithms 💯..#dsa - علي سمير
Master essential Data Structures and Algorithms (DSA) for software engineering, computer science, and interview preparation. Enhance your problem-solving skills with this comprehensive guide.
❤3
The Linux Desktop Guide 🚀
Practical desktop Linux guidance for new and intermediate users.
https://thelinuxbook.com
.
.
#linux
Practical desktop Linux guidance for new and intermediate users.
https://thelinuxbook.com
.
.
#linux
دردشة سريعة عن الـ Monolithic Architecture 💯
.
.
مش كل مشروع محتاج Architecture معقدة من البداية.
أحيانًا أبسط حل ممكن يكون هو الأنسب، وده بالضبط جوهر الـ Monolithic Architecture: تطبيق واحد، Codebase واحد، و عملية Deployment واحدة.
لكن بساطة الـ Monolith مش معناها إنه مناسب لكل الحالات، ومع نمو المشروع ممكن تظهر تحديات تخليك تفكر في Architecture مختلفة.
تعال نشوف مع بعض إيه مميزاته وعيوبه، وإمتى يكون اختيار مناسب فعلًا.
———
تخيل إنك بتبني سيستم كامل زي موقع e-commerce فيه:
- الـ UI (front-end).
- الـ business logic (زي إضافة منتجات للسلة، حساب الخصومات).
- الـ database access (CRUD operations).
في الـ Monolithic Architecture… كل ده بيكون في codebase واحد، ويتعمله deploy كـ تطبيق واحد (single unit).
يعني لو عايز تعدل في جزء معين لازم تعمل Deploy للتطبيق كله تاني.
———
📌 مميزات الـ Monolithic Architecture
1- البساطة:
الكود كله في مكان واحد، سهل تفهم العلاقات بين الأجزاء المختلفة.
2- سهولة عملية الـ Development في البداية:
مثالي جدًا للـ MVP أو المشاريع الصغيرة.
3- أداء كويس:
مفيش network latency بين components (كلها في نفس العملية).
4- سهولة الـ Testing:
تقدر تعمل end-to-end test بسهولة لأن كل حاجة في مكان واحد.
———
📌 عيوب الـ Monolithic Architecture
1- صعوبة التوسّع (Scalability):
عايز تكبر جزء واحد بس من السيستم؟ مش هتقدر… لازم تكبر التطبيق كله.
2- الـ Codebase هيبقى ضخم ومعقد مع الوقت:
لما المشروع يكبر، الكود بيبقى صعب أي حد يفهمه ويتعامل معاه.
3- ضعف المرونة في اختيار التكنولوجي:
مش هينفع تبني جزء بـ Node.js وجزء بـ Python، كله لازم يبقى بنفس الـ stack.
4- بطء في عملية الـ Deployment:
أي تعديل صغير لازم هتعمل Deploy التطبيق كله.
5- الـ Reliability ضعيفة:
لو جزء واحد وقع، ممكن يأثر على السيستم كله.
———
📌 إمتى تستخدم Monolithic Architecture؟
- لو بتبني مشروع صغير أو MVP وعايز تجرّب الفكرة بسرعة.
- لو عندك فريق صغير ومحتاج تقلل الـ overhead.
- لو لسه السيستم مش معقد ومش محتاج Scalability عالية.
———
الـ Monolithic: كل حاجة في تطبيق واحد.
الـ Microservices: السيستم متقسم لمجموعة خدمات مستقلة، كل خدمة بتشتغل لوحدها وتقدر تعمل Deploy/Scale/Debug بشكل منفصل.
———
#software_development
.
.
مش كل مشروع محتاج Architecture معقدة من البداية.
أحيانًا أبسط حل ممكن يكون هو الأنسب، وده بالضبط جوهر الـ Monolithic Architecture: تطبيق واحد، Codebase واحد، و عملية Deployment واحدة.
لكن بساطة الـ Monolith مش معناها إنه مناسب لكل الحالات، ومع نمو المشروع ممكن تظهر تحديات تخليك تفكر في Architecture مختلفة.
تعال نشوف مع بعض إيه مميزاته وعيوبه، وإمتى يكون اختيار مناسب فعلًا.
———
تخيل إنك بتبني سيستم كامل زي موقع e-commerce فيه:
- الـ UI (front-end).
- الـ business logic (زي إضافة منتجات للسلة، حساب الخصومات).
- الـ database access (CRUD operations).
في الـ Monolithic Architecture… كل ده بيكون في codebase واحد، ويتعمله deploy كـ تطبيق واحد (single unit).
يعني لو عايز تعدل في جزء معين لازم تعمل Deploy للتطبيق كله تاني.
———
📌 مميزات الـ Monolithic Architecture
1- البساطة:
الكود كله في مكان واحد، سهل تفهم العلاقات بين الأجزاء المختلفة.
2- سهولة عملية الـ Development في البداية:
مثالي جدًا للـ MVP أو المشاريع الصغيرة.
3- أداء كويس:
مفيش network latency بين components (كلها في نفس العملية).
4- سهولة الـ Testing:
تقدر تعمل end-to-end test بسهولة لأن كل حاجة في مكان واحد.
———
📌 عيوب الـ Monolithic Architecture
1- صعوبة التوسّع (Scalability):
عايز تكبر جزء واحد بس من السيستم؟ مش هتقدر… لازم تكبر التطبيق كله.
2- الـ Codebase هيبقى ضخم ومعقد مع الوقت:
لما المشروع يكبر، الكود بيبقى صعب أي حد يفهمه ويتعامل معاه.
3- ضعف المرونة في اختيار التكنولوجي:
مش هينفع تبني جزء بـ Node.js وجزء بـ Python، كله لازم يبقى بنفس الـ stack.
4- بطء في عملية الـ Deployment:
أي تعديل صغير لازم هتعمل Deploy التطبيق كله.
5- الـ Reliability ضعيفة:
لو جزء واحد وقع، ممكن يأثر على السيستم كله.
———
📌 إمتى تستخدم Monolithic Architecture؟
- لو بتبني مشروع صغير أو MVP وعايز تجرّب الفكرة بسرعة.
- لو عندك فريق صغير ومحتاج تقلل الـ overhead.
- لو لسه السيستم مش معقد ومش محتاج Scalability عالية.
———
الـ Monolithic: كل حاجة في تطبيق واحد.
الـ Microservices: السيستم متقسم لمجموعة خدمات مستقلة، كل خدمة بتشتغل لوحدها وتقدر تعمل Deploy/Scale/Debug بشكل منفصل.
———
#software_development
❤2
برنامج سفراء الذكاء الإصطناعي
.
.
البرنامج الأكبر لتأهيل غير المتخصصين لاستخدام تقنيات الذكاء الاصطناعي ونشر ثقافة الذكاء الاصطناعي في بيئات العمل.
———
تستهدف المبادرة تدريب غير المتخصصين في مجالات تكنولوجيا المعلومات، من العاملين في المؤسسات الحكومية والقطاع الخاص، وطلاب الجامعات، والمهتمين بفهم أساسيات الذكاء الاصطناعي وتطبيقاته العملية. ويُعد البرنامج التدريبي الذي تقدمه المبادرة من أوائل البرامج في المنطقة العربية التي تتيح لغير الخبراء فرصة تعلم مفاهيم مثل التعلم الآلي، والتعلم العميق، وتحليل البيانات، وتوظيف أدوات الذكاء الاصطناعي في تطوير العمل والخدمات.
———
📌️️ رابط الإنضمام:
https://nti.sci.eg/ai-ambassadors
.
.
البرنامج الأكبر لتأهيل غير المتخصصين لاستخدام تقنيات الذكاء الاصطناعي ونشر ثقافة الذكاء الاصطناعي في بيئات العمل.
———
تستهدف المبادرة تدريب غير المتخصصين في مجالات تكنولوجيا المعلومات، من العاملين في المؤسسات الحكومية والقطاع الخاص، وطلاب الجامعات، والمهتمين بفهم أساسيات الذكاء الاصطناعي وتطبيقاته العملية. ويُعد البرنامج التدريبي الذي تقدمه المبادرة من أوائل البرامج في المنطقة العربية التي تتيح لغير الخبراء فرصة تعلم مفاهيم مثل التعلم الآلي، والتعلم العميق، وتحليل البيانات، وتوظيف أدوات الذكاء الاصطناعي في تطوير العمل والخدمات.
———
📌️️ رابط الإنضمام:
https://nti.sci.eg/ai-ambassadors
❤2