it-swarm.asia

حول أداء ترابط واحد مقابل أداء قواعد البيانات متعددة مؤشرات الترابط

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

سؤالي هو: متى تصبح قاعدة البيانات متعددة الخيوط أكثر إثارة للاهتمام من قاعدة بيانات مؤشر ترابط واحد؟ كم عدد المستخدمين؟ كم عدد العمليات؟ ما هو الزناد؟ أي شخص لديه خبرة للمشاركة؟

ملخص

  • الاختناق المعتاد هو الوصول إلى القرص
  • محركات الأقراص ذات الحالة الثابتة سريعة ولكنها هشة (إجراء الفشل أمر لا بد منه)
  • استعلام واحد طويل على نظام مؤشر ترابط واحد سيحظر جميع الآخرين
  • يمكن أن يكون تكوين نظام متعدد الخيوط أمرًا صعبًا
  • قواعد البيانات متعددة مؤشرات الترابط مفيدة حتى على أنظمة أحادية النواة
59
Jérôme Verstrynge

هنا رأيي:

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

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

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

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

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

31
StanleyJohns

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

innodb_thread_concurrency تعين الحد الأعلى لعدد الخيوط المتزامنة التي يمكن لـ InnoDB الاحتفاظ بها مفتوحة. أفضل رقم دائري يتم تعيينه لهذا هو (عدد 2 من وحدات المعالجة المركزية) + عدد الأقراص. [~ # ~] تحديث [~ # ~] : كما علمت بشكل مباشر من مؤتمر بيركونا في نيويورك ، يجب عليك تعيين هذا إلى 0 من أجل التنبيه محرك تخزين InnoDB للعثور على أفضل عدد من الخيوط للبيئة التي يعمل فيها.

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

innodb_commit_concurrency تحدد عدد المعاملات المتزامنة التي يمكن ارتكابها. نظرًا لأن القيمة الافتراضية هي 0 ، فإن عدم تعيين هذا يسمح لأي عدد من المعاملات بالالتزام في نفس الوقت.

innodb_thread_sleep_delay يحدد عدد المللي ثانية التي يمكن أن يكون فيها مؤشر ترابط InnoDB خاملًا قبل إعادة إدخال قائمة انتظار InnoDB. الإعداد الافتراضي هو 10000 (10 ثوانٍ).

innodb_read_io_threads و innodb_write_io_threads (كلاهما منذ MySQL 5.1.38) يخصصان عددًا محددًا من سلاسل عمليات القراءة والكتابة. القيمة الافتراضية 4 والحد الأقصى 64.

innodb_replication_delay يفرض تأخيرًا في مؤشر الترابط على عبد يتم الوصول إلى innodb_thread_concurrency.

innodb_read_ahead_threshold يسمح بقراءات خطية لعدد محدد من النطاقات (64 صفحة [صفحة = 16 كيلوبايت]) قبل التبديل إلى القراءة غير المتزامنة.

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

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

لقد لعبت مع MySQL 5.5 مثيلات تجمع المخزن المؤقت المتعددة (162 جيجابايت في 9 مثيلات تجمعات المخزن المؤقت) وحاولت تقسيم البيانات تلقائيًا في الذاكرة بهذه الطريقة. يقول بعض الخبراء أن هذا يجب أن يمنحك تحسينًا بنسبة 50 ٪ في الأداء. ما حصلت عليه هو الكثير من قفل الخيط الذي جعل InnoDB يزحف في الواقع. لقد تحولت إلى مخزن مؤقت واحد (162 جيجابايت) وكان كل شيء جيدًا مرة أخرى في العالم. أعتقد أنك بحاجة إلى خبراء بيركونا تحت تصرفكم لتعيين هذا. سأكون غداً في مؤتمر بيركونا MySQL في نيويورك غداً وسأستفسر عما إذا كانت الفرصة متاحة.

في الختام ، يتصرف InnoDB بشكل جيد الآن في خادم وحدة المعالجة المركزية المتعددة نظرًا لإعداداته الافتراضية للعمليات متعددة مؤشرات الترابط. يتطلب تغييرها بعناية كبيرة وصبرًا كبيرًا وتوثيقًا رائعًا وقهوة رائعة (أو Red Bull ، Jolt ، إلخ).

صباح الخير ومساء الخير ومساء الخير !!!

تحديث 2011-05-27 20:11

عاد من مؤتمر بيركونا الخلية في نيويورك يوم الخميس. يا له من مؤتمر. تعلمت الكثير ، لكني حصلت على إجابة سوف أنظر فيها بخصوص InnoDB. أبلغني (رونالد برادفورد أن ضبط innodb_thread_concurrency على 0 سيتيح لـ InnoDB تحديد أفضل مسار عمل داخليًا باستخدام التزامن الخيط. سأختبر هذا أكثر في MySQL 5.5.

تحديث 2011-06-01 11:20

بقدر ما يذهب استعلام واحد طويل ، InnoDB هو متوافق مع ACID ويعمل بشكل جيد جدًا باستخدام MultiVersion Concurrency Control . يجب أن تكون المعاملات قادرة على حمل مستويات العزل (تقرأ قابلة للتكرار بشكل افتراضي) التي تمنع الأشخاص الآخرين من الوصول إلى البيانات.

أما بالنسبة للأنظمة متعددة النواة ، فقد قطعت InnoDB شوطًا طويلاً. في الماضي ، لم يكن أداء InnoDB جيدًا في بيئة متعددة النوى. أتذكر الاضطرار إلى تشغيل مثيلات mysql متعددة على خادم واحد للحصول على النوى المتعددة لتوزيع عمليات mysqld المتعددة عبر وحدات المعالجة المركزية. لم يعد هذا ضروريًا ، بفضل Percona ، ولاحقًا MySQL (eh ، Oracle ، قائلين إن ذلك لا يزال يجعلني أسكت) ، حيث قاموا بتطوير InnoDB إلى محرك تخزين أكثر نضجًا يمكنه الوصول إلى النوى بكل بساطة دون ضبط كبير. يمكن أن يعمل المثيل الحالي لـ InnoDB اليوم بشكل جيد في خادم أحادي النواة.

49
RolandoMySQLDBA

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

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

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

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

11
Luke Hutteman

من ما يمكنني أن أقول ، "الخيوط المفردة" هي تسمية خاطئة قليلاً لـ H2. النقطة هي أنه يقوم بتسلسل جميع المعاملات (أي يقوم بها في وقت واحد).

السؤال الحاسم بشأن ما إذا كان ذلك "جيدًا" أم لا لتطبيقك ليس "كم عدد المستخدمين؟" أو حتى "كم عدد العمليات؟" ، ولكن "كم ستستغرق معاملاتي؟"

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

--تعديل

يبدو أن H2 لا يقوم بالفعل بتسلسل المعاملات - فقط DML. بمعنى آخر ، الكثير من التحديثات القصيرة في معاملة واحدة طويلة لن تمنع التحديثات الأخرى . ومع ذلك ، إلا إذا كنت تستخدم ميزة MVCC التجريبية ، يعني تأمين الجدول أن هذا له تأثير مماثل في الممارسة. هناك أيضًا ميزة "mult_threaded" التجريبية ولكنها لا يمكن استخدامها في نفس وقت MVCC

8
Jack says try topanswers.xyz

نقلا عن أجزاء وقطع من موقع PostgreSQL ... يرجى ملاحظة أنني لا أملك أي فكرة على الإطلاق عن مزايا هذه الحجج - فهي لم تتناسب مع التعليق.

من المطور FAQ ("لماذا لا يتم استخدام سلاسل الرسائل ..."):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

لا يتم استخدام سلاسل الرسائل حاليًا بدلاً من عمليات متعددة للواجهة الخلفية للأسباب التالية: (...)

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

من قائمة Todo ("الميزات التي لا نريدها"):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

تعمل جميع الواجهات الخلفية كمؤشرات في عملية واحدة (غير مطلوبة)

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

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

5
Denis de Bernardy