لو انا عملت select all من table معين مع شوية filters هل ال filters دي بتتنفذ في ال hard disk والداتا اللي بتجيلي بتحون الداتا اللي معمول ليها filter بس ولا الداتا كلها بتروح ال RAM وبعدين ال CPU يعمل ال filter operations دي ولو بتحصل في ال hard ده بيتم ازاي لو في اكتر من condition وبرده كان عندي معلومات ان ال CPU مش بيتعامل مباشرة مع ال hard ولكن ال RAM زي وسيط ما بينهم وده في الوضع الطبيعي طبعا
اذا افترضنا عدم وجود index يبقى هنعمل full table scan. بيتم قراءة الداتا من الdisk إلى الRAM (بيقرا كل مرة page كاملة من الديسك للRAM) وبعدين يبدأ ياخد كل row و يشوف الfilters متحققة ولا لأ على الrow ده وبعدين يعمل نفس الكلام للpage اللى بعدها وهكذا. فبالتالي تنفيذ الfilters بيكون على الداتا فى الRAM. لو فيه index فبيتم برضه تحميل الindex من الديسك إلى الRAM و بعدين يبتدى يشوف الfilter على الindex وده هيحدد محتاج يقرأ اى rows من الديسك
@@TechVault_ كده اقدر افهم من كلام حضرتك ان حتى لو عملت select ل بعض ال columns برده اللي هيرجع ال table كامل وبعدها يبدأ يعمل projection في ال RAM برده ولو كده يبقى ال select columns بدل ال select * هترفق بس في ال نقل ال data دي عن طريق ال network بس .. ده اول سؤال تاني سؤال معذرا ال rows اللي متحققش عليها ال filters هل في garbage collection بيتعمل مع ال rows اللي مش متطابقة ويشيلها من ال RAM ؟
بالنسبة للسؤال الاول... مش صح قوى. اى query فى الاخر هى مجموعة عمليات ورا بعض وكل عملية بتدينا intermediate result اللى هى كأنها temp table فى الميموري وده اللى بيدخل على العملية اللى بعدها. ممكن الoptimizer يعمل الprojection بدري على قد ما يقدر عشان يقلل حجم ال intermediate result وبالتالى مش دايما هتكون اخر عملية. لكن الداتا اللى بنقراها من الديسك لازم تكون الrow كله. السؤال التانى...برضه له علاقة بالintermediate results. الrows اللى محققتش الfilter هي جزء من الoutput بتاع الscan operation لكن مهياش في ال output بتاع الfilter operation. طبعا كل execution engine ممكن تكون له طريقة مختلفة. فممكن مثلا يزود bit يقوله إذا كان الrow عدا الfilter ولا لأ. وبعدين كل الداتا اللى فى الmemory كده كده بتنتهى بانتهاء الquery فمش محتاج garbage collection. طبعا ده باستثناء حاجة زى الcache مثلا
ممكن حضرتك تعمل فديو عن الفروقات بين mysql و postgres من ناحية query execution و انهي فيهم بيكون احسن في scenarios مختلفة وليه
ماشاء الله، اول مره الاقى شرح عربى لمواضيع متقدمه فى الداتا بيز بالشكل ده.
كل الدعم لحضرتك.❤
تحفة فنية♥
جميل جدا الشرح منظم ومحتوى عربي نادر في المواضيع دي
نتمنى لك الاستمرار ومواصلة الإفادة ❤
ما شاء الله تبارك الله
شكرا يا دكتور عمرو على شرحك المتميز للموضوعات المتقدمة في الداتا بيز
استاذ عمرو ما اعرف شلون اشكرك، صححتلي وفهمتني اهواي مواضيع، واتمنى من حضرتك موضوع خاص عن البحث FTS وشكرا جزيلا مقدما وعلى كل شيء
كل الدعم للشرح المنظم وبينظم المعلومات ف دماغنا
ربنا يبارك ف حضرتك يا دكتور و يزيدك من فضله و علمه♥♥
في وقتها 👌❤
كل الشكر ياهندسه شرحك تحفه
ربنا يكرمك ويبارك فيك، شكرا من القلب ❤
Keep going Dr.Amr ❤️
Thank you very much, Dr. Amr 🙏
ربنا يبارك فيك شرح قمة في الروعة ❤❤
ما شاء الله ،ممتاز ، ربنا يبارك فيك
Great work ❤
ربنا يباركلك يارب
ربنا يباركلك
Keep going
لو انا عملت select all من table معين مع شوية filters هل ال filters دي بتتنفذ في ال hard disk والداتا اللي بتجيلي بتحون الداتا اللي معمول ليها filter بس ولا الداتا كلها بتروح ال RAM وبعدين ال CPU يعمل ال filter operations دي
ولو بتحصل في ال hard ده بيتم ازاي لو في اكتر من condition وبرده كان عندي معلومات ان ال CPU مش بيتعامل مباشرة مع ال hard ولكن ال RAM زي وسيط ما بينهم وده في الوضع الطبيعي طبعا
اذا افترضنا عدم وجود index يبقى هنعمل full table scan. بيتم قراءة الداتا من الdisk إلى الRAM (بيقرا كل مرة page كاملة من الديسك للRAM) وبعدين يبدأ ياخد كل row و يشوف الfilters متحققة ولا لأ على الrow ده وبعدين يعمل نفس الكلام للpage اللى بعدها وهكذا. فبالتالي تنفيذ الfilters بيكون على الداتا فى الRAM.
لو فيه index فبيتم برضه تحميل الindex من الديسك إلى الRAM و بعدين يبتدى يشوف الfilter على الindex وده هيحدد محتاج يقرأ اى rows من الديسك
@@TechVault_
تسلم يا هندسة ❣️
@@TechVault_ كده اقدر افهم من كلام حضرتك ان حتى لو عملت select ل بعض ال columns برده اللي هيرجع ال table كامل وبعدها يبدأ يعمل projection في ال RAM برده ولو كده يبقى ال select columns بدل ال select * هترفق بس في ال نقل ال data دي عن طريق ال network بس ..
ده اول سؤال
تاني سؤال معذرا ال rows اللي متحققش عليها ال filters هل في garbage collection بيتعمل مع ال rows اللي مش متطابقة ويشيلها من ال RAM ؟
بالنسبة للسؤال الاول... مش صح قوى. اى query فى الاخر هى مجموعة عمليات ورا بعض وكل عملية بتدينا intermediate result اللى هى كأنها temp table فى الميموري وده اللى بيدخل على العملية اللى بعدها. ممكن الoptimizer يعمل الprojection بدري على قد ما يقدر عشان يقلل حجم ال intermediate result وبالتالى مش دايما هتكون اخر عملية. لكن الداتا اللى بنقراها من الديسك لازم تكون الrow كله.
السؤال التانى...برضه له علاقة بالintermediate results. الrows اللى محققتش الfilter هي جزء من الoutput بتاع الscan operation لكن مهياش في ال output بتاع الfilter operation. طبعا كل execution engine ممكن تكون له طريقة مختلفة. فممكن مثلا يزود bit يقوله إذا كان الrow عدا الfilter ولا لأ. وبعدين كل الداتا اللى فى الmemory كده كده بتنتهى بانتهاء الquery فمش محتاج garbage collection. طبعا ده باستثناء حاجة زى الcache مثلا
@@TechVault_
حقيقي استافدت جدا بالردود بتاعت حضرتك
شكرا ليك يا هندسة ❣️