الحياة بدون روابط... فهم وممارسات مشتركة

Question

تستخدم الكثير من مواقع "BAW" (مواقع الويب الكبيرة) تقنيات تخزين البيانات واسترجاعها التي تعتمد على جداول ضخمة تحتوي على فهارس، وتستخدم استعلامات لا تستخدم/لا يمكنها استخدام JOINs في استعلاماتها (BigTable، HQL، إلخ) للتعامل مع قابلية التوسع وتقسيم قواعد البيانات.كيف يعمل ذلك عندما يكون لديك الكثير والكثير من البيانات جداً متعلق ب؟

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

وبالنسبة لـ ORMs المتوفرة بشكل شائع، كيف تميل إلى التعامل مع عدم القدرة على استخدام الصلات؟هل هناك دعم لهذا في ORMs المستخدمة بكثافة اليوم؟أم أن معظم المشاريع التي يتعين عليها الوصول إلى هذا المستوى من البيانات تميل إلى تنفيذ مشاريعها الخاصة على أي حال؟

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

كما قال أحد الأشخاص أدناه، فإن ORMs "لا تعمل" بدون الصلات.هل هناك طبقات أخرى للوصول إلى البيانات متاحة بالفعل للمطورين الذين يعملون مع البيانات على هذا المستوى؟

يحرر:للحصول على بعض التوضيح، فينكو فرسالوفيتش قال:

"أعتقد أن Snicker يريد التحدث عن No-SQL ، حيث يتم تغيير بيانات المعاملات واستخدامها في مخططات Hadoop أو Bigtable أو Cassandra."

وهذا بالفعل ما أتحدث عنه.

نقاط إضافية لأولئك الذين يحصلون على مرجع xkcd.

Answer 1

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

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

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

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

للإجابة على سؤالك حول كيفية تعامل ORMs شائعة الاستخدام مع عدم القدرة على استخدام JOINs، فإن الإجابة المختصرة هي لم يفعلوا ذلك.يرمز ORM إلى رسم الخرائط العلائقية للكائنات، ومعظم وظائف ORM هي مجرد ترجمة النموذج العلائقي القوي لهياكل البيانات المنطقية البسيطة الموجهة للكائنات.معظم قيمة ما يقدمونه لك لن تكون ممكنة ببساطة من متجر ذي قيمة أساسية.من الناحية العملية، ربما تحتاج إلى إنشاء وصيانة طبقة الوصول إلى البيانات الخاصة بك التي تناسب احتياجاتك الخاصة، لأن ملفات تعريف البيانات على هذه المقاييس ستختلف بشكل كبير وأعتقد أن هناك الكثير من المفاضلات لظهور أداة للأغراض العامة وتصبح مهيمنة بالطريقة التي تمتلكها أنظمة RDBMS.باختصار، سيتعين عليك دائمًا القيام بالمزيد من العمل على هذا النطاق.

ومع ذلك، سيكون من المثير للاهتمام بالتأكيد معرفة نوع الوظائف الارتباطية أو التجميعية الأخرى التي يمكن بناؤها فوق أساسيات متجر القيمة الرئيسية.ليس لدي حقًا ما يكفي من الخبرة هنا للتعليق على وجه التحديد، ولكن هناك الكثير من المعرفة في حوسبة المؤسسات حول هذا الأمر الذي يعود إلى سنوات عديدة (على سبيل المثال.Oracle)، والكثير من المعرفة النظرية غير المستغلة في الأوساط الأكاديمية، والكثير من المعرفة العملية في Google وAmazon وFacebook وآخرين، لكن المعرفة التي تسربت إلى مجتمع التطوير الأوسع لا تزال محدودة إلى حد ما.

ولكن الآن بعد أن انتقلت الكثير من التطبيقات إلى الويب، وأصبح المزيد والمزيد من سكان العالم متصلين بالإنترنت، سيتعين حتماً توسيع نطاق المزيد والمزيد من التطبيقات، وستبدأ أفضل الممارسات في التبلور.سيتم تقليص الفجوة المعرفية من كلا الجانبين من خلال الخدمات السحابية مثل AppEngine وEC2، بالإضافة إلى قواعد البيانات مفتوحة المصدر مثل Cassandra.وإلى حد ما، يسير هذا جنبًا إلى جنب مع الحساب المتوازي وغير المتزامن الذي لا يزال في بداياته أيضًا.بالتأكيد وقت رائع لتكون مبرمجًا.

Answer 2

أنت تبدأ من افتراض خاطئ.

لا يؤدي تخزين البيانات إلى تسوية البيانات بنفس الطريقة التي يقوم بها تطبيق المعاملة.لا يوجد "الكثير" من الصلات.هناك عدد قليل نسبيا.

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

نظرًا لأنه لا داعي للقلق بشأن التحديثات، فلا تحلل الأمور إلى مستوى 2NF حيث لا يمكن أن يؤدي التحديث إلى علاقات شاذة.عدم وجود تحديثات يعني عدم وجود حالات شاذة؛ولا تحلل ولا ينضم.يمكنك الانضمام مسبقا إلى كل شيء.

بشكل عام، يتم تحليل بيانات DW وفقًا لمخطط النجوم.يرشدك هذا إلى تحليل البيانات إلى جداول "الحقائق" الرقمية التي تحتوي على المقاييس - الأرقام ذات الوحدات - ومراجع المفاتيح الخارجية للبعد.

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

---

للإجابة على بعض أسئلتك.

"يجب أن يتم هذا الانضمام على الجانب التطبيقي للأشياء".نوع من.يتم "ضم البيانات مسبقًا" قبل تحميلها.غالبًا ما تكون بيانات البعد عبارة عن ضم لبيانات المصدر ذات الصلة بهذا البعد.لقد تم ضمها وتحميلها كبنية مسطحة نسبيًا.

لم يتم تحديثه.بدلاً من التحديثات، يتم إدراج سجلات تاريخية إضافية.

"ولكن ألا يبدأ هذا في أن يصبح باهظ الثمن؟".نوع من.يستغرق الأمر بعض العناية لتحميل البيانات.ومع ذلك، لا يوجد الكثير من عمليات انضمام التقارير/التحليلات.تم ضم البيانات مسبقًا.

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

Answer 3

أ JOIN هو مصطلح علائقي خالص وليست كل قواعد البيانات علائقية.

نماذج قواعد البيانات الأخرى لديها طرق أخرى لبناء العلاقات.

تستخدم قواعد بيانات الشبكة سلاسل لا نهاية لها من find a key - fetch the reference - find a key والتي ينبغي برمجتها باستخدام لغة برمجة مشتركة.

يمكن تشغيل التعليمات البرمجية على جانب التطبيق أو على جانب الخادم، ولكنها ليست كذلك SQL ولا حتى على أساس مجموعة.

إذا تم تصميم قاعدة بيانات الشبكة بشكل صحيح، فيمكن أن تكون أسرع بكثير من قاعدة بيانات علائقية.

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

وهذا يجعل اجتياز الشبكات أكثر سرعة، إذا كتبت رمزًا فعالاً للقيام بذلك.

يمكن لقاعدة البيانات العلائقية فقط تخزين المراجع كأزواج من القيم الأساسية مثل الأعداد الصحيحة (أو الثلاثيات أو المجموعات ذات الترتيب الأعلى).

للعثور على هذه القيم في قاعدة البيانات العلائقية، يجب على المحرك القيام بالأمور التالية:

• اكتشف مكان وجود المجموعة التي تحتوي على القيمة الأولى
• أوجد القيمة الثانية
• ابحث عن عنوان الجذر في a B-Tree الاحتفاظ بالبيانات التي يشير إليها الرقم الثاني
• اجتياز هذه الشجرة
• ابحث عن المؤشر إلى الجدول الفعلي (والذي يمكن تخزينه كملف B-Tree نفسه، وفي هذه الحالة يكون المؤشر هو قيمة PRIMARY KEY من الصف الذي نتبعه)
• ابحث عن صف الجدول بواسطة المؤشر أو قم باجتياز الجدول
• وأخيرا الحصول على النتيجة.

ولا يمكنك التحكم في هذا إلا إلى حد معين.بعد ذلك، يمكنك فقط إصدار SQL الاستعلام والانتظار.

نموذج علائقي تم تصميمه لتبسيط حياة المطور، وليس لتحقيق السرعة الفائقة دائمًا ومهما كان الأمر.

هذا هو نفس التجميع مقابل التجميع.اللغات ذات المستوى الأعلى، والنموذج العلائقي هو لغة ذات مستوى أعلى.

قد ترغب في قراءة المقال في مدونتي

• ما هي قاعدة البيانات العلائقية؟

, ، حيث أحاول شرح الاختلافات بين العديد من نماذج قواعد البيانات شائعة الاستخدام.

Answer 4

عندما تقوم بإلغاء تسوية بياناتك بهذه الطريقة، فإنك تفعل ذلك لتجنب تكلفة ضم العناصر المتباينة؛أنت تقبل أن بعض البيانات قد تكون مكررة وأن بعض الطرق لدمجها قد تكون صعبة، وذلك لتحقيق فائدة الأداء من خلال استخدام الاستعلامات البسيطة.

إذا كان عليك القيام بأي قدر كبير من الانضمام على مستوى التطبيق، فهذا يعني أنك لم تقم بإلغاء تطبيعه بما فيه الكفاية.

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

هذا النوع من الأشياء مطلوب حقًا فقط لمجموعات البيانات الضخمة حقًا، وهناك جميع أنواع المقايضات المعنية.لإعطاء مثال واحد فقط:لا يمكن لـ BigTable إجراء استعلامات مجمعة، مثل إعطائك عددًا.يمكن استخدامه لإعطائك رقمًا دقيقًا تقريبًا - بمعنى أنه إذا كان لديك، على سبيل المثال، 12,149,173 سجلًا تمت إضافة 23,721 منها في الساعة الأخيرة، فلا يهم حقًا إذا كان أفضل ما يمكنك اكتشافه هو ذلك لديك "حوالي 12,100,000 سجل".إذا كان تطبيقك يعتمد على معرفة الرقم الدقيق في أي لحظة معينة، فلا ينبغي عليك استخدام BigTable لذلك، هذا هو الموقف العام.

Answer 5

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

يتيح هذا السماح للبيانات بعدم تطبيعها دون ضرب المشكلات الشائعة مع التحديثات.

يمكن لتطبيقات مثل Amazon تحميل جميع البيانات الخاصة بمستخدم واحد في ذاكرة الوصول العشوائي (ما هو حجم عربة التسوق في نهاية المطاف؟)، ثم تحديث البيانات في ذاكرة الوصول العشوائي وكتابتها كعنصر بيانات واحد.

مرة أخرى إزالة الحاجة إلى تطبيع معظم البيانات.

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

Answer 6

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

Answer 7

بشكل عام، يتم إنشاء تخزين البيانات حول استخدام الصلات وتقسيم البيانات إلى أبعاد وجداول حقائق (مع ما يسمى "المخططات النجمية" وما إلى ذلك)

غالبًا ما يتم حساب عمليات الانضمام مسبقًا وتخزينها كجداول غير طبيعية.

لست على علم بأي أدوات ORM تعمل مع أنظمة قواعد البيانات التي لا تسمح بالانضمام، حيث لا يُنظر إليها عمومًا على أنها قواعد بيانات علائقية تقليدية.