No SQL تقنية بدأت اليوم وكأنها ظاهرة لحل مشاكل قواعد البيانات الضخمة , ولكنها ليست جديدة فكانت كثيرا ما تستخدم في الأنظمة المغموسة وكذلك بعص البرامج مثل Apollo, إنما إستدعت الحاجة إليها ظهورها والإهتمام بها , نظرا لصعوبة وتكلفة توزيع وتقسيم انظمة قواعد البيانات RDBMS على التطبيقات الموزعة.
ماهي ال No SQL
ليست مضاد ال SQL وإنما هي Not SQL بمعنى أنها لا تستخدم لغة ال SQL المشهورة التي تعمل من خلال قواعد البيانات المبنية بطريقة الجداول والصفوف والأعمدة , ال No SQL تتمتع بمرونة أكثر حيث يمكن تخزين معلومات مختلفة لكل صف , كما يمكن إدخال بيانات مصنفة داخل حقل مثل حفظ Arrays , Objects ..etc في داخل الحقول.
علينا أن ندرك أن ال 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 (إمكانية التقسيم) : أن النظام يعمل بشكل جيد في الشبكة الموزعة.
وبالتالي فإن البعض قد يفضل ضمان الإتساق مع قابلية التقسيم (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
