الكاش او الملفات المؤقتة بأسهل الطرق

[مهندس مصرى]

انا لي فريم وورك خاص بي بسيط به الاوامر التي احتاجها فقط و اعمل على نظام الكاش اذا تم اضافة جديد يتم تحديث الكاش تلقائيا بعد الاضافة فقط واعتقد ان هذا افضل شىء في انظمة الكاش التقليدية
ساحاول استخدام ال xcache كما تفضل الاخ المجروح بوضع الشرح له
لكن كاستفسار بسيط .. هل لك اخي المجروح ان توضح آلية عمله بمعنى ..
طريقة استخدامه ؟
اذا كات لدينا استعلام هل نقارن الوقت اولا قبل كتابة الاستعلام واذا كان اقل من الوقت المسموح للكاش يتم جلبه من الذاكرة واذا كان اكبر من الوقت المسموح للكاش يتم تنفيذ الاستعلام مرة أخرى ام كيف نستخدمه؟

[محب الله ورسوله]

انا لي فريم وورك خاص بي بسيط به الاوامر التي احتاجها فقط و اعمل على نظام الكاش اذا تم اضافة جديد يتم تحديث الكاش تلقائيا بعد الاضافة فقط واعتقد ان هذا افضل شىء في انظمة الكاش التقليدية
ساحاول استخدام ال xcache كما تفضل الاخ المجروح بوضع الشرح له
لكن كاستفسار بسيط .. هل لك اخي المجروح ان توضح آلية عمله بمعنى ..
طريقة استخدامه ؟
اذا كات لدينا استعلام هل نقارن الوقت اولا قبل كتابة الاستعلام واذا كان اقل من الوقت المسموح للكاش يتم جلبه من الذاكرة واذا كان اكبر من الوقت المسموح للكاش يتم تنفيذ الاستعلام مرة أخرى ام كيف نستخدمه؟

لا وقت ولا شئ أخي انت تخزن في الذاكرة بيانات بعد عمل serialize لها لحمايتها من أي تغير فيها
مثلا جلبت بيانات جروب الأعضاء في الموقع مع كل خياراتها في مصفوفة كبيرة
اعمل لها serialize وخزنها في الإكس كاش

الأن حينما تأتي لدالة جلب البيانات اللي تكتبها في أول الصفحة خلي فيها شرط
لو البيان موجود في الذاكرة ( عندك دالة isset خاصة بالإكس كاش كما تري ) يجلب من الرام
ولو غير موجود يجلبها بتعليمة سكول ويخزنها في الرام متفقين ؟

طيب متي نحدث البيانات ؟
هكذا ستظل في الرام دائماً

أكتب لنفسك دالة وظيفتها كل ما تناديها تقوم وحدها بعمل تعليمة السكول تلك وتخزين الناتج في الرام ( تعمل unset للبيانات في الذاكرة وتعمل تعليمة السكول وتعيد تخزينها )

ونادي دالتك هذه في كل مكان فيه تحديث للجروبات

بمعني حينما تدخل كمشرف عام للوحة التحكم وتقوم بإضافة مجموعة جديدة ضع مناداة الدالة في أخر مكان لتلك ال action وهي الخاصة بتخزين بيانات المجموعة الجديدة

ايضا ضعها في أخر الأكشن الخاصة بعمل update لمجموعة

هذا المقصد من الكاش اللي نغيره بالأكشن وهذا من الممكن أن يمر يوم كامل علي موقعك لا يتم عمل أية تعليمات سكول
بعكس شخص أخر يجيب الجروبات دائما من قواعد البيانات مع كل زائر فلو لديه 50 ألف صفحة مستعرضة في اليوم تكون أنت وفرت 50 ألف تعليمة سكول ( هذا غير أن تلك المصفوفة كبيرة جدا وستشغل حيز كبير جدا في الذاكرة لكل زائر كل فترة لهذا فأنت وفرت في الذاكرة أيضا )

أما الكاش الخاص بالزمن فخزن في الذاكرة وأكتب له دالة أيضا
وعن طريق الكرون نادي الدالة كل ساعة أو كل وقت حسب ما تريد

بإختصار خصص لنفسك صفحة لدوال الكاش ضع فيها دالة خاصة لكل نقطة هامة في برمجيتك تحتاج فيها لكاش وناديها حسب ال action أو حسب الزمن من خلال الكرون

============
ملحوظة أخواني
ركبت الأكس كاش علي السيرفر وبعده مباشرة قل إستهلاك الذاكرة لدي من 58% تقريبا ل 34% كمتوسط
وهذا أمر أكثر من رائع

[almosmm]

almosmm صراحة لا اقتنع بان CodeIgniter مفيدة في ال caching

بسبب استهلاكها لموارد النظام الذي تسببه هي بمفردها + الكاش الموجودة بها وطريقة التحكم بدائيتين.

هل تقصد استهلاك إطار العمل كله لموارد النظام ؟

اشرح لي عملياً اخي الفاضل! ارجوا ان لا تكون ممن يلقون بكلام " سمعوه " فقط من غيرهم ... لأنه وحتى الآن .. الجميع "وأعني المحترف والمبتدئ " يعلم ان CI هو من أقوى وأسرع إطارات العمل المتواجدة حالياً في الساحة ( يتفوق على CakePHP و Zend Framework وغيرهم )
انا لا اقول هذا الكلام فقط لأنني اقدم دروس CI هنا
ولا اريد ان اتطرق إلى الاسباب العلمية لأنني ذكرتها مراراً وتكراراً

وبخصوص نظام الكاش ... لم اقل انه قوي ابداً عزيزي .. بل انني حتى لا استخدمه ..
النقطة هنا انك تستطيع ان تستخدمه في المجال الذي تريده .. لو افترضنا انك تمتلك صفحة بها معلومات تأتي من قاعدة البيانات ولا تحتاج إلى إستدعائها في كل مرة تدخل الصفحة لأنها ثابتة .. في هذه الحالة استخدم الكاش ..

كما انني دائماً افضل التعديل على المميزات التي لا تعجبني في CI بنفسي ..
بالطريقة التي تم بناء CI عليها .. تستطيع ان تشاهد المصدر بوضوح تاااام وسوف تجد ان الموضوع سهل جداً

ارجوا ان يتشارك الاخوة ويطرحوا النقاط المهمة للكاش لكي يستفيد منها من يريد ان ينصع نظام الكاش الخاص به

[عبد الواحد البشيري]

شكراً على الشرح المبسط
ملحوظه بسيطه .. نسيت

fclose($fp); 

بعد التعديل على ملف الكاش ..

صحيح نسيتها وهي مهمة جدا
شكرا لك

لا وقت ولا شئ أخي انت تخزن في الذاكرة بيانات بعد عمل serialize لها لحمايتها من أي تغير فيها
مثلا جلبت بيانات جروب الأعضاء في الموقع مع كل خياراتها في مصفوفة كبيرة
اعمل لها serialize وخزنها في الإكس كاش

الأن حينما تأتي لدالة جلب البيانات اللي تكتبها في أول الصفحة خلي فيها شرط
لو البيان موجود في الذاكرة ( عندك دالة isset خاصة بالإكس كاش كما تري ) يجلب من الرام
ولو غير موجود يجلبها بتعليمة سكول ويخزنها في الرام متفقين ؟

طيب متي نحدث البيانات ؟
هكذا ستظل في الرام دائماً

أكتب لنفسك دالة وظيفتها كل ما تناديها تقوم وحدها بعمل تعليمة السكول تلك وتخزين الناتج في الرام ( تعمل unset للبيانات في الذاكرة وتعمل تعليمة السكول وتعيد تخزينها )

ونادي دالتك هذه في كل مكان فيه تحديث للجروبات

بمعني حينما تدخل كمشرف عام للوحة التحكم وتقوم بإضافة مجموعة جديدة ضع مناداة الدالة في أخر مكان لتلك ال action وهي الخاصة بتخزين بيانات المجموعة الجديدة

ايضا ضعها في أخر الأكشن الخاصة بعمل update لمجموعة

هذا المقصد من الكاش اللي نغيره بالأكشن وهذا من الممكن أن يمر يوم كامل علي موقعك لا يتم عمل أية تعليمات سكول
بعكس شخص أخر يجيب الجروبات دائما من قواعد البيانات مع كل زائر فلو لديه 50 ألف صفحة مستعرضة في اليوم تكون أنت وفرت 50 ألف تعليمة سكول ( هذا غير أن تلك المصفوفة كبيرة جدا وستشغل حيز كبير جدا في الذاكرة لكل زائر كل فترة لهذا فأنت وفرت في الذاكرة أيضا )

أما الكاش الخاص بالزمن فخزن في الذاكرة وأكتب له دالة أيضا
وعن طريق الكرون نادي الدالة كل ساعة أو كل وقت حسب ما تريد

بإختصار خصص لنفسك صفحة لدوال الكاش ضع فيها دالة خاصة لكل نقطة هامة في برمجيتك تحتاج فيها لكاش وناديها حسب ال action أو حسب الزمن من خلال الكرون

============
ملحوظة أخواني
ركبت الأكس كاش علي السيرفر وبعده مباشرة قل إستهلاك الذاكرة لدي من 58% تقريبا ل 34% كمتوسط
وهذا أمر أكثر من رائع

بما ان المعلومات مخزنة في الذاكرة الا يسبب ذالك ضغط على الذاكرة

[mr_m]

almosmm اهلا بك اخي نعم اعني بالفعل ان اطار العمل الجاهز يستهلك موارد النظام .. بشكل نسبي!

بمعنى.. انك من الممكن ان تبني صفحاتك بشكل سريع وبمرونة عالية بدون اي اطار عمل ..
لكن قد يحتم عليك تواجدك في فريق او عملك بشكل عام استعمال واحد خاص بكم أو customized او جاهز تماما ..
> هذا المفهوم نتج بعد اختبار اساليب عدة مع عدد لا باس به من المحاولات. حقيقة لسنوات عدة ان كان يهمك الزمن.

وبما اني قد مررت بمثل هذا الحديث من قبل فسوف اختصر الحوار حتى لا اكرره
كنت اقول لمن يحاورني ان يذهب لموقع يعتمد على ZF او CI -ما تم اختبارهم.
ثم يأتي بمتوسط اوقات التكوين لصفحات العرض ثم التدرج الى عملية شراء المنتج.
و كان الحد الادنى 7 ملي ثانية (يعني 0.007) والنتيجة عندي لم تزيد عن 2 ملي وهناك صفحات ظهر فيها 0.9 ملي.:1power:
* طبعا تمت مراعاة تشابه البرنامجين.


أما بخصوص الكاش الخاصة ب CI فهي على ما اذكر تعتمد على الملفات في التخزين والاسترجاع والتحقق .. وهذا يضيع وقت كبير.
لذلك يمكنك تحويلها على الرام مع بعض اللمسات ثم لاحظ فرق الوقت قبل وبعد وادعيلي.

[mr_m]

ارجوا ان يتشارك الاخوة ويطرحوا النقاط المهمة للكاش لكي يستفيد منها من يريد ان ينصع نظام الكاش الخاص به

ما رايكم -اذا سمح اخونا عبد الواحد- في ان يحدد احد سكربت مجاني لنتنافس في عمل كاش له

حقيقة احب روح المنافسة والتجديد كثيرا

؟

[عبد الواحد البشيري]

ما رايكم -اذا سمح اخونا عبد الواحد- في ان يحدد احد سكربت مجاني لنتنافس في عمل كاش له

حقيقة احب روح المنافسة والتجديد كثيرا

؟

الموضوع موضوعكم

والله اني استفدت من الردود شكرا لكم

[محب الله ورسوله]

صحيح نسيتها وهي مهمة جدا
شكرا لك

بما ان المعلومات مخزنة في الذاكرة الا يسبب ذالك ضغط على الذاكرة

بل يقللها
لأنه تكون مخزنة مرة واحدة فقط
لكن مع الكويري فيتم جلبها مع كل زائر للذاكرة ( لكن أعتقد الماي سكول تقوم بعدم التكرار لو كانت الداتا نفسها ولا أدري هل ذلك إفتراضياً أم بطرق معينة )

وكما قلت الطريقة مجربة وخفضت الإستهلاك بشدة للسيرفر
مع العلم اني لدي موقع واحد علي سيرفر 4 جيجا رام

[mr_m]

هناك شيء قابلني عند عمل serializing لمصفوفات كبيرة لوضعها على الرام:

ان هذا في بعض الاحيان يكون ابطأ من طلبها من قاعدة البيانات حيث اننا هنا قمنا ب
= طلب قيمة نصية طويلة جدا من الرام
= فك ال serializing ثم التعريف للمصفوفة
= عند طلب عنصر فيها سوف يبحث فيها عن العنصر ليرجع لك مصفوفته التي ستبحث داخلها عن خصائصه.

اما من قاعدة البيانات:
= البحث في جدول -مؤرشف في الاساس لغرض البحث-
= ارجاع مصفوفة واحدة فقط او عدم ارجاع شيء.


لذلك انتقلت لقاعدة البيانات فترة .. ثم انتقلت لوسيلة اراها افضل
وهي تخزين محتويات المصفوفة على شكل نص بدون serializing - ثم استعمال ال Regular Expressions في التحقق والارجاع.
نظرا لان التعامل مع النصوص اسرع واخف بمرات عديدة من التعامل مع المصفوفات.
وايضا يقتصد من المعالجة لدى البروسيسور، و قطعة الذاكرة المؤقتة من الرام والتي تخزن فيها المعلومات للمرة الثانية في كل تنفيذ للصفحة..

[محب الله ورسوله]

هناك شيء قابلني عند عمل serializing لمصفوفات كبيرة لوضعها على الرام:

ان هذا في بعض الاحيان يكون ابطأ من طلبها من قاعدة البيانات حيث اننا هنا قمنا ب
= طلب قيمة نصية طويلة جدا من الرام
= فك ال serializing ثم التعريف للمصفوفة
= عند طلب عنصر فيها سوف يبحث فيها عن العنصر ليرجع لك مصفوفته التي ستبحث داخلها عن خصائصه.

اما من قاعدة البيانات:
= البحث في جدول -مؤرشف في الاساس لغرض البحث-
= ارجاع مصفوفة واحدة فقط او عدم ارجاع شيء.


لذلك انتقلت لقاعدة البيانات فترة .. ثم انتقلت لوسيلة اراها افضل
وهي تخزين محتويات المصفوفة على شكل نص بدون serializing - ثم استعمال ال Regular Expressions في التحقق والارجاع.
نظرا لان التعامل مع النصوص اسرع واخف بمرات عديدة من التعامل مع المصفوفات.
وايضا يقتصد من المعالجة لدى البروسيسور، و قطعة الذاكرة المؤقتة من الرام والتي تخزن فيها المعلومات للمرة الثانية في كل تنفيذ للصفحة..

أخي أين تجرب ذلك ؟
لا تجرب علي السيرفر الشخصي ولكن جرب علي سيرفر حقيقي وأنت كزائر ( كان لدي كويري علي جهازي في السيرفر الخصي كانت تأخذ أقل من نصف ثانية وهو وقت كبير ولكن علي السيرفر أخذت بالضبط 39 ثانية تخيل !! من يومها وأنا أجرب علي السيرفر علي قاعدة بيانات مليئة بالمحتوي وليس علي السيرفر الشخصي في قاعدة بيانات خاوية )
كما أني لم أتكلم عن توفير الحمل علي الماي سكول فقط ولكن أيضا توفير الإستهلاك من الذاكرة
هذا غير أن تنفيذ تعليمة سكول من الأساس لا تجيب لك البيان من الهارد للمعالج
ولكن تنقلها للذاكرة ويبدأ المعالج التعامل معها ويبدوا أن فهمك للأمر خطأ أخي وبناءا عليه كان إستنتاجك خطأ
كما أنك في تعليمة السكول ترسل كويري يتم ترجمتها أولاً عن طريق الإنتربريتر لفهم المطلوب ثم تكوينه علي الهارد ثم نقله للذاكرة هم يبدأ المعالج بالتعامل معها

فأيهما أفضل
ان يكون البيان في الذاكرة مباشرة وتجلبه وتتعامل معه وهو بيان موجود مرة واحدة
ام يكون علي الهارد مفركش في قاعدة بيانات ثم ترسل كويري يتم ترجمتها ثم بعد الترجمة يتم تكوين البيان المطلوب في جدول جديد ثم إرساله للذاكرة ( مع كل زائر يتم ذلك أو كل وقت من الزمن حسب قواعد البيانات ) ثم يتم التعامل معها !!

ثم أنك أفترضت أن تلك الكويري تجلب من جدول حقيقي موجود ولن نستخدم join التي ستجمع البيانات من أكثر من جدول عن طريق جدول إفتراضي تقوم بحمله والتجميع فيه وهذا حمل زائد

الفرق هنا تفرقه بين دالة serialize فقط
وبين عمود طويل من العمليات

[mr_m]

= اخي بداية استخدامي للنصوص في التعامل مع الرام تم التوصل اليها + تجميعها على سرفرات حقيقية موجودة على الانترنت وعليها ضغط عالي من الزوار.
و على مواقع متوسطة لها قواعد بيانات بداخلها 45+ الف عضو و ايضا جداول في بعضها اكثر من 100+ الف record . ان ام تخني الذاكرة


وطالما انك تتعامل مع سيرفر فمن السهل جدا ان تطلع على بيانات الاستخدام و تعرف المقدار المرجو لاستخدام البرنامج من الرام
و تقدير استهلاكه للبروسيسور، طبعا بعد فصل الملفات التي غير HTML و الXML وال XSL على حسب استخدامك.
ثم يمكنك استخدام جهاز virtual بنسبة شير تحددها للبروسيسور و قطعة الرام،
وهذا ما اختبر عليه كل شيء حاليا قبل رفعه .. لن اذكر شيء اضافي لان هذا ليس مجال حديثنا ولن يفيد.



= بخصوص الانتقال كلية لتخزين الكاش على قاعدة البيانات بامكانك ان تسميه "خطأ" وانا معك في ذلك.
لكن هذا كان سنة 2006 وبامكانك تخيل مدى قلة المعلومات والتجارب في هذا المجال وقتها.

اذا اردت المقارنة في "التخزين على الرام" فقارن بين استخدام المصفوفات X استخدام النصوص
الذي اعتمد عليه حاليا عند التخزين على الرام كما ذكرت في ردي السابق.



= لا يجب الاعتماد على الرام كلية و هذا تجده عند المواقع التي عليها ضغط من الزوار سوف تقتصد في استخدام الرام..
عن نفسي ادمج بين انواع التخزين فعلى سبيل المثال وليس الحصر:

- هناك صفحات ستاتيك تماما يتم تحويل الزائر لها وتكونها بالكرون.
- وهناك صفحات تستدعي اجزاء استاتيك من الرام واخرى من صفحات اخرى.
- وايضا هناك fetching لنتائج استعلامات و اعادة تخزينها في جداول لسهولة جلبها.
- وهناك خرائط للسكشنز والاكشنز الخاصة بها و طريقة عرضها في الرام.
- وتخزين بيانات دخول لمستخدمين معينين واعدادات اللغة في الرام على شكل نصوص وترك آخرين.


* واشكال الاستخدام تتوقف على مجال ومهمة الموقع الذي تعمل له كاش .. او بمعنى اصح optimization
* يمكنني المناقشة فيما تم ذكره فقط حتى تعم الفائدة .. لكن ليس اكثر.

[محب الله ورسوله]

= اخي بداية استخدامي للنصوص في التعامل مع الرام تم التوصل اليها + تجميعها على سرفرات حقيقية موجودة على الانترنت وعليها ضغط عالي من الزوار.
و على مواقع متوسطة لها قواعد بيانات بداخلها 45+ الف عضو و ايضا جداول في بعضها اكثر من 100+ الف record . ان ام تخني الذاكرة


وطالما انك تتعامل مع سيرفر فمن السهل جدا ان تطلع على بيانات الاستخدام و تعرف المقدار المرجو لاستخدام البرنامج من الرام
و تقدير استهلاكه للبروسيسور، طبعا بعد فصل الملفات التي غير HTML و الXML وال XSL على حسب استخدامك.
ثم يمكنك استخدام جهاز virtual بنسبة شير تحددها للبروسيسور و قطعة الرام،
وهذا ما اختبر عليه كل شيء حاليا قبل رفعه .. لن اذكر شيء اضافي لان هذا ليس مجال حديثنا ولن يفيد.



= بخصوص الانتقال كلية لتخزين الكاش على قاعدة البيانات بامكانك ان تسميه "خطأ" وانا معك في ذلك.
لكن هذا كان سنة 2006 وبامكانك تخيل مدى قلة المعلومات والتجارب في هذا المجال وقتها.

اذا اردت المقارنة في "التخزين على الرام" فقارن بين استخدام المصفوفات X استخدام النصوص
الذي اعتمد عليه حاليا عند التخزين على الرام كما ذكرت في ردي السابق.



= لا يجب الاعتماد على الرام كلية و هذا تجده عند المواقع التي عليها ضغط من الزوار سوف تقتصد في استخدام الرام..
عن نفسي ادمج بين انواع التخزين فعلى سبيل المثال وليس الحصر:

- هناك صفحات ستاتيك تماما يتم تحويل الزائر لها وتكونها بالكرون.
- وهناك صفحات تستدعي اجزاء استاتيك من الرام واخرى من صفحات اخرى.
- وايضا هناك fetching لنتائج استعلامات و اعادة تخزينها في جداول لسهولة جلبها.
- وهناك خرائط للسكشنز والاكشنز الخاصة بها و طريقة عرضها في الرام.
- وتخزين بيانات دخول لمستخدمين معينين واعدادات اللغة في الرام على شكل نصوص وترك آخرين.


* واشكال الاستخدام تتوقف على مجال ومهمة الموقع الذي تعمل له كاش .. او بمعنى اصح optimization
* يمكنني المناقشة فيما تم ذكره فقط حتى تعم الفائدة .. لكن ليس اكثر.

أنا فقط وجدت خطأ في كلامك فأحببت توضيحه فربما أكون أكثر معرفة منك في جانبك الهاردوير والتعامل مع البيانات كونه مجال تخصصي في كلية الهندسة الإلكترونية

فأنت تقول أن تخزين البيان في الذاكرة كان أبطأ من جلبه من قاعدة البيانات
كيف ذلك والبيان اصلا حينما تطلبه من قاعدة البيانات يتم نقله للذاكرة ليبدأ التعامل معه !!
يعني هذه الخطوة ما هي إلا خطوة من خطوات التعليمة التي لا بد أن تمر بها وأنت بذلك وفرت كل الخطوات وأستخدمت خطوة واحدة

هذا هو الخطأ اللي احببت توضيحه ولو تريد توضيح أكثر لعمل تعليمات السكول سأسرد لك القصة كله من أول إقلاع نظام التشغيل حتي أنظمة ال DBMS والتي درستها في مادتين للداتا بيز في الكلية أيضا إلخ لتعلم اللعبة

تخزين بيان في الذاكرة لإستخدامه بدلاً من تطبيق تعليمة سكول هو عملية تحدث في التعليمة نفسها وأنت تكون وفرت زمن الترجمة للتعليمة والتنفيذ لها علي الهارد ديسك وجلب البيان من الهارد ديسك لنقله للذاكرة ليصبح في الأخر في الذاكرة وهي الخطوة التي نستخدمها في الكاش ونستغني عما قبلها كله مع زيادة أيضا وهو جعل ذلك البيان موجود مرة واحدة في الذاكرة بدلاً من جلبه مع كل زائر وتخزينه في address مختلفة من الذاكرة ( أنظمة ال DBMS المتقدمة لا تفعل ذلك ولكن لو كانت التعليمة ونتائجها نفسها ولانتائج في الذاكرة فهي ترسل النتائج ولكن هذا يتم بمقياس زمني يعتمد علي إعدادات حتي لا يحدث أخطاء )

مع العلم أن نظام التخزين في الذاكرة وتحديد ال address كان مجال دراسة لنا في مادتين أيضا مع معالج 8086 ثم جهاز الماري والمانو وكيفية تحديد الأدريس وتخزين البيانات وأيضا درسنا دراسة بسيطة للأسمبلي ليكون تطبيق عملي مع ما درسناه في الهاردوير

فإذا كان بإمكانك أن تتحكم أنت بالأمر بتدخل بشري منك في ناتج تعليمة معينة فهذا أمر رائع ولهذا وجدت مسرعات ال php وأوجدت تلك الخاصة لكي تسمح لك بعمل ما لا يمكن لأنظمة الداتا بيز عمله لأنها لا تعلم إن كان ذلك الناتج قابل للتحديث أم لا وما مدي ذلك

[mr_m]

اخي هل تعني انك مثلا لكي تعمل تحقق لل login لزائر مثلا هل سوف تتحقق منه عن طريق جلب 50000 مصفوفة
من الرام و البحث عن اسمه فيها ثم مقارنة معلوماته ؟ أم سوف تتحقق عنه باستعلام SQL ؟

وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟


* حقيقة بخصوص الهاردوير فهو هواية لي قبل ان تفيدني اجزاء بسيطة منه في العمل.
* وبخصوص الداتابيس فلا يوجد لي علم كبير فيها -فقط الحد الذي يفيدني في عملي .. نظرا لاني لا اتعلمها بغرض العلم.
* لكن أعتمد بشكل كبير على الاحصائيات والارقام التي اراها بعيني في المفاضلة بين الاشياء.

[محب الله ورسوله]

اخي هل تعني انك مثلا لكي تعمل تحقق لل login لزائر مثلا هل سوف تتحقق منه عن طريق جلب 50000 مصفوفة
من الرام و البحث عن اسمه فيها ثم مقارنة معلوماته ؟ أم سوف تتحقق عنه باستعلام SQL ؟

وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟


* حقيقة بخصوص الهاردوير فهو هواية لي قبل ان تفيدني اجزاء بسيطة منه في العمل.
* وبخصوص الداتابيس فلا يوجد لي علم كبير فيها -فقط الحد الذي يفيدني في عملي .. نظرا لاني لا اتعلمها بغرض العلم.
* لكن أعتمد بشكل كبير على الاحصائيات والارقام التي اراها بعيني في المفاضلة بين الاشياء.

لا أخي ما أقصده أنك حينما تطلب مثلاً بيانات العضو رقم 5
يتم ترجمة تعليمة السكول من خلال المعالج عبر المترجم الخاص بال DBMS والذي يحمل نفسه للذاكرة مع الكيرنل الخاص بالنظام
بعد الترجمة تذهب للهاد باحثة عن الجدول المطلوب
بعد إيجاده يتم نقله للذاكرة
ثم يبدأ المعالج في تنفيذ ما تريده علي بيانات ذلك العضو بينه وبين الذاكرة

ولتفهم ما قصدته بالكاش اللي شرحته
لديك مجموعات الأعضاء
حينما تريد بيانات العضو الفلاني وصلاحيته طبقاً لمجموعته
تذهب وتجلب مجموعته فقط

ولكن في حالتي تخزن كل المجموعات في مصفوفة في الرام

هنا ستقول لي إذا الأفضل جلبها سأخبرك لا
لأنه في نفس الوقت هناك عشرات الأعضاء من أماكن مختلفة دخلوا وتجلب لهم بيانات مجموعاتهم

هنا لديك الأن 100 زائر في الموقع من 50 مجموعة مختلفة
كل عضو منهم جلبت له بيانات مجموعة عضويته وخزنتها في address مختلفة في الذاكرة لتبدأ التعامل مع محتواها بعمليات البرمجة ( المنطقية والحسابية )
طيب هذا يعني أنك جلب معلومات مجموعة العضوية الفلانية مثلا 80 مرة وخزنتها مكررة 80 مرة وأجريت لها في ذلك الوقت 80 تعليمة سكول لنقلهما للذاكرة

فتوفر هذا كلاه وتجعل المصفوفة كلها في الذاكرة مرة واحدة فقط فتكون

1- وفرت مساحة الذاكرة بشدة من تكرار بيانات المجموعات
2- وفرت عملية الترجمة للسكول


هل وصلت الفكرة ؟
ما تنقله للذاكرة هو ما تريده فقط فلما مع كل زائر تنقله للذاكرة
خليه هناك
=======================================
علي الهامش

بشكل مختصر جدا
كل ما يقوم به المعالج من عمليات يقوم في أول عمله بنقلها للذاكرة والتعامل معها عن طريق الجسر الشمالي
ولهذا فالشركات من إنتل ل amd تحاول توفير سرعة نقل أفضل
ومتحكم الذاكرة اللي كان مدمج في المعالج من أول المعالج athelon ولم يكن مدمج في معالجات إنتل وبدأت بدمجه من أول المعالج core i7 هو المتحكم في أماكن البيانات في الذاكرة ونقلها إلخ

طيب ماذا يحدث لو كان هناك بيان كثير الإستخدام من قبل المعالج
يعني بيان طلبت عمل أس له ( عمليات الاس أو الفلوتينج بوينت هي أكثر العمليات إرهاق للمعالج ويتم بها قياس قدرة المقالج والتفرقة بينها )
يقوم المعالج بنقل البيان من الذاكرة البعيدة لذاكرة الكاش القريبة والتي تكون أسرع بكثير ويختلف حجمها من معالج لأخر بل ويختلف طريقة إستخدامها من شركة لأخري
في amd يوجد مستويين للكاش l1 و l2
وتزيد إنتل في المعالجات الجديدة ب l3
كل مستوي يكون أقرب للذاكرة وأقل حجماً ويكون أكثر سرعة وتكلفته أعلي

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

لو تريد سرد تفصيلي من أول فتح الحاسوب وما يقوم به البايوس وتحميل كيرنل النظام في الذاكرة إلي الفرق بين الذاكرة وما فيها وما يتم نقله للذاكرة الإحتياطية علي الهارد ( swap في حالة لينوكس ) إلخ فقط أمر أخي

سأحاول بإذن الله شرح الأمر فهو مفيد جدا للمبرمجين لأنه فيه كلام عن ال DBMS خاصة وأن المتطور منها يمكنه أن يضع بيانات داخل الكاش ميموري للمعالج ويتحكم في كل بيان داخل وخارج من المعالج ويخصص bit لتحديد ما كانت المتغير الفلاني حدث عليه تغيير أم لا

ولكن هذه الأمور يتم إستخدامها دائما في المشاريع الكبيرة مثل البنوك وغيرها
فتخيل معي أنك عند البنك وطلبت سحب مبلغ وبعدما تم تنفيذ البيان بالطرح في قاعدة البيانات أنقطعت الكهرباء ولم يخرج لك المال :shy:
ماذا يحدث هنا ؟

هنا تستخدم ال transaction وكل هذه العمليات تعتمد بشدة علي فهم ما يتم علي الرام وما يتم علي الهارد ديسك

طيب ماذا لو لم تنقطع الكهرباء ولكن حدث عطب في الهارد ديسك ولم تكن البيانات الخاصة بأخر 5 دقائق نقلت للنظام العام للبنك ؟

طيب ماذا لو كنت عند شباك وتسحب فلوس وفي نفس اللحظة يقوم موظف اخر بإضافة فلوس لك في الحساب
فسحب الموظف الأول مبلغك من قاعدة البيانات وهو 2000 جنية ثم سحب الموظف علي الشباك الأخر ال 2000 جنيه أيضا
ثم قام الموظف الجديد بطرح 1000 جنيه سحبتها فأصبح المبلغ الجديد 1000 جنيه
لأن صار الموظف الثاني لديه بيان يقوم أن حسابك 2000 جنيه وهذا خطأ
وبالتالي أي عملية يقوم بها يقوم بها علي رقم خاطئ
هنا يجب أن موظف الشباك الأول كان يغلق علي بيانك في قاعدة البيانات حينما سحبه وحينما يأتي الموظف الثاني لسحبه يخبره النظام أن المتغير مغلق

طيب هل يغلقه قراءة وكتابة أم كتابة فقط ؟
طيب لو الموظف الثاني طلبه وتم الرفض هل يطلبه مرة أخري أم يتم تعليمه علي طابوم طلبات مطلوب للمتغير الفلاني ليتم إعطاءه له أو ما يتم فك الإغلاق ؟

الداتا بيز أكبر بكثير من ان تكون مجرد تعليمة سكول

خلاصة القول وبشكل عملي
طلبت تنفيذ تعليمة ستجلب من 5 جداول بإستخدام ال join
يتم تنفيذ ما طلبت علي الهارد ديسك وتكوين جدول جديد فيه ما طلبت وذلك عن طريق mysql_query()
الأن يتم نقل هذا الجدول للذاكرة
ثم يمكنك أن تتعامل معه طوال الفترة الباقية للصفحة من خلال الذاكرة
سواء mysql_fetch_assoc() أو عد عدد الصفوف إلخ
كل هذه تتم علي البيانات التي جلبتها لتوك للذاكرة وهذا لتسريع العمل
ولكن لو ظلت علي الهارد فسيكون الأمر مرهق جدا في كل تنفيذ علي النتائج

هل وصلت الفكرة ؟

[mr_m]

اخي لو انك اجبت على اسئلتي على شكل نقط وكل على حدة كنت ستسهل علي عملية الرد..

لا أخي ما أقصده أنك حينما تطلب مثلاً بيانات العضو رقم 5
يتم ترجمة تعليمة السكول من خلال المعالج عبر المترجم الخاص بال DBMS والذي يحمل نفسه للذاكرة مع الكيرنل الخاص بالنظام
بعد الترجمة تذهب للهاد باحثة عن الجدول المطلوب
بعد إيجاده يتم نقله للذاكرة
ثم يبدأ المعالج في تنفيذ ما تريده علي بيانات ذلك العضو بينه وبين الذاكرة

ولتفهم ما قصدته بالكاش اللي شرحته
لديك مجموعات الأعضاء
حينما تريد بيانات العضو الفلاني وصلاحيته طبقاً لمجموعته
تذهب وتجلب مجموعته فقط

ولكن في حالتي تخزن كل المجموعات في مصفوفة في الرام

هنا ستقول لي إذا الأفضل جلبها سأخبرك لا
لأنه في نفس الوقت هناك عشرات الأعضاء من أماكن مختلفة دخلوا وتجلب لهم بيانات مجموعاتهم

هنا لديك الأن 100 زائر في الموقع من 50 مجموعة مختلفة
كل عضو منهم جلبت له بيانات مجموعة عضويته وخزنتها في address مختلفة في الذاكرة لتبدأ التعامل مع محتواها بعمليات البرمجة ( المنطقية والحسابية )
طيب هذا يعني أنك جلب معلومات مجموعة العضوية الفلانية مثلا 80 مرة وخزنتها مكررة 80 مرة وأجريت لها في ذلك الوقت 80 تعليمة سكول لنقلهما للذاكرة

فتوفر هذا كلاه وتجعل المصفوفة كلها في الذاكرة مرة واحدة فقط فتكون

1- وفرت مساحة الذاكرة بشدة من تكرار بيانات المجموعات
2- وفرت عملية الترجمة للسكول


هل وصلت الفكرة ؟
ما تنقله للذاكرة هو ما تريده فقط فلما مع كل زائر تنقله للذاكرة
خليه هناك

طيب انت ذكرت تعامل الداتابيس مع داتا ولم تذكر تعامل PHP مع ال 50000 مصفوفة المخزنة في الرام
والتي تقوم بفك ال serializing لها ثم تعمل لها declaring في كل طلب للصفحة -ولا يخزن المسرع الا ال intermediate code للصفحات فقط-
اي ان المصفوفات سيتم معالجتها ووضعها في جدول المتغيرات في الرام ثم يبحث داخل ال 50000 عنصرر في المصفوفة ليخرج لك مصفوفة تتعامل معها.

بمعنى انك طالما طلبت المصفوفات سوف يتم تعريفها في PHP و البحث فيها مع كل تنفيذ للكود..
ترى هل هذه العملية اسرع ام البحث في الداتابيس؟

وبخصوص طريقة تعامل MySQL مع الداتا وفرزها هل يعقل انه لو عندك جدول 500 ميجا انها تنقله للرام؟ ومع كل يوزر:con2:

لا بالطبع عزيزي ما اعرفه انها تبحث فقط ضمن الحقل المحدد لها وهو هنا ال username ولا اعرف ان كانت تنقله للرام كاملا ام لا.
و ايضا لا يتم التحقق من كل ال entries الموجودة به -حيث يتم فرزها وترتيبها اثناء عملية التخزين- ثم البحث بداخلها.
ثم بعد النجاح تحدد الاجزاء التي طلبتها من الجدول وترجعها لك.. لكن لا اعتقد ان الجدول ينقل كاملا للذاكرة.


* وعلى كل ساقتبس لك سطر من ردي قبل السابق

- وتخزين بيانات دخول لمستخدمين معينين واعدادات اللغة في الرام على شكل نصوص وترك آخرين.

ويتم وضع ال rules لهم بناء على تحليل اخر اوقات الدخول.



* لكنك لم تجب على باقي اسئلتي

وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟

-------------
اما ما هو مكتوب على الهامش فسوف اقرأه بتأني لأعلق عليه.