أنظمة تقنية المعلومات

NO SQL , ماهو ؟ لماذا ؟ هل هو البديل القادم ؟

By حسام الكرد

March 04, 2014

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

إعتماد التطبيقات المختلفة على قاعدة بيانات واحدة (RDBM)

ماهي ال No SQL

ليست مضاد ال SQL وإنما هي Not SQL بمعنى أنها لا تستخدم لغة ال SQL المشهورة التي تعمل من خلال قواعد البيانات المبنية بطريقة الجداول والصفوف والأعمدة , ال No SQL تتمتع بمرونة أكثر حيث يمكن تخزين معلومات مختلفة لكل صف , كما يمكن إدخال بيانات مصنفة داخل حقل مثل حفظ Arrays , Objects ..etc في داخل الحقول.

إمكانية توزيع المعلومات حسب التطبيقات في أنظمة ال  NO SQL

علينا أن ندرك أن ال No Sql:

– لن تكون الحل الفريد لمشكلة ال Scalability الخاصة بتطبيقك. – لن يكون من السهل التعامل مع البيانات مثل ال SQL حيث يمكن الإستفادة من العلاقات وعمل Joins.

 

لماذا ال No SQL :

– عدد المستخدمين الكبير , وترددهم بشكل عشوائي إلى التطبيقات , ودخولهم من أجهزة مختلفة فتارة من الهاتف المحمول وتارة من الtablet وتارة من جهاز الحاسوب.

– حجم البيانات الضخم , مثلما ذكرنا سابقا في تدوينة “البيانات الضخمة (BIG DATA) من يملك المعلومة يملك القوة !” أن التطبيقات أصبحت لابد أن تسجل كل المعلومات الخاصة بالمستخدمين مما جعل البيانات المسجلة معقدة وغير موحدة النوع حيث أن أغلبها يميل لأن يكون عشوائي.

توضيح أن الداتا في طبيعتها غير مصنفة

– الحاجة لتوزيع المعلومات على أجهزة مختلفة لضمان الفعالية المستمرة مثل ال Cloud Computing مثلما طرحنا سابقا في موضوع ال “المشكلة الكبيرة , يمكن حلها بالتجزئة … ال MapReduce“.

 

أنواع ال No SQL

ليست كل ال No Sql واحدة فهناك أنواع مختلفة نذكر منها :

Document Store : ويتم تخزين المعلومات فيها على شكل مستندات مصنفة بصيغ مشهورة مثل (XML , JSON ..etc) بحيث يسهل الإستعلام عن المعلومات بداخلها ولكن دون إستعمال ال Joins وغالبا ما تتوافق مع طبيعة ال OOP في التنظيم والتصنيف.

Key- value Store : ويتم تخزين المعلومات بناء على Key وقيمة , ومن عيوبه أنه لا يمكن الإستعلام عن القيم إلا بواسطة ال Key في اغلب الأحيان.

Tabular / Big Table : يتم تخزين المعلومات في جداول ولكن تختلف بأن كل صف قد يحوي أعمدة خاصة بها , ويتم تخصيص نسخة لكل صف.

Graph : يتم تخزين البيانات على شكل رسومي , وتم تصميمها لتوضح النقاط المتواصلة.

 

نظرية ال CAP :

نظرية تقوم على أن كل نظام موزع يمكن أن يضمن عنصرين من أصل ثلاثة عناصر أساسية

Consistency (الإتساق) : أن كل الnodes او الأجهزة لديها نفس المعلومات في نفس الوقت (محدثه). Availability (التوفر) : أنه يمكن القراءة والكتابة دائما على كل ال nodes. Partition tolerance (إمكانية التقسيم) : أن النظام يعمل بشكل جيد في الشبكة الموزعة.

 

No SQL CAP theorem

وبالتالي فإن البعض قد يفضل ضمان الإتساق مع قابلية التقسيم (CP)  بدون التوفر A في كل الوقت , أو التوفر وقابلية التقسيم AP دون الإتساق في نفس الوقت

أمثلة على أنظمة Consistent, Partition-Tolerant (CP) Systems

BigTable (column-oriented/tabular) used By Google Hypertable (column-oriented/tabular) HBase (column-oriented/tabular) used by twitter specially in search MongoDB (document-oriented) Terrastore (document-oriented) Redis (key-value) Scalaris (key-value) MemcacheDB (key-value) used by Facebook for cash Berkeley DB (key-value)

أمثلة على أنظمة Available , Partition-Tolerant (AP) Systems

Dynamo (key-value) used by amazon Voldemort (key-value) used By linked in Tokyo Cabinet (key-value) KAI (key-value) Cassandra (column-oriented/tabular) used By Facebook , twitter still exterminating CouchDB (document-oriented) SimpleDB (document-oriented) used by amazon Riak (document-oriented)

دمتم بود وإلى تدوينة أخرى

المصادر

http://blog.beany.co.kr/archives/275 http://www.lynda.com http://www.couchbase.com/why-nosql/nosql-database http://blog.nahurst.com/visual-guide-to-nosql-systems Scalable SQL and NoSQL Data StoresRick Cattell , Cattell.Net Software ,SIGMOD Record, December 2010