قواعد بيانات لم تسمع عنها

السلام عليكم ،

كنت أريدها مقالة قصيرة علمية رصينة ، ولكن لظروف قاهرة ^{[كسل رهيب ]} جعلت المقالة ترفع شعار " للاطلاع فقط " ، ولم أتمكن من تمحيصها جيداً ، حيث انشغلت البارحة بمتابعة Ice Age للمرة الرابعة عشر، ولكن لنبدأ بالعصر الحجري للكمبيوتر ، حيث كانت الأفكار في ذلك الوقت تحاول أن تتخيّل الكمبيوتر وتحاول توجد الأدوات التي من خلالها نصنع البرنامج ولم أسبر أغوار تلك الفترة جيداً لذلك سأنتقل للعصر الجليدي - أواخر السبعينات - حيث CIA كانت تريد من شركة Ampex ، التي كان يعمل فيها " Ellison" ، تطوير قاعدة بيانات أسماها فيما بعد بـOracle والتي ظهرت كقاعدة بيانات علائقية - مبنية على فكرة الجداول - ومن الجيد أن اذكر أني قرأت في مكان ما أن أوّل نسختين من Oracle تم تطويرها باستخدام Assembly قبل أن ينتقلوا للغة السي ، وهذا يفتح باب لسؤال مهم : أيهم أقوى ، السي أم الاسمبلي ؟ _{تباً ..هل دار بخلدك هذا السؤال الآن ؟!}

على مدار تطوّر Oracle وتقدمها ، بدايةً من اعتمادها على معمارية Client/Server ثم 3-tier ، واخراج لغة مثل PLSQL وما إلى ذلك .. إلا أن الفكرة كانت واحدة وهي الاعتماد على " الجداول " كمبدأ أساسي في تخزين البيانات وتنفيذ الاستعلامات باستخدام لغة SQL . خلال هذه الفترة ، لم تكن Oracle تعيش بسلام ، فكونها ماموثة العصر الجليدي ، لم يمنع الغير من المنافسة فكانت IBM بمنتجها DB2 تزاحم Oracle ، ودخول Microsoft على الخط بشراءها لأحد المنتجات الذي تحوّل إلى SQL Server ، أشعل المنافسة .

وفي العصر الجليدي لابد من ظهور بعض الطفيليات .. حتى في جو قارص ، فكانت SQLight هي تلك ، فصارت هي ( سنجاب ) العصر الجليدي الذي يلاحق (حبّة الفسدق) ليحصل على شيء من الوجبة . SQLight يسير على نفس النمط .. جداول مع sql ، ولكن بتطويرات تتمثل بـميزة الحجم الصغير ، قدرة على العمل في بيئة لاتحوي على " سيرفر " .. فكل ماتحتاجه هو " بضعة بايتات " من جهازك لتستخدم SQLlight في برنامجك ، وهذا ما جعل Mozilla تختار SQLight بل وتدعمها وتستخدمها في أعز ما تملك - Firefox - ، فهي الخيار المفضل للبرامج التي تعمل على Client فقط ، وما بين السنجاب SQLight و الماموثة Oracle لابد ان يظهر ( الكسلان ) وهو الـ Access ليشير بذيله : أنا موجود .


MySQL و postgreSQL و " عد و اغلط " ، كلها قواعد بيانات تسير على نفس النمط .. جداول مع sql ، ولكن بحذف عيب وإضافة ميزة. وتستطيع أن تضم محبوبة Sun - عليها الرحمة - ، المسمّاة بـ Apache Derby ، ضمن " الجوقة " .. قد يكون الاختلاف هنا ، أنك أمام قاعدة بيانات مكتوبة بلغة أخرى ، لغة الشمس .. لغة Java ، كانت Sun تحب Apache Derby كثيراً :-( .

مع ظهور الانترنت وانتشاره ، ظهرت XML ( هل هناك ربط بينهما ؟ لا أعرف ) ، XML أثارت ضجة وحركت المياه الراكدة في أواخر القرن الماضي ، جعلت بيل جيتس يقرر أن كل شيء تنتجه Microsoft ، يُبنى على XML كوسيلة لتخزين وتبادل البيانات . صدق وهو الصدوق عند محبيه الكذوب عند البطاريق ، فكانت أوامره قد وصلت لفريق Microsoft Office لينفذوا ذلك ، فكل شيء يخزن على هيئة XML ، وفتح هذا مجالاً واسعاً لتبادل مستندات MS Office عبر الويب ، وعبر التطبيقات المختلفة . وكان هذا حال كثير من التطبيقات التي انتقلت إلى XML لتخزين بيانتها بدلاً من أسلوب العصر الحجري الأزلي ، Binary Files . قد تكون ضخامة المساحة على القرص الصلب هي من دفعت بـ XML للازدهار .. ولكن من يقف وراء XML ما اكتفى بهذا ، بل أنتج XSLT و XPath ، ليجعل من XML أداة جاهزة وطيّعة لتحل كبديل لقواعد البيانات العلائقية Relational database .. والأمور لم تتوقف عند هذا ، بل ظهرت XQuery لتكون بمثابة SQL لـ XML .

موضة " المواصفات القياسية " التي أخرجتها W3 ، لم تمنع Google من أن تنتفض وتنتج أسلوبها الخاص في تخزين بياناتها " الضخمة جداً جداً " ، فكان BigTable المبني على GFS ، هذا المنتج لازال قابعاً في شركة Google حسب ما قرأت. المنتج لايسير على نفس نهج وطريقة " قواعد البيانات السابقة ، فموضة Client/Server البائدة وموضة 3-tier الحالية ، يبدو أنها لا تكفي .. لا أعلم عن تفاصيل هذا المنتج ، ولكن تستطيع تشبيهه بمنتج Facebook ذو الاسم الحسن و الوجه الحسن Cassandra الذي أتاحوه لـ Apache لتكمل المهمة .. كاسندرا ، ترفع شعار " رنان " ، وهو NoSQL ، صدّقني ستسمع هذا كثيراً في كوابيسك ... NoSQL ... NoSQL ... ، الميزة التي يتكلمون عنها ، أنك أمام قاعدة بيانات يمكن أن تطوّرها بمجرد إضافة مزيد من Hardware دون الحاجة لتدخل سوفتويري .. ثورة Google و Facebook ثم لحاق Digg بهم ونظرها للمستقبل بعيون كاسندرا لا بعيون MySQL ، بل وحتى ثورة Amazon على الأساليب التقليدية في تخزين البيانات ، جاء بسبب أنك أمام أعداد مهولة منتشرة بأصقاع الأرض ، تريد الحصول على مواردك resources ، وبالتالي بدا أن Oracle لوحدها ، ليست هي ذاك الحل المثالي ، فالعملاء تغيروا ، فأنت لست أمام " بنك " أو " فندق " ، أنت أمام Google و Facebook ، وأضف عليهما Twitter .

وبمناسبة ذكر Amazon ، كلنا يعرف أن Amazon خدمتناسنين طويلة "بكتبها " .. لكن أضف لمعلوماتك أن Amazon تنوي قطع أرزاق بعض قرّاءنا الأعزاء ، بفكرة واقعية جداً : لماذا أقوم بتوظيف DBA وأخسر راتب شهري 30 ألف ريال ، بينما يمكنني قطع رزق ذاك الموظف بـطريقة Simple ؟ استطاعوا بالفعل أن يوجدوا طريقة لقطع رزق DBAs من خلال SimpleDB، والأرزاق بيد الله - نسيت أن اخبرك ان SimpleDB أيضاً ترفع شعار NoSQL . وبمناسبة NoSQL ، من الجيد أن تعرف من يرفع هذا الشعار لتأمن شره أو تنضم للقافلة وتكون ممن ينادي لا " إس كيو ال " .

يكفي ان تتخيّل أن JSON دخلت على الخط ، فهناك قاعدة بيانات تقوم على فكرة JSON أيضاً .. الفكرة يبدو أنها ثورية ، بالرغم من بساطتها ( key and value ) ، فحين تستخدم Javascript قاعدة بياناتها الخاصة بأسلوبها الذي تفهمه ، يجعل الأمور تختلف وقواعد اللعبة تختلف ، بل ويخالجك شعور ، أنك وصلت لعصر متقدّم جداً ، خذ DovetailDB بطريقك !

المنتجات كثيرة ، فقاعدة بيانات MongoDB الساحرة ، CoucheDB، HyperTable و أخيراً لا ننسى الشاب Redis لنضمّه للقافلة تشجيعاً له ، كلها دليل على أن الأمور تغيّرت ، وأن Oracle كماموثة للعصر الجليدي قد تنقرض يوماً ما .. فالكل يستطيع أن ينتج والكل يستطيع أن يصنع قاعدة بياناته بيده لا بيد عمرو ، أما موضة " الجداول " و " الكويريات " الكلاسيكية ، انتهت .

أن تكتب" كويري وقح " ، كهذا :

SELECT emp.ename, dept.dname, sg.grade
  FROM emp 
  JOIN dept ON emp.deptno = dept.deptno
  JOIN salgrade sg 
        ON ((emp.sal BETWEEN sg.losal AND sg.hisal)
        AND (emp.sal NOT IN (
                SELECT losal
                FROM salgrade))
        AND (emp.sal NOT IN (
                SELECT hisal
                FROM salgrade )))

ليس كما تكتب " استعلام ألطف " كهذا :

  db.users.find({last_name: 'Smith'}, {'ssn': 1});

الاستعلامين مختلفين .. صحيح ، لكن القصد هو اختلاف المبدأ الذي يقوم عليه الاثنان .


هذه الثورة ، بدأت في أواخر التسعينات من القرن الماضي ، وازدادت هيجاناً مع بداية الألفية و انتشار تطبيقات Web 2.0 و الحوسبة السحابية و لغات البرمجة الكائنية و ظهور لغات برمجة متوازية مثل Erlang يمكنها أن تكون الاختيار الأفضل لبناء DBMS بدلاً من لغة السي أو الاسمبلي ( هل حسمت أمرك بعد وعرفت من الأقوى ؟ .. لا ؟ تباً ) ، فهنا أصبحت قواعد البيانات موجهة لبيئة معينة ، مثل تطبيقات الويب التي يزورها يومياً البلايين ، وليس للتطبيقات الكلاسيكية ، الموجهة للفنادق و المطاعم الفخمة ، والتي لو جمعت روّادها لن يتعدوا عدد أطراف " دودة أم 44 " .

أغلب RDBMS مثل Oracle فهمت قواعد اللعبة ، وصارت تحاول أن تغطي جميع الاتجاهات الممكنة بما فيها Document-oriented Database ، ولكن وصمة Relational و لعنة SQL لا زالت تلاحقها . وليت SQL Server يرفع شعار NoSQL أو حتى YesStanardSQL بدلاً من SQL ممسوخ ، وبما أن Document-Oriented Databse ذُكرت ، من الجيد ان نقول أن هذا يشمل أي قاعدة بيانات مبنية على XML أو JSON .


مع كل هذه الثورة ، وكل هذه الأعداد الهائلة من DBMSs التي وردت في هذا المقال ، يحق لنا أن نتساءل ...

ألم يمت " الكسلان " بعد ؟