مدونة عمار الخوالده

طرق تخزين جداول قواعد البيانات: Row-oriented vs Column-oriented

قُصاصة

تنقسم قواعد البيانات من حيث طريقة تخزين البيانات على مستوى الجداول إلى نوعين:

  1. Row-oriented Database
  2. Column-oriented Database

هذا التقسيم متعلق بآلية التخزين في الـ Storage System.

التخزين في الـ Row-Oriented Databases

يتم تخزين القيم الخاصة بنفس الـ Entity على صف واحد بحيث تكون كلها متتالية، وهذا هو الافتراضي في قواعد البيانات المعروفة كـ PostgreSQL و SQLite.

Row-Oriented Databases

أنظمة قواعد البيانات التقليدية (PostgreSQL, MySQL) - OLTP

جدول products

ID, Name, Price, Category

الصف 1: 1، لابتوب، 999.99، إلكترونيات

الصف 2: 2، ماوس، 29.99، إلكترونيات

الصف 3: 3، مكتب، 299.99، أثاث

الصف 4: 4، كرسي، 199.99، أثاث

بالتالي، اذا وجدت قاعدة البيانات بداية الصف، فبامكانها الحصول على جميع بيانات هذا الـ Entity عن طريق قراءة الصف كاملا.

التخزين في الـ Column-Oriented Databases

وعلى عكس الطريقة الأولى، يتم تخزين البيانات المتشابهة في صف واحد، فأسماء المستخدمين في صف، وعناوين البريد الإلكتروني في صف آخر.

Column-Oriented Databases

أنظمة التحليل (Redshift, BigQuery) - OLAP

جدول products

ID, Name, Price, Category

عمود ID:

1، 2، 3، 4

عمود Name:

لابتوب، ماوس، مكتب، كرسي

عمود Price:

999.99، 29.99، 299.99، 199.99

عمود Category:

إلكترونيات، إلكترونيات، أثاث، أثاث

ما الفرق بين طريقتي التخزين؟

الـ Row-Oriented Databases هي الأنسب لأنظمة OLTP (Online Transaction Processing)، ففي متجر إلكتروني مثلا، ستحتاج إلى بيانات “المنتج” كاملة (اسمه وسعره وتقييمه) أو على الأقل عددا منها حتى تنفذ عليه أي عملية كالتعديل أو الإضافة إلى السلة.

Row-Oriented Databases

أنظمة قواعد البيانات التقليدية (PostgreSQL, MySQL) - OLTP

جدول products

ID, Name, Price, Category

الصف 1: 1، لابتوب، 999.99، إلكترونيات

الصف 2: 2، ماوس، 29.99، إلكترونيات

الصف 3: 3، مكتب، 299.99، أثاث

الصف 4: 4، كرسي، 199.99، أثاث

تخيل حاجتنا للبحث عن منتج (وليكن المكتب من المثال السابق) لعرضه في متجر إلكتروني، ستبحث قاعدة البيانات في جميع الصفوف، لكن بمجرد الوصول إلى الصف رقم 3، يمكن لقاعدة البيانات الوصول إلى جميع بيانات “المكتب” عن طريق قراءة ذلك السطر، لأن بيانات كل منتج متتالية في الـ Storage.

الوصول إلى بيانات نفس المنتج أبطأ وأعقد في الـ Column-Oriented Databases، فللحصول على جميع بيانات “المكتب” بعد البحث بالاسم كما في المثال السابق ستبحث قاعدة البيانات في البيانات الخاصة بعمود Name، قاعدة البيانات تعلم الآن ان بيانات “المكتب” موجودة دائما في الحقل الثالث، فستقوم بقراءة كل صف من البيانات (عمود في تمثيل قاعدة البيانات الطبيعي) واستخراج الحقل الثالث لبناء Entity المكتب:

Column-Oriented Databases

أنظمة التحليل (Redshift, BigQuery) - OLAP

جدول products

ID, Name, Price, Category

عمود ID:

3 ، 4

عمود Name:

لابتوب، ماوس، مكتب ، كرسي

عمود Price:

999.99، 29.99، 299.99 ، 199.99

عمود Category:

إلكترونيات، إلكترونيات، أثاث ، أثاث

ما فائدة الـ Column-Oriented Databases إذا كانت أبطأ؟

الـ Column-Oriented Databases أنسب لأنظمة OLAP (Online Analytical Processing) مثل مستودعات البيانات (Data Warehouses)، عادة في أنظمة الإحصائيات، تحتاج لعمليات التجميع (Aggregations) من نفس الحقول.

فعلى عكس المثال السابق، لو كان المطلوب هو الحصول على عدد المنتجات في كل تصنيف، ستكون الـ Row-Oriented Databases ابطأ بسبب حاجتها لقراءة كل صف من البيانات (كل منتج) واستخراج عمود Category.

بينما في الـ Column-Oriented Databases، بيانات عمود Category كلها مخزنة بشكل متتالٍ في الـ Storage مما يسرع عملية الوصول إليها.

Column-Oriented Databases

أنظمة التحليل (Redshift, BigQuery) - OLAP

جدول products

ID, Name, Price, Category

عمود ID:

1، 2، 3، 4

عمود Name:

لابتوب، ماوس، مكتب، كرسي

عمود Price:

999.99، 29.99، 299.99، 199.99

عمود Category:

إلكترونيات، إلكترونيات ، أثاث، أثاث

إضافة إلى ما سبق، بما أن البيانات المتتالية في وحدة التخزين متشابهة كما ترى في بيانات الـ category في المثال السابق، يمكن تنفيذ خوارزميات الضغط (Compression) مما يقلل المساحة المطلوبة لتخزين البيانات ويزيد من سرعة تنفيذ الـ Aggregation Functions.

على أرض الواقع، قد يختلف الـ implementation بحسب الـ Database System، فربما تجد قاعدة بيانات Row-Oriented تنفذ بعض عمليات الـ Aggregation بكفاءة أو العكس.

في المشاريع الصغيرة، يكفي وجود indexes مناسبة لتسريع عمليات الـ Aggregation، ويمكن تخزين بعض النتائج في أعمدة أخرى أو جداول مخصصة للإحصائيات (عملية De-normalization).

عند زيادة حجم المشروع وزيادة الحاجة للإحصائيات المعقدة، غالبا ما يتم انشاء قاعدة بيانات مخصصة للـ OLAP مستقلة عن قاعدة البيانات الرئيسية للنظام.