it-swarm.asia

كيف يساعد تقسيم الجدول؟

أجد صعوبة في الاستيلاء على فكرة إيجابيات وسلبيات تقسيم الجدول. أنا على وشك البدء في العمل في مشروع يحتوي على 8 جداول وسيكون أحدها جدول البيانات الرئيسي الذي سيحتوي على 180-260 مليون سجل. لأنه سيتم فهرسته بشكل صحيح ، لذلك أفكر في تحديد سجلات الجدول إلى 20 مليون بهذه الطريقة سيكون علي إنشاء 9-13 جدولًا.

لكنني لست متأكدًا تمامًا من كيفية تحسين الأداء لأنهم سيجلسون على نفس الجهاز (ذاكرة وصول عشوائي 32 جيجابايت)؟

أنا أستخدم MySQL والجداول ستكون MyISAM والجدول الكبير يحتوي على فهرس في حقل المعرف وليس هناك المزيد من التعقيدات مثل البحث عن النص الكامل وما إلى ذلك.

يرجى أيضًا إلقاء الضوء على تقسيم الجدول مقابل تقسيم قاعدة البيانات.

28
Rick James

ما يلي هو مجرد صخب وجنون ...

إذا تركت جميع البيانات في جدول واحد (بدون تقسيم) ، فسيكون لديك أوقات بحث O (تسجيل n) باستخدام مفتاح. دعونا نأخذ أسوأ مؤشر في العالم ، الشجرة الثنائية. كل عقدة شجرة لها مفتاح واحد بالضبط. يبلغ ارتفاع شجرة ثنائية متوازنة تمامًا مع 268،435،455 (2 ^ 28 - 1) عقد 28. إذا قسمت هذه الشجرة الثنائية إلى 16 شجرة منفصلة ، فستحصل على 16 شجرة ثنائية لكل منها 16777،215 (2 ^ 24 - 1) عقد الشجرة لارتفاع 24. يتم تقليل مسار البحث بمقدار 4 عقد ، وهو تخفيض ارتفاع 14.2857٪. إذا كان وقت البحث بالميكروثانية ، فإن تقليل وقت البحث بنسبة 14.2857٪ لا يُذكر.

الآن في العالم الحقيقي ، سيكون مؤشر BTREE يحتوي على treenodes مع مفاتيح متعددة. يؤدي كل بحث BTREE إلى إجراء بحث ثنائي داخل الصفحة مع إمكانية لائقة في صفحة أخرى. على سبيل المثال ، إذا كانت كل صفحة BTREE تحتوي على 1024 مفتاحًا ، فسيكون ارتفاع الشجرة 3 أو 4 هو القاعدة ، وهو ارتفاع شجرة قصير بالفعل.

لاحظ أن تقسيم الجدول لا يقلل من ارتفاع BTREE الصغير بالفعل. نظرًا لتقسيم 260 مليون صف ، هناك احتمال كبير لامتلاك عدّة BTREEs بنفس الارتفاع. قد يمر البحث عن مفتاح عبر جميع صفحات BTREE الجذر في كل مرة. واحد فقط سيفي بمسار نطاق البحث المطلوب.

الآن توسيع على هذا. جميع الأقسام موجودة على نفس الجهاز. إذا لم يكن لديك أقراص منفصلة لكل قسم ، فسيكون لديك القرص I/O وتدوير المغزل كإختناق تلقائي خارج أداء البحث عن القسم.

في هذه الحالة ، لا يشترط التقسيم بواسطة قاعدة البيانات أي شيء سواء كان id هو مفتاح البحث الوحيد الذي يتم استخدامه.

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

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

32
RolandoMySQLDBA

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

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

  • وحدات تخزين متعددة على القرص يسمح لك التقسيم بتقسيم البيانات لتوزيع حركة مرور القرص عبر وحدات تخزين متعددة من أجل السرعة. مع وحدة تحكم RAID الحديثة ، من غير المحتمل أن يكون هذا مشكلة لـ OP.

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

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

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

16
ConcernedOfTunbridgeWells

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

1
Bill