تقسيم / تقسيم / تقسيم MySQL - ما هي الطريقة التي يجب اتباعها؟
https://stackoverflow.com/questions/45879
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لدينا قاعدة بيانات InnoDB يبلغ حجمها حوالي 70 غيغابايت ونتوقع أن تنمو إلى عدة مئات غيغابايت في السنتين إلى الثلاث سنوات القادمة.حوالي 60% من البيانات تنتمي إلى جدول واحد.تعمل قاعدة البيانات حاليًا بشكل جيد حيث لدينا خادم مزود بذاكرة وصول عشوائي (RAM) تبلغ سعتها 64 جيجابايت، لذا فإن قاعدة البيانات بأكملها تقريبًا تناسب الذاكرة، ولكننا نشعر بالقلق بشأن المستقبل عندما تكون كمية البيانات أكبر بكثير.نحن الآن نفكر في طريقة ما لتقسيم الجداول (خاصة تلك التي تمثل الجزء الأكبر من البيانات) وأنا الآن أتساءل، ما هي أفضل طريقة للقيام بذلك.
الخيارات التي أعرفها حاليًا هي
- استخدام قسم MySQL الذي يأتي مع الإصدار 5.1
- استخدام نوع من مكتبة الطرف الثالث التي تقوم بتغليف تقسيم البيانات (مثل أجزاء السبات)
- تنفيذها بأنفسنا داخل التطبيق لدينا
تطبيقنا مبني على J2EE وEJB 2.1 (نأمل أن نتحول إلى EJB 3 يومًا ما).
ما اقتراحك؟
تحرير (2011/02/11):
مجرد تحديث:يبلغ حجم قاعدة البيانات حاليًا 380 جيجابايت، وحجم بيانات جدولنا "الكبير" هو 220 جيجابايت، وحجم فهرسه 36 جيجابايت.لذلك، في حين أن الجدول بأكمله لم يعد مناسبًا للذاكرة، فإن الفهرس يفعل ذلك.
لا يزال النظام يعمل بشكل جيد (لا يزال على نفس الجهاز) وما زلنا نفكر في تقسيم البيانات.
تحرير (2014/06/04):تحديث آخر:حجم قاعدة البيانات بأكملها هو 1.5 تيرابايت، وحجم جدولنا "الكبير" هو 1.1 تيرابايت.قمنا بترقية الخادم الخاص بنا إلى جهاز ذو 4 معالجات (Intel Xeon E7450) مع ذاكرة وصول عشوائي (RAM) تبلغ سعتها 128 جيجابايت.النظام لا يزال يعمل بشكل جيد.ما نخطط للقيام به بعد ذلك هو وضع طاولتنا الكبيرة على خادم قاعدة بيانات منفصل (لقد قمنا بالفعل بالتغييرات اللازمة في برنامجنا) مع الترقية في نفس الوقت إلى أجهزة جديدة بذاكرة وصول عشوائي (RAM) تبلغ سعتها 256 جيجابايت.
من المفترض أن يستمر هذا الإعداد لمدة عامين.بعد ذلك سيتعين علينا إما أن نبدأ أخيرًا في تنفيذ حل التجزئة أو مجرد شراء خوادم بها 1 تيرابايت من ذاكرة الوصول العشوائي والتي من شأنها أن تبقينا مستمرين لبعض الوقت.
تحرير (2016/01/18):
لقد قمنا منذ ذلك الحين بوضع طاولتنا الكبيرة في قاعدة البيانات الخاصة بها على خادم منفصل.يبلغ حجم قاعدة البيانات هذه حاليًا حوالي 1.9 تيرابايت، ويبلغ حجم قاعدة البيانات الأخرى (مع جميع الجداول باستثناء الجدول "الكبير") 1.1 تيرابايت.
إعداد الأجهزة الحالية:
- اتش بي بروليانت دي ال 580
- 4 × وحدة المعالجة المركزية Intel(R) Xeon(R) E7-4830
- 256 جيجابايت رام
الأداء جيد مع هذا الإعداد.
المحلول
إذا كنت تعتقد أنك ستكون مرتبطًا بالإدخال/الذاكرة، فلا أعتقد أن التقسيم سيكون مفيدًا.كالعادة، سيساعدك قياس الأداء أولاً على معرفة الاتجاه الأفضل.إذا لم يكن لديك خوادم احتياطية بذاكرة سعة 64 جيجابايت، فيمكنك دائمًا أن تطلب من البائع الخاص بك "وحدة تجريبية".
أميل إلى التقسيم إذا كنت لا تتوقع تقريرًا مجمعًا للاستعلام واحدًا.أفترض أنك ستقوم بتقسيم قاعدة البيانات بأكملها وليس فقط جدولك الكبير:فمن الأفضل إبقاء الكيانات بأكملها معًا.حسنًا، إذا كان النموذج الخاص بك ينقسم بشكل جيد، على أي حال.
نصائح أخرى
ستبدأ بالتأكيد في مواجهة مشكلات على هذا الجدول الذي تبلغ سعته 42 جيجابايت بمجرد عدم احتوائه على الذاكرة.في الواقع، بمجرد أن لا يتناسب مع الذاكرة بعد الآن، سوف يتدهور الأداء بسرعة كبيرة.إحدى طرق الاختبار هي وضع هذا الجدول على جهاز آخر به ذاكرة وصول عشوائي أقل ومعرفة مدى ضعف أدائه.
أولاً، لا يهم تقسيم الجداول إلا إذا قمت أيضًا بنقل بعض الجداول إلى مجلد فعلي منفصل.
هذا غير صحيح.يمكن أن يوفر التقسيم (إما من خلال الميزة الموجودة في MySQL 5.1، أو نفس الشيء باستخدام جداول MERGE) فوائد كبيرة في الأداء حتى لو كانت الجداول على نفس محرك الأقراص.
على سبيل المثال، لنفترض أنك تقوم بتشغيل استعلامات SELECT على جدولك الكبير باستخدام نطاق زمني.إذا كان الجدول كاملاً، فسيتم فرض الاستعلام على الجدول بأكمله (وبهذا الحجم، حتى استخدام الفهارس يمكن أن يكون بطيئًا).تتمثل ميزة التقسيم في أن استعلاماتك ستعمل فقط على الأقسام التي تكون ضرورية للغاية.إذا كان حجم كل قسم 1 غيغابايت وكان استعلامك يحتاج فقط إلى الوصول إلى 5 أقسام من أجل تنفيذ نفسه، فإن الجدول المدمج الذي يبلغ حجمه 5 غيغابايت يكون أسهل بكثير على MySQL للتعامل معه من الإصدار الكبير الذي تبلغ سعته 42 غيغابايت.
الشيء الوحيد الذي عليك أن تسأله لنفسك هو كيف تستفسر عن البيانات.إذا كان هناك احتمال أن تحتاج استعلاماتك فقط إلى الوصول إلى أجزاء معينة من البيانات (على سبيل المثال:نطاق تاريخ أو نطاق معرف)، سيكون التقسيم من نوع ما مفيدًا.
لقد سمعت أنه لا يزال هناك بعض الأخطاء في تقسيم MySQL 5.1، خاصة فيما يتعلق باختيار MySQL للمفتاح الصحيح.يمكن أن توفر جداول الدمج نفس الوظيفة، على الرغم من أنها تتطلب حملًا إضافيًا قليلاً.
أتمنى أن ذلك يساعد، حظا طيبا!
يعد هذا مثالًا رائعًا لما يمكن أن يفعله تقسيم MySql في مثال واقعي لتدفقات البيانات الضخمة:
على أمل أن يكون مفيدا لقضيتك.
منذ فترة، في حدث Microsoft ArcReady، رأيت عرضًا تقديميًا حول قياس الأنماط التي قد تكون مفيدة لك.أنت تستطيع عرض الشرائح لذلك عبر الإنترنت.
سأختار MariaDB InnoDB + Partitions (إما حسب المفتاح أو حسب التاريخ، اعتمادًا على استفساراتك).
لقد فعلت هذا والآن لم يعد لدي أي مشاكل في قاعدة البيانات.
يمكن استبدال MySQL بـ MariaDB في ثوانٍ...تبقى جميع ملفات قاعدة البيانات كما هي.
أولاً، لا يهم تقسيم الجداول إلا إذا قمت أيضًا بنقل بعض الجداول إلى مجلد فعلي منفصل.
ثانيًا، ليس بالضرورة أن يكون الجدول ذو الحجم المادي الأكبر هو الذي تريد نقله.قد يكون لديك جدول أصغر بكثير يحصل على مزيد من النشاط، بينما يظل الجدول الكبير ثابتًا إلى حد ما أو يقوم بإلحاق البيانات فقط.
مهما فعلتم، لا تنفذوه بأنفسكم.دع نظام قاعدة البيانات يتعامل معها.
ماذا تفعل الطاولة الكبيرة.
إذا كنت ستقوم بتقسيمها، فلديك بعض الخيارات:
- تقسيمها باستخدام نظام قاعدة البيانات (لا أعرف الكثير عن ذلك)
- تقسيمها على التوالي.
- تقسيمه حسب العمود.
لن يكون تقسيمها حسب الصف ممكنًا إلا إذا كان من الممكن فصل بياناتك بسهولة إلى أجزاء.على سبيل المثالشيء مثل معسكر القاعدة لديه حسابات متعددة منفصلة تمامًا.يمكنك الاحتفاظ بـ 50% من الحسابات في جدول واحد و50% في جدول مختلف على جهاز مختلف.
يعد التقسيم حسب العمود مفيدًا للمواقف التي يحتوي فيها حجم الصف على حقول نصية كبيرة أو كائنات كبيرة الحجم.إذا كان لديك جدول يحتوي (على سبيل المثال) على صورة مستخدم وكتلة كبيرة من النص، فيمكنك دمج الصورة في جدول مختلف تمامًا.(على جهاز مختلف)
لقد كسرت التطبيع هنا، لكنني لا أعتقد أن ذلك سيسبب الكثير من المشاكل.
كالعادة، سيساعدك قياس الأداء أولاً على معرفة الاتجاه الأفضل.
هذا ما يقوله لي معظم الناس، لذا أعتقد أنني سأضطر أخيرًا إلى تناول تلك الحبة...
ربما ترغب في تقسيم تلك الطاولة الكبيرة في النهاية.ربما تريد وضعه على قرص ثابت منفصل، قبل التفكير في خادم ثانٍ.يعد القيام بذلك باستخدام MySQL هو الخيار الأكثر ملاءمة.إذا كان قادرا، فاذهب إليه.
لكن
كل شيء يعتمد على كيفية استخدام قاعدة البيانات الخاصة بك، حقا.إحصائيات.
