في
الجزء الأول ، تحدثنا عن الابتكارات والتغييرات الرئيسية في PostgreSQL 11. هذه المرة ، سنناقش بمزيد من التفصيل بعض النقاط في تنسيق السؤال / الإجابة التي أثارها اللقاء.
ما هي أفضل طريقة لنقل مصفوفة بيانات كبيرة كمجموعة من معلمات الإدخال لإجراء مخزن في PL / pgSQL؟
الطريقة الأكثر ملاءمة هي إنشاء جدول مؤقت ، وعمل نسخ من البيانات هناك ، ثم استخدامه في الإجراء.
المحركات الخارجية (zheap) وتطوير PostgreSQL داخل الذاكرة
ليس لجميع أعباء العمل ، نموذج مناسب لتخزين الإصدارات القديمة من السجلات في الجدول نفسه مناسب. في كل subd أخرى (versionionniki) يتم تخزينها في سجل التراجع. يمكنك الجدال حول الجدوى ، ولكن خلاصة القول هي أنك تحتاج إلى تخزين السجلات القديمة في مكان ما. إذا كان لديهم عمر قصير ونادرًا ما يخاطبهم أحدهم ، فإن التخزين في الجدول نفسه ضار. محرك zheap الخارجي PostgreSQL هو محاولة من قبل EnterpriseDB لإنشاء محرك جدول لـ PostgreSQL مع سجل التراجع. يعمل ، على الرغم من أنه لا يزال هناك شيء لتحسينه.
من يعمل مع السيدة يعرف SQL في وضع SNAPSHOT Isolation Level أنه يحتوي على tempdb ، حيث يضع إصدارات قديمة ، ومجهزًا تمامًا بفراغ بالغ لتنظيف tempdb. من ناحية أخرى ، يطلب المجتمع إنشاء جداول في الذاكرة في PostgreSQL. يمكن القيام بذلك بسهولة تامة: tmpfs ، وهذا كل ما في الأمر. في PostgreSQL Pro حتى تم إصدار أول إصدار تجريبي ، يمكنك تجربته.
ما لم يكن PostgreSQL هو محركات التوصيل. كانت هناك فهارس قابلة للتوصيل تستخدم WAL مشترك. لدى PostgreSQL الكثير لتوصيله والقليل لاستبداله بسرعة. على سبيل المثال ، لم يتم تعطيل المنفذ ، ولكن يمكنك بالفعل استخدام العقد المخصصة التي تقوم أنت ببرمجتها بنفسك. المحسنات في PostgreSQL قابلة للتوصيل بالكامل. يمكنك كتابة ما يخصك واستخدام PostgreSQL كمترجم لاستفساراتك. لا يمكن توصيل محلل SQL.
تريد المحركات الاتصال في ثلاثة اتجاهات:
- محرك مع سجل التراجع
- في الذاكرة
- تخزين الأعمدة لاستعلامات OLAP
تجري Postgres Pro محادثات مع EnterpriseDB حول كيفية إنشاء واجهة برمجة تطبيقات لربط كل هذا.
حول المفتاح الأجنبي
يتم تنفيذ المفتاح الخارجي داخل PostgreSQL بواسطة المشغلات. يمكنك كتابة المشغل الذي سينفذ أي نوع من الوظائف. يجب القيام بكل القيود الممكنة في الزناد. المنطق في المحفزات ليس ضروريًا بشكل خاص للاحتفاظ به ، ولكن تحقق من كل شيء - إنه ضروري.
هل يخطط Postgres Pro لإجراء SaaS أو PaaS؟
تخطط Postgres Pro لجعل PostgreSQL أكثر تحسينًا للسحابة ، على وجه الخصوص ، لتطبيق التغييرات الديناميكية على المخازن المؤقتة للمشاركة ، لتقليل عدد المعلمات التي تتطلب إعادة تشغيل PostgreSQL. لن يقوموا ببناء السحابة بأنفسهم.
كيف أقوم بإعداد محرك أقراص بحيث تعمل الفهرسة المتوازية بشكل أسرع؟ أيهما أفضل ، محركات أقراص صلبة متعددة أو SSD واحد؟
أفضل SSDs قليلة. كلما زادت خيارات التوازي التي توفرها الأجهزة ، كان ذلك أفضل. إذا كان لديك قرص واحد ، وليس ذاكرة كافية ومعالج واحد ، فلن يساعدك التوازي. لكن محركات الأقراص ذات الحالة الصلبة لها خصوصية: فهي تبدأ في التباطؤ إذا تم شغل أكثر من 80 ٪ من الحجم. لذلك ، لا تنس ضبط القطع ، وإلا فإن حد 80 ٪ سيأتي في مكان ما حول 50 ٪.
إدارة القاموس وإضافة الكلمات في البحث عن نص كامل
إذا كنت تستخدم الإملاء أو كرة الثلج ، فما عليك سوى تغيير قاموس الإيقاف. المشكلة هي أنه إذا أضفت كلمة توقف ، فلا فائدة من الفهرسة. يمكن القيام بذلك ببطء. سيتم إيقاف كلمة التوقف من الطلب ولن يتم البحث عنها مطلقًا. وإذا قمت بإزالة كلمة التوقف ، فلن يكون هناك أي شيء في المجموعة ولا تحتاج إلى إعادة فهرستها. المشكلة ليست في القاموس ، ولكن في حقيقة أنك استخدمته بالفعل وحفظت معرفتك.
أيضًا ، في كثير من الحالات ، يمكنك استخدام وظيفة ts_rewrite غير المعروفة ، والتي تتيح لك استبدال جزء من الطلب بطلب آخر. على سبيل المثال ، عندما غرقت غواصة كورسك ، اندفع الجميع للبحث عن معلومات عنها. عمل فيدور سيغيف في ذلك الوقت في قائمة متسللة ، وبناءً على طلب معلومات "كورسك" حول المدينة. قاموا على الفور باستبدال: في هذه الكلمة ، أعطوا معلومات حول الغواصة. ولكن بعد ذلك بدأ المستخدمون في لعنة المهتمين بالقرية نفسها. لا أعرف ما إذا كانوا قد أدركوا أم لا ، ولكن كان من الضروري تقديم "مدينة كورسك". تسمح هذه الاستبدالات بإجراء ts_rewrite. بالإضافة إلى ذلك ، يمكن استخدام الوظيفة لانتقال سلس خلال فترة تغييرات القاموس.
بالطبع ، يعد تغيير المحلل اللغوي والقواميس مهامًا معقدة. تتوافق اللغات ذات الحروف الأبجدية المختلفة ، مثل الروسية والإنجليزية ، بشكل جيد. والأسوأ من ذلك الآن ، على سبيل المثال ، النصوص الفرنسية-الإنجليزية. ليس من الواضح ما هي اللغة التي تشير إليها الكلمة ، والتي تتم كتابتها بنفس الطريقة ، ولكن في لغة ما هي كلمة توقف ، وفي لغة أخرى ليست كذلك. يعمل Postgres Pro حاليًا على تحسين القواميس لوصف تكوينات أكثر تعقيدًا.
تغطية المؤشرات والتحديث الساخن
إنه أصدقاء تمامًا. صحيح ، إذا تم تحديث حقل واحد على الأقل في فهرس التغطية ، فسيعمل المؤشر كالمعتاد ، وسيتم استبدال كل شيء.
عدم القدرة على إنشاء جداول مؤقتة عند تنفيذ الاستعلامات في وضع الاستعداد
لا يقوم PostgreSQL بتخزين معرفة الجدول في دليل النظام ، ولكن يوجد تصحيح ينقل المعرفة إلى دليل النظام. لذلك ، مع هذا التصحيح يمكنك استخدام الجداول المؤقتة. ولكن بعد ذلك تنشأ مشكلة أخرى: لا توجد معاملات على أهبة الاستعداد. للعمل مع جدول مؤقت ، سيتعين عليك استخدام ضعف معرف المعاملة الظاهري ، الذي ينطبق فقط على الجداول المؤقتة ، وليس على الجداول الرئيسية التي تأتي من المعالج. وعندما تنظر إلى رقم 32 بت ، فسيكون رقمان مختلفان.
يحتوي Postgres Pro أيضًا على وحدة pg_variables ، والتي تعمل أيضًا على أهبة الاستعداد. هذا ليس جدولًا مؤقتًا ، ولكن يمكن وصف الوظائف اللازمة.
تنفيذ فهرس الكتلة
قام Postgres Pro بعدة محاولات لتنفيذه. الآن يمكنك إدخال فهرس جدول الكتلة وسيكون الجدول بنفس الترتيب. يعاني من كيفية الحفاظ على جدول في حالة متفاوتة المسافات. لقد جربنا طرقًا مختلفة ، ولكن الإدراج دائمًا في مثل هذا الجدول كان مكلفًا للغاية. وهذا ليس مثيرًا للاهتمام لأي شخص. لذلك ، تم حتى الآن استنتاج أنه من الضروري الانتقال إلى فهرسة الجداول المنظمة.
عامل مقياس التفريغ التلقائي الموصى به
يوصى عادةً بتعيين 1 - 5٪. لكن هذا اختياري تمامًا. بالنسبة للجداول الصغيرة ، والتي على الرغم من التغييرات ، في المتوسط ، يبقى نفس التوزيع ، يمكن تعيين قيمة كبيرة. إذا كان الجدول كبيرًا ونادرًا ما يتم تجديده ، ولكن بشكل مناسب ، مع تغيير قوي في التوزيع ، سيكون عليك اختراع شيء آخر. كل هذا يتوقف على توزيع البيانات الخاصة بك.
تلميحات في استعلامات معقدة
في Oracle ، مع الاستعلامات المعقدة ، يجب عليك المساعدة بشكل دوري في التلميحات ، لأن عمليات المسح الكاملة المفاجئة تحدث. هناك تلميحات في Postgres Pro ، مزاجية للغاية ، ولكن يمكنك الحصول عليها. ومع ذلك ، لا توجد تلميحات في PostgreSQL العادية ، ومن غير المحتمل أن تظهر. إذا كانت لديك تلميحات مضمنة ، فسيواجه المستخدمون مشكلة في المُحسّن ، ثم أدخل التلميحات ، وتهدئة ولا تبلغ عن مشكلة. توقف تطوير المحسن.
بالمناسبة ، محسن PostgreSQL لديه مشكلة. عندما يقدر عينة من جدول ، حتى لو كان مبلغًا معقولًا أكثر أو أقل ، فهو يخمن بعض الأخطاء. ثم يبدأ الاتصال ، وتكون النتيجة مرتبطة بشيء آخر ، ويتراكم الخطأ ، ويفتقد PostgreSQL في المستوى الثالث أو الرابع كثيرًا.
هناك مثل هذا الإعداد - حد انهيار الانضمام. يقوم PostgreSQL بفرز JOINs لاستخدام أكثر كفاءة ، ولكن حد الفرز الافتراضي هو 8. إذا كان هناك أكثر من 8 JOINs في صف واحد ، فلن يقوم النظام بفرزها وسيكون هناك اعتماد على ترتيب JOIN في الاستعلام.
هناك أيضًا مُحسّن وراثيًا مع معلمات مختلفة. يمكنك تمكين إعدادات متنوعة في جلسة ما ، ويصف بشكل أو بآخر كيفية تنفيذ الطلب. باستخدام هذا الترتيب ، بمساعدة الأقواس ، يمكنك ضبط إيقاف تشغيل بعض العمليات ، وهو نفس الفحص بالثانية. خيار آخر هو إدراج معلمات معينة في الوظائف. بمعنى ما ، هذه أيضًا تلميحات. ليست مريحة للغاية ، ولكن على الأقل شيء.