تم تطوير أنظمة DBMS المجمعة بشكل نشط في سنوات الصفر ، في اللحظة التي وجدوا فيها مكانها ولا تتنافس عمليًا مع أنظمة الأحرف الصغيرة التقليدية. وبموجب الخفض ، يفهم المؤلف ما إذا كان الحل الشامل ممكنًا ومدى عمليته.
"هناك تقدم في كل شيء ... لا تخف من أنهم سوف يتصلون بك إلى المكتب ويقولون:" لقد استشرنا هنا ، وغدًا سيتم إيواءك أو إحراقك حسب اختيارك. "سيكون خيارًا صعبًا. أعتقد أنه سيكون في حيرة من قبل الكثير منا ".
ياروسلاف هاسيك. مغامرات الجندي شويك الشجاع.
الخلفية
كم عدد قواعد البيانات الموجودة ، هذه المواجهة الأيديولوجية هي إلى حد كبير. بدافع الفضول ، وجد المؤلف كتابًا لـ J. Martin من IBM [1] في صناديق عام 1975 وتعثر على الفور بالكلمات (ص. 183): "العلاقات الثنائية تستخدم في الأعمال [...] ، أي علاقات مجالين فقط. من المعروف أن العلاقات الثنائية تعطي أكبر قدر من المرونة للقاعدة. ومع ذلك ، فإن العلاقات بدرجات مختلفة مريحة في المهام التجارية ". تُفهم العلاقات هنا على أنها علاقات علائقية. والأعمال المذكورة مؤرخة عام 1967 ... 1970.
دع Sybase IQ كان أول عمود DBMS مستخدم صناعيًا ، ولكن على الأقل على مستوى الأفكار ، تم التحدث عن كل شيء قبل 25 عامًا.
في الوقت الحاضر ، يتم دعم DBMSs التالية في أعمدة أو إلى درجة أو أخرى (يتم أخذ هذا بشكل رئيسي
هنا ):
تجاري
مصدر مجاني ومفتوح
الاختلافات
العلاقة العلائقية هي مجموعة من الصفوف ، وهي في الأساس جدول ثنائي الأبعاد. وفقًا لذلك ، هناك خياران للتخزين - الصفوف أو حسب العمود. الفصل هو اصطناعي قليلاً ومنطقي. توقف مطورو قواعد البيانات منذ فترة طويلة عن تخطيط
الأسطوانات وتتبع السجلات. تتمثل مهمة مسؤولي DBMS في تحليل بيانات DBMS على النحو الأمثل في نظام (أنظمة) الملفات ، ولكن الطريقة التي تقوم بها أنظمة الملفات بترتيب البيانات على الأقراص الفعلية معروفة بشكل رئيسي لمطوري نظام الملفات.
سيكون من المنطقي السماح لنظام إدارة قواعد البيانات (DBMS) بتحديد ترتيب تخزين البيانات. هنا نتحدث عن بعض أنظمة إدارة قواعد البيانات الافتراضية التي تدعم كلا الخيارين لتنظيم تخزين البيانات ولديها القدرة على تعيين جدول لأي منها. لا نعتبر خيارًا شائعًا جدًا لدعم قاعدتي بيانات - واحدة للعمل ، والثانية للتحليلات / التقارير. فضلا عن فهرسة العمود ل Microsoft SQL Server. ليس لأنها سيئة ، ولكن لاختبار الفرضية القائلة بأن هناك طريقة أكثر أناقة.
لسوء الحظ ، لا يمكن لأي DBMS افتراضي اختيار أفضل طريقة لتخزين البيانات. لأن لا يفهم كيف سنستخدم هذه البيانات. وبدون ذلك ، من المستحيل اتخاذ قرار ، على الرغم من أنه مهم للغاية.
الجودة الأكثر قيمة لنظام DBMS هي القدرة على معالجة البيانات بسرعة (ومتطلبات
ACID ، بالطبع). يتم تحديد سرعة DBMS بشكل أساسي من خلال عدد عمليات القرص. تنشأ حالتان متطرفتان من هذا:
- يتم تغيير / إضافة البيانات بسرعة ، تحتاج إلى وقت للكتابة. الحل الواضح - يوجد خط (tuple) ، إن أمكن ، على صفحة واحدة ، لا يمكن القيام به بشكل أسرع.
- نادرًا ما تتغير البيانات أو لا تتغير على الإطلاق ، نقرأ البيانات عدة مرات ، ولا يشارك سوى عدد صغير من الأعمدة في كل مرة. في هذه الحالة ، من المنطقي استخدام متغير من الأعمدة للتخزين ، ثم عند قراءة أقل عدد ممكن من الصفحات سوف يرتفع.
لكن هذه حالات متطرفة ، في الحياة كل شيء ليس واضحًا.
- إذا كنت ترغب في قراءة الجدول بأكمله ، فمن وجهة نظر عدد الصفحات ، فإن البيانات ليست مهمة سطرًا بسطر أو في الأعمدة. أي أن هناك بعض الاختلاف ، بالطبع ، في نسخة العمود الحكيمة لدينا القدرة على ضغط المعلومات بشكل أفضل ، ولكن هذا ليس مهمًا في الوقت الحالي.
- ولكن من حيث الأداء ، هناك فرق بسبب مع التسجيل سطرًا بسطر ، ستتم القراءة من القرص بشكل خطي أكثر. يتجه عدد أقل من محرك الأقراص الثابتة إلى الأمام بشكل أسرع للقراءة. تسمح قراءة الملف التي يمكن التنبؤ بها أثناء التسجيل سطرًا تلو الآخر لنظام التشغيل (OS) باستخدام ذاكرة التخزين المؤقت على القرص بكفاءة أكبر. هذا مهم حتى بالنسبة لمحركات أقراص SSD ، لأن التحميل عن طريق الافتراض ( اقرأ المستقبل ) غالبًا ما يؤدي إلى النجاح.
- لا يغير التحديث دائمًا السجل بالكامل. لنفترض أن الحالة الشائعة هي تغيير في عمودين. ثم سيكون من الجيد إذا كانت بيانات هذه الأعمدة ستكون في صفحة واحدة ، لأنك تحتاج فقط إلى قفل صفحة واحد لكل سجل بدلاً من صفحتين. من ناحية أخرى ، إذا كانت البيانات موزعة عبر الصفحات ، فهذا يجعل من الممكن للمعاملات المختلفة تغيير بيانات صف واحد دون تعارضات.
هنا نظرة عن قرب. الخيار الافتراضي هو جعل الجدول صغيرًا أو عموديًا ، يجب أن يقوم DBMS بعمله عند إنشائه. ولكن لاختيار هذا الاختيار ، سيكون من الجيد أن نعرف ، على سبيل المثال ، كيف سنغير هذا الجدول. ربما يجب عليك رمي عملة معدنية؟
- لنفترض أننا نستخدم بنية شجرة (على سبيل المثال: فهرس مجمع) للتخزين. في هذه الحالة ، يمكن أن تؤدي إضافة البيانات أو حتى تغييرها إلى إعادة توازن الشجرة أو جزء منها. في تخزين الصفوف ، يوجد قفل كتابة (واحد على الأقل) ، والذي يمكن أن يؤثر على جزء كبير من الجدول. في النسخة العمودية ، تحدث مثل هذه القصص كثيرًا ، ولكنها تسبب ضررًا أقل بسبب تهم فقط عمود معين.
- خذ بعين الاعتبار التصفية حسب الفهرس. افترض أن العينة متناثرة بما فيه الكفاية. ثم يفضل التسجيل سطرًا تلو الآخر ، لأنه في هذه الحالة تكون نسبة المعلومات المفيدة للقراءة للشركة أفضل.
- إذا كان الترشيح يعطي تدفقًا أكثر كثافة وكان مطلوبًا فقط جزءًا صغيرًا من الأعمدة ، فإن النسخة الأعمدة من الحكمة تصبح أرخص. أين الفارق بين هذه الحالات وكيف نحدده؟
بعبارة أخرى ، لن يتحمل نظام إدارة قواعد البيانات الافتراضي لدينا تحت أي ظرف من الظروف مسؤولية الاختيار بين خيارات تخزين الخطوط والأعمدة ، ويجب أن يتم ذلك بواسطة مصمم قواعد البيانات.
ومع ذلك ، نظرًا لما سبق ، سيكون مصمم قاعدة البيانات أيضًا في اختيار صعب للغاية. كان يحير الكثير منا.
ماذا لو
في الجوهر ، يقوم كل من المتغيرات من حيث العمود والعمود - الحالات القصوى لفكرة واحدة - بقطع الجدول إلى "شرائط" وتخزين البيانات سطرًا بسطر داخل كل شريط. فقط في حالة واحدة يكون الشريط واحدًا ، وفي الآخر يتدهور الشريط إلى عمود واحد.
فلماذا لا تسمح بالخيارات الوسيطة - إذا كانت بيانات بعض الأعمدة تأتي / تقرأ معًا ، حتى لو كانت على نفس الشريط. وإذا لم يكن هناك بيانات (NULLs) في الشريط ، فلا حاجة لتخزين أي شيء. في الوقت نفسه ، تتم إزالة مشكلة الحجم الأقصى للصف - يمكنك تقسيم الجدول عندما يكون هناك خطر من عدم احتواء الصف في صفحة واحدة.
هذه الفكرة ليست أصلية ، فقد أتيحت للمؤلف فرصة لرؤية الشيء نفسه وتطبيقه بنفسه. عنصر الجدة هو تمكين مصمم قاعدة البيانات من تحديد كيفية تقسيم طاولته إلى أجزاء وفي أي شكل ستذهب البيانات إلى القرص.
فعلنا ذلك لأنفسنا على النحو التالي:
- عند إنشاء جدول ، يتم تمرير معلومات حول تفضيلاتنا إلى معالج SQL باستخدام البراغمات
- في البداية ، عند إنشاء جدول ، من المفترض أن الصف بأكمله سيكون موجودًا على صفحة واحدة من شجرة B
- ومع ذلك ، يمكنك استخدام - - #pragma page_break
لإخبار معالج SQL أن الأعمدة التالية ستكون موجودة على صفحة أخرى (في شجرة أخرى) - الاستخدام - - #pragma column_based
يسمح لنا أن نقول بشكل موجز أن الأعمدة التي تذهب أبعد من ذلك تقع على شجرتها الخاصة - - - #pragma row_based
يلغي الإجراء القائم على الأعمدة - وبالتالي ، يتكون الجدول من شجرة B واحدة أو أكثر ، والعنصر الرئيسي الأول هو حقل الهوية المخفية. يُعتقد أن الترتيب الذي يتم فيه إنشاء السجلات (قد يرتبط جيدًا بالترتيب الذي تتم فيه قراءة السجلات) مهم أيضًا ولا يجب إهماله. المفتاح الأساسي هو شجرة منفصلة ، ولكن هذا لا ينطبق على الموضوع.
كيف يمكن لهذا أن يبدو عمليا؟
على سبيل المثال ، مثل هذا:
CREATE TABLE twomass_psc ( ra double precision, decl double precision, …
على سبيل المثال ، تم أخذ الجدول الرئيسي لأطلس
2MASS ، الأسطورة
هنا وهنا .
J ،
H ،
K - نطاقات فرعية تعمل بالأشعة تحت الحمراء ، من المنطقي تخزين البيانات عليها معًا ، حيث يتم معالجتها معًا في البحث. هنا ،
على سبيل المثال :
الصورة الأولى التي ظهرت.
أو
هنا ، أجمل:
لقد حان الوقت للتأكيد على أن هذا له معنى عملي.
النتائج
ويرد أدناه:
- مخطط الطور (رقم X للصفحة المسجلة ، رقم Y لآخر تسجيل سابق) لإجراءات كتابة الصفحات (أرقام منطقية) إلى القرص عند إنشاء جدول في نسختين
- في العمود ، تم تعيينه على أنه by_1
- ولجدول مقطوع إلى 16 عمودًا ، يتم تعيينه على أنه by_16
- مجموع الأعمدة 181
دعونا نلقي نظرة فاحصة على كيفية عملها:
- يعتبر خيار by_16 أكثر إحكاما بشكل ملحوظ ، وهو منطقي ، والأخير - خيار الخط سيعطي خط مستقيم فقط (مع القيم المتطرفة).
- القيم المتطرفة المثلثية - سجل الصفحات المتوسطة من الأشجار B.
- يظهر سجل البيانات ، بالطبع ، ستبدو القراءة شيء من هذا القبيل.
- قيل أعلاه أن جميع الخيارات تسجل نفس كمية المعلومات وأن الدفق الذي يحتاج إلى طرح هو نفسه تقريبًا (± كفاءة الضغط).
ولكن هنا يظهر بوضوح شديد أنه في نسخة العمود ، تنمو الأشجار بسرعات مختلفة بسبب تفاصيل البيانات (في أحد الأعمدة غالبًا ما تتكرر وتضغط بشكل جيد للغاية ، في العمود الآخر - الضوضاء من وجهة نظر الضاغط). ونتيجة لذلك ، تتقدم بعض الأشجار إلى الأمام ، بينما يتأخر البعض الآخر ؛ عند القراءة ، نحصل بشكل موضوعي على وضع قراءة "ممزق" غير سارٍ جدًا لنظام الملفات. - لذا ، فإن by_16 أفضل بكثير للقراءة من العمود الحكيم ، فهي تكاد تكون متساوية في الراحة مع الخط الحكيم.
- ولكن في الوقت نفسه ، يتميز متغير by_16 بالمزايا الرئيسية لمتغير العمود في الحالة عندما يكون هناك حاجة إلى عدد صغير من الأعمدة. خاصة إذا لم تقسم الطاولة ميكانيكيًا لـ 16 قطعة ، ولكن بشكل هادف ، بعد تحليل احتمالات استخدامها المشترك.
مصادر
[1] جيه مارتن. تنظيم قواعد البيانات في أنظمة الحوسبة. العالم 1978
[2]
فهارس العمود ، وميزات الاستخدام[3] دانيال عبادي ، صموئيل مادن ، نبيل هاشم.
متاجر Column مقابل متاجر الصف: ما مدى اختلافهم حقًا؟ ، وقائع المؤتمر الدولي ACM SIGMOD بشأن إدارة البيانات ، فانكوفر ، كولومبيا البريطانية ، كندا ، يونيو 2008
[4] مايكل ستونبراكر ، Uğur Çetintemel.
"مقاس واحد يناسب الجميع": فكرة حان وقتها ، عام 2005