الخماسي هو وسيلة لتقديم أجزاء من البيانات الذرية تشير إلى دورها في مجال الأعمال. يمكن للخماسيات وصف أي عنصر ، بينما يحتوي كل منهم على معلومات كاملة عن نفسه وعلاقاته بخماسيات أخرى. هذا الوصف لا يعتمد على النظام الأساسي المستخدم. هدفها هو تبسيط تخزين البيانات وتحسين وضوح عرضها.
سنناقش طريقة لتخزين المعلومات ومعالجتها ومشاركة بعض الأفكار حول إنشاء منصة تطوير في هذا النموذج الجديد. لماذا؟ لتطوير أسرع وتكرارات أقصر: ارسم مشروعك ، وتأكد من أنه ما فكرت فيه ، وصقله ، ثم استمر في تحسين النتيجة.تحتوي الخماسية على خصائص: النوع ، القيمة ، الأصل ، الترتيب بين الأقران. وبالتالي ، هناك 5 مكونات بما في ذلك المعرف. هذا هو أبسط شكل عالمي لتسجيل المعلومات ، وهو معيار جديد يمكن أن يلائم أي متطلبات برمجة. يتم تخزين الخماسيات في نظام الملفات الخاص بالهيكل الموحد ، في مجموعة متجانسة من البيانات المفهرسة المستمرة. نموذج بيانات الخماسي - نموذج بيانات يصف أي بنية بيانات كقائمة واحدة مترابطة من الأنواع والمصطلحات الأساسية المستندة إليها (بيانات التعريف) ، وكذلك مثيلات الكائنات المخزنة وفقًا لبيانات التعريف هذه (البيانات).
نصف دقيقة من كلماتفي الوقت الحاضر ، هناك عدد لا حصر له من المعايير لتسجيل البيانات ، والعديد من الأساليب والقواعد ، والتي تعتبر المعرفة ضرورية للعمل مع هذه السجلات. يتم وصف المعايير بشكل منفصل ولا تتعلق مباشرة بالبيانات المقابلة. في حالة الخماسيات ، بأخذ أي منها ، يمكنك الحصول على المعلومات ذات الصلة حول طبيعتها وخصائصها وقواعد المعالجة في مجال عمل المستخدم. المعيار موحد وثابت لجميع المناطق. يتم إخفاء الخماسي من المستخدم - البيانات الوصفية والبيانات متاحة للأخير بطريقة مشتركة مفهومة.
الخماسية ليست معلومات فقط ، بل يمكن أن تمثل أيضًا رمزًا قابلاً للتنفيذ. ولكن قبل كل شيء ، هي البيانات التي تريد تسجيلها وتخزينها واستعادتها. نظرًا لأن الخماسي في قضيتنا قابلة للعنونة مباشرة ومترابطة وفهرسة ، فسنخزنها في نوع من قواعد البيانات.
لماذا الخماسي بدلا من البايت؟
لا بت أو الدافع الإلكتروني الذي يوجه المغزل المغناطيسي.لقد اعتدنا على قياس البيانات بالبايت ، سواء كان حجم المستند أو الصورة ، أو حد حركة مرور الإنترنت ، أو المساحة المتوفرة على جهازك المحمول. نقترح إجراء آخر - الخماسي - الذي لا يحتوي على حجم ثابت مثل بايت ، ولكنه يمثل كمية ذرية من البيانات ، والتي لها بعض القيمة للمستخدم.
على سبيل المثال ، يمكنك القول أن قاعدة البيانات الخاصة بك تشغل 119 ميغابايت من مساحة التخزين أو يمكنك أن تقول أن قاعدة البيانات هذه تخزن 1.37 ميغابايت. لا تهتم كثيرًا بماهية البايتة في هذا السياق ، لكنك تدرك أن قاعدة البيانات هذه تحتوي على 1.37 مليون من أوصاف المصطلحات ، والكائنات ، وسماتها ، والروابط ، والأحداث ، والاستعلامات مع تفاصيلها ، إلخ. إن امتلاك 1.37 مليون قطعة من البيانات القيمة يبدو أكثر جاذبية من وجود 119 ميغابايت من الأشياء عليك.
وبالتالي ، هذا لا يحل محل الطريقة التي يتم بها تخزين المعلومات على وسيط البيانات ، ولكن للانتقال إلى مستوى آخر من التجريد.
هيكل خماسي
الفكرة الرئيسية لهذه المقالة هي استبدال أنواع الماكينات بمصطلحات بشرية واستبدال المتغيرات بالكائنات. ليس بهذه الأشياء التي تحتاج إلى مُنشئ ، مدمر ، واجهات ، وجامع قمامة ، ولكن بوحدات معلومات واضحة تمامًا يتعامل معها العميل. أي إذا قال العميل "عميل" ، فإن حفظ جوهر هذا البيان في الوسط لن يتطلب خبرة مبرمج.

من المنطقي تركيز انتباه المستخدم فقط على قيمة الكائن ، بينما يجب أن يكون نوعه وأصله وترتيبه (من بين يساوي في التبعية) والمعرف واضحًا من السياق أو ببساطة مخفيًا. هذا يعني أن المستخدم لا يعرف شيئًا عن الخمور على الإطلاق ، إنه ببساطة يعطي مهمة ، ويتأكد من قبولها بشكل صحيح ، ثم يبدأ تنفيذها.
المفاهيم الأساسية
هناك مجموعة من أنواع البيانات يفهمها الجميع: السلسلة والرقم والملف والنص والتاريخ وما إلى ذلك. مثل هذه المجموعة البسيطة كافية لرسم الحل و "برمجة" مع الشروط اللازمة لتنفيذه. قد تبدو الأنواع الأساسية التي تمثلها الخماسيات كما يلي:

في هذه الحالة ، لا يتم استخدام بعض مكونات الخماسي ، بينما يتم استخدام الخماسي نفسه كنوع أساسي. هذا يجعل نواة النظام أسهل في التنقل عند جمع البيانات الأولية.
الخلفية
بسبب الفجوة التحليلية بين المستخدم والمبرمج ، يحدث تشوه كبير في المفاهيم في مرحلة تحديد المشروع. غالبًا ما تتحول فكرة التقليل من القيمة وعدم الوضوح والمبادرة غير المرغوب فيها إلى فكرة بسيطة ومعقولة عن العميل إلى فوضى مستحيلة منطقياً ، إذا تم تقييمها من وجهة نظر المستخدم.

يجب أن يحدث نقل المعرفة دون فقدان وتشويه. علاوة على ذلك ، عند تنظيم تخزين هذه المعرفة ، يجب عليك التخلص بشكل أفضل من القيود التي يفرضها نظام إدارة البيانات الذي تم اختياره.
كيف نقوم بتخزين البيانات الآن
عادة ، هناك العديد من قواعد البيانات على الخادم. كل واحد منهم يحتوي على وصف لنظام البيانات مع مجموعة محددة من التفاصيل - البيانات المترابطة منطقيا. يتم تخزينها على وسيط البيانات في ترتيب معين ، من الناحية المثالية - الأمثل لتقليل جهود الاسترجاع.
نظام تخزين المعلومات المقترح هو حل وسط بين مختلف الأساليب المعروفة: الموجهة نحو العمود ، العلائقية و NoSQL. وهو مصمم لحل المهام التي يؤديها عادةً أحد هذه الأساليب.
على سبيل المثال ، تبدو نظرية DBMS الموجهة للعمود جميلة: نقرأ فقط العمود المطلوب ، ولكن ليس كل صفوف السجلات ككل. ومع ذلك ، في الممارسة العملية ، من غير المحتمل أن يتم وضع البيانات على الوسائط بحيث تكون ملائمة لاسترداد العشرات من الأبعاد التحليلية المختلفة. تجدر الإشارة إلى أنه يمكن إضافة السمات والمقاييس التحليلية وإزالتها ، وأحيانًا أسرع من إعادة بناء سعة التخزين العمودية الخاصة بنا. ناهيك عن أنه يمكن تعديل البيانات الموجودة في قاعدة البيانات ، مما ينتهك أيضًا جمال مخطط التخزين نظرًا للتجزؤ الذي لا مفر منه.
الفوقية
قدمنا مفهومًا - مصطلحًا - لوصف أي كائنات نعمل بها: كيان ، خاصية ، طلب ، ملف ، إلخ. سنحدد جميع المصطلحات التي نستخدمها في مجال أعمالنا. وبمساعدتهم ، سنصف جميع الكيانات التي لديها تفاصيل ، بما في ذلك شكل العلاقات بين الكيانات. على سبيل المثال ، سمة - رابط لإدخال قاموس الحالة. تتم كتابة المصطلح كخماسي من البيانات.
مجموعة من أوصاف المصطلحات هي بيانات وصفية مثلها مثل بنية الجداول والحقول في قاعدة بيانات منتظمة. على سبيل المثال ، هناك بنية البيانات التالية: طلب خدمة في تاريخ ما يحتوي على المحتوى (وصف الطلب) وحالة ، يضيف إليها المشاركون في عملية الإنتاج تعليقات تشير إلى التاريخ. في مُنشئ قاعدة البيانات التقليدية ، سيبدو كالتالي:

نظرًا لأننا قررنا إخفاء جميع التفاصيل غير الضرورية من المستخدم ، مثل معرفات الربط ، على سبيل المثال ، فسيتم تبسيط المخطط إلى حد ما: تتم إزالة إشارات المعرفات وسيتم دمج أسماء الكيانات وقيمها الأساسية.
يقوم المستخدم "بسحب" المهمة: طلب من تاريخ اليوم له حالة (قيمة مرجعية) ويمكنك إضافة تعليقات تشير إلى التاريخ:

نرى الآن 6 حقول مختلفة للبيانات بدلاً من 9 ، والمخطط بأكمله يتيح لنا قراءة وفهم 7 كلمات بدلاً من 13. على الرغم من أن هذا ليس هو الشيء الرئيسي ، بالطبع.
فيما يلي الخماسيات التي تم إنشاؤها بواسطة نواة معالجة الخماسيات لوصف هذه البنية:

يتم توفير التوضيحات بدلاً من القيم الخماسية المميزة باللون الرمادي للوضوح. لا يتم ملء هذه الحقول ، لأن جميع المعلومات الضرورية يتم تحديدها بشكل لا لبس فيه من خلال المكونات المتبقية.
انظر كيف ترتبط الخماسيات
ما لدينا هنا:
- السمات ذات المعرفات 80 و 81 و 83 لها نفس الأصل - طلب
- الخماسية # 82 هي سمة التعليق ، والتي بدورها سمة من سمات الطلب
- السمة # 74 هي مرجع للنوع الموصوف في الخماسية # 73 ويستخدم كسمة # 81 للطلب
قد يبدو هذا معقدًا قليلاً بالنسبة للبشر ، ولكن الخبر السار هو - لن يرى الإنسان هذا أبدًا. ستمثل النواة البيانات الوصفية كرسومات بيانية مفهومة والبيانات كجداول مسطحة بسيطة.
بيانات المستخدم
اسمحوا لي أن أظهر كيف نقوم بتخزين مجموعة البيانات هذه للمهمة المذكورة أعلاه:

يتم تخزين البيانات نفسها في الخماسيات وفقا لبيانات التعريف. يمكننا تصورهم بنفس الطريقة التي فعلنا بها أعلاه:

نرى بنية هرمية مألوفة مكتوبة باستخدام شيء مثل طريقة قائمة المجاورة.
التخزين الفعلي
تتم كتابة البيانات على الذاكرة كتسلسل لعناصر الخماسي بالبايت من البيانات. للبحث عن طريق الفهرس ، يعامل kernel وحدات بايت البيانات هذه وفقًا لنوع البيانات المحدد لها حسب الأنواع الأساسية.
هذا كل شيء: قائمة ضخمة من خمسة عناصر البيانات.
لا تختلف مبادئ التخزين كثيرًا عن تلك الموجودة في RDBMS ، مما يتيح لنا إنشاء استعلامات SQL للبيانات لجعل استرجاع البيانات ، JOINs ، الوظائف التجميعية وغيرها من الأشياء التي نحبها في قواعد البيانات العلائقية.
لاختبار النموذج الأولي لمنصة تطوير تعتمد على نظام التخزين الخماسي ، نستخدم قاعدة بيانات علائقية.
أداء
المثال أعلاه بسيط للغاية ، ولكن ماذا سيكون عندما يكون الهيكل أكثر تعقيدًا بآلاف المرات وهناك غيغابايت من البيانات؟
ما نحتاجه:
- هيكل هرمي ناقش - 1 جهاز كمبيوتر.
- B- شجرة للبحث عن طريق ID ، الوالد ونوع - 3 أجهزة الكمبيوتر.
وبالتالي ، سيتم فهرسة جميع السجلات في قاعدة البيانات الخاصة بنا ، بما في ذلك البيانات والبيانات الوصفية. هذا الفهرسة ضروري للحصول على فوائد قاعدة بيانات علائقية - الأداة الأكثر بساطة والأكثر شعبية. الفهرس الأصل مركب في الواقع (نوع معرف الهوية الأصل). الفهرس حسب النوع مركب أيضًا (type + value) للبحث السريع عن كائنات من نوع معين.
البيانات الوصفية تسمح لنا بالتخلص من التكرار: على سبيل المثال ، للعثور على جميع تفاصيل كائن ما ، نستخدم الفهرس بمعرف أصل. إذا كنت بحاجة إلى البحث عن كائنات من نوع معين ، فإننا نستخدم الفهرس حسب معرف النوع. النوع عبارة عن تمثيلي لاسم الجدول وحقل في قواعد بيانات علائقية.

على أي حال ، لا نقوم بمسح مجموعة البيانات بالكامل ضوئيًا ، وحتى مع وجود عدد كبير من القيم من أي نوع ، يمكن العثور على القيمة المطلوبة في عدد صغير من الخطوات.
الأساس لمنصة التطوير
في حد ذاتها ، فإن قاعدة البيانات هذه ليست مكتفية ذاتيا في برمجة التطبيقات ، وليست كاملة ، كما يقولون ، وفقًا لتورينج. ومع ذلك ، فإننا نتحدث هنا ليس فقط عن قاعدة البيانات ، ولكننا نحاول تغطية جميع الجوانب: الكائنات هي ، من بين أمور أخرى ، خوارزميات التحكم التعسفي التي يمكن إطلاقها ، وأنها ستعمل.
نتيجةً لذلك ، بدلاً من بنيات قواعد البيانات المعقدة ورمز مصدر خوارزميات التحكم المخزنة بشكل منفصل ، نحصل على حقل معلومات موحد ، مقيد بحجم مساحة التخزين ويحكمه البيانات الأولية. يتم تقديم البيانات نفسها للمستخدم في شكل مفهوم له - هيكل مجال الموضوع والإدخالات المقابلة فيه. يقوم المستخدم بتغيير البنية والبيانات بشكل تعسفي ، بما في ذلك إجراء عمليات مجمعة معهم.
لم نخترع أي شيء جديد: يتم تخزين جميع البيانات بالفعل في نظام الملفات ويتم البحث فيها باستخدام B-tree ، إما في نظام الملفات ، أو في قاعدة البيانات. لقد قمنا بإعادة تنظيم عرض البيانات حتى يكون التعامل معها أسهل وأكثر وضوحًا.
للعمل مع تمثيل البيانات هذا ، ستحتاج إلى برنامج kernel مضغوط جدًا - محرك قاعدة البيانات الخاص بنا بحجم أصغر من BIOS لجهاز الكمبيوتر ، وبالتالي ، يمكن صنعه إن لم يكن في الأجهزة ، ثم بسرعة وعلى الأقل الأخطاء مجانا ممكن. لأسباب أمنية ، يمكن أيضًا أن يكون للقراءة فقط.
إضافة فئة جديدة إلى مجموعة في المفضلة .Net ، يمكننا أن نلاحظ فقدان 200-300 ميغابايت من ذاكرة الوصول العشوائي فقط على تعريف هذه الفئة. لن تنسجم هذه الميجابايت مع ذاكرة التخزين المؤقت للمستوى المناسب ، مما يتسبب في تبديل النظام على القرص بكامله. موقف مماثل مع جافا. سوف يستغرق وصف نفس الفئة مع الخماسيات عشرات أو مئات البايتات ، لأن الفصل يستخدم العمليات البدائية فقط للعمل مع البيانات التي يعرفها النواة بالفعل.
قد تعتقد أن هذا النهج تم تنفيذه بالفعل عدة مرات في تطبيقات مختلفة ، لكن هذا غير صحيح.
لقد أجرينا بحثًا عميقًا في قواعد الإنترنت والملكية الفكرية (براءات الاختراع) ، ولا يدعي أحد أن يقوم بنفس الحل تمامًا لكسر حد أداء المنشئات ، وحلول جدول واحد ، والأنظمة الأخرى المستندة إلى EAV. ومع ذلك ، فقد وضعنا مئات الجيجابايت في تطبيق الخماسي هذا ووجدنا أنه يعمل جيدًا. إذا كنت ترغب في رؤية الأدلة ، وإنشاء واختبار حالتك الخاصة ، فلا تتردد في زيارة حساب جيثب الخاص بنا.
يحتوي النموذج الأولي للنظام الأساسي الذي أنشأناه على أربعة مكونات:
- محرر النوع البصري لتعريف البيانات الأولية
- أداة تنقل البيانات مثل متصفح SQL بسيط
- مصمم تقرير مرئي لإنشاء استعلامات SQL إلى البيانات
- معالج القوالب لدمج القوالب مع البيانات التي يتم استرجاعها بواسطة الاستعلامات

كما كان مقصودًا ، فإن العمل مع النموذج الأولي لا يعتقد أي مستخدم أن هناك خماسيات بالداخل - هذا يبدو تمامًا مثل مُنشئ عادي.
كيفية التعامل مع صيغ مختلفة: قواعد RDBMS ، NoSQL ، الأعمدةيغطي النهج الذي تمت مناقشته مجالين رئيسيين: RDBMS و NoSQL. عند حل المشكلات التي تستفيد من قواعد البيانات العمودية ، نحتاج إلى إخبار النواة بضرورة تخزين بعض الكائنات ، مع الأخذ في الاعتبار الأمثلية لأخذ عينات جماعية من قيم نوع بيانات معين (المصطلح الخاص بنا). لذلك ، سيتمكن kernel من وضع البيانات على القرص بأكثر الطرق ربحية.
وبالتالي ، بالنسبة لقاعدة البيانات العمودي ، يمكننا توفير المساحة التي تشغلها الخماسيات بشكل كبير: استخدم واحدًا أو اثنين فقط من مكوناته لتخزين البيانات المفيدة بدلاً من خمسة ، وكذلك استخدام الفهرس فقط للإشارة إلى بداية سلاسل البيانات. في العديد من الحالات ، سيتم استخدام الفهرس فقط لأخذ العينات من قاعدة تماثلية لدينا ، دون الحاجة إلى الوصول إلى بيانات قائمة الخماسي نفسها.
تجدر الإشارة إلى أن الفكرة لا تهدف إلى جمع كافة التطورات المتقدمة من هذه الأنواع الثلاثة من قواعد البيانات. على العكس من ذلك ، سيتم تقليل محرك النظام الجديد إلى أقصى حد ممكن ، بحيث يتضمن الحد الأدنى الضروري من الوظائف - كل ما يغطي طلبات DDL و DML في المفهوم الموضح هنا.
نموذج البرمجة
لا يقتصر النهج الموصوف على استخدام الخماسيات فقط ، بل يروّج لنموذج مختلف عن النموذج الذي اعتاد المبرمجون عليه. بدلاً من لغة إلزامية أو تعريفية أو موضوعية ، نقترح لغة الاستعلام باعتبارها مألوفة أكثر للإنسان وتسمح لنا بتعيين المهمة مباشرة على الكمبيوتر ، متجاوزين المبرمجين والطبقة التي لا يمكن اختراقها من بيئات التطوير الحالية.
بالطبع ، لا يزال من الضروري وجود مترجم من لغة مستخدم عادي إلى لغة متطلبات واضحة في معظم الحالات.سيتم وصف هذا الموضوع بمزيد من التفصيل في مقالات منفصلة مع أمثلة والتطورات الحالية.
لذلك ، بعد قليل ، يعمل كما يلي:
- وصفنا ذات مرة أنواع البيانات البدائية باستخدام الخماسيات: السلسلة والرقم والملف والنص وغيرها ، وقمنا أيضًا بتدريب النواة على العمل معهم. التدريب يعني العرض الصحيح للبيانات وتنفيذ عمليات بسيطة معهم.
- نصف الآن مصطلحات المستخدم (أنواع البيانات) - في شكل بيانات وصفية. الوصف هو مجرد تحديد نوع البيانات البدائية لكل نوع مستخدم وتحديد العلاقات.
- نقوم بإدخال خماسيات البيانات وفقًا للهيكل المحدد بواسطة البيانات الوصفية. تحتوي كل خماسية من البيانات على رابط لنوعها وأصلها ، مما يتيح لك العثور عليها بسرعة في تخزين البيانات.
- تنطلق مهام kernel لجلب البيانات وإجراء عمليات بسيطة معها لتنفيذ خوارزميات معقدة تعسفية يحددها المستخدم.
- يدير المستخدم البيانات والخوارزميات باستخدام واجهة مرئية تقدم كل منهما.
يتم ضمان اكتمال تورينج للنظام بأكمله من خلال تجسيد للمتطلبات الأساسية: يمكن للنواة القيام بعمليات متسلسلة وفرع مشروط ومعالجة البيانات وإيقاف العمل عند تحقيق نتيجة معينة.
بالنسبة للشخص ، تكون الفائدة هي بساطة الإدراك ، على سبيل المثال ، بدلاً من إعلان دورة تتضمن متغيرات
for (i = 0; i <length (A); i ++) if A [i] meets a condition do something with A [i]
يستخدم شكل أكثر قابلية للفهم ، مثل
with every A, that match a condition, do something
نحلم بالاستخلاص من التفاصيل الدقيقة ذات المستوى المنخفض لأنظمة المعلومات: الحلقات ، المنشئات ، الوظائف ، البيانات ، المكتبات - كل هذه الأمور تشغل حيزًا كبيرًا في عقل مبرمج ، مما يترك مساحة صغيرة للعمل الإبداعي والتطوير.
التدرجية
غالبًا ما يكون التطبيق عديم الفائدة دون أي وسائل للتحجيم: يلزم توفر قدرة غير محدودة على زيادة سعة التحميل لنظام المعلومات. في النهج الموصوف ، مع الأخذ في الاعتبار البساطة الشديدة لتنظيم البيانات ، اتضح أن التوسع في التنظيم ليس أكثر تعقيدًا مما هو عليه الحال في البنى الحالية.
في المثال أعلاه مع طلبات الخدمة ، يمكنك فصلها ، على سبيل المثال ، بواسطة معرّفها ، مما يؤدي إلى إنشاء معرّف باستخدام بايت عالي ثابت لخوادم مختلفة. أي عند استخدام 32 بت لتخزين المعرف ، ستشير البتات اليسرى من ثلاثة إلى أربعة أو أكثر ، حسب الحاجة ، إلى الخادم الذي يتم تخزين هذه التطبيقات عليه. وبالتالي ، سيكون لكل خادم مجموعة خاصة به من المعرفات.
يمكن أن تعمل نواة خادم واحد بشكل مستقل عن الخوادم الأخرى ، دون معرفة أي شيء عنها. عند إنشاء كائن ، سيتم إعطاء أولوية عالية للخادم مع الحد الأدنى لعدد المعرفات المستخدمة ، لضمان توزيع الأحمال.
نظرًا لوجود مجموعة محدودة من الأشكال المختلفة للطلبات والاستجابات في تنظيم البيانات هذا ، ستحتاج إلى مرسل مدمج إلى حد ما يقوم بتوزيع الطلبات عبر الخوادم وتجميع نتائجها.