كنت مخطط إني الخص فصول الكتاب ده وانا بقرأه، لكن في نفس اليوم إلي كتبت فيه الثريد ده جدتي اتوفت، فنفسي اتسدت عن الكتاب، لكن الي رجعني دلوقتي وفاة أحمد مجدي @Lynguist_0، هو كان بيحب العلم وبيحب ينشره، ف اتمنى تدعولهم الاتنين بالرحمة.
البلوج بتاعته:
lynguist0.medium.com
0/n
البلوج بتاعته:
lynguist0.medium.com
0/n
وصلنا المرة الي فاتت للكاشينج، الكاش هو عبارة عن temporary storage area بتكون في الميموري، بنستخدمها عشان الوصول ليها دايمًا بيكون أسرع من إنك تروح وتعمل طلب لحاجة من الداتا بيز وتستنى ترجعلك، وكمان عشان تقلل الـ workloads عليها.
1/n
1/n
عشان نفهم الي بيحصل في الصورة الي فوق دي، تعالى نتخيل ان شخص مشهور جدًا كتب تويتة جدلية، وقتها هيكون في ملايين من الناس بتدخل على بروفايل الشخص ده، ف الي هيحصل هنا إن كل مرة حد هيطلب البروفايل ده من الويب سيرفر، الويب سيرفر هيروح يطلب من الداتا بيز بيانات البروفايل ده
2/n
2/n
البوستس بقى وعدد الفولورز والليلة دي كلها، تخيل لو دخل ملايين من الناس؟ كل الناس دي بتمثل لود على ال db وعلى داتا هي حاليا بتتطلب باستمرار، ايه رأيك بقى طالما الداتا دي بتتطلب باستمرار نحطها في مكان سريع جدًا بحيث لما حد يطلبها ترجعله بسرعة وفي نفس الوقت مش محتاجين نروح لل db
3/n
3/n
ولا نعمل لود عليها، هو ده حرفيًا افايدة الكاشينج، ف الي بيحصل في الصورة ان الويب سيرفر لما يجيله ريكويست هيروح يسأل الكاش، هل الداتا دي عندك؟ لو الكاش عنده الداتا دي هيرجعها للويب سيرفر يرجعها لليوزر، ولو لأ ف هيطلب من الداتا بيز الداتا دي ويحطها في الكاش ويرجعها لليوزر.
4/n
4/n
الـ strategy دي في الكاشينج اسمها read-through cache.
في strategies كتيرة للكاشينج بتعتمد على الـ data type وحجم الداتا ومعدل طلب الداتا دي، ممكن نتكلم عن الاختلافات دي في ثريد منفصل بعد ده.
دلوقتي ايه هي الاعتبارات لما بنستخدم الـ cache؟
5/n
في strategies كتيرة للكاشينج بتعتمد على الـ data type وحجم الداتا ومعدل طلب الداتا دي، ممكن نتكلم عن الاختلافات دي في ثريد منفصل بعد ده.
دلوقتي ايه هي الاعتبارات لما بنستخدم الـ cache؟
5/n
1 - بنستخدم الكاش لما الداتا تكون بتتقرأ بشكل متكرر، لكن بتتعدل بشكل غير متكرر.
ملحوظة: الكاش مش مناسب لل persisting data لإنك لما بتعمل ريستارت الداتا بتتمسح.
2 - مفروض وانتَ بتستخدم الكاش تهتم بالـ Expiration policy لإن الداتا بتفضل في الميموري للأبد لو مبقتش Expired.
6/n
ملحوظة: الكاش مش مناسب لل persisting data لإنك لما بتعمل ريستارت الداتا بتتمسح.
2 - مفروض وانتَ بتستخدم الكاش تهتم بالـ Expiration policy لإن الداتا بتفضل في الميموري للأبد لو مبقتش Expired.
6/n
مفروض كمان متخليش ال Expiration date بتاعها قصير جدًا عشان وقتها هتفضل تطلب الداتابيز بإستمرار ووقتها كإنك معملتش حاجة، ولا طويلة جدًا فيبقى الداتا قديمة وملهاش لازمة.
3 - الـ Consistency ركن مهم أثناء استخدام الكاشينج، لإنك لازم تخلي الكاش والـ data store بتاعك متزامنين سوا
7/n
3 - الـ Consistency ركن مهم أثناء استخدام الكاشينج، لإنك لازم تخلي الكاش والـ data store بتاعك متزامنين سوا
7/n
الحوار ده بيكون صعب لما بتـ Scale في multiple regions لإن مفيش transaction واحدة بتعدل في الكاش وال data store في نفس الوقت.
4- خلي بالك دايمًا من ال SPOF (single point of failure) وده معناه حسب ويكيبيديا إن لو عندك جزء واحد في النظام بتاعك فشل ف النظام كله هيقفـ عشان كده
8/n
4- خلي بالك دايمًا من ال SPOF (single point of failure) وده معناه حسب ويكيبيديا إن لو عندك جزء واحد في النظام بتاعك فشل ف النظام كله هيقفـ عشان كده
8/n
بيوصى إنك تستخدم multiple cache servers في كذا data centers أو إنك تزود نسبة معينة من ال memory عن الي انت هتحتاجه بحيث تكون مساحة احتياطية لو الـ memory اتملت.
5- ضروري جدًا تاخد بالك من الـ Eviction Policy لإن بمجرد ما الكاش بتتملي بتبدأ تعمل cache eviction أو طرد لل items
9/n
5- ضروري جدًا تاخد بالك من الـ Eviction Policy لإن بمجرد ما الكاش بتتملي بتبدأ تعمل cache eviction أو طرد لل items
9/n
الي في الكاش بتاعتك، وفي كذا طريقة الكاش بتخَرَج العناصر منها زي ال Least-recently-used وده الأشهر وفيها بتخرج الداتا الأقل استخدامًا من فترة طويلة.
وعندك كمان الـ Least Frequently Used وهنا انتَ بتخرج الداتا الي اتطلبت عدد أقل من المرات.
10/n
وعندك كمان الـ Least Frequently Used وهنا انتَ بتخرج الداتا الي اتطلبت عدد أقل من المرات.
10/n
وكمان في الـ First in First Out وهنا الداتا بتخرج بناءًا على ترتيب دخولها للكاش، فـ الداتا الأقدم هي الداتا الي بتخرج الأول زي الـ queue كده.
لما لقينا فكرة الكاشينج مفيدة أوي كده في المحتوى الي بيتم طلبه باستمرار لكن التعديل فيه بيكون قليل، جت فكرة ال cdn
11/n
لما لقينا فكرة الكاشينج مفيدة أوي كده في المحتوى الي بيتم طلبه باستمرار لكن التعديل فيه بيكون قليل، جت فكرة ال cdn
11/n
وهي عبارة عن نتورك من السيرفرات متوزعة حول العالم وظيفتها انها بتعمل caching للstatic content في منها لل Dynamic content لكن الكتاب مش مغطيها فممكن نتكلم عنها في ثريد تاني.
خلينا نبص على ازاي ال cdn بيشتغل من ال high level.
12/n
خلينا نبص على ازاي ال cdn بيشتغل من ال high level.
12/n
لو اليوزر طلب صورة من السيرفر بتاعك زي الصورة دي، والسيرفر بتاعك ده في اوروبا مثلا، فهيحتاج 120 مللي ثانية عشان الصورة ترجعله، تخيل لو في سيرفر قريب اوي من اليوزر، فبدل ما يروح ياخد الصورة دي من السيرفر الي في اوروبا لأ هياخدها من أقرب سيرفر للمكان الي هو فيه
13/n
13/n
وقتها هياخد زمن أقل، وليكن 40 مللي ثانية زي الصورة دي كده، متخيل الفرق قد ايه؟ هي دي وظيفة ال cdn بقى، انه يوزع المحتوى الثابت بتاعك على سيرفرات حوالين العالم، وعلى حسب مكان اليوزر بيطلب الملفات دي من أقرب سيرفر ليه.
بس اليوزر طلب صورة مكانتش موجودة على ال cdn؟
14/n
بس اليوزر طلب صورة مكانتش موجودة على ال cdn؟
14/n
وقتها ال cdn هيطلب الصورة من السيرفر بتاعك، ويعملها cache عنده، بعدين يرجعها لليوزر و لأي يوزر يطلبها بعد كده بدون الرجوع للسيرفر.
في شوية اعتبارات مفروض نخلي بالنا منهم واحنا بنستخدم ال cdn زي
1 - التكلفة، الـ CDN بيتقدم من خلال third-party providers وانتَ بتحاسب على
15/n
في شوية اعتبارات مفروض نخلي بالنا منهم واحنا بنستخدم ال cdn زي
1 - التكلفة، الـ CDN بيتقدم من خلال third-party providers وانتَ بتحاسب على
15/n
الـ data transfer الي بيحصل خلال ال CDN.
ولو عندك داتا بيتم الوصول ليها بشكل غير متكرر وعاملها كاش ف كده هي ملهاش لازمة، حاول تشيلها وتبدلها ب داتا بتطلب بإستمرار.
2 - زي ما اتكلمنا في إعتبارات الكاشينج، خلي دايمًا الـ Expiration date مظبوطة حسب نوع الداتا
16/n
ولو عندك داتا بيتم الوصول ليها بشكل غير متكرر وعاملها كاش ف كده هي ملهاش لازمة، حاول تشيلها وتبدلها ب داتا بتطلب بإستمرار.
2 - زي ما اتكلمنا في إعتبارات الكاشينج، خلي دايمًا الـ Expiration date مظبوطة حسب نوع الداتا
16/n
بحيث انها متكنش كبيرة فـ النسخة من الداتا عندك تكون قديمة، وفي نفس الوقت المدة متكنش صغيرة ف تضطر انك تتعامل مع الداتابيز أو السيرفر بتاعك كتير لأجل الداتا دي.
3- الـ CDN fallback، خلي عندك دايمًا احتياطات لو الـ CDN وقعت، إزاي الأبلكيشن بتاعك هيتعامل مع مشكلة زي دي
17/n
3- الـ CDN fallback، خلي عندك دايمًا احتياطات لو الـ CDN وقعت، إزاي الأبلكيشن بتاعك هيتعامل مع مشكلة زي دي
17/n
وإزاي الـ clients هتـdetect المشكلة وهيقدروا يطلبوا الريسورسز مباشرة من الـ origin (السيرفرات بتاعتك)
4- انتَ تقدر تمسح object من ال CDN قبل ما يكون Expired عن طريق عملية من الإتنين دول، الأولى إنك تستخدم الـ API الي بيقدمهولك الـ CDN Providers.
18/n
4- انتَ تقدر تمسح object من ال CDN قبل ما يكون Expired عن طريق عملية من الإتنين دول، الأولى إنك تستخدم الـ API الي بيقدمهولك الـ CDN Providers.
18/n
والتانية هي إنك تستخدم الـ object versioning عشان تقدر تـserve فيرجن تانية من ال object ده، عشان تعمل نسخة تانية من الأوبجيكت تقدر تحط مثلاً ال version number كـ parameter خلال ال URL زي كده img.png?v=2.
19/n
19/n
احنا عارفين ان الـ http هو عبارة عن stateless protocol لإنه فعليًا مبيعرفش لو اتبعتله ريكويستين ورا بعض انهم من نفس الشخص، عشان كده ظهر حاجات لأجل ال authorization زي السيشن الي بتكون في الكوكيز، وزي ال JWT والحاجات دي كلها، المعلومة هتخلق عندنا مشكلة في الديزاين لأي سيستم
20/n
20/n
scalable، انت دلوقتي لما بتبعت ريكويست لسيرفر هو بيديك سيشن ويحفظ عنده السيشن دي بحيث لو طلبت منه حاجة تاني يعرف انتَ مين.
في الصورة دي اليوزر A طلب من سيرفر 1 صورة بروفايله، ف رجعهاله فعلا لإنه لقى ان السيشن بتاعت اليوزر A موجودة عندخ، ويوزر B بعت لسيرفر 2 وحصل نفس الكلام
21/n
في الصورة دي اليوزر A طلب من سيرفر 1 صورة بروفايله، ف رجعهاله فعلا لإنه لقى ان السيشن بتاعت اليوزر A موجودة عندخ، ويوزر B بعت لسيرفر 2 وحصل نفس الكلام
21/n
ويوزر C عمل نفس الكلام مع سيرفر 3، بس تفتكر ايه الي هيحصل لو يوزر A بعت ريكويست لسيرفر 2؟ ايوة، مش هيرد عليه بحاجة لإن السيشن بتاعت اليوزر A مش موجودة في سيرفر 2 واحنا اساسًا لما اتكلمنا عن ال load balancer قولنا ان هيكون عندنا اكتر من سيرفر الأبلكيشن بتاعنا شغال عليهم
22/n
22/n
وال load balancer هيوزع الأحمال عليهم، فكده لو في يوزر كان عامل لوج ان على سيرفر وجرب يعمل ريفريش هيطلب منه انه يعمل login تاني لإنه حرفيًا نسيه. الـ architecture ده اسمه الـ Stateful architecture والحقيقة ان الموضوع ده ليه حل في أغلب ال load balancers
23/n
23/n
اسمه الـ sticky sessions لكن مش ده الي مفروض يحصل لإنه بيضيف overhead ومفروض إن عملية اضافة السيرفرات أو ازالتها تكون سهلة، عشان كده تعالوا نشوف الapproach التاني وهو الـStateless architecture حلها ازاي.
24/n
24/n
الحل ببساطة انك هتضيف data store وتكون shared بين كل ال web servers بتاعتك وفيها ال State data وبكده هيكون سهل من حيث ال scalability والبساطة.
ملحوظة، الdata store دي ممكن تكون أي حاجة، relational database او Memcached/Redis او NoSQL وإلخ، اوقات بيختاروا الـ NoSQL data store
25/n
ملحوظة، الdata store دي ممكن تكون أي حاجة، relational database او Memcached/Redis او NoSQL وإلخ، اوقات بيختاروا الـ NoSQL data store
25/n
عشان سهولة ال scalability فيها.
دلوقتي نفترض ان الأبلكيشن بتاعك بقى كبير، وبيجيله يوزرز من كل حتة في العالم، لكن السيرفرات بتاعتك في data center واحده لسه ولإنك ناصح وعارف انه لا تضع البيض في سلة واحدة، قررت تقسمهم ان عدد x% من الترافيك هيروح للداتا سنتر بتاعت أمريكا
26/n
دلوقتي نفترض ان الأبلكيشن بتاعك بقى كبير، وبيجيله يوزرز من كل حتة في العالم، لكن السيرفرات بتاعتك في data center واحده لسه ولإنك ناصح وعارف انه لا تضع البيض في سلة واحدة، قررت تقسمهم ان عدد x% من الترافيك هيروح للداتا سنتر بتاعت أمريكا
26/n
والباقي هيروح للداتا سنتر في بريطانيا مثلا، لكن اليوزرز هيعرفوا ازاي انهم يروحوا لأقرب داتا سنتر ليهم؟ ده بيحصل عن طريق الـ geoDNS وده عبارة عن DNS service بتخلي الـ domain name يـ resolve لـ IP Address بناءًا على مكان اليوزر، وفي حالة ان حصل data center outage لأي سبب كان
27/n
27/n
وقتها الترافيك بالكامل هيروح للداتا سنتر التانية المتاحة.
في شوية تحديات مفروض تخلي بالك منها وانت بتعمل الـ multi-data center setup
1 - الـ Traffic redirection، وهنا المقصود انك تستخدم Effective tools عشان توجه الترافيك بتاعك للداتا سنتر الصحيحة
28/n
في شوية تحديات مفروض تخلي بالك منها وانت بتعمل الـ multi-data center setup
1 - الـ Traffic redirection، وهنا المقصود انك تستخدم Effective tools عشان توجه الترافيك بتاعك للداتا سنتر الصحيحة
28/n
زي الـ GeoDNS الي اتكلمنا عليها.
2 - الـ Data synchronization: ممكن المستخدمين من داتا سنتر واحده يستخدموا local databases او caches (على مستوى الداتا سنتر)، ف لو حصل مشكلة في الداتا سنتر دي والـ GeoDNS اعاد توجيه المستخدمين دول للداتا سنتر التانية فـ وقتها بيانات اليوزر
28/n
2 - الـ Data synchronization: ممكن المستخدمين من داتا سنتر واحده يستخدموا local databases او caches (على مستوى الداتا سنتر)، ف لو حصل مشكلة في الداتا سنتر دي والـ GeoDNS اعاد توجيه المستخدمين دول للداتا سنتر التانية فـ وقتها بيانات اليوزر
28/n
الي كانت على ال local databases والكاش في الداتا سنتر القديمة مبقتش موجودة، فكده حصل فقد في البيانات والمستخدمين دول البيانات بتاعتهم طارت، الحل الشائع للمشكلة دي انك تـ replicate الـ data على multiple data centers.
29/n
29/n
3- الـ Test and deployment: لو هتستخدم الـ multi-data center setup مفروض تخلي بالك انك تعمل test لل application بتاعك في locations مختلفة وتستخدم Automated deployment tools عشان تحافظ على الـ services consistent في كل الـdata centers.
30/n
30/n
بما اننا عمالين نفصل في الـ components بتاعت ال System واحنا بنعمله scale فتعالى نقدم strategy مهمة جدًا في الdistributed systems وبتستخدم بكثرة في ال real world applications وهي الـ Message queue.
الـ message queue بيعتبر من أعمدة النظام بتاعك، بيتخزن في ال memory
31/n
الـ message queue بيعتبر من أعمدة النظام بتاعك، بيتخزن في ال memory
31/n
وبيدعم الـ asynchronous communication، وبمثابة buffer و بيـdistributes asynchronous requests الـ basic architecture بتاعه سهل، عبارة عن Input services اسمها producers او publishers وهي الي بتـcreate messages وتعملها publish في الـ message queue والتانية عبارة عن services
32/n
32/n
او سيرفرات اسمها consumers او subscribers بيتكون متصلة بالـ queue ده وبتعمل الـ actions المتعرف في ال message.
الـ architecture ده مُفضل وانتَ بتبني scalable و reliable ابلكيشنز، وهتدرك أهميته في المثال الجاي، بس الأول تخيل معايا ان عندك سيرفيس بتجمع تاسكس معينة
33/n
الـ architecture ده مُفضل وانتَ بتبني scalable و reliable ابلكيشنز، وهتدرك أهميته في المثال الجاي، بس الأول تخيل معايا ان عندك سيرفيس بتجمع تاسكس معينة
33/n
ل سيرفيس تانية، وبتحطها في هيئة طابور، تخيل بقى لو السيرفيس التانية دي كانت مشغولة في تاسك معينة بتاخد وقت، هل مفروض ان السيرفيس الأولى تستناها تخلص؟ لأ، مجرد هتحط التاسك دي في ال queue وتروح تجيب تاسكس تانية وتحطها، ولما السيرفس التانية تخلص الي بتعمله تاخد تاسك جديدة
34/n
34/n
والخ حتى لو السيرفيس الاولى مشغولة.
كمثال على ده تخيل ان عندك موقع بيعمل image processing قوية على الصور، وعندك يوزر دخل صورة، فهل مفروض ان الويب سيرفر بتاعك يفضل عطلان ومفيش اي يوزرز تانيين يقدروا يستخدموه لحد ما الصورة دي ال processing الي عليها يخلص ويرجعها؟ لأ طبعًا
35/n
كمثال على ده تخيل ان عندك موقع بيعمل image processing قوية على الصور، وعندك يوزر دخل صورة، فهل مفروض ان الويب سيرفر بتاعك يفضل عطلان ومفيش اي يوزرز تانيين يقدروا يستخدموه لحد ما الصورة دي ال processing الي عليها يخلص ويرجعها؟ لأ طبعًا
35/n
عشان كده الويب سيرفر (producer) في الحالة دي هياخد الطلب بتاع اليوزر ده ويحط الصورة بتاعته في الـ message queue ولو في يوزر في نفس الوقت بيحط صورة تانية هياخد الصورة التانية دي ويحطها في ال message queue وهكذا، فتيجي السيرفيس(consumer) الي بتعمل ال image processing
36/n
36/n
تاخد صورة صورة من ال message queue بالدور وتعالجها، في نفس الوقت الويب سيرفر (producer) بيحط صور في الـ message queue عادي والسيرفيس (consumer) بتاعت ال image processing بتاخد على مهلها صورة صورة تشتغل عليها وترجعها للويب سيرفر وهكذا.
37/n
37/n
الـ producer والـ consumer ممكن يتعملهم scale بشكل مستقل، يعني لو حجم الـ queue بقى كبير فممكن تزود عدد ال consumers.
لو انت ويب سايت صغير شغال على سيرفرين تلاته فـ ال logging والـ metrics والـ automation تعتبر good practices لكن مش ضرورية، لكن لما البيزنيس بتاعك يكبر
38/n
لو انت ويب سايت صغير شغال على سيرفرين تلاته فـ ال logging والـ metrics والـ automation تعتبر good practices لكن مش ضرورية، لكن لما البيزنيس بتاعك يكبر
38/n
هتحتاج انك تعمل ده عشان مثلا في الـ Logging تقدر تعمل Monitoring الـerror logs عشان تعرف مشاكل النظام بتاعك، ممكن تشوف اللوجز بتاعت كل سيرفر لوحده أو تستخدم tool عشان تجمعهم في centralized service عشان تقدر تسرش فيهم بسهولة.
39/n
39/n
الـ Metrics كمان مهم انك تعرفها عشان تفهم الـ health status للسيستم بتاعك زي الـ CPU, Memory, disk والخ بالنسبة للـ Host-level.
اما بالنسبة للـAggregated level فممكن منها تعرف الـ performance بتاع ال DB tier والـ cache tier.
40/n
اما بالنسبة للـAggregated level فممكن منها تعرف الـ performance بتاع ال DB tier والـ cache tier.
40/n
وبالنسبة للـ Key business فتقدر تعرف منها الـ daily active users والـ retention وال revenue والخ.
أما بالنسبة للـAutomation فلما السيستم بتاعك بيكبر وبيزيد التعقيد فـ انت محتاج لأوتوميشن تولز عشان تزود الـ productivity زي الـ Continuous integration وانك تأوتوميت الـbuild
41/n
أما بالنسبة للـAutomation فلما السيستم بتاعك بيكبر وبيزيد التعقيد فـ انت محتاج لأوتوميشن تولز عشان تزود الـ productivity زي الـ Continuous integration وانك تأوتوميت الـbuild
41/n
والـtest والـ deploy process بتاعتك والخ.
أخر حاجة في الشابتر ده هنتكلم عنها هي الـ Database scaling، احنا عندنا 2 approaches عشان الـ DB scaling، الأولى vertical scaling وهي هي زي ال vertical scaling لل servers وهي انا نزود ال CPU, RAM, DISK, etc ونفس المشاكل، تاني حاجة
42/n
أخر حاجة في الشابتر ده هنتكلم عنها هي الـ Database scaling، احنا عندنا 2 approaches عشان الـ DB scaling، الأولى vertical scaling وهي هي زي ال vertical scaling لل servers وهي انا نزود ال CPU, RAM, DISK, etc ونفس المشاكل، تاني حاجة
42/n
وهي horizontal scaling والمعروفة بالـ sharding وهي اننا نضيف سيرفرات تانية.
الـ sharding هو إننا بنقسم الـlarge databases لأجزاء أصغر و manageable أكتر اسمها shards. كل shard بيتشاركوا نفس الschema بالرغم ان البيانات على كل shard بتكون unique.
43/n
الـ sharding هو إننا بنقسم الـlarge databases لأجزاء أصغر و manageable أكتر اسمها shards. كل shard بيتشاركوا نفس الschema بالرغم ان البيانات على كل shard بتكون unique.
43/n
طب دلوقتي ازاي بتقدر تعرف الداتا بتاعتك موجودة في انهي shard ازاي؟
تخيل اننا عملنا 4 shards فعشان نعرف الداتا موجودة في انهي shard بالظبط في كذا تكنيك لده، لكن الأغلب بيستخدم ال hash function لأجل ده، ازاي؟
مفروض انت بتعمل hash function مجرد ما بتديها input بترجعلك
44/n
تخيل اننا عملنا 4 shards فعشان نعرف الداتا موجودة في انهي shard بالظبط في كذا تكنيك لده، لكن الأغلب بيستخدم ال hash function لأجل ده، ازاي؟
مفروض انت بتعمل hash function مجرد ما بتديها input بترجعلك
44/n
الـ user id والـ user id ده بتجيب ال modulus بتاعه مع عدد ال shards بتاعتك الي هي 4 وقتها بتعرف الداتا بتاعتك مفروض تكون في انهي جزء بالظبط، يعني احنا لو عندنا ال user id ب 4 او 8 فـ لو جبت طبقت ال userid % shard_size هتلاقي ان الاتنين دول موجودين في ال shard رقم 0
45/n
45/n
ولو جربت مثلا ارقام زي 2 و 6 فهتلاقيهم في ال shard رقم 2 وهكذا زي ما هو باين في الصورة.
هل شرط يكون ال user id الي انا بعمل بيه العملية دي؟ الحقيقة انه لأ، انت ممكن تعمل ده بأي sharding key والي بيكون اسمه برضو partition key، ال sharding key ممكن يبقى column واحد أو اكتر
46/n
هل شرط يكون ال user id الي انا بعمل بيه العملية دي؟ الحقيقة انه لأ، انت ممكن تعمل ده بأي sharding key والي بيكون اسمه برضو partition key، ال sharding key ممكن يبقى column واحد أو اكتر
46/n
بيعبر عن ازاي الداتا دي distributed تقدر تفهم الموضوع أكتر من الفيديو الي هسيبه في أخر الثريد لـ م. أحمد الإمام بيشرح الموضوع ده.
في criteria مفروض تاخد بالك منها وانتَ بتختار ال key لإن زي ما الكاتب قال ان ال Sharding عبارة عنgreat technique to scale the database لكن
47/n
في criteria مفروض تاخد بالك منها وانتَ بتختار ال key لإن زي ما الكاتب قال ان ال Sharding عبارة عنgreat technique to scale the database لكن
47/n
هو بعيد عن ال perfect solution عشان التعقيدات والتحديات الي بيضيفها للسيستم، فـ انتَ مفروض تاخد بالك من الحاجات دي
1 - الـ Resharding data، الكاتب بيقول ان الـ Resharding data بنكون محتاجينها لما يكون الـ single shard مش قادرة تشيل داتا تاني نظرًا للداتا الكتير الي بتدخل
48/n
1 - الـ Resharding data، الكاتب بيقول ان الـ Resharding data بنكون محتاجينها لما يكون الـ single shard مش قادرة تشيل داتا تاني نظرًا للداتا الكتير الي بتدخل
48/n
الداتا بيز او لو في shard بتعاني من ال shard exhaustion اسرع من غيرها بسبب توزيع غير متساوي للبيانات، فلما بيحصل shard exhaustion بيكون مطلوب مننا اننا ن update الـ sharding function وننقل البيانات. في تقنية الكاتب قال عنها لكن في شابتر 5 اسمها Consistent hashing مفروض
49/n
49/n
انها بتحل المشكلة دي.
2 - الـ Celebrity problem او الـ hotspot key problem، تخيل انك حطيت داتا بتاعت مشاهير كتيرة زي جاستن بيبر، وكاتي بيري، والجيار في shard واحده، وقتها الـ shard هتكون overwhelmed من ال read operations لو كان تطبيقك سوشيال ميديا مثلا
50/n
2 - الـ Celebrity problem او الـ hotspot key problem، تخيل انك حطيت داتا بتاعت مشاهير كتيرة زي جاستن بيبر، وكاتي بيري، والجيار في shard واحده، وقتها الـ shard هتكون overwhelmed من ال read operations لو كان تطبيقك سوشيال ميديا مثلا
50/n
ف الحل انك تـ allocate a shard لكل celebrity.
3 - الـ Join and de-normalization، بمجرد ما الداتا بيز بتاعتك تتقسم على كذا سيرفر مختلف، هيكون صعب انك تعمل join operations ما بين الـ database shards دي، الـ workaround الشائع وهو انك تـ de-normalize الـ database
51/n
3 - الـ Join and de-normalization، بمجرد ما الداتا بيز بتاعتك تتقسم على كذا سيرفر مختلف، هيكون صعب انك تعمل join operations ما بين الـ database shards دي، الـ workaround الشائع وهو انك تـ de-normalize الـ database
51/n
ووقتها الـ queries هتحصل في single table.
ده الديزاين الي وصلناله بنهاية الشابتر، والي مفروض انه يقدر يخدم ملايين اليوزرز، ان شاء الله ممكن خلال الاسبوع ده ننزل الشابتر الجاي والي بعده لإنهم صغيرين،و ياريت لو في حاجة أنا مش فاهمها كويس او كاتبها غلط توضحهالي، ألف شكر <3
52/52
ده الديزاين الي وصلناله بنهاية الشابتر، والي مفروض انه يقدر يخدم ملايين اليوزرز، ان شاء الله ممكن خلال الاسبوع ده ننزل الشابتر الجاي والي بعده لإنهم صغيرين،و ياريت لو في حاجة أنا مش فاهمها كويس او كاتبها غلط توضحهالي، ألف شكر <3
52/52
ده الفيديو الي قولت هسيبه في اخر التويتة بمناسبة ال sharding، معلش بقى نمت ونسيت :"D
youtube.com
youtube.com
جاري تحميل الاقتراحات...