تحقق من المستودع النظير [** تحديات البرمجة التفاعلية **](https://github.com/donnemartin/interactive-coding-challenges), which contains an additional Anki deck:
من المتوقع عمومًا أن يعرف المرشحون الأكثر خبرة المزيد عن تصميم النظام. من المتوقع أن يعرف المهندسون ذوي الخبرة أو قادة الفريق أكثر من المساهمين الفرديين. من المرجح أن تجري شركات التكنولوجيا الكبرى جولة أو أكثر من مقابلات التصميم.
ابدأ على نطاق واسع وتعمق في مناطق قليلة. من المفيد معرفة القليل عن مواضيع تصميم النظام الرئيسية المختلفة. اضبط الدليل التالي بناءً على جدولك الزمني وخبرتك والوظائف التي تجري مقابلة معها والشركات التي تجري مقابلات معها.
يمكنك استخدام الخطوات التالية لتوجيه المناقشة. للمساعدة في ترسيخ هذه العملية ، اعمل من خلال [أسئلة مقابلة تصميم النظام مع حلول](#system-design-interview-questions-with-solutions) باستخدام الخطوات التالية.
تكون الخدمة ** قابلة للتطوير ** إذا أدت إلى زيادة ** الأداء ** بطريقة تتناسب مع الموارد المضافة. بشكل عام ، تعني زيادة الأداء خدمة المزيد من وحدات العمل ، ولكن يمكن أيضًا التعامل مع وحدات عمل أكبر ، مثل عندما تنمو مجموعات البيانات. <sup><ahref=http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html>1</a></sup>
* [فهم وقت الاستجابة مقابل معالجة النظام للمعلومات](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
AP هو اختيار جيد إذا سمحت احتياجات العمل بذلك [الاتساق في نهاية المطاف](#eventual-consistency) أو عندما يحتاج النظام إلى مواصلة العمل بالرغم من الأخطاء الخارجية.
من خلال نسخ متعددة من نفس البيانات ، نواجه خيارات حول كيفية مزامنتها بحيث يكون لدى العملاء عرض متسق للبيانات. تذكر تعريف التناسق من [نظرية CAP](#cap-theorem) - كل قراءة تتلقى أحدث كتابة أو خطأ.
يظهر هذا النهج في أنظمة مثل memcached. يعمل التناسق الضعيف بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP ودردشة الفيديو والألعاب متعددة اللاعبين في الوقت الفعلي. على سبيل المثال ، إذا كنت تجري مكالمة هاتفية وفقدت الاستقبال لبضع ثوان ، فعند استعادة الاتصال ، لا تسمع ما تم التحدث به أثناء فقدان الاتصال.
مع تجاوز الفشل السلبي النشط ، يتم إرسال دقات القلب بين الخادم النشط والخادم الخامل في وضع الاستعداد. في حالة مقاطعة نبضات القلب ، يتولى الخادم الخامل عنوان IP الخاص بالنشط ويستأنف الخدمة.
يتم تحديد مدة التعطل من خلال ما إذا كان الخادم الخامل يعمل بالفعل في وضع الاستعداد "الساخن" أو ما إذا كان يحتاج إلى بدء التشغيل من وضع الاستعداد "البارد". فقط الخادم النشط يتعامل مع حركة المرور.
إذا كانت الخوادم تواجه الجمهور ، فسيحتاج DNS إلى معرفة عناوين IP العامة لكلا الخادمين. إذا كانت الخوادم مواجهة داخلية ، فسيحتاج منطق التطبيق إلى معرفة كلا الخادمين.
غالبًا ما يتم تحديد مدى التوفر حسب وقت التشغيل (أو وقت التوقف عن العمل) كنسبة مئوية من الوقت الذي تتوفر فيه الخدمة. يُقاس التوافر عمومًا بعدد 9 ثوانٍ - توصف خدمة توفر بنسبة 99.99٪ بأنها تحتوي على أربع 9 ثوانٍ.
DNS هرمي ، مع وجود عدد قليل من الخوادم الموثوقة في المستوى الأعلى. يوفر جهاز التوجيه أو موفر خدمة الإنترنت معلومات حول خادم (خوادم) DNS الذي يجب الاتصال به عند إجراء بحث. تعيينات ذاكرة التخزين المؤقت لخوادم DNS ذات المستوى الأدنى ، والتي قد تصبح قديمة بسبب تأخيرات انتشار DNS. يمكن أيضًا تخزين نتائج نظام أسماء النطاقات مؤقتًا بواسطة المتصفح أو نظام التشغيل لفترة زمنية معينة ، يتم تحديدها بواسطة [وقت البقاء (TTL)](https://en.wikipedia.org/wiki/Time_to_live).
خدمات مثل[CloudFlare](https://www.cloudflare.com/dns/) و [Route 53](https://aws.amazon.com/route53/) تقدم خدمات DNS المُدارة. يمكن لبعض خدمات DNS توجيه حركة المرور من خلال طرق مختلفة:
* يؤدي الوصول إلى خادم DNS إلى تأخير طفيف ، على الرغم من التخفيف من حدته عن طريق التخزين المؤقت الموضح أعلاه.
* قد تكون إدارة خادم DNS معقدة وتتم إدارتها بشكل عام بواسطة [الحكومات ومزودي خدمة الإنترنت والشركات الكبيرة](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729).
* تعرضت خدمات DNS مؤخرًا إلى [هجوم DDoS](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/) ، مما يمنع المستخدمين من الوصول إلى مواقع الويب مثل Twitter دون معرفة عنوان (عناوين) IP الخاص بتويتر.
شبكة توصيل المحتوى (CDN) هي شبكة موزعة عالميًا من الخوادم الوكيلة ، تخدم المحتوى من مواقع أقرب إلى المستخدم. بشكل عام ، يتم تقديم الملفات الثابتة مثل HTML / CSS / JS والصور ومقاطع الفيديو من CDN ، على الرغم من أن بعض شبكات CDN مثل Amazon's CloudFront تدعم المحتوى الديناميكي. سيخبر حل DNS الخاص بالموقع العملاء بالخادم الذي يجب الاتصال به.
يتلقى دفع CDNs محتوى جديدًا كلما حدثت تغييرات على الخادم الخاص بك. أنت تتحمل المسؤولية الكاملة عن توفير المحتوى والتحميل مباشرة إلى CDN وإعادة كتابة عناوين URL للإشارة إلى CDN. يمكنك تكوين وقت انتهاء صلاحية المحتوى ووقت تحديثه. يتم تحميل المحتوى فقط عندما يكون جديدًا أو متغيرًا ، مما يقلل من حركة المرور ، مع زيادة التخزين.
تعمل المواقع التي تحتوي على قدر ضئيل من حركة المرور أو المواقع ذات المحتوى الذي لا يتم تحديثه غالبًا بشكل جيد مع شبكات CDN للدفع. يتم وضع المحتوى على شبكات CDN مرة واحدة ، بدلاً من إعادة سحبه على فترات منتظمة.
تحصل شبكات CDN على محتوى جديد من الخادم الخاص بك عندما يطلب المستخدم الأول المحتوى. تترك المحتوى على الخادم الخاص بك وتعيد كتابة عناوين URL للإشارة إلى CDN. ينتج عن هذا طلب أبطأ حتى يتم تخزين المحتوى مؤقتًا على CDN.
تحدد [مدة البقاء (TTL)](https://en.wikipedia.org/wiki/Time_to_live) مدة تخزين المحتوى مؤقتًا. تعمل شبكات CDN على تقليل مساحة التخزين على شبكة CDN ، ولكن يمكنها إنشاء حركة مرور زائدة عن الحاجة إذا انتهت صلاحية الملفات وتم سحبها قبل تغييرها بالفعل.
تقوم موازين التحميل بتوزيع طلبات العميل الواردة على موارد الحوسبة مثل خوادم التطبيقات وقواعد البيانات. في كل حالة ، يُرجع موازن التحميل الاستجابة من مورد الحوسبة إلى العميل المناسب. موازنات التحميل فعالة في:
* ** إنهاء SSL ** - فك تشفير الطلبات الواردة واستجابات الخادم المشفرة حتى لا تضطر الخوادم الخلفية إلى إجراء هذه العمليات التي يحتمل أن تكون باهظة الثمن
* يزيل الحاجة إلى تثبيت شهادات [X.509](https://en.wikipedia.org/wiki/X.509) على كل خادم
* ** استمرار الجلسة ** - إصدار ملفات تعريف الارتباط وتوجيه طلبات عميل معين إلى الحالة نفسها إذا كانت تطبيقات الويب لا تتعقب الجلسات
تنظر موازنات أحمال الطبقة 4 إلى المعلومات الموجودة في [طبقة النقل](#communication) لتحديد كيفية توزيع الطلبات. بشكل عام ، يتضمن هذا المصدر وعناوين IP الوجهة والمنافذ الموجودة في الرأس ، ولكن ليس محتويات الحزمة. تقوم موازنات تحميل الطبقة 4 بإعادة توجيه حزم الشبكة من وإلى الخادم الرئيسي ، مع تنفيذ [ترجمة عنوان الشبكة (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/).
تنظر موازن تحميل الطبقة 7 إلى [طبقة التطبيق](#communication) لتحديد كيفية توزيع الطلبات. يمكن أن يشمل ذلك محتويات الرأس والرسالة وملفات تعريف الارتباط. تنهي موازنات تحميل الطبقة 7 حركة مرور الشبكة ، وتقرأ الرسالة ، وتتخذ قرار موازنة التحميل ، ثم تفتح اتصالاً بالخادم المحدد. على سبيل المثال ، يمكن لموازنة تحميل الطبقة 7 توجيه حركة مرور الفيديو إلى الخوادم التي تستضيف مقاطع فيديو مع توجيه حركة مرور فوترة المستخدم الأكثر حساسية إلى خوادم مشددة الأمان.
على حساب المرونة ، تتطلب موازنة تحميل الطبقة 4 وقتًا وموارد حوسبة أقل من الطبقة 7 ، على الرغم من أن تأثير الأداء يمكن أن يكون ضئيلًا على الأجهزة السلعية الحديثة.
يمكن أن تساعد موازين التحميل أيضًا في القياس الأفقي ، وتحسين الأداء والتوافر. يعد التوسع في استخدام آلات السلع الأساسية أكثر فعالية من حيث التكلفة وينتج عنه توافر أعلى من توسيع نطاق خادم واحد على أجهزة أكثر تكلفة ، تسمى ** التحجيم الرأسي **. كما أنه من الأسهل توظيف المواهب التي تعمل على الأجهزة السلعية مقارنةً بأنظمة المؤسسات المتخصصة.
الوكيل العكسي هو خادم ويب يركز الخدمات الداخلية ويوفر واجهات موحدة للجمهور. يتم إعادة توجيه الطلبات الواردة من العملاء إلى خادم يمكنه الوفاء بها قبل أن يقوم الوكيل العكسي بإرجاع استجابة الخادم للعميل.
* ** زيادة الأمان ** - إخفاء المعلومات حول خوادم الواجهة الخلفية ، وعناوين IP للقائمة السوداء ، والحد من عدد الاتصالات لكل عميل
* ** زيادة قابلية التوسع والمرونة ** - يرى العملاء فقط عنوان IP للوكيل العكسي ، مما يسمح لك بتوسيع نطاق الخوادم أو تغيير تكوينها
* ** إنهاء SSL ** - فك تشفير الطلبات الواردة واستجابات الخادم المشفرة حتى لا تضطر الخوادم الخلفية إلى إجراء هذه العمليات التي يحتمل أن تكون باهظة الثمن
* يزيل الحاجة إلى تثبيت شهادات [X.509](https://en.wikipedia.org/wiki/X.509) على كل خادم
* يعد نشر موازن التحميل مفيدًا عندما يكون لديك عدة خوادم. في كثير من الأحيان ، توجه موازين التحميل حركة المرور إلى مجموعة من الخوادم التي تخدم نفس الوظيفة.
* يمكن أن تكون البروكسيات العكسية مفيدة حتى مع خادم ويب أو خادم تطبيق واحد فقط ، مما يفتح الفوائد الموضحة في القسم السابق.
* يمكن أن تدعم الحلول مثل NGINX و HAProxy كلاً من البروكسي العكسي للطبقة 7 وموازنة الحمل.
* الوكيل العكسي المنفرد هو نقطة فشل واحدة ، حيث يؤدي تكوين العديد من الوكلاء العكسيين (على سبيل المثال ، [تجاوز الفشل](https://en.wikipedia.org/wiki/Failover)) إلى زيادة التعقيد.
يسمح لك فصل طبقة الويب عن طبقة التطبيق (المعروفة أيضًا باسم طبقة النظام الأساسي) بتوسيع نطاق كلتا الطبقتين وتكوينهما بشكل مستقل. تؤدي إضافة واجهة برمجة تطبيقات جديدة إلى إضافة خوادم التطبيقات دون الحاجة إلى إضافة خوادم ويب إضافية. يناصر مبدأ ** المسؤولية الفردية ** الخدمات الصغيرة والمستقلة التي تعمل معًا. يمكن للفرق الصغيرة ذات الخدمات الصغيرة التخطيط بقوة أكبر للنمو السريع.
تتعلق بهذه المناقشة [microservices](https://en.wikipedia.org/wiki/Microservices) ، والتي يمكن وصفها بأنها مجموعة من الخدمات المعيارية الصغيرة والقابلة للنشر بشكل مستقل. تدير كل خدمة عملية فريدة وتتواصل من خلال آلية خفيفة الوزن ومحددة جيدًا لخدمة هدف العمل. <sup><ahref=https://smartbear.com/learn/api-design/what-are-microservices>1</a></sup>
أنظمة مثل [Consul](https://www.consul.io/docs/index.html) و [Etcd](https://coreos.com/etcd/docs/latest) و [Zookeeper](http: //www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) يمكن أن تساعد الخدمات في العثور على بعضها البعض من خلال تتبع الأسماء والعناوين والمنافذ المسجلة. تساعد [الفحوصات الصحية](https://www.consul.io/intro/getting-started/checks.html) في التحقق من سلامة الخدمة ويتم إجراؤها غالبًا باستخدام نقطة نهاية [HTTP](#hypertext-transfer-protocol-http). يحتوي كل من Consul و Etcd على [مخزن قيمة المفتاح](#key-value-store) والذي يمكن أن يكون مفيدًا لتخزين قيم التكوين والبيانات المشتركة الأخرى.
هناك العديد من الأساليب لتوسيع نطاق قاعدة البيانات العلائقية: ** النسخ المتماثل الرئيسي والعبد ** ، ** النسخ المتماثل الرئيسي / الرئيسي ** ، ** الاتحاد ** ، ** التجزئة ** ، ** عدم التطابق ** ، و ** SQL ضبط**.
يخدم السيد القراءة والكتابة ، ويكرر الكتابة إلى واحد أو أكثر من الخدم ، والتي تخدم القراءة فقط. يمكن للخدم أيضًا نسخ الخدم الإضافيين بطريقة تشبه الأشجار. إذا كان السيد غير متصل ، يمكن للنظام أن يستمر في العمل في وضع القراءة فقط حتى يتم ترقية العبد إلى سيد أو توفير سيد جديد.
يعمل كلا السيدين على القراءة والكتابة والتنسيق مع بعضهما البعض في عمليات الكتابة. في حالة تعطل أي منهما ، يمكن للنظام الاستمرار في العمل مع كل من عمليات القراءة والكتابة.
* هناك احتمال لفقدان البيانات إذا فشل البرنامج الرئيسي قبل أن يتم نسخ أي بيانات مكتوبة حديثًا إلى العقد الأخرى.
* يتم إعادة عمليات الكتابة إلى النسخ المتماثلة للقراءة. إذا كان هناك الكثير من عمليات الكتابة ، فيمكن أن تتعثر النسخ المتماثلة للقراءة في إعادة قراءة الكتابات ولا يمكنها إجراء العديد من القراءات.
* كلما زاد عدد العبيد الذين تمت قراءتهم ، زادت الحاجة إلى التكرار ، مما يؤدي إلى تأخر النسخ المتماثل بشكل أكبر.
* في بعض الأنظمة ، يمكن أن تؤدي الكتابة إلى المعلم إلى إنتاج خيوط متعددة للكتابة بالتوازي ، بينما تدعم النسخ المتماثلة للقراءة الكتابة بالتسلسل باستخدام مؤشر ترابط واحد.
* يضيف النسخ المتماثل المزيد من الأجهزة وتعقيدًا إضافيًا.
يقسم الاتحاد (أو التقسيم الوظيفي) قواعد البيانات حسب الوظيفة. على سبيل المثال ، بدلاً من قاعدة بيانات واحدة متجانسة ، يمكن أن يكون لديك ثلاث قواعد بيانات: ** المنتديات ** ، ** المستخدمون ** ، و ** المنتجات ** ، مما يؤدي إلى تقليل حركة القراءة والكتابة لكل قاعدة بيانات وبالتالي تقليل النسخ المتماثل بطئ. ينتج عن قواعد البيانات الأصغر حجمًا أكبر من البيانات التي يمكن أن تتسع في الذاكرة ، مما يؤدي بدوره إلى المزيد من نتائج ذاكرة التخزين المؤقت بسبب موقع ذاكرة التخزين المؤقت المحسّن. مع عدم وجود تسلسل رئيسي مركزي واحد للكتابات ، يمكنك الكتابة بالتوازي ، وزيادة الإنتاجية.
* الاتحاد غير فعال إذا كان مخططك يتطلب وظائف أو جداول ضخمة.
* ستحتاج إلى تحديث منطق التطبيق الخاص بك لتحديد قاعدة البيانات التي يجب قراءتها وكتابتها.
* يعد ربط البيانات من قاعدتي بيانات أكثر تعقيدًا باستخدام [رابط الخادم](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different- الخوادم).
* يضيف الاتحاد المزيد من الأجهزة وتعقيدًا إضافيًا.
تقوم المشاركة بتوزيع البيانات عبر قواعد بيانات مختلفة بحيث يمكن لكل قاعدة بيانات فقط إدارة مجموعة فرعية من البيانات. أخذ قاعدة بيانات المستخدمين كمثال ، مع زيادة عدد المستخدمين ، تتم إضافة المزيد من القطع إلى المجموعة.
على غرار مزايا [الاتحاد](#federation) ، ينتج عن التجزئة حركة مرور أقل للقراءة والكتابة ، وتكرار أقل ، والمزيد من نتائج ذاكرة التخزين المؤقت. يتم أيضًا تقليل حجم الفهرس ، مما يؤدي بشكل عام إلى تحسين الأداء باستخدام استعلامات أسرع. إذا تعطلت إحدى القطع ، فإن الأجزاء الأخرى لا تزال تعمل ، على الرغم من أنك سترغب في إضافة شكل من أشكال النسخ المتماثل لتجنب فقد البيانات. مثل الفدرالية ، لا يوجد أي كتابات رئيسية مركزية متسلسلة واحدة ، مما يسمح لك بالكتابة بالتوازي مع زيادة الإنتاجية.
* ستحتاج إلى تحديث منطق التطبيق الخاص بك للعمل مع الأجزاء ، مما قد يؤدي إلى استعلامات SQL معقدة.
* يمكن أن يصبح توزيع البيانات غير متوازن في جزء. على سبيل المثال ، يمكن أن تؤدي مجموعة من المستخدمين المتمرسين على أحد الأجزاء إلى زيادة التحميل على هذا الجزء مقارنة بالآخرين.
* يضيف إعادة التوازن تعقيدًا إضافيًا. يمكن أن تقلل وظيفة التجزئة القائمة على [التجزئة المتسقة](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) من كمية البيانات المنقولة.
* يعد ربط البيانات من أجزاء متعددة أكثر تعقيدًا.
* تضيف التجزئة المزيد من الأجهزة وتعقيدًا إضافيًا.
تحاول Denormalization تحسين أداء القراءة على حساب بعض أداء الكتابة. تتم كتابة نسخ مكررة من البيانات في جداول متعددة لتجنب الصلات باهظة الثمن. بعض أنظمة RDBMS مثل [PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) ودعم أوراكل [المشاهدات المادية](https://en.wikipedia.org/wiki/Materialized_view) التي تتعامل مع عمل التخزين المعلومات الزائدة عن الحاجة والاحتفاظ بالنسخ الزائدة عن الحاجة.
بمجرد توزيع البيانات باستخدام تقنيات مثل [الاتحاد](#federationالاتحاد) و [التجزئة](#sharding) ، تؤدي إدارة الصلات عبر مراكز البيانات إلى زيادة التعقيد. قد يؤدي عدم التطابق إلى الالتفاف على الحاجة إلى مثل هذه الصلات المعقدة.
في معظم الأنظمة ، يمكن أن يفوق عدد القراءات عدد عمليات الكتابة 100: 1 أو حتى 1000: 1. يمكن أن تكون القراءة الناتجة عن ربط قاعدة بيانات معقدة باهظة الثمن ، مما يؤدي إلى قضاء قدر كبير من الوقت في عمليات القرص.
يعد ضبط SQL موضوعًا واسعًا وقد تمت كتابة العديد من [الكتب](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias٪3Daps&field-keywords=sql+tuning) كمرجع.
* يتم تفريغ MySQL على القرص في كتل متجاورة للوصول السريع.
* استخدم "CHAR" بدلاً من "VARCHAR" للحقول ذات الطول الثابت.
* يسمح "CHAR" بشكل فعال بالوصول السريع والعشوائي ، بينما مع "VARCHAR" ، يجب أن تجد نهاية سلسلة قبل الانتقال إلى السلسلة التالية.
* استخدم "TEXT" للكتل الكبيرة من النص مثل مشاركات المدونة. يسمح "TEXT" أيضًا بإجراء عمليات بحث منطقية. يؤدي استخدام حقل "TEXT" إلى تخزين مؤشر على القرص يُستخدم لتحديد موقع كتلة النص.
* استخدم "INT" للأعداد الأكبر حتى 2 ^ 32 أو 4 مليار.
* استخدم "DECIMAL" للعملة لتجنب أخطاء تمثيل النقطة العائمة.
* تجنب تخزين "BLOBS" كبيرة ، قم بتخزين مكان مكان الحصول على الكائن بدلاً من ذلك.
* `` VARCHAR (255) '' هو أكبر عدد من الأحرف يمكن عده بعدد 8 بت ، وغالبًا ما يزيد استخدام البايت في بعض أنظمة RDBMS.
* قم بتعيين القيد "NOT NULL" حيثما ينطبق ذلك على [تحسين أداء البحث](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search).
* الأعمدة التي تستعلم عنها (`SELECT` ،` GROUP BY` ، `ORDER BY` ،` JOIN`) يمكن أن تكون أسرع مع الفهارس.
* يتم تمثيل المؤشرات عادةً على أنها ذاتية التوازن [B-tree](https://en.wikipedia.org/wiki/B-tree) التي تحافظ على البيانات مرتبة وتسمح بعمليات البحث والوصول المتسلسل والإدخالات والحذف في الوقت اللوغاريتمي.
* يمكن أن يؤدي وضع فهرس إلى الاحتفاظ بالبيانات في الذاكرة ، مما يتطلب مساحة أكبر.
* يمكن أيضًا أن تكون عمليات الكتابة أبطأ نظرًا لأن الفهرس يحتاج أيضًا إلى التحديث.
* عند تحميل كميات كبيرة من البيانات ، قد يكون من الأسرع تعطيل الفهارس وتحميل البيانات ثم إعادة بناء المؤشرات.
* في بعض الحالات ، قد يؤدي [استعلام التخزين المؤقت](https://dev.mysql.com/doc/refman/5.7/en/query-cache.html) إلى [مشكلات في الأداء](https://www.percona.com/blog/2016/10/12/mysql-5-7-performance-tuning-immediately-after-installation/).
* [هل هناك سبب وجيه لاستخدام VARCHAR (255) كثيرًا?](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
* [كيف تؤثر القيم الخالية على الأداء?](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)
NoSQL عبارة عن مجموعة من عناصر البيانات ممثلة في ** متجر القيمة الرئيسية ** أو ** مخزن المستندات ** أو ** مخزن الأعمدة العريض ** أو ** قاعدة بيانات الرسم البياني **. يتم إلغاء تنسيق البيانات ، ويتم إجراء الصلات بشكل عام في رمز التطبيق. تفتقر معظم مخازن NoSQL إلى معاملات حمض صحيح ويفضل [التناسق النهائي](#eventual-consistency).
بالإضافة إلى الاختيار بين [SQL أو NoSQL] (#sql-or-nosql) ، من المفيد فهم نوع قاعدة بيانات NoSQL الأنسب لحالة (حالات) الاستخدام الخاصة بك. سنراجع ** مخازن القيمة الرئيسية ** و ** مخازن المستندات ** و ** مخازن الأعمدة الواسعة ** و ** قواعد بيانات الرسم البياني ** في القسم التالي.
يسمح مخزن القيمة الرئيسية عمومًا لـ O (1) بالقراءة والكتابة وغالبًا ما يكون مدعومًا بالذاكرة أو SSD. يمكن لمخازن البيانات الاحتفاظ بالمفاتيح في [ترتيب معجمي](https://en.wikipedia.org/wiki/Lexicographical_order) ، مما يسمح بالاسترداد الفعال لنطاقات المفاتيح. يمكن أن تسمح مخازن القيمة الرئيسية بتخزين البيانات الوصفية ذات القيمة.
توفر مخازن القيمة الرئيسية أداءً عاليًا وغالبًا ما تُستخدم لنماذج البيانات البسيطة أو للبيانات سريعة التغير ، مثل طبقة ذاكرة التخزين المؤقت في الذاكرة. نظرًا لأنها تقدم مجموعة محدودة فقط من العمليات ، يتم نقل التعقيد إلى طبقة التطبيق إذا كانت هناك حاجة لعمليات إضافية.
* [قاعدة بيانات القيمة الأساسية](https://en.wikipedia.org/wiki/Key-value_database)
* [عيوب متاجر القيمة الرئيسية](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
يتمركز مخزن المستندات حول المستندات (XML ، JSON ، ثنائي ، إلخ) ، حيث يخزن المستند جميع المعلومات الخاصة بكائن معين. توفر مخازن المستندات واجهات برمجة تطبيقات أو لغة استعلام للاستعلام بناءً على البنية الداخلية للمستند نفسه. * ملاحظة ، تتضمن العديد من متاجر القيمة الرئيسية ميزات للعمل مع البيانات الوصفية للقيمة ، مما يؤدي إلى تعتيم الخطوط بين هذين النوعين من التخزين. *
بناءً على التنفيذ الأساسي ، يتم تنظيم المستندات حسب المجموعات أو العلامات أو البيانات الوصفية أو الدلائل. على الرغم من إمكانية تنظيم المستندات أو تجميعها معًا ، فقد تحتوي المستندات على حقول مختلفة تمامًا عن بعضها البعض.
بعض مخازن المستندات مثل [MongoDB](https://www.mongodb.com/mongodb-architecture) و [CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture /) توفر أيضًا لغة شبيهة بلغة SQL لإجراء استعلامات معقدة. [DynamoDB](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) يدعم كلاً من القيم الأساسية والمستندات.
وحدة البيانات الأساسية لمخزن الأعمدة العريضة هي العمود (زوج الاسم / القيمة). يمكن تجميع العمود في مجموعات الأعمدة (مماثلة لجدول SQL). عائلات الأعمدة الفائقة مجموعات أعمدة المجموعة. يمكنك الوصول إلى كل عمود بشكل مستقل باستخدام مفتاح صف ، وتشكل الأعمدة التي تحتوي على مفتاح الصف نفسه صفًا. تحتوي كل قيمة على طابع زمني لتعيين الإصدار وحل التعارض.
قدمت Google [Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) كأول مخزن عمود عريض ، والذي أثر على المصدر المفتوح [HBase] ( https://www.edureka.co/blog/hbase-architecture/) غالبًا ما تستخدم في نظام Hadoop البيئي ، و [Cassandra] (http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/ archIntro.html) من Facebook. تحتفظ المتاجر مثل BigTable و HBase و Cassandra بالمفاتيح بترتيب معجمي ، مما يسمح بالاسترداد الفعال لنطاقات المفاتيح الانتقائية.
في قاعدة بيانات الرسم البياني ، كل عقدة عبارة عن سجل وكل قوس عبارة عن علاقة بين عقدتين. تم تحسين قواعد بيانات الرسم البياني لتمثيل العلاقات المعقدة مع العديد من المفاتيح الخارجية أو علاقات أطراف بأطراف.
تقدم قواعد بيانات الرسوم البيانية أداءً عاليًا لنماذج البيانات ذات العلاقات المعقدة ، مثل الشبكات الاجتماعية. فهي جديدة نسبيًا ولم يتم استخدامها على نطاق واسع بعد ؛ قد يكون من الصعب العثور على أدوات التطوير والموارد. لا يمكن الوصول إلى العديد من الرسوم البيانية إلا باستخدام [REST APIs](#Representational-state-transfer-rest).
يعمل التخزين المؤقت على تحسين أوقات تحميل الصفحة ويمكن أن يقلل الحمل على الخوادم وقواعد البيانات الخاصة بك. في هذا النموذج ، سيقوم المرسل أولاً بالبحث عما إذا كان الطلب قد تم تقديمه من قبل ومحاولة العثور على النتيجة السابقة لإرجاعها ، من أجل حفظ التنفيذ الفعلي.
غالبًا ما تستفيد قواعد البيانات من التوزيع المنتظم للقراءات والكتابة عبر أقسامها. يمكن أن تؤدي العناصر الشائعة إلى انحراف التوزيع ، مما يتسبب في حدوث اختناقات. يمكن أن يساعد وضع ذاكرة التخزين المؤقت أمام قاعدة البيانات على امتصاص الأحمال غير المتكافئة والزيادات المفاجئة في حركة المرور.
يمكن أن توجد ذاكرات التخزين المؤقت على جانب العميل (نظام التشغيل أو المستعرض) ، [جانب الخادم](#reverse-proxy-web-server) ، أو في طبقة ذاكرة تخزين مؤقت مميزة.
يمكن أن تخدم [الوكلاء العكسيون](#reverse-proxy-web-server) وذاكرة التخزين المؤقت مثل [Varnish](https://www.varnish-cache.org/) محتوى ثابتًا وديناميكيًا بشكل مباشر. يمكن لخوادم الويب أيضًا تخزين الطلبات مؤقتًا ، وإرجاع الردود دون الحاجة إلى الاتصال بخوادم التطبيق.
تتضمن قاعدة البيانات الخاصة بك عادةً مستوى معينًا من التخزين المؤقت في تكوين افتراضي ، محسّن لحالة استخدام عامة. يمكن أن يؤدي التغيير والتبديل في هذه الإعدادات لأنماط استخدام معينة إلى زيادة تعزيز الأداء.
إن ذاكرات التخزين المؤقت في الذاكرة مثل Memcached و Redis هي مخازن ذات قيمة أساسية بين تطبيقك وتخزين البيانات. نظرًا لأن البيانات محفوظة في ذاكرة الوصول العشوائي ، فهي أسرع بكثير من قواعد البيانات النموذجية حيث يتم تخزين البيانات على القرص. ذاكرة الوصول العشوائي محدودة أكثر من القرص ، لذا [إلغاء ذاكرة التخزين المؤقت](https://en.wikipedia.org/wiki/Cache_algorithms) خوارزميات مثل [الأقل استخدامًا مؤخرًا (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) يمكن أن تساعد في إبطال الإدخالات "الباردة" والحفاظ على البيانات "الساخنة" في ذاكرة الوصول العشوائي.
عندما تقوم بالاستعلام عن قاعدة البيانات ، قم بتجزئة الاستعلام كمفتاح وقم بتخزين النتيجة في ذاكرة التخزين المؤقت. هذا النهج يعاني من مشاكل انتهاء الصلاحية:
انظر إلى بياناتك ككائن ، على غرار ما تفعله برمز التطبيق الخاص بك. اجعل تطبيقك يجمع مجموعة البيانات من قاعدة البيانات إلى مثيل فئة أو بنية (هياكل) بيانات:
نظرًا لأنه لا يمكنك تخزين سوى كمية محدودة من البيانات في ذاكرة التخزين المؤقت ، فستحتاج إلى تحديد استراتيجية تحديث ذاكرة التخزين المؤقت التي تعمل بشكل أفضل لحالة الاستخدام الخاصة بك.
<i><ahref=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Source: From cache to in-memory data grid</a></i>
تتم القراءات اللاحقة للبيانات المضافة إلى ذاكرة التخزين المؤقت بسرعة. يشار إلى ذاكرة التخزين المؤقت الجانبية أيضًا باسم التحميل البطيء. يتم تخزين البيانات المطلوبة فقط مؤقتًا ، مما يؤدي إلى تجنب ملء ذاكرة التخزين المؤقت بالبيانات غير المطلوبة.
* ينتج عن كل خطأ في ذاكرة التخزين المؤقت ثلاث رحلات ، مما قد يتسبب في تأخير ملحوظ.
* يمكن أن تصبح البيانات قديمة إذا تم تحديثها في قاعدة البيانات. يتم تخفيف هذه المشكلة عن طريق تعيين مدة البقاء (TTL) التي تفرض تحديثًا لإدخال ذاكرة التخزين المؤقت ، أو باستخدام الكتابة.
* عندما تفشل عقدة ، يتم استبدالها بعقدة جديدة فارغة ، مما يؤدي إلى زيادة زمن الوصول.
يستخدم التطبيق ذاكرة التخزين المؤقت كمخزن بيانات رئيسي لقراءة البيانات وكتابتها عليها ، بينما يكون التخزين المؤقت مسؤولاً عن القراءة والكتابة في قاعدة البيانات:
الكتابة من خلال عملية إجمالية بطيئة بسبب عملية الكتابة ، لكن القراءات اللاحقة للبيانات المكتوبة للتو تكون سريعة. يتسامح المستخدمون بشكل عام مع وقت الاستجابة عند تحديث البيانات أكثر من قراءة البيانات. البيانات في ذاكرة التخزين المؤقت ليست قديمة.
* عند إنشاء عقدة جديدة بسبب فشل أو تحجيم ، لن تقوم العقدة الجديدة بتخزين الإدخالات مؤقتًا حتى يتم تحديث الإدخال في قاعدة البيانات. يمكن أن يؤدي وضع ذاكرة التخزين المؤقت جنبًا إلى جنب مع الكتابة من خلال إلى التخفيف من هذه المشكلة.
* قد لا تتم قراءة معظم البيانات المكتوبة مطلقًا ، ويمكن تصغيرها باستخدام TTL.
<i><ahref=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Source: From cache to in-memory data grid</a></i>
يمكن أن يؤدي التحديث المسبق إلى تقليل وقت الاستجابة مقابل القراءة الكاملة إذا كان بإمكان ذاكرة التخزين المؤقت التنبؤ بدقة بالعناصر التي من المحتمل أن تكون مطلوبة في المستقبل.
* تحتاج إلى الحفاظ على الاتساق بين ذاكرات التخزين المؤقت ومصدر الحقيقة مثل قاعدة البيانات من خلال [إبطال ذاكرة التخزين المؤقت](https://en.wikipedia.org/wiki/Cache_algorithms).
* يعد إبطال ذاكرة التخزين المؤقت مشكلة صعبة ، وهناك تعقيد إضافي مرتبط بموعد تحديث ذاكرة التخزين المؤقت.
* تحتاج إلى إجراء تغييرات على التطبيق مثل إضافة Redis أو memcached.
* [من ذاكرة التخزين المؤقت إلى شبكة البيانات في الذاكرة](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
* [أنماط تصميم النظام القابلة للتطوير](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
* [مقدمة في هندسة أنظمة القياس](http://lethain.com/introduction-to-architecting-systems-for-scale/)
تساعد تدفقات العمل غير المتزامنة على تقليل أوقات الطلب للعمليات الباهظة التي كان من الممكن إجراؤها في نفس الوقت. يمكنهم أيضًا المساعدة من خلال القيام بعمل يستغرق وقتًا طويلاً مسبقًا ، مثل التجميع الدوري للبيانات.
تقوم قوائم انتظار الرسائل باستلام الرسائل والاحتفاظ بها وتسليمها. إذا كانت العملية بطيئة جدًا بحيث لا يمكن تنفيذها بشكل مضمّن ، فيمكنك استخدام قائمة انتظار الرسائل مع سير العمل التالي:
لا يتم حظر المستخدم وتتم معالجة المهمة في الخلفية. خلال هذا الوقت ، قد يقوم العميل اختياريًا بكمية صغيرة من المعالجة لجعل الأمر يبدو وكأن المهمة قد اكتملت. على سبيل المثال ، في حالة نشر تغريدة ، يمكن نشر التغريدة على الفور على جدولك الزمني ، ولكن قد يستغرق الأمر بعض الوقت قبل أن يتم تسليم تغريدتك فعليًا إلى جميع متابعيك.
تستقبل قوائم انتظار المهام المهام والبيانات المتعلقة بها ، وتقوم بتشغيلها ، ثم تسليم نتائجها. يمكنهم دعم الجدولة ويمكن استخدامها لتشغيل وظائف حسابية مكثفة في الخلفية.
إذا بدأت قوائم الانتظار في النمو بشكل ملحوظ ، يمكن أن يصبح حجم قائمة الانتظار أكبر من الذاكرة ، مما يؤدي إلى فقد ذاكرة التخزين المؤقت وقراءة القرص وحتى أداء أبطأ. يمكن أن يساعد [الضغط الخلفي](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) في الحد من حجم قائمة الانتظار ، وبالتالي الحفاظ على معدل إنتاجية مرتفع واستجابة جيدة مرات للوظائف الموجودة بالفعل في قائمة الانتظار. بمجرد امتلاء قائمة الانتظار ، يحصل العملاء على خادم مشغول أو رمز حالة HTTP 503 للمحاولة مرة أخرى لاحقًا. يمكن للعملاء إعادة محاولة الطلب في وقت لاحق ، ربما باستخدام [التراجع الأسي](https://en.wikipedia.org/wiki/Exponential_backoff).
* قد تكون حالات الاستخدام مثل العمليات الحسابية غير المكلفة وسير العمل في الوقت الفعلي مناسبة بشكل أفضل للعمليات المتزامنة ، حيث يمكن أن يؤدي إدخال قوائم الانتظار إلى زيادة التأخير والتعقيد.
* [ما الفرق بين قائمة انتظار الرسائل وقائمة انتظار المهام?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue -لماذا تتطلب قائمة انتظار مهمة وسيط رسالة مثل RabbitMQ-Redis-Celery-or-IronMQ-to-function)
HTTP هي طريقة لتشفير ونقل البيانات بين العميل والخادم. إنه بروتوكول طلب / استجابة: يصدر العملاء طلبات ويصدر الخوادم استجابات بالمحتوى ذي الصلة ومعلومات حالة الإكمال حول الطلب. HTTP قائم بذاته ، مما يسمح للطلبات والاستجابات بالتدفق عبر العديد من أجهزة التوجيه والخوادم الوسيطة التي تقوم بموازنة التحميل والتخزين المؤقت والتشفير والضغط.
TCP هو بروتوكول مهيأ للاتصال عبر [شبكة IP](https://en.wikipedia.org/wiki/Internet_Protocol). يتم إنشاء الاتصال وإنهائه باستخدام [المصافحة](https://en.wikipedia.org/wiki/Handshaking). نضمن وصول جميع الحزم المرسلة إلى الوجهة بالترتيب الأصلي وبدون فساد من خلال:
إذا لم يتلق المرسل استجابة صحيحة ، فسيعيد إرسال الحزم. إذا كانت هناك مهلات متعددة ، فسيتم قطع الاتصال. ينفذ TCP أيضًا [التحكم في التدفق](https://en.wikipedia.org/wiki/Flow_control_(data)) و [التحكم في الازدحام](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control). تتسبب هذه الضمانات في حدوث تأخيرات وتؤدي عمومًا إلى نقل أقل كفاءة من UDP.
لضمان إنتاجية عالية ، يمكن لخوادم الويب الاحتفاظ بعدد كبير من اتصالات TCP مفتوحة ، مما يؤدي إلى استخدام ذاكرة عالية. قد يكون وجود عدد كبير من الاتصالات المفتوحة بين سلاسل عمليات خادم الويب مكلفًا ، ولنقل ، خادم [memcached](https://memcached.org/). يمكن أن يساعد [تجميع الاتصال](https://en.wikipedia.org/wiki/Connection_pool) بالإضافة إلى التبديل إلى UDP عند الاقتضاء.
يعد بروتوكول TCP مفيدًا للتطبيقات التي تتطلب موثوقية عالية ولكنها تستغرق وقتًا أقل أهمية. تتضمن بعض الأمثلة خوادم الويب ومعلومات قاعدة البيانات و SMTP و FTP و SSH.
UDP غير متصل. يتم ضمان مخططات البيانات (المشابهة للحزم) فقط على مستوى مخطط البيانات. قد تصل مخططات البيانات إلى وجهتها خارج الترتيب أو لا تصل على الإطلاق. لا يدعم UDP التحكم في الازدحام. بدون الضمانات التي يدعمها TCP ، يكون UDP أكثر كفاءة بشكل عام.
يمكن لـ UDP البث وإرسال مخططات البيانات إلى جميع الأجهزة الموجودة على الشبكة الفرعية. هذا مفيد مع [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) لأن العميل لم يتلق عنوان IP بعد ، وبالتالي يمنع طريقة لبث TCP بدون عنوان IP.
يعد UDP أقل موثوقية ولكنه يعمل بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP ودردشة الفيديو والبث المباشر والألعاب متعددة اللاعبين في الوقت الفعلي.
في RPC ، يتسبب العميل في تنفيذ إجراء على مساحة عنوان مختلفة ، عادةً ما يكون خادمًا بعيدًا. يتم ترميز الإجراء كما لو كان استدعاء إجراء محلي ، مع استبعاد تفاصيل كيفية الاتصال بالخادم من برنامج العميل. عادةً ما تكون المكالمات عن بُعد أبطأ وأقل موثوقية من المكالمات المحلية ، لذا من المفيد التمييز بين مكالمات RPC والمكالمات المحلية. تتضمن أطر عمل RPC الشائعة [Protobuf](https://developers.google.com/protocol-buffers/) و [Thrift](https://thrift.apache.org/) و [Avro](https://avro.apache.org/docs/current/).
يركز RPC على فضح السلوكيات. غالبًا ما يتم استخدام RPCs لأسباب تتعلق بالأداء مع الاتصالات الداخلية ، حيث يمكنك إجراء مكالمات محلية يدويًا لتناسب حالات الاستخدام الخاصة بك بشكل أفضل.
* يجب تحديد واجهة برمجة تطبيقات جديدة لكل عملية أو حالة استخدام جديدة.
* قد يكون من الصعب تصحيح أخطاء RPC.
* قد لا تتمكن من الاستفادة من التقنيات الحالية خارج الصندوق. على سبيل المثال ، قد يتطلب الأمر جهدًا إضافيًا للتأكد من أن [مكالمات RPC مخبأة بشكل صحيح](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) على خوادم التخزين المؤقت مثل [Squid ](http://www.squid-cache.org/).
REST هو أسلوب معماري يفرض نموذج العميل / الخادم حيث يعمل العميل على مجموعة من الموارد التي يديرها الخادم. يوفر الخادم تمثيلاً للموارد والإجراءات التي يمكنها إما معالجة أو الحصول على تمثيل جديد للموارد. يجب أن تكون جميع الاتصالات عديمة الحالة وقابلة للتخزين المؤقت.
يركز REST على كشف البيانات. إنه يقلل من الاقتران بين العميل / الخادم وغالبًا ما يستخدم لواجهات برمجة تطبيقات HTTP العامة. يستخدم REST طريقة أكثر عمومية وموحدة لعرض الموارد من خلال URIs ، [التمثيل من خلال الرؤوس](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) ، و الإجراءات من خلال أفعال مثل GET و POST و PUT و DELETE و PATCH. كونه عديم الحالة ، فإن REST رائع للقياس والتقسيم الأفقي.
* مع تركيز REST على كشف البيانات ، قد لا يكون مناسبًا إذا لم يتم تنظيم الموارد بشكل طبيعي أو الوصول إليها في تسلسل هرمي بسيط. على سبيل المثال ، لا يتم التعبير بسهولة عن إعادة جميع السجلات المحدثة من الساعة الماضية التي تتطابق مع مجموعة معينة من الأحداث كمسار. باستخدام REST ، من المحتمل أن يتم تنفيذه بمجموعة من مسار URI ومعلمات الاستعلام وربما نص الطلب.
* يعتمد REST عادةً على بعض الأفعال (GET و POST و PUT و DELETE و PATCH) والتي لا تناسب أحيانًا حالة الاستخدام الخاصة بك. على سبيل المثال ، قد لا يتناسب نقل المستندات منتهية الصلاحية إلى مجلد الأرشيف تمامًا مع هذه الأفعال.
* يتطلب جلب الموارد المعقدة ذات التسلسلات الهرمية المتداخلة رحلات ذهاب وإياب متعددة بين العميل والخادم لعرض طرق عرض فردية ، على سبيل المثال جلب محتوى إدخال مدونة والتعليقات على هذا الإدخال. بالنسبة لتطبيقات الهاتف المحمول التي تعمل في ظروف شبكة متغيرة ، فإن هذه الرحلات المتعددة ذهابًا وإيابًا غير مرغوب فيها إلى حد كبير.
* بمرور الوقت ، قد تتم إضافة المزيد من الحقول إلى استجابة API وسيتلقى العملاء الأكبر سنًا جميع حقول البيانات الجديدة ، حتى تلك التي لا يحتاجونها ، ونتيجة لذلك ، يؤدي ذلك إلى تضخيم حجم الحمولة ويؤدي إلى زمن انتقال أكبر.
* قم بتعقيم جميع إدخالات المستخدم أو أي معلمات إدخال معروضة للمستخدم لمنع [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) و [إدخال SQL](https://en.wikipedia.org/wiki/SQL_injection).
* استخدم الاستعلامات ذات المعلمات لمنع إدخال SQL.
* استخدم مبدأ [الامتياز الأقل](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
سيُطلب منك أحيانًا عمل تقديرات "ظهر الظرف". على سبيل المثال ، قد تحتاج إلى تحديد المدة التي سيستغرقها إنشاء 100 صورة مصغرة من القرص أو مقدار الذاكرة التي ستستغرقها بنية البيانات. تعد ** صلاحيات الجدولين ** و ** أرقام وقت الاستجابة التي يجب أن يعرفها كل مبرمج ** من المراجع المفيدة.
* [أرقام وقت الاستجابة التي يجب على كل مبرمج معرفتها - 1](https://gist.github.com/jboner/2841832)
* [أرقام وقت الاستجابة التي يجب على كل مبرمج معرفتها - 2](https://gist.github.com/hellerbarde/2843375)
* [تصاميم ودروس ومشورة من بناء أنظمة موزعة كبيرة](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)
* [نصائح هندسة البرمجيات من بناء أنظمة موزعة كبيرة الحجم](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)
| Design a file sync service like Dropbox | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) |
| Design a search engine like Google | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)<br/>[stackexchange.com](http://programmers.stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)<br/>[ardendertat.com](http://www.ardendertat.com/2012/01/11/implementing-search-engines/)<br/>[stanford.edu](http://infolab.stanford.edu/~backrub/google.html) |
| Design a scalable web crawler like Google | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) |
| Design Google docs | [code.google.com](https://code.google.com/p/google-mobwrite/)<br/>[neil.fraser.name](https://neil.fraser.name/writing/sync/) |
| Design a key-value store like Redis | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
| Design a cache system like Memcached | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Design a recommendation system like Amazon's | [hulu.com](https://web.archive.org/web/20170406065247/http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)<br/>[ijcai13.org](http://ijcai13.org/files/tutorial_slides/td3.pdf) |
| Design a tinyurl system like Bitly | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/) |
| Design a chat app like WhatsApp | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)
| Design a picture sharing system like Instagram | [highscalability.com](http://highscalability.com/flickr-architecture)<br/>[highscalability.com](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html) |
| Design the Facebook news feed function | [quora.com](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed)<br/>[quora.com](http://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed)<br/>[slideshare.net](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture) |
| Design the Facebook timeline function | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)<br/>[highscalability.com](http://highscalability.com/blog/2012/1/23/facebook-timeline-brought-to-you-by-the-power-of-denormaliza.html) |
| Design the Facebook chat function | [erlang-factory.com](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)<br/>[facebook.com](https://www.facebook.com/note.php?note_id=14218138919&id=9445547199&index=0) |
| Design a graph search function like Facebook's | [facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph-search/10151347573598920)<br/>[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-indexing-and-ranking-in-graph-search/10151361720763920)<br/>[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-natural-language-interface-of-graph-search/10151432733048920) |
| Design a content delivery network like CloudFlare | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) |
| Design a trending topic system like Twitter's | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)<br/>[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
| Design a random ID generation system | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)<br/>[github.com](https://github.com/twitter/snowflake/) |
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/cs.ucsb.edu/files/docs/reports/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
| Design a system that serves data from multiple data centers | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
| Design an online multiplayer card game | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
| Design a garbage collection system | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
| Design an API rate limiter | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) |
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implemenation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
| Data processing | **MapReduce** - Distributed data processing from Google | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) |
| Data processing | **Spark** - Distributed data processing from Databricks | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) |
| Data processing | **Storm** - Distributed data processing from Twitter | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) |
| | | |
| Data store | **Bigtable** - Distributed column-oriented database from Google | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) |
| Data store | **HBase** - Open source implementation of Bigtable | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) |
| Data store | **Cassandra** - Distributed column-oriented database from Facebook | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666)
| Data store | **DynamoDB** - Document-oriented database from Amazon | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) |
| Data store | **MongoDB** - Document-oriented database | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) |
| Data store | **Spanner** - Globally-distributed database from Google | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) |
| Data store | **Memcached** - Distributed memory caching system | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Data store | **Redis** - Distributed memory caching system with persistence and value types | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
| | | |
| File system | **Google File System (GFS)** - Distributed file system | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |
| File system | **Hadoop File System (HDFS)** - Open source implementation of GFS | [apache.org](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) |
| | | |
| Misc | **Chubby** - Lock service for loosely-coupled distributed systems from Google | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |
| ESPN | [Operating At 100,000 duh nuh nuhs per second](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) |
| Google | [Google architecture](http://highscalability.com/google-architecture) |
| Instagram | [14 million users, terabytes of photos](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)<br/>[What powers Instagram](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances) |
| Justin.tv | [Justin.Tv's live video broadcasting architecture](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) |
| Facebook | [Scaling memcached at Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/key-value/fb-memcached-nsdi-2013.pdf)<br/>[TAO: Facebook’s distributed data store for the social graph](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/data-store/tao-facebook-distributed-datastore-atc-2013.pdf)<br/>[Facebook’s photo storage](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf)<br/>[How Facebook Live Streams To 800,000 Simultaneous Viewers](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) |
| Mailbox | [From 0 to one million users in 6 weeks](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) |
| Netflix | [A 360 Degree View Of The Entire Netflix Stack](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)<br/>[Netflix: What Happens When You Press Play?](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) |
| Pinterest | [From 0 To 10s of billions of page views a month](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)<br/>[18 million visitors, 10x growth, 12 employees](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) |
| Playfish | [50 million monthly users and growing](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) |
| Tumblr | [15 billion page views a month](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) |
| Twitter | [Making Twitter 10000 percent faster](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)<br/>[Storing 250 million tweets a day using MySQL](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html)<br/>[150M active users, 300K QPS, a 22 MB/S firehose](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html)<br/>[Timelines at scale](https://www.infoq.com/presentations/Twitter-Timeline-Scalability)<br/>[Big and small data at Twitter](https://www.youtube.com/watch?v=5cKTP36HVgI)<br/>[Operations at Twitter: scaling beyond 100 million users](https://www.youtube.com/watch?v=z8LU0Cj6BOU)<br/>[How Twitter Handles 3,000 Images Per Second](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) |
| Uber | [How Uber scales their real-time market platform](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)<br/>[Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) |
* أقوم بتوفير التعليمات البرمجية والموارد في هذا المستودع لك بموجب ترخيص مفتوح المصدر. نظرًا لأن هذا هو مستودعي الشخصي ، فإن الترخيص الذي تتلقاه للرمز الخاص بي وموارده هو مني وليس من صاحب العمل (Facebook). *
