- ما الذي سنتحدث عنه بالضبط؟ لا يتعلق بالاختيارات والانضمام البدائي - أعتقد أن معظمكم يعرف بالفعل عنها.
سنتحدث عن الاستخدام الحقيقي لقواعد البيانات ، والصعوبات التي يمكن أن تواجهها وما تحتاج إلى معرفته كمطور للواجهة الخلفية. سيكون هناك الكثير من المعلومات ، ها هو المحتوى. لا تحتاج إلى معرفة تفاصيل كل نقطة من هذه النقاط بدقة ، ولكن عليك أن تعرف أن هذه النقطة موجودة.
وتحتاج إلى معرفة كيفية حل المشكلات بحيث عندما يكون لديك مهمة لبناء هيكل وحفظ البيانات ، فأنت تعرف نموذج البيانات الذي تختاره وكيفية حفظه. أو لنفترض أن لديك مشكلة ، ترى أن قاعدة البيانات معطلة ، أو بطيئة ، أو أن هناك مشاكل في البيانات ، أو عدم تناسق. ثم يجب أن تفهم أين تحفر. أي أنك بحاجة إلى معرفة المفاهيم الموجودة ومن أي جانب للتعامل مع المشكلات.
أولاً ، سنتحدث عن البيانات. ما هذا على أي حال؟ هناك العديد من الحقائق حولنا ، والكثير من المعلومات ، ولكن حتى يتم جمعها بأي شكل من الأشكال ، فإنها تكون عديمة الفائدة بالنسبة لنا. نقوم بجمعها وهيكلها وتخزينها. وهذه الهيكلة المخزنة تسمى البيانات ، وما يخزنها يسمى قاعدة البيانات. ولكن بينما يتم جمع هذه البيانات في مكان ما ، إلا أنها أيضًا عديمة الفائدة بالنسبة لنا. لذلك ، هناك طبقة فوق قواعد البيانات - DBMS. هذا ما يسمح لنا باسترجاع البيانات وتخزينها وتحليلها. وبالتالي ، نقوم بتحويل البيانات التي نتلقاها إلى معلومات يمكننا عرضها بالفعل للمستخدم. يتلقى المستخدم المعرفة ويطبقها.
سنناقش كيفية هيكلة المعلومات والحقائق ، وتخزينها ، في أي شكل من أشكال البيانات ، وفي أي نموذج. وكيفية الحصول عليها حتى يتمكن العديد من المستخدمين من الوصول إلى البيانات في وقت واحد والحصول على النتيجة الصحيحة ، بحيث تكون معرفتنا النهائية التي سنطبقها صحيحة وصحيحة.
أولاً ، سنتحدث عن قواعد البيانات العلائقية. أعتقد أن النموذج العلائقي مألوف لكثير منكم. إنه نموذج لنوع الجداول والعلاقات بين الجداول. تخيل أن لدينا رسول نكتب فيه البيانات والرسائل بين المستخدمين. يمكننا كتابتها جميعًا في جدول واحد ضخم ، واسع ، حيث سيكون لدينا الكثير من البيانات المتكررة - من ، من ، إلى من ، وفي أي دردشة. ويمكننا كتابة كل هذا في جداول مختلفة ، أي تسوية بياناتنا وإعادتها إلى الصيغة العادية الثالثة.
هناك ملاحظات ومراجع على الشرائح. لن نتعمق في كل مفهوم الآن. سأحاول ألا أتحدث عن المفاهيم التقنية التي قد تكون غير مألوفة لك. لكن كل ما أقوله ستجده في ملاحظات الشرائح. بما في ذلك التطبيع ، سيكون هناك أيضًا مرجع ، يمكنك قراءته إذا لم تكن معتادًا على هذا المفهوم.
بشكل عام ، التسوية هي تقسيم البيانات إلى جداول بهدف جعل البيانات أكثر تنظيمًا. على سبيل المثال ، يوجد الآن جدول مستخدم ودردشة رسائل ورسائل. يضمن هذا الهيكل تسجيل الرسائل الواردة من المستخدمين الذين نعرفهم بالضبط ومن الدردشات التي نعرفها هنا. أي أننا نضمن سلامة البيانات. نحن نضمن حقيقة أنه يمكننا دائمًا جمع الصورة كاملة. ولكن في الوقت نفسه ، نقوم بتخزين المعرفات فقط في جدول الرسائل ، على سبيل المثال. وبالتالي ، نقوم بتقليل الحجم الكلي لقاعدة البيانات ، مما يجعلها أصغر. وفقًا لذلك ، نجعل من السهل الكتابة إلى قاعدة البيانات هذه. لا نحتاج إلى الكتابة باستمرار إلى العديد من الجداول. نكتب فقط إلى نفس الجدول مع أخصائي الهوية.
إذا تحدثنا عن التطبيع ، فإنه بشكل عام يبسط رؤية النظام إلى حد كبير ، لأنه رسوم بيانية للغاية ، ويصبح من الواضح لنا على الفور العلاقات بين أي جداول.
نقوم بتقليل عدد الأخطاء عند كتابة البيانات ، لأننا إذا كتبنا رسالة في برنامج messenger ولم يكن لدينا مثل هذا المستخدم بعد ، فسيتعين علينا إنشاء واحد. لكن الصورة النهائية ، البيانات العامة ، ستبقى كاملة.
لقد قلت بالفعل عن تقليل حجم قاعدة البيانات. لا يتعين علينا كتابة جميع البيانات الخاصة بالمستخدم في جدول الرسائل في كل مرة. لعرض ملف التعريف ، يمكننا ببساطة الانتقال إلى جدول المستخدم.
لقد حذرت أيضًا من التبعية غير المتسقة. هذه مجرد روابط لمعرفات الجداول الأخرى ، والمعرفات هي قيم فريدة في جدول واحد. بطريقة أخرى ، تسمى المفاتيح الأساسية ، وعندما يكون لدينا رابط لهذه المفاتيح الأساسية ، فإن الرابط نفسه في جدول آخر يسمى مفتاح خارجي.
تحمي هذه البنية أيضًا بياناتنا من الحذف العرضي. لا يمكننا حذف مستخدم ، لأنه ، على سبيل المثال ، لديه رسالة. هذه شبكة أمان صغيرة ولكنها آمنة.
يبدو أننا صنعنا هيكلًا ممتازًا ، كل شيء واضح ، كل شيء يعتمد ، كل شيء متكامل. ماذا تحتاج للعمل مع؟
دعونا نتخيل أننا قمنا بتشغيله بالفعل ، لدينا الكثير من المستخدمين ، وبالتالي ، لدينا الكثير من الرسائل. يتواصلون باستمرار مع بعضهم البعض. ماذا يحدث في جدول الرسائل لدينا؟ إنه ينمو باستمرار. ومن أجل البحث في غير البيانات ، نحتاج إلى استعراض جميع الرسائل باستمرار ، والتحقق مما إذا كانت من هذا المستخدم أم لا ، في هذه الدردشة أم لا ، وبعد ذلك فقط نعرضها.
وبطبيعة الحال ، كلما زاد عدد المستخدمين ، زاد عدد الرسائل ، كلما استغرقت طلبات البحث وقتًا أطول. نحتاج إلى حل يسمح لنا بالبحث بسرعة عن الرسائل في الجدول.
في مثل هذه الحالة ، يتم استخدام الفهارس لتسريع البحث. أبسط ارتباط بالفهارس هو المحتوى الموجود في الكتاب. إذا كنت بحاجة إلى العثور على معلومات في كتاب ، فيمكنك فقط التنقل خلال الكتاب ، أو يمكنك الانتقال إلى جدول المحتويات. الفهارس هي نوع من جدول المحتويات.
هناك أيضًا مثال جيد مع دليل الهاتف. يمكنك النقر فوق حرف على هاتفك ، وسيتم إلقاءك على الفور بالرجوع إلى الألقاب التي تبدأ بهذا الحرف. تعمل فهارس قواعد البيانات بطريقة مشابهة جدًا. دعونا نرى جدولنا مع الرسائل وكيف سنحصل على هذه البيانات.
يرجى الانتباه إلى كيفية تعاملنا مع البيانات. ليس مع الصفوف الموجودة في الجدول ، ولكن بشكل عام. يتم إنشاء الفهارس على أساس الاستعلامات التي تجريها.
دعنا نتخيل أننا نقدم طلبات بشكل أساسي من خلال الدردشة ، أي أننا نكتشف الرسائل الموجودة في هذه الدردشة. لنقم ببناء الفهرس بالضبط في عمود الدردشة. فهارس قاعدة البيانات هي بنية منفصلة. الجدول مستقل عنه. أي يمكنك حذف الفهرس وإعادة بنائه في أي وقت ، ولن يعاني الجدول من ذلك.
هنا يمكنك رؤية ما اخترناه ، ووضع الفهرس في العمود ، ولدينا هيكل منفصل قلل بالفعل عدد الإدخالات بشكل طفيف ، لأن الدردشة 11 بها بالفعل عدة رسائل. يوفر DBMS بحثًا سريعًا على جدول الدردشة الصغير هذا. كيف يتم ذلك؟ بطبيعة الحال ، فإن البحث ليس عملية بحث بسيطة. هناك العديد من خوارزميات البحث السريع ، وسوف نلقي نظرة على واحدة من أكثر الخوارزميات شيوعًا والتي يتم استخدامها افتراضيًا في معظم قواعد البيانات. إنها شجرة متوازنة.
كيف يعمل؟ لدينا رقم دردشة ، هذه قيمة صحيحة ، والشجرة مبنية وفقًا للمبدأ التالي: ما هو أقل على يسار العقدة ، المزيد من القيم على يمين العقدة. ماذا يعطينا هذا الهيكل؟ إذا نظرت إلى أوراق ملخص هذه الشجرة ، فسيتم ترتيب جميع القيم الموجودة في الأسفل. هذه إضافة ضخمة في مكاسب الإنتاجية. الآن سأريك لماذا.
على سبيل المثال ، نحن نبحث عن قيمة. من السهل جدًا البحث عن معنى واحد. نذهب إلى أسفل الشجرة أو إلى اليسار ، إلى اليمين - اعتمادًا على ما إذا كانت هذه القيمة أكبر أو أقل.
وإذا أردنا العثور على نطاق ، على سبيل المثال ، فابحث عن مدى بساطة وسرعة ذلك. نصل إلى القيمة ثم نتبع الروابط الموجودة في الأوراق ، بالفعل على طول القيم المرتبة ، فقط انتقل إلى النهاية.
إذا احتجنا إلى نطاق محدد من وإلى ، فإننا نفعل الشيء نفسه تمامًا. ابحث عن القيمة الأولية واتبع الروابط الطرفية للوصول إلى القيمة القصوى. مشينا على الشجرة مرة واحدة فقط. انها مريحة جدا وسريعة جدا.
بنفس الطريقة ، سنبحث عن القيم القصوى والدنيا. المشي إلى اليسار تمامًا ، تمامًا إلى اليمين. سوف نتلقى أيضًا قائمة مرتبة. بمعنى ، إذا احتجنا فقط إلى الحصول على جميع الدردشات بطريقة منظمة ، فإننا نصل إلى الأولى وننتقل عبر الأوراق إلى القيمة القصوى ، نحصل على قائمة مرتبة. وفقًا لهذا المبدأ ، تبحث قاعدة البيانات بسرعة كبيرة في جدول الفهرس عن تلك الصفوف التي نحتاج إلى تحديدها ، وإرجاعها.
ما المهم أن تعرفه هنا؟ قد يبدو هيكلًا رائعًا - الآن سنبني لكل عمود وفقًا لمثل هذه الشجرة وسنبحث. لماذا تعتقد أنها لن تعمل؟ لماذا لا يتم زيادة السرعة إذا قمنا ببناء شجرة لكل عمود؟ (...)
اختياراتنا ستسرع حقًا. في كل مرة نحتاج فيها إلى تجاوز بعض القيم ، نذهب إلى الفهرس ، ونجد ارتباطًا للقيم نفسها. تحتوي الفهارس عادةً على مراجع الأسطر بالضبط ، وليس الأسطر نفسها. ولتحديده يعمل بشكل مثالي. ولكن بمجرد أن نرغب في تعيين بيانات الجدول أو تحديث البيانات أو حذفها ، فسيتعين إعادة بناء كل هذه الأشجار.
في الواقع ، لن يؤدي الحذف إلى إعادة البناء ، بل سيؤدي ببساطة إلى تجزئة هذه الشجرة ، وسوف ينتهي بنا الأمر بالعديد من القيم الفارغة. ستكون هناك شجرة ضخمة بقيم فارغة. ولكن مع التحديث والخلق ، سيتم إعادة بناء هذه الأشجار في كل مرة. نتيجة لذلك ، سوف نحصل على نفقات ضخمة فوق كل هذا الهيكل. وبدلاً من جلب البيانات بسرعة وتسريع قاعدة البيانات ، سنعمل على إبطاء استفساراتنا.
ما هو المهم أيضا أن تعرف؟ عندما تعمل مع قاعدة بيانات ، انظر ، اقرأ ، ما هي الفهارس الموجودة فيها ، لأن كل قاعدة بيانات لها تطبيقاتها الخاصة ، وفهارسها المختلفة. هناك فهارس للإسراع ، وهناك فهارس لضمان التكامل. أحد أبسطها هو المفتاح الأساسي فقط. هذا أيضًا فهرس فريد. وفيما يتعلق بقاعدة البيانات الخاصة بك ، انظر كيف تعمل ، وكيف تعمل معها ، لأن هذا هو نوع المعرفة التي ستساعدك على كتابة الاستعلامات المثلى.
ناقشنا ما يجب أخذه في الاعتبار النفقات العامة للحفاظ على الفهارس عند إدراج البيانات. لقد نسيت أن أقول أنه عند إنشاء فهرس ، يجب أن يكون انتقائيًا للغاية. ماذا يعني؟
دعونا ننظر إلى هذه الشجرة. نحن نتفهم أنه إذا تم ضبط الفهرس على true false ، فسنحصل على قطعتين كبيرتين من الخشب على اليسار واليمين. ونستعرض 50٪ من الجدول في أحسن الأحوال ، وهي في الواقع ليست فعالة للغاية. من الأفضل فهرسة تلك الأعمدة التي تحتوي على قيم مختلفة تمامًا. هذا سوف يسرع اختياراتنا.
قلت عن التجزئة ؛ عند حذف البيانات ، عليك أن تضعها في الاعتبار. إذا كان لدينا غالبًا عمليات حذف على البيانات الموجودة في الفهرس ، فقد نحتاج إلى إلغاء تجزئتها ، وهذا يحتاج أيضًا إلى المراقبة. من المهم أيضًا أن تفهم أنك تبني فهرسًا لا يعتمد على الأعمدة التي لديك ، ولكن على كيفية استخدامك لتلك البيانات. ويجب كتابة الاستعلامات التي تتضمن فهارس بعناية شديدة. ماذا يعني أنيق؟ عند كتابة استعلام وإرساله إلى قاعدة البيانات ، لا يتم إرساله مباشرة إلى قاعدة البيانات ، ولكن إلى طبقة برامج معينة تسمى جدولة الاستعلام.
يحتوي المجدول على جدول مراسلات معين لمقدار تكاليف العملية ومدى تكلفتها. في مثال PostgreSQL ، توجد جداول فنية خاصة تجمع معلومات حول بياناتك وجداولك. يبحث المخطط في نوع الاستعلام الذي لديك والبيانات المخزنة في جدول pg_stat. هذا هو بالضبط الجدول الذي يخزن المعلومات العامة حول مقدار البيانات لديك والأعمدة الموجودة في الجدول ، والفهارس الموجودة فيه. بناءً على ذلك ، ينظر في خطط تنفيذ استعلامك ، ويحسب المدة التي ستستغرقها أي خطة لإكمال الاستعلام ، ويختار أفضل خطة.
إذا كنت تريد أن ترى وقت التنفيذ المتوقع لاستعلامك ، يمكنك استخدام عملية Explain. إذا كنت تريد التنفيذ الفعلي ، يمكنك استخدام شرح التحليل. ماهو الفرق؟ كما قلت ، يحسب المجدول في البداية وقت التنفيذ بناءً على الوقت المقدر لكل عملية. لذلك ، قد يختلف الوقت الفعلي حسب الجهاز وطبيعة بياناتك. لذلك إذا كنت تريد التنفيذ الفعلي ، فمن الأفضل بالطبع استخدام تحليل التفسير.
يمكنك رؤية مثال على هذه الشريحة. يُظهر أنه في بعض الأحيان قد لا تستخدم الاستعلامات المستندة إلى العمود الذي يحتوي على فهارس فهرس الفحص ، ولكن فقط الفحص الكامل عبر الجدول بأكمله. يحدث هذا إذا كان لدينا انتقائية منخفضة للمؤشر وإذا كان المخطط يعتقد أن استعلام فحص كامل على الجدول سيكون أكثر ربحية.
دعنا نتخيل أن لدينا رسولنا ونريد في قائمة الدردشة ، على سبيل المثال ، إظهار اسم الدردشة أو عدد الرسائل غير المقروءة. إذا قمنا في كل مرة بفتح محادثة ، بإعادة حساب جميع البيانات لجميع الدردشات ، فسيكون ذلك غير مربح للغاية.
هناك شيء من هذا القبيل - عدم التطابق. هذه نسخة من أحدث البيانات المستخدمة أو حساب مسبق للبيانات المطلوبة وحفظها في جدول.
هكذا قد تبدو العلاقة بين المستخدم والمحادثة. أي ، بالإضافة إلى معرف المستخدم ومعرف الدردشة ، سنحفظ لفترة وجيزة اسم الدردشة وسجل الدردشة وعدد الرسائل غير المقروءة هناك. وبالتالي ، في كل مرة لن نحتاج إلى تحميل جميع جداولنا وإجراء التحديدات وإعادة حساب كل هذا.
ما هي ميزة إلغاء التطبيع؟ نقوم بتسريع عملية أخذ عينات البيانات. أي أن اختياراتنا تمر بأسرع وقت ممكن ، ونمنح المستخدمين إجابة في أسرع وقت ممكن.
تكمن الصعوبة في أنه في كل مرة نضيف فيها بيانات جديدة ، نحتاج إلى إعادة حساب كل هذه الأعمدة ويكون احتمال الخطأ مرتفعًا جدًا. أي ، إذا أصبحت اختياراتنا أبسط بكثير ولا نحتاج إلى الانضمام طوال الوقت ، فسيصبح التحديث والإنشاء مرهقين للغاية ، لأننا نحتاج إلى تعليق المشغلات هناك وإعادة الحساب وعدم نسيان أي شيء.
لذلك ، يجب ألا تستخدم إلغاء التطابق إلا عندما تكون في حاجة إليه حقًا. وبما أننا اتبعنا الآن هذا المنطق بأكمله ، فأنت بحاجة أولاً إلى تسوية البيانات ، ومعرفة كيفية استخدامها ، وضبط الفهارس. إذا كانت لديك استفسارات تعتقد أنها لا تعمل بشكل جيد ، فقم بإلقاء نظرة على "شرح" قبل إلغاء التطبيع. اكتشف كيف يتم أداؤها بالفعل ، وكيف يقوم المجدول بتنفيذها. وعندها فقط ، عندما تكون قد توصلت بالفعل إلى استنتاج مفاده أن إلغاء التطبيع لا يزال مطلوبًا ، عندئذٍ يمكنك القيام بذلك. ولكن هناك مثل هذه الممارسة ، وفي المشاريع الحقيقية ، غالبًا ما يتم استخدام إلغاء تسوية البيانات.
لنذهب أبعد من ذلك. حتى إذا قمت بتنظيم البيانات جيدًا ، واخترت نموذجًا للبيانات ، وقمت بجمعها ، وقمت بإلغاء تنسيق كل شيء ، وابتكرت الفهارس ، فلا يزال هناك الكثير من الأخطاء في عالم تكنولوجيا المعلومات.
قد يفشل البرنامج أو قد تنقطع الطاقة أو قد تفشل الأجهزة أو الشبكة. هناك فئة ثانية من المشاكل: قواعد البيانات الخاصة بنا يستخدمها الكثير من المستخدمين في وقت واحد. يمكنهم تحديث نفس البيانات في نفس الوقت. يجب أن نكون قادرين على حل كل هذه المشاكل.
دعنا نلقي نظرة على أمثلة محددة لما يدور حوله هذا.
دعنا نتخيل أن هناك مستخدمين يريدان حجز غرفة اجتماعات. يرى المستخدم 1 أن غرفة الاجتماعات مجانية في هذا الوقت ويبدأ في حجزها. تفتح نافذته ، ويفكر في أي من زملائي سأتصل به. أثناء تفكيره ، يرى المستخدم 2 أيضًا أن غرفة الاجتماعات مجانية ويفتح نافذة تحرير لنفسه.
نتيجة لذلك ، عندما قام المستخدم 1 بحفظ هذه البيانات ، غادر ويعتقد أن كل شيء على ما يرام ، تم حجز غرفة الاجتماعات. ولكن في هذا الوقت ، يقوم المستخدم 2 بالكتابة فوق بياناته ، ويتضح أن غرفة المحادثة مخصصة للمستخدم 2. وهذا ما يسمى تعارض البيانات. ويجب أن نكون قادرين على إظهار هذه النزاعات للناس وحلها بطريقة ما. في هذا المكان سيكون لدينا إعادة تسجيل.
كيف افعلها؟ يمكننا ببساطة حظر غرفة الاجتماعات لفترة بينما يفكر المستخدم 1. إذا حفظ البيانات ، فلن نسمح للمستخدم 2 بالقيام بذلك. إذا أصدر البيانات ولم يحفظها ، فسيتمكن المستخدم 2 من حجز غرفة اجتماعات. يمكنك رؤية صورة مماثلة عند شراء تذاكر السينما. يتم منحك 15 دقيقة لدفع ثمن التذاكر ، وإلا يتم توفيرها مرة أخرى لأشخاص آخرين يمكنهم أيضًا أخذها ودفع ثمنها.
إليك مثال آخر يوضح لنا مدى أهمية ضمان تنفيذ عملياتنا بالكامل. لنفترض أنني أريد تحويل الأموال من الحساب المصرفي 1 إلى الحساب 2. في هذه اللحظة لدي ثلاث عمليات. أتحقق من أن لدي أموالاً كافية ، وقم بخصم الأموال من حسابي الأول وإيداعها في الحساب الثاني. من الواضح أنه إذا فشلت في أي من هذه اللحظات ، فسيحدث خطأ ما.
على سبيل المثال ، إذا حدثت معاملة أخرى في هذه المرحلة تقرأ البيانات ، فلن تكون الأموال في حسابي كافية بعد الآن ، ولن أتمكن من إجراء عمليات أخرى. إذا حدثت مشكلة في اللحظة الثانية ، فإننا ، على سبيل المثال ، نسحب الأموال من حساب واحد ، لكننا لم نرمي الأموال في الحساب الثاني. اتضح أنه نتيجة لذلك ، سيتم تخفيض حسابي المصرفي ، وجميع حساباتي ، بمقدار ما. لا يمكن إرجاع هذه الأموال بأي شكل من الأشكال.
لحل مثل هذه المشاكل ، هناك مفهوم الصفقة - تنفيذ ذري متكامل لجميع العمليات الثلاث في وقت واحد.
كيف تقوم قاعدة البيانات بذلك؟ يكتب كل هذه التغييرات في سجل معين ويطبقها فقط عندما يتم الالتزام بمعاملاتنا. وبالتالي ، فإننا نضمن أن جميع هذه العمليات سيتم إجراؤها ككل أو لن يتم إجراؤها على الإطلاق.
إذا حدث فشل في أي لحظة من هذا الوقت ، فلن يتم خصم الأموال من الحساب الأول ، وبالتالي لن نخسرها.
المعاملات لها أربع خصائص ، أربعة متطلبات لها. هذه هي الذرية والاتساق والعزلة والمتانة - ذرية البيانات والاتساق والعزلة والمثابرة. ما هي هذه الخصائص؟
- الذرية أو الذرية هي ضمان أن العملية التي تقوم بها ستكتمل بالكامل ، ولن يتم تنفيذها جزئيًا. وبالتالي ، فإننا نضمن أن الاتساق العام للبيانات في قاعدة البيانات الخاصة بنا سيكون قبل العملية وبعدها.
- Consistency — -, . (Integrity). - , , Integrity Error, : , . . — , .
, , , , . . .
- Isolation — , . . , .
- Durability — , , , , .
دعنا نتحدث قليلا عن العزل. يعد عزل المعاملات خاصية باهظة الثمن ، يتم إنفاق الكثير من الموارد عليها ، ولهذا السبب لدينا العديد من مستويات العزل في قواعد البيانات الخاصة بنا. دعونا نرى ما هي المشاكل التي يمكن أن تكون ، وبناءً على ذلك ، سنناقش بالفعل كيفية حلها.
هناك أربع فئات رئيسية من المشاكل - التحديث المفقود ، والقراءة المتسخة ، والقراءة غير المتكررة ، والقراءة الخفية. دعونا نلقي نظرة فاحصة.
يشبه التحديث المفقود في مثال غرفة الدردشة ، عندما يقوم المستخدم 1 بالكتابة فوق البيانات ولا يعرف عنها. أي أننا لم نحظر البيانات التي يقوم هذا المستخدم بتغييرها ، وبالتالي ، تلقينا الكتابة فوقها.
تحدث مشكلة القراءة غير النظيفة عندما يرى المستخدم تغييرات مؤقتة من قبل مستخدم آخر ، والتي يمكن التراجع عنها بعد ذلك أو إجراؤها مؤقتًا.
في هذه الحالة ، كتب المستخدم 1 شيئًا ما إلى قاعدة البيانات. كان المستخدم 2 في ذلك الوقت يحسب شيئًا من هناك ويقوم ببناء التحليلات على هذه البيانات. وواجه المستخدم 1 خطأً ، وعدم تناسق ، وهو يتراجع عن هذه البيانات. وبالتالي ، فإن التحليلات التي كتبها المستخدم 2 ستكون مزيفة وغير صحيحة ، لأن البيانات التي حسبها لم تعد موجودة. تحتاج أيضًا إلى أن تكون قادرًا على حل هذه المشكلة.
القراءة غير القابلة للتكرار هي عندما يكون لدينا مستخدم بمعاملة واحدة طويلة. يقوم بجلب البيانات من قاعدة البيانات ، وفي هذا الوقت يغير المستخدم 2 جزءًا من نفس البيانات.
في هذه الحالة ، اتضح أن المستخدم 1 لم يحظر التغييرات على البيانات الموجودة لديه. وعلى الرغم من حقيقة أنه حصل هو نفسه على لقطة من البيانات ، عندما يُطلب منه التحديد نفسه مرة أخرى ، يمكنه الحصول على قيم مختلفة في هذه السطور. وبالتالي ، سيكون لها تعارض وعدم تطابق في البيانات التي تكتبها.
يمكن أن تحدث مشكلة مماثلة إذا قام المستخدم 2 بإضافة البيانات أو حذفها. وهذا يعني أن المستخدم 1 قدم طلبًا ، وبعد ذلك ، بعد طلب ثانٍ لنفس البيانات ، كان لديه صفوف أو اختفى. في هذه الحالة ، في إطار الصفقة ، من الصعب جدًا فهم ما يجب فعله بها وكيفية معالجتها على الإطلاق.
لحل هذه المشاكل ، هناك أربعة مستويات للعزل. المستوى الأول والأدنى هو قراءة غير ملتزم بها. هذا ما تصفه PostgreSQL بأنه لا يوجد قفل. عندما نقرأ البيانات أو نكتبها ، فإننا لا نمنع المستخدمين الآخرين من قراءة تلك البيانات أو كتابتها. اتضح أننا لا نمنع أي تغييرات. كل هذه المشاكل الأربعة يمكن أن تحدث. ولكن ما الذي يحمي هذا المستوى من العزلة؟ يضمن تنفيذ جميع المعاملات التي تأتي إلى قاعدة البيانات. إذا بدأ مستخدمان في نفس الوقت تنفيذ استعلامات بنفس البيانات ، فسيتم تنفيذ هاتين العمليتين بالتتابع.
ما فائدة هذا؟ نادرًا ما يتم استخدام مستوى العزل هذا في الممارسة العملية ، ولكنه قد يكون مفيدًا ، على سبيل المثال ، عندما يكون هناك استعلام تحليلي كبير وتريد قراءته في الاستعلام الثاني ومعرفة المرحلة التي تكون فيها تحليلاتك ، وما هي البيانات التي تم تسجيلها بالفعل وأيها غير مسجل. ثم الطلب الثاني - وهو التصحيح والتصحيح والتحقق - يتم تشغيله فقط في مستوى العزل هذا. وهو يرى جميع التغييرات في استعلامك التحليلي الأول ، والذي يمكن التراجع عنه في النهاية. أو لم يتم التراجع ، ولكن في الوقت الحالي يمكنك رؤية حالة النظام.
قراءة الالتزام ، قراءة البيانات الملتزمة. يتم استخدام مستوى العزل هذا بشكل افتراضي في معظم قواعد البيانات العلائقية ، بما في ذلك PostgreSQL و Oracle. يضمن لك عدم قراءة البيانات القذرة. أي أن معاملة أخرى لا ترى أبدًا المراحل الوسيطة للمعاملة الأولى. الميزة هي أنها تعمل بشكل جيد للغاية مع الاستعلامات الصغيرة والقصيرة. نحن نضمن أنه لن يكون لدينا موقف حيث نرى بعض أجزاء البيانات ، بيانات غير كاملة. على سبيل المثال ، نقوم بزيادة رواتب قسم بأكمله ولا نرى عندما يحصل جزء فقط من الموظفين على زيادة ، والجزء الثاني يجلس مع رواتب غير مفهرسة. لأنه إذا كان لدينا مثل هذا الموقف ، فمن المنطقي أن "يرحل" محللنا على الفور.
ما الذي لا يحمي مستوى العزل هذا؟ إنه لا يحمي من حقيقة أن البيانات التي حددتها يمكن تغييرها. بالنسبة للاستعلامات الصغيرة ، يكون مستوى العزل هذا كافيًا ، ولكن للاستعلامات الكبيرة والطويلة والتحليلات المعقدة ، بالطبع ، يمكنك استخدام مستويات أكثر تعقيدًا لتأمين جداولك.
يحمي مستوى عزل القراءة المتكرر من المشكلات الثلاث الأولى التي ناقشناها معك. هذا والتحديث المفقود عندما أعدنا تسجيل غرفة الدردشة لدينا ؛ القراءة القذرة - قراءة البيانات غير الملتزم بها ؛ وهذه البيانات غير القابلة للتكرار للقراءة والمحدثة بمعاملات أخرى.
كيف يتم توفيرها؟ من خلال قفل الجدول ، أي قفل تحديدنا. عندما نأخذ التحديد في معاملتنا ، يبدو الأمر وكأنه لقطة من البيانات. وفي هذه اللحظة لا نرى التغييرات من المستخدمين الآخرين ، كل الوقت الذي نعمل فيه مع هذه اللقطة من البيانات. الجانب السلبي هو أننا نحظر البيانات ، وبالتالي ، لدينا عدد أقل من الطلبات المتوازية التي يمكنها العمل مع البيانات. هذا جانب مهم جدا. وبوجه عام ، لماذا يوجد الكثير من مستويات العزلة هذه؟
كلما ارتفع المستوى ، زاد عدد الكتل وعدد المستخدمين الذين يمكنهم العمل مع قاعدة البيانات بشكل متوازٍ. ترى كل معاملة لقطة محددة من البيانات التي لا يمكن تغييرها. لكن قد تظهر بيانات جديدة. لذا فإن مستوى العزل هذا لا ينقذنا من ظهور بيانات جديدة مناسبة للاختيار.
هناك مستوى عزل آخر - التسلسل. هذا غالبا ما يشار إليه بالطلب. هذا قفل بيانات كامل على الطاولة. إنه يحفظ من القراءة الوهمية ، أي من قراءة البيانات التي أضفناها أو حذفناها فقط ، لأننا نغلق الطاولة ، ولا نسمح بالكتابة عليها. ونلبي طلباتنا بشكل كلي.
يعد هذا مفيدًا جدًا للاستعلامات التحليلية المعقدة والكبيرة حيث تكون الدقة وتكامل البيانات أمرًا بالغ الأهمية. لن يتضح أننا في مرحلة ما نقرأ بيانات المستخدم ، ثم ظهرت إحصائيات جديدة في جدول آخر واتضح أنها غير متزامنة.
هذا هو أعلى مستوى من العزلة. يحتوي على أكبر عدد من الأقفال وأصغر موازية ممكنة للاستعلامات.
ماذا تريد أن تعرف عن المعاملات؟ أنها تجعل الحياة أسهل بالنسبة لنا ، لأنها يتم تنفيذها على مستوى نظام إدارة قواعد البيانات (DBMS) ونحتاج فقط إلى إجراء استفساراتنا بشكل صحيح ، وتشكيلها بشكل صحيح ، بحيث تكون البيانات متسقة في النهاية. ولحجب البيانات التي يعمل بها المستخدمون بالضبط. يجب ألا يغيب عن البال أنه من السيئ حظر كل شيء في كل مكان. اعتمادًا على النظام الذي لديك ومن يقرأ / يكتب ، سيكون لديك مستوى مختلف من العزلة. إذا كنت تريد أسرع نظام ممكن يرتكب بعض الأخطاء ، يمكنك اختيار الحد الأدنى من مستوى العزل. إذا كان لديك نظام مصرفي يجب أن يضمن تناسق البيانات ، فإن كل شيء يتم ولا يتم فقد أي شيء - إذن ، بالطبع ، تحتاج إلى اختيار أقصى مستوى للعزل.
لقد أحرزنا بالفعل بعض التقدم الجيد في فهم كيفية هيكلة قاعدة البيانات وما يمكن أن يحدث. لنذهب أبعد من ذلك.
ما مدى أمان تخزين قاعدة بيانات واحدة. بالتأكيد ليست آمنة. إذا حدث شيء لها ، فإننا نفقد كل البيانات. إذا كان هناك نسخة احتياطية ، فيمكننا تشغيلها ، ولكن سيكون هناك وقت تعطل للنظام. إذا تعطلت شبكتنا أو أصبحت العقدة غير متوفرة ، فسيكون النظام أيضًا خاملاً لبعض الوقت ، في وقت التعطل.
كيف يمكن حل هذا؟ هناك مثل هذا المفهوم - التكرار. هذا هو تكرار قاعدة البيانات إلى العقد والخوادم الأخرى.
هذا بالضبط تكرار كامل ، نسخة من قاعدة البيانات. كيف يمكننا استخدام هذه الآلية؟
أولاً ، إذا حدث شيء ما لقاعدة البيانات ، فيمكننا إعادة توجيه الطلبات إلى نسخة أخرى من قاعدة البيانات ، وهذا أمر منطقي من حيث المبدأ. هذا هو التطبيق الرئيسي. وإلا كيف يمكننا استخدام هذا؟
لنتخيل أن المستخدم بعيد عن الخادم. يمكننا توزيع الخوادم بطريقة تغطي أكبر عدد ممكن من المستخدمين ومنحهم الطلبات في أسرع وقت ممكن. سيكون لكل من هذه الخوادم نفس النسخة مثل الخوادم الأخرى ، لكن الطلبات ستعود إلى المستخدمين بشكل أسرع.
استخدام آخر شائع جدًا هو موازنة التحميل. نظرًا لأن لدينا نسخًا متطابقة من البيانات ، لا يمكننا القراءة من رؤوسنا ، وليس من قاعدة بيانات واحدة ، ولكن من قواعد مختلفة. وبالتالي ، نقوم بإلغاء تحميل الخادم الخاص بنا.
لدينا أيضًا مفهوم استعلامات OLTP واستعلامات OLAP. ما هذا؟ OLTP - استعلامات المعاملات القصيرة. OLAP عبارة عن تحليلات طويلة المدى. هذا عندما نأخذ ارتباطًا كبيرًا ، وتحديدًا كبيرًا ، ودمج كل شيء ، ومن المهم جدًا بالنسبة لنا في هذه اللحظة أن يتم تأمين جميع البيانات ، بحيث لا توجد تغييرات وقاعدة البيانات كاملة.
في مثل هذه الحالات ، يمكنك إجراء تحليلات على نسخة منفصلة من قاعدة البيانات. لذلك لن نؤثر على مستخدمينا ، يمكنهم أيضًا إجراء إدخالات في قاعدة البيانات ، وعندها فقط ستأتي هذه الإدخالات إلى نسختنا.
من أجل توزيع نسخ قواعد البيانات بشكل صحيح ، تم تقديم مفهوم العقدة الرئيسية والعقدة التابعة ، Master and Slave. غالبًا ما يُطلق على العبد نسخة طبق الأصل أو تابع. Master - العقدة التي يكتب إليها مستخدمنا ، تطبيقنا. يطبق السيد جميع التغييرات ، ويحتفظ بسجل للتغييرات ، ويرسل هذا السجل إلى التابع. لا يقبل التابع التغييرات من المستخدمين ، ولكنه يطبق التغييرات فقط على السجل من Master. يرجى ملاحظة أن السيد لا يرسل نسخة في كل مرة ، ولكنه يرسل التغييرات. يتدحرج العبد على هذه التغييرات ويتلقى نفس نسخة البيانات كما في السيد.
معلمة مهمة جدًا للنظام المنسوخ هي أن الطلبات يتم تنفيذها بشكل متزامن أو غير متزامن. ما هو الطلب المتزامن؟ هذا عندما يرسل السيد طلبًا إلى نسخة متماثلة متزامنة ، إلى تابع متزامن ، وينتظر التابع ليقول "نعم ، لقد قبلت" ، ويعيد التأكيد إلى السيد. عندها فقط سيعيد السيد الإجابة إلى المستخدم. إذا كانت النسخة المتماثلة غير متزامنة ، يرسل السيد طلبًا إلى النسخة المتماثلة ، ولكنه يخبر المستخدم على الفور أن "هذا كل شيء ، لقد كتبته". دعونا نرى كيف يعمل.
هناك مستخدم قام بكتابة البيانات إلى Master. أرسلها Master إلى نسختين متماثلتين ، وانتظر استجابة من نسخة متماثلة متزامنة وأعطى إجابة للمستخدم على الفور. تم تسجيل نسخة متماثلة غير متزامنة وقالت للسيد: "نعم ، لا بأس ، البيانات مكتوبة."
من حيث هذا التسلسل الهرمي ، السيد والعبد ، يمكن أن يكون لدينا رأس واحد أو عدة رأس. إذا كانت لدينا عقدة رئيسية واحدة ، فمن الملائم جدًا الكتابة إليها ، ولكن يمكنك القراءة من نسخة متماثلة متزامنة. لماذا بالضبط من متزامن؟ لأن النسخة المتماثلة المتزامنة تضمن تحديث البيانات بأقصى قدر من الدقة.
عندما يتم تطبيق استعلام على البيانات ، فإن عملية من السجل تستغرق وقتًا أيضًا. لذلك ، إذا كانت دقة البيانات التي تريد تلقيها بنسبة مائة بالمائة مهمة بالنسبة لك ، فيجب أن تذهب للقراءة ، للاختيار في Master. إذا لم تكن حرجًا من أن البيانات قد تصل مع تأخير بسيط ، فيمكنك القراءة من التابع المتزامن. إذا لم تكن تنتقد أهمية البيانات على الإطلاق ، فيمكنك القراءة ، بما في ذلك من النسخة المتماثلة غير المتزامنة ، وبالتالي إلغاء تحميل النسخة المتماثلة الرئيسية والنسخة المتماثلة المتزامنة من الطلبات.
يمكن أن يكون للنسخ المتماثل أيضًا العديد من الشرائح الرئيسية. يمكن للتطبيقات المختلفة الكتابة إلى رؤوس مختلفة ، ومن ثم يقوم هؤلاء المعلمون بحل النزاعات مع بعضهم البعض.
من الأمثلة البسيطة جدًا على استخدام مثل هذه البيانات جميع أنواع التطبيقات غير المتصلة بالإنترنت. على سبيل المثال ، لديك تقويم على هاتفك. لقد قطعت الاتصال بالشبكة وسجلت حدثًا في التقويم. في هذه الحالة ، التخزين المحلي ، هاتفك ، هو Master. لقد قام بتخزين البيانات في حد ذاته ، وعندما تظهر الشبكة الرئيسية ، ستعمل نسختك المحلية والنسخة الموجودة على الخادم على حل التعارضات ودمج هذه البيانات.
هذا مثال بسيط جدًا لمثل هذا النسخ المتماثل. غالبًا ما يتم استخدامه للتحرير التعاوني للمستندات عبر الإنترنت ، أو عندما يكون هناك احتمال كبير بفقدان الشبكة.
توجد أيضًا عمليات تكرار غير متقنة. ما هذا؟ هذا هو النسخ المتماثل ، حيث يرسل العميل نفسه البيانات إلى معظم النسخ المتماثلة ويقرأها من معظم النسخ المتماثلة أيضًا. هنا يمكنك أن ترى أن النسخة المتماثلة الوسطى لدينا هي تقاطع القراءة والتحديث.
وهذا يعني أننا نضمن أنه في كل مرة نقرأ فيها البيانات ، سوف ندخل إلى واحدة على الأقل من النسخ المتماثلة ، والتي تكون البيانات أكثر صلة بها. وفيما بينها ، تبني النسخ المتماثلة آلية لتبادل المعلومات مع السجل الرئيسي للتغييرات والتعارضات بين النسخ المتماثلة. في هذه الحالة ، غالبًا ما يتم تنفيذ العميل السمين. إذا تلقى بيانات من نسخة متماثلة تحتوي على تغييرات أحدث من أخرى ، فحينئذٍ يرسل البيانات إلى نسخة متماثلة أخرى أو يحل التعارض.
ما المهم معرفته عن النسخ المتماثل؟ النقطة الرئيسية للنسخ هي التسامح مع أخطاء النظام والتوافر العالي للخادم الخاص بك. مهما حدث لقاعدة البيانات ، سيكون النظام متاحًا ، وسيكون المستخدمون قادرين على كتابة البيانات ، وعند استعادة الاتصال مع الرئيسي أو بنسخة متماثلة أخرى ، ستتم أيضًا استعادة جميع البيانات.
النسخ المتماثل مفيد جدًا في إلغاء تحميل الخوادم وإعادة توزيع طلبات القراءة من Master إلى النسخ المتماثلة. يمكننا قياس هذه القراءة وإنشاء المزيد من النسخ المتماثلة للقراءة وجعل نظامنا أسرع. يمكنك أيضًا إنشاء نسخة متماثلة من الاستعلامات التحليلية المعقدة طويلة المدى التي تتطلب عددًا كبيرًا من الأقفال ويمكن أن تؤثر على توفر النظام.
باستخدام التطبيقات غير المتصلة بالإنترنت كمثال ، نظرنا في كيفية تخزين هذه البيانات وحل التعارضات. في حالة النسخة المتماثلة المتزامنة ، قد يكون هناك تأخر في النسخ المتماثل ، أي تأخر زمني. في حالة وجود نسخة متماثلة غير متزامنة ، فهي موجودة دائمًا تقريبًا. أي عندما تقرأ البيانات من نسخة متماثلة غير متزامنة ، يجب أن تفهم أنها قد لا تكون ذات صلة.
وفقًا للتسلسل الهرمي ، نسيت أن أقول أنه عندما يكون هناك معلم واحد ينتظر استجابة من نسخة متماثلة متزامنة ، فمن المنطقي أن نفترض أنه إذا كانت جميع النسخ المتماثلة متزامنة ، وأصبح بعضها غير متاح فجأة ، فلن يتمكن نظامنا من حفظ الطلب. بعد ذلك ، سيكتب لنا السيد إلى التابع الأول المتزامن ، ويتلقى إجابة ، ويسأل عن التابع الثاني ، ولا يتلقى أي رد ، ونتيجة لذلك ، سيتعين عليك التراجع عن المعاملة بالكامل.
لذلك ، في مثل هذه الأنظمة ، كقاعدة عامة ، يتم جعل نسخة متماثلة واحدة متزامنة ، والباقي غير متزامن. تضمن النسخة المتماثلة المتزامنة أن بياناتك لا تزال في مكان آخر. أي ، بالإضافة إلى Master ، الذي يمكن أن يحدث به شيء ما ، نضمن وجود عقدة أخرى على الأقل تحتوي على نسخة كاملة من نفس سجل المعاملات بالضبط ، ونفس البيانات.
من ناحية أخرى ، لا تضمن النسخة المتماثلة غير المتزامنة تكامل البيانات. إذا كان لدينا فقط النسخ المتماثلة غير المتزامنة وتم قطع الاتصال الرئيسي ، فقد تتأخر ، وربما لم تصل البيانات إلى هناك بعد. في مثل هذه الحالات ، كقاعدة عامة ، يقومون ببناء مثل هذا التسلسل الهرمي بحيث إما أن يكون لدينا Master ، أو نسخة متماثلة متزامنة واحدة والباقي غير متزامن ، أو لدينا Master وجميع النسخ المتماثلة غير متزامنة ، إذا كان استمرار البيانات غير مهم بالنسبة لنا.
هناك واحدة "لكن": يجب أن تحتوي جميع النسخ المتماثلة على نفس التكوين. إذا تحدثنا عن PostgreSQL كمثال ، فيجب أن يكون لديهم نفس الإصدار من PostgreSQL نفسه ، لأن الإصدارات المختلفة من قاعدة البيانات يمكن أن يكون لها تنسيق مختلف لسجل العمليات. وإذا ظهرت النسخة المتماثلة من إصدار مختلف ، فقد لا تقرأ ببساطة العمليات التي كتبتها القاعدة الأخرى.
ما هي النسخة المقلدة؟ هذه نسخة كاملة من جميع البيانات. لنفترض أن هناك الكثير من البيانات التي لا يستطيع الخادم معالجتها. ما هو الحل الأول؟
الحل الأول هو شراء جهاز أكثر تكلفة مع ذاكرة أكبر ووحدة معالجة مركزية أكبر وقرص أكبر. سيكون هذا القرار صحيحًا في الغالب ، طالما أنك لا تواجه مشكلة ارتفاع تكلفة الحديد. في يوم من الأيام سيكون شراء سيارة جديدة مكلفًا للغاية ، وإلا فلن يكون هناك مكان للنمو. هناك كمية هائلة من البيانات التي يستحيل فعليًا ملاءمتها على جهاز واحد.
في مثل هذه الحالات ، يمكنك استخدام القياس الأفقي. ما رأيناه سابقًا ، الزيادة في الأداء لكل آلة ، هو التحجيم الرأسي. الزيادة في عدد الآلات هي مقياس أفقي.
لتقسيم البيانات حسب الجهاز أو التجزئة أو بمعنى آخر التقسيم. أي تقسيم البيانات إلى أقسام وكتل حسب المفتاح والمعرف والتاريخ. سنتحدث عن هذا أكثر ، هذا هو أحد المعلمات الرئيسية ، لكن النقطة بالتحديد هي تقسيم البيانات وفقًا لمعيار معين وإرسالها إلى أجهزة مختلفة. وبالتالي ، قد تصبح أجهزتنا أقل كفاءة ، ولكن لا يزال بإمكان النظام العمل واستقبال البيانات من أجهزة مختلفة.
من أجل فهم مكان البيانات بشكل عام ، تحتاج إلى جدول مراسلات معين للجزء ونسختنا وبياناتنا.
هناك أوقات لا يتم فيها استخدام مخزن بيانات خاص ويسير العميل ببساطة عبر كل جزء بدوره ويتحقق مما إذا كانت هناك بيانات تتوافق مع طلبه.
هناك طبقة برامج خاصة تخزن معرفة معينة حول أي جزء في أي نطاق بيانات. وبناءً على ذلك ، فإنه يذهب هناك بالضبط ، إلى العقدة ذاتها حيث توجد البيانات الضرورية.
هناك عميل سمين. يحدث هذا عندما لا نخيط العميل بنفسه في طبقة منفصلة ، لكننا نخيط فيه البيانات حول كيفية تجزئة بياناتنا.
هذا هو الحال. بالمناسبة ، هو الأكثر استخدامًا. الشيء الجيد هو أن تطبيقنا ، عميلنا ، حتى الكود الذي تكتبه ، لا يعرف أن الجدول مجزأ ، على الرغم من أننا نشير إلى ذلك في التكوين ، في قاعدة البيانات نفسها. نقول لها فقط - حدد ، وفي قاعدة البيانات نفسها بالفعل ، هناك تقسيم إلى أجزاء وفهم للمكان الذي تختار منه. هنا ، في الكود نفسه ، تحدد مكان قراءة البيانات منه.
هناك خدمات خاصة تساعد في هيكلة المعلومات وتحديثها بشكل عام. من الصعب إبقائها متسقة وذات صلة. لقد اخترنا شيئًا ، وسجلنا بيانات جديدة. أو تغير شيء ما ونحتاج إلى توجيه طلباتنا بشكل صحيح للغاية. هناك خدمات خاصة لتنسيق الطلبات. واحد منهم هو Zookeper. يمكنك أن ترى كيف يعملون بشكل عام. هيكل مثير جدا للاهتمام. لقد وفروا الكثير من الأعصاب والوقت للمطورين.
ما هو المهم ، ما هي الجوانب التي يجب مراعاتها عند التقسيم؟ من المهم أن نفهم ما هو المفتاح الذي سنستخدمه للتقسيم إلى أجزاء. تعد إعادة جمع كل هذه البيانات مكلفة للغاية ، لذلك من المهم جدًا ألا نخطئ في كيفية استخدام البيانات في المستقبل. إذا قمنا بالتقسيم بشكل جيد وصحيح ، فمع الاستعلامات الأكثر استخدامًا ، سنعرف دائمًا النسخة المتماثلة التي يجب الانتقال إليها.
على سبيل المثال ، إذا قمنا ، وفقًا لمعرفات المستخدم ، بتخزين جميع بياناتهم على نسخ متماثلة معينة ، فإننا نفهم أنه يمكننا الوصول إلى هذه النسخة المتماثلة والقيام بجميع الصلات عليها. لكن الاحتفاظ بها عن طريق المعرف ليس أفضل فكرة. الآن سأخبرك لماذا.
إذا حددنا المفتاح بشكل غير صحيح في التقسيم ، إذا كان لدينا استعلام معقد للغاية ، فعلينا حقًا الانتقال إلى أجزاء مختلفة ، ودمج جميع البيانات ، وبعد ذلك فقط نقدمها إلى التطبيق. لحسن الحظ ، فإن معظم نظم إدارة قواعد البيانات تفعل ذلك لنا. ولكن أي نوع من النفقات العامة سيأتي في ظل الاستفسارات المكتوبة بشكل سيء؟ أم تحت التكسير ، الذي ينكسر على العقدة الخطأ؟
حول المعرفات. إذا كان النظام لا يعمل إلا مع مستخدمين جدد ولدينا زيادة في المعرفات ، فستنتقل جميع الطلبات إلى العقدة الأخيرة.
ماذا حدث؟ ستقف آلات التشغيل الثلاثة الأخرى في وضع الخمول. وستحترق هذه السيارة ببساطة - ما يسمى بالنقطة الساخنة. هذا هو عنق الزجاجة لنظامك المحتمل ، المكان الذي قد يرفض حتى الاتصالات.
لذلك ، عندما نحدد مفتاح التجزئة ، من المهم جدًا فهم مدى توازن هذه العقد. تُستخدم التجزئة في كثير من الأحيان ، وهذا ترتيب محايد إلى حد ما ومتوازن للبيانات. ولكن إذا كانت لديك وظيفة تجزئة على مفتاح ، فلن تتمكن من التحديد ، على سبيل المثال ، حسب النطاقات. إنه أمر منطقي ، لأنه لا يمكن نشر النطاقات إلى أجزاء مختلفة.
حسب التاريخ - نفس الشيء. على سبيل المثال ، إذا قمنا بتشتيت التحليلات وعملنا شظايا حسب التاريخ ، فبالطبع لن يتم استخدام أي جزء قبل عشر سنوات على الإطلاق. انها ليست مربحة بالنسبة لنا. ودائمًا ما تكون إعادة بناء البيانات والإرهاق أمرًا مكلفًا للغاية.
سأجيب على السؤال الذي جاء من قبل. هل من الأفضل تحديد المؤشرات أم عمل شظايا؟ المؤشرات بالطبع.
انظر ، القطع عبارة عن آلات منفصلة ببنية تحتية مرتفعة بالكامل. ويحتوي هذا المكون الأوسط على شيء يشبه الفهارس. هناك بحث سريع عن طريق المعلمات - أين وأين نذهب. ها هي النسبة. ولكن إذا كان هناك تجزئة ، فستكون الصورة النهائية كما يلي:
هناك تطبيقات ، نوع من الرأس يعرف إلى أين يذهب. وهناك شظايا ، يتم تكوين نسخة متماثلة على كل منها. هذا هو بالفعل عبء كبير إذا لم يكن هناك الكثير من البيانات. أي أنك تحتاج فقط إلى اللجوء إلى التجزئة عندما تصل حقًا إلى حد القياس الرأسي ، عندما لا يكون شراء آلة أكثر تكلفة مناسبًا لبياناتك أو دخلك. ثم يمكنك شراء العديد من السيارات المختلفة الرخيصة وبناء مثل هذه الهندسة عليها.
ما هي النسخ المتماثلة ، على ما أعتقد ، واضح: لأن القطع مكسورة ، فهي أجزاء من قواعد البيانات ، لكنها فريدة نوعًا ما. تم العثور عليها فقط في هذه الأماكن. نقوم أيضًا بتقسيمها إلى نسخ ، مما يجعل عقدنا تتسامح مع الأخطاء وتؤمن ضد المشاكل.
أهم شيء: يتم استخدام التجزئة بالضبط حيث لا تريد فقط تقسيم البيانات إلى تصنيف ، ولكن بالضبط حيث يوجد بالفعل الكثير من البيانات.
الآن دعنا ندخل المزيد في نماذج البيانات ونرى كيف يمكن تخزين البيانات.
تتمتع قواعد البيانات العلائقية التي نظرنا إليها من قبل بعدد كبير من المزايا ، لأنها أولاً وقبل كل شيء شائعة جدًا ومفهومة للجميع. إنها تظهر العلاقة بين الأشياء بصريًا وتوفر التكامل.
لكن هناك جانبًا سلبيًا: فهي تتطلب هيكلًا واضحًا. هناك جدول يجب أن ندفع فيه جميع البيانات. إذا نظرت إلى جميع المعلومات والحقائق التي نجمعها بشكل عام ، فهي مختلفة تمامًا. وهذا يعني أنه يمكننا العمل مع بيانات المنتج وبيانات المستخدم والرسائل وما إلى ذلك. تتطلب هذه البيانات حقًا بنية واضحة وسلامة. قاعدة البيانات العلائقية مثالية لهم.
لكن افترض أن لدينا ، على سبيل المثال ، سجل للعمليات أو وصفًا للأشياء ، حيث لكل كائن خصائص مختلفة. يمكننا بالطبع كتابة هذا في jason في قاعدة بيانات علائقية ويسعدنا أنه ينمو معنا إلى ما لا نهاية.
ويمكننا أن ننظر إلى المخططات الأخرى ، في أنظمة التخزين الأخرى. NoSQL هو اختصار مبهرج للغاية ، حتى أنه استفزازي بشكل مباشر - "لا يوجد SQL". كيف حدث ذلك؟
عندما واجه الناس حقيقة أن قواعد البيانات العلائقية ليست ناجحة في كل مكان ، قاموا بتجميع مؤتمر يحتاج إلى علامة تصنيف ، ولذا توصلوا إلى #NoSQL. لقد ترسخت. في وقت لاحق بدأوا يقولون ليس "لا SQL" ، ولكن "ليس فقط SQL". إنه مجرد أي شيء غير علائقي: مجموعة ضخمة من قواعد البيانات المختلفة التي ليست منظمة بشكل صارم وتخطيطي وجدولي مثل قواعد البيانات العلائقية.
تنقسم عائلة نماذج البيانات غير العلائقية إلى أربعة أنواع: قواعد البيانات ذات القيمة الرئيسية والموجهة نحو المستندات والعمودية والرسم البياني. دعنا نفكر في كل نقطة من هذه النقاط ، واكتشف البيانات الأفضل تخزينها وفي أي منها وما يتم استخدامها.
مفتاح القيمة. هذا هو الأبسط. ها هو القاموس ، ها هي النسبة. هذه قاعدة بيانات يتم فيها تخزين البيانات بواسطة المفاتيح ، ولا يهم ما هو موجود تحت مفتاح معين. لدينا كل من المفتاح نفسه ويمكن أن تكون البيانات هياكل بسيطة وأكثر تعقيدًا. الشيء الجيد في قاعدة البيانات هذه هو أنها ، مثل الفهرس ، تبحث عن البيانات بسرعة كبيرة. هذا هو السبب في استخدام key-value غالبًا لذاكرة التخزين المؤقت. الميزة هي أن قيمتنا يمكن أن تكون مختلفة في مفاتيح مختلفة.
يمكننا استخدام المفتاح ، على سبيل المثال ، لتخزين جلسات المستخدم. نقر المستخدم ، وكتبنا هذا في القيمة. إنه مخطط ، نموذج بيانات بدون مخطط محدد ، بنية قيمة. نظرًا لأنه هيكل بسيط للغاية ، فهو سريع وسهل القياس. لدينا المفاتيح بالفعل ، ويمكننا بسهولة تكسيرها وعمل تجزئاتها. إنها واحدة من أكثر قواعد البيانات قابلية للتطوير.
ومن الأمثلة على ذلك Redis و Memcached و Amazon DynamoDB و Riak و LevelDB. يمكنك رؤية ميزات التنفيذ لمخازن القيمة الرئيسية.
قواعد بيانات المستندات تشبه إلى حد بعيد قيمة المفتاح في بعض استخداماتها. لكن وحدتهم وثيقة. هذا هيكل معقد يمكننا من خلاله تحديد بيانات معينة ، والقيام بعمليات مجمعة: الإدراج بالجملة والتحديث المجمع.
يمكن لكل مستند تخزينه في حد ذاته ، كقاعدة عامة ، XML أو JSON أو BSON - JSON المخزن ثنائيًا. ولكن الآن دائمًا ما يكون JSON أو BSON. هذا أيضًا مثل زوج القيمة الرئيسية ، يمكنك تخيله كجدول يحتوي كل صف على خصائص معينة ، ويمكننا الحصول على شيء منه باستخدام هذه المفاتيح.
ميزة قواعد البيانات الموجهة للمستندات هي أنها تتمتع بقدر كبير من المرونة وتوفر البيانات. في أي مستند ، في أي JSON ، يمكنك كتابة أي مجموعة من البيانات على الإطلاق. وغالبًا ما يتم استخدامها - على سبيل المثال ، عندما تحتاج إلى إنشاء كتالوج وعندما يكون لكل منتج في الكتالوج خصائص مختلفة.
أو ، على سبيل المثال ، ملفات تعريف المستخدمين. أشار شخص ما إلى فيلمه المفضل ، شخص ما - طعامه المفضل. من أجل عدم لصق كل شيء في حقل واحد ، والذي سيخزن ، ليس من الواضح ما هو ، يمكننا كتابة كل شيء في JSON لقاعدة المستند.
هناك نموذج آخر مناسب لتخزين البيانات وهو قواعد البيانات العمودية. وتسمى أيضًا قاعدة البيانات العمودية.
هذا هيكل مثير للاهتمام يتم استخدامه ، كما يبدو لي ، في جميع المشاريع الكبيرة والمعقدة تقريبًا. تشير قاعدة البيانات هذه إلى أننا نقوم بتخزين البيانات على القرص ليس في خطوط ، ولكن في أعمدة. تُستخدم لعمليات البحث السريعة جدًا على كمية هائلة من البيانات. كقاعدة عامة - للتحليلات ، عندما تحتاج إلى تحديد قيم من أعمدة معينة فقط.
لنتخيل أن لدينا طاولة ضخمة. وإذا قمنا بتخزين البيانات في سطور ، فسيكون ما يلي: عدد كبير من السطور. لتحديد ثلاث معلمات لهذا الجدول ، نحتاج إلى استعراض الجدول بأكمله. وعندما نخزن القيم حسب الأعمدة ، ثم عند التحديد بثلاث قيم ، نحتاج إلى المرور بثلاثة فقط من هذه الأسطر ، تقريبًا ، لأن الأعمدة مكتوبة على هذا النحو. بالمرور عبر هذه الأسطر الثلاثة ، نحصل على الفور على الرقم الترتيبي للقيمة التي نحتاجها ونحصل عليها من الأعمدة الأخرى.
ما هي ميزة قواعد البيانات هذه؟ نظرًا لحقيقة أنهم يبحثون عن كمية صغيرة من البيانات ، فإن لديهم سرعة عالية جدًا في معالجة الاستعلام ومرونة كبيرة في البيانات ، لأنه يمكننا إضافة أي عدد من الأعمدة دون تغيير الهيكل. هنا ، ليس كما هو الحال في قواعد البيانات العلائقية ، لا نحتاج إلى فرض بياناتنا في إطارات معينة.
أشهرها على الأرجح هي Cassandra و HBase و ClickHouse. اختبرهم. من المثير للاهتمام للغاية عكس نسبة الصفوف والأعمدة في رأسك. وهذا حقًا وصول فعال وسريع إلى كميات كبيرة من البيانات.
هناك أيضًا مجموعة من قواعد بيانات الرسم البياني. تحتوي أيضًا على عقد وحواف. تُستخدم الحواف لإظهار العلاقات ، تمامًا كما هو الحال في قواعد البيانات العلائقية. لكن قواعد الرسم البياني يمكن أن تنمو بلا حدود في اتجاهات مختلفة. لذلك ، فهو أكثر مرونة. يتميز بسرعة بحث عالية جدًا ، لأنه لا توجد حاجة لاختيار جميع الجداول والانضمام إليها. تحتوي العقدة على حواف تظهر العلاقة بكل الكائنات المختلفة على الفور.
ما هي قواعد البيانات هذه المستخدمة؟ في أغلب الأحيان - فقط لإظهار العلاقة. على سبيل المثال ، في الشبكات الاجتماعية ، يمكنك الإجابة على سؤال من يتابع من. لدينا على الفور روابط لجميع متابعي الشخص المناسب. لا تزال قواعد البيانات هذه تستخدم في كثير من الأحيان لتحديد مخططات الاحتيال ، لأن هذا يرتبط أيضًا بإثبات علاقة المعاملات ببعضها البعض. على سبيل المثال ، يمكنك تتبع وقت استخدام نفس البطاقة المصرفية في مدينة أخرى أو عندما قام شخص آخر بإدخال حساب مستخدم آخر من نفس عنوان IP.
هذه العلاقات المعقدة هي التي تساعد في حل المواقف غير العادية التي تستخدم غالبًا لتحليل مثل هذه التفاعلات والعلاقات.
قواعد البيانات غير العلائقية لا تحل محل قواعد البيانات العلائقية. هم فقط مختلفون. تنسيق بيانات مختلف ومنطق مختلف لعملهم ، ليس أسوأ ولا أفضل. إنها مجرد طريقة مختلفة للبيانات الأخرى. ونعم ، يتم استخدام قواعد البيانات غير العلائقية كثيرًا. لا داعي للخوف منهم ، بل على العكس ، يجب أن تجربهم.
إذا قمت بإنشاء ذاكرة تخزين مؤقت ، إذن ، بالطبع ، خذ نوعًا من Redis ، قيمة مفتاح بسيطة وسريعة. إذا كان لديك عدد كبير من السجلات للتحليل ، فيمكنك إفلاته في ClickHouse أو في قاعدة عمودية ، والتي ستكون بعد ذلك ملائمة جدًا للبحث. أو اكتبها في قاعدة المستند ، لأنه قد تكون هناك معاني مختلفة للوثائق. يمكن أن يكون هذا مفيدًا أيضًا للاختيار.
اختر نموذج بيانات بناءً على البيانات التي ستستخدمها. إما علائقية أو غير علائقية. صف البيانات. بهذه الطريقة ، يمكنك العثور على أنسب مساحة تخزين يمكنك توسيعها في المستقبل.
لقد تعلمت اليوم الكثير عن مختلف المشاكل وطرق تخزين البيانات. سأكرر مرة أخرى ما قلته في البداية: لست بحاجة إلى معرفة كل شيء بالتفصيل ، ولست بحاجة إلى الخوض في شيء واحد. إذا كنت مهتمًا ، بالطبع يمكنك ذلك. لكن من المهم أن تعرف أنه موجود بشكل عام ، وما هي الأساليب الموجودة وكيف يمكنك التفكير بشكل عام. إذا كنت بحاجة إلى التسامح مع الخطأ ، فمن المنطقي عمل نسخة طبق الأصل. لنفترض أنني كتبت البيانات ، لكنني لم أرها. ثم ، على الأرجح ، أعطت ملاحظتي تأخرًا. ليست هناك حاجة لإعادة اختراع العجلة - فهناك بالفعل العديد من الحلول الجاهزة لمهام مختلفة. وسّع آفاقك ، وإذا ظهر خطأ أو مشكلة أخرى ، فستفهم بالضبط مكان حدوث الفشل من خلال خصائص الخطأ ، ويمكنك إيجاد حل من خلال محرك البحث. شكرآ لك على أهتمامك.