تم اختراع Postgres Pro Standard DBMS لتقديم منتجات التطوير الخاصة بنا للمستخدمين بشكل أسرع مما يمكننا القيام به من خلال PostgreSQL. تلك الميزات التي لم يتم تضمينها بعد في PostgreSQL ، ولكنها في مسار ثابت هناك ، نحن ندرج في Postgres Pro Standard. أيضًا ، يتضمن Postgres Pro Standard بعض الإضافات التي يطلبها عملاؤنا ، ولكنها غير متوفرة في توزيع PostgreSQL القياسي.
في بعض الأحيان ، تكون هناك استثناءات في Postgres Pro Standard ، بناءً على طلب المستخدمين ولرضاهم ، يتم تضمين ميزات أقل تافهة ، وهي في مكان جيد فقط في Postgres Pro Enterprise. على وجه الخصوص ، هو PTRACK ، حول هذا الموضوع أدناه.
ليس كل شيء ، ولكن تم تطوير حصة عادلة من الامتدادات والأدوات المساعدة الإضافية المضمنة في Standard بواسطة Postgres Professional. تم اختراع وتنفيذ جميع بقع Postgres Pro بجهودنا الخاصة. لنبدأ بالتحسينات التي تتطلب التدخل في مشغل قاعدة البيانات.
يختلف Postgres Pro Standard عن PostgreSQL على مستويين: مجموعة الامتدادات والأدوات المساعدة الموجودة في التجميع ، والنواة نفسها. تم تطبيق بعض التصحيحات المفيدة على النواة التي تعمل على تحسين الأداء (على سبيل المثال ، كاشف قفل غير فرامل) والتصحيحات التي تزيد من كفاءة الأدوات المساعدة والإضافات (على سبيل المثال ، لجعل pg_probackup تعمل بكامل قوتها ، يتم تطبيق تصحيح PTRACK 2.0). يتم تقليل الاختلافات بين الإصدار الأساسي من Standard و PostgreSQL لأقصى توافق ممكن. دعنا نقول أن امتداد pg_pathman هو جزء من Standard ، ولكن يمكن تنزيله من github ، الذي تم إنشاؤه وتثبيته على فانيليا PostgreSQL ، لن تكون هناك مشاكل في التوافق.
لنبدأ بالتغييرات في النواة.
التحقق من إصدارات وحدة العناية المركزة
في PostgreSQL ، بشكل افتراضي ، يتم استخدامها لمقارنة السلاسل بمقارنتها باستخدام مكتبة C القياسية ، ولكن هناك أيضًا إمكانية استخدام مكتبة
ICU التي طورتها IBM لنفس الغرض. تعد هذه المكتبة ذات قيمة لنا في المقام الأول لأنها توفر فرزًا مستقلًا عن النظام الأساسي. لهذا السبب ، على سبيل المثال ، يتم استخدامه في 1C ، وتعمل PostgreSQL "للتجميعات الفردية" مع هذه المكتبة لفترة طويلة.
بالإضافة إلى ذلك ، تكون مقارنات السلسلة من خلال وحدة العناية المركزة في بعض الأحيان أسرع من خلال libc ، وعدد الأحرف المعروفة لها أكبر. بشكل عام ، مكتبة مفيدة. تعمل Postgres Pro Standard معها منذ الإصدار الأول (9.5). في PostgreSQL ، أصبح العمل مع ICU ممكنًا منذ الإصدار 10.
المكتبة مفيدة ، لكن عليك أن تضع في اعتبارك بعض حالات الطوارئ. لنفترض أن مستخدم نظام إدارة قواعد البيانات قد قرر ترقية نظام التشغيل. جنبا إلى جنب مع نظام التشغيل ، يمكن أيضا ترقية مكتبة وحدة العناية المركزة ، وسوف يتغير ترتيب الكلمات في الفرز. بعد ذلك ، ستصبح جميع الفهارس غير قابلة للاستخدام على الفور: نتائج البحث في الفهرس تعطي نتائج غير صحيحة. في مثل هذه الحالات ، قالت القاعدة أن إصدار وحدة العناية المركزة قد تغير وتوقف.
لكن هذا قرار صعب للغاية. بعد مناقشات ومسح للعملاء ، تقرر تخفيف السلوك. الآن فقط يتم فحص إصدارات COLLATION (قواعد الفرز). في حالة تغيير إصدارات COLLATION المستخدمة في قاعدة البيانات ، تصدر قاعدة البيانات تحذيراً عند بدء تشغيل DBMS ، لكنها لا تتوقف. كما أنه يذكر المستخدم في بداية كل جلسة.
الاستفادة المثلى من الأقفال ، وصناديق و GROUP BY
يمكن أن تضعف آلية الكشف عن حالة توقف تام الأداء. لم يعد بالإمكان استخدام المعيار القياسي: يسمح التصحيح kernel بالعمل دون الكبح. بعد إدخال تحسينات كبيرة على آلية التحقق ، لا تظهر هذه المشكلات إلا على عدد كبير من النوى والاتصالات.
تحسين تقدير عدد نتائج الوصلات في وجود مؤشرات مناسبة.
يمكنك الآن استخدام فهارس مناسبة لتجميع وفرز الحقول. تم تضمين هذه الميزة لأول مرة في المعيار 11.1.1 و Enterprise 11.2.1. لدينا معيار 12 لديها أيضا واحدة.
قدم Fedor Sigaev ، CTO من Postgres Professional ، هذه التصحيحات المفيدة للمجتمع ، ويتم النظر فيها ، ونأمل أن يتم تضمينها في الإصدار PG 13.
نوضح تحسين عملية GROUP BY بأمثلة: فهي واضحة وقابلة للتكرار بسهولة.
الهدف من هذا التصحيح هو أن بوستجرس لم يقم بتحسين ترتيب الحقول المدرجة في GROUP BY. ووقت التنفيذ يعتمد على تسلسل التجميع (مع نفس نتيجة الاستعلام). هناك تفاصيل في
المناقشة على القائمة البريدية
للمتسللين .
إذا كانت القيمة في العمود الأول المراد معالجتها فريدة ، فلا يجب مقارنة أي شيء آخر. إذا بدأت من عمود آخر ، فعليك أن تقارن.
الوصول إلى الاختبار:
DROP TABLE IF EXISTS btg; SELECT i AS id, i/2 AS p, format('%60s', i%2) AS v INTO btg FROM generate_series(1, 1000000) i;
في حقل النص v ، يتم إنشاء 60 مسافة ، متبوعة بالأرقام 0 أو 1. تبدو الإدخالات كما يلي:
SELECT * FROM btg ORDER BY id DESC LIMIT 3; id | p | v
VACUUM btg; ANALYSE btg; SET enable_hashagg=off; SET max_parallel_workers= 0; SET max_parallel_workers_per_gather = 0;
مجموعة النتائج:
VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY p, v;
خطة بوستجرس
QUERY PLAN
الآن بالترتيب العكسي: v ، وعندها فقط p:
EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p; QUERY PLAN
اتضح أن العكس هو أبطأ بشكل ملحوظ. وذلك لأن الحقل الأول
v تحليله بفارق صغير من القيم. يجب عليك إجراء الكثير من الاختبارات على الحقول المتبقية (هنا - الحقل p).
لنرى كيف سيعمل نفس الاستعلام مع تصحيح يحدد الترتيب الأمثل لمعالجة الأعمدة:
QUERY PLAN
وفي ترتيب عكسي:
QUERY PLAN
تقول الخطة أنه يوجد وهناك أمر المعالجة نفسه: Sort Key: p، v. وفقا لذلك ، فإن الوقت هو نفسه تقريبا. قارن الآن ما يحدث عند استخدام الفهرس.
CREATE INDEX ON btg(p, v); SET enable_seqscan=off; SET enable_bitmapscan=off; VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p ;
في بوستجرس
QUERY PLAN
وفي ترتيب عكسي:
QUERY PLAN
الآن في قياسي:
QUERY PLAN
وفي ترتيب عكسي:
QUERY PLAN
الوقت هو نفسه مرة أخرى ، وهو أمر طبيعي: في الواقع ، الإجراءات هي نفسها.
استبدال بايت فارغة عند التمهيد
لا يقبل Postgres Pro صفر بايت (0x00) في البيانات ، لذلك مع COPY FROM يجب استبدالها ،
وإلا سيكون هناك خطأ . هذه هي المشكلة الحقيقية التي واجهها العميل أثناء استيراد البيانات من ملف CSV. الحل الخاص به هو استبدال البايتات الفارغة بحرف ASCII المحدد. يجب أن يكون مختلفًا عن الأحرف QUOTE و DELIMITER المستخدمة عند تنفيذ COPY FROM؛ خلاف ذلك ، قد تكون النتيجة غير متوقعة. بشكل افتراضي ، قيمة المتغير nul_byte_replacement_on_import (السلسلة) '\ 0' ، أي ، لا يتم إجراء استبدال.
WaitLSN
LSN هو
رقم متسلسل في السجل ، أي مؤشر إلى موضع في WAL (رقم تسلسل السجل). ينتظر الأمر WAITLSN تشغيل LSN المحدد. إذا كان التطبيق يعمل مع كل من الرئيسي والنسخة المتماثلة ، فأنت بحاجة إلى التأكد من أنها متزامنة من وقت لآخر. WAITLSN هي آلية interprocess في PostgrePro تتحكم في المزامنة أثناء
النسخ المتماثل المتزامن . افتراضيًا ، يكون وقت الانتظار غير محدود. يمكنك إحباط الانتظار بالضغط على Ctrl + C أو إيقاف خادم postgres. يمكنك أيضًا تعيين المهلة عن طريق إضافة تلميح TIMEOUT ، أو التحقق من حالة LSN الهدف دون الانتظار باستخدام تلميح NOWAIT.
افترض أن أحد التطبيقات يقوم بإجراء معين ، ويتلقى رقم LSN من DBMS على الرئيسي ويريد الآن التأكد من أن الإجراءات الموجودة على النسخة المتماثلة ستتم مزامنتها مع الرئيسي ، أي يمكن أن يتأكد التطبيق من أن ما سجله على المعالج قد وصل بالفعل إلى النسخة المتماثلة وجاهز للقراءة. بشكل افتراضي ، هذا عادة ما يكون غير مضمون. يسمح لك WAITLSN بالتحكم في هذا التفاعل وتحديد وضع السكون من INFINITELY افتراضيًا إلى TIMEOUT و NOWAIT.
إعادة قراءة المتغيرات من recovery.conf السابق
في إشارة SIGHUP ، يعيد PostgreSQL قراءة postgresql.conf ، لكن ليس recovery.conf. تم إدخال تصحيح kernel جديد نسبيًا في Standard and Enterprise 10.4.1. اضطر إلى إعادة قراءة و recovery.conf. ولكن في Postgres 12 لا يوجد ملف recovery.conf على الإطلاق: يتم نقل جميع المتغيرات منه إلى postgresql.conf. ومع ذلك ، على الرغم من إعادة قراءة الملف بأكمله ، لم تتم إعادة تعريف المتغيرات من recovery.conf بواسطة SIGHUP ، ولكن تطلب إعادة تشغيل Postgres. في Standard ، هذا غير مطلوب: يتم قراءة كل شيء وإعادة تعريفه.
دعم PTRACK
2.0 PTRACK هي آلية PTRACK المعاد تصميمها للإصدارات القياسية والإصدارات 11 والإصدارات الأقدم. على مستوى نظام إدارة قواعد البيانات (DBMS) ، فقد نجح بفضل تصحيح kernel ، والآن تمت إضافة ملحق ptrack إلى
التصحيح . يتعقب PTRACK 2.0 تغييرات صفحة البيانات ويوفر واجهة لاسترداد هذه المعلومات. يمكن استخدامه على حد سواء لأغراض التشخيص ، على سبيل المثال ، للحصول على فكرة عن مدى قوة "تحور" المثيل بالنسبة لنقطة زمنية محددة ، وتعيين كرقم متسلسل في السجل (LSN) ، وإنشاء نسخ احتياطية تدريجية.
الجزء الأصعب و "المكلف" من إجراء النسخ الاحتياطي التزايدي ، كقاعدة عامة ، هو عزل مجموعة فرعية من الصفحات التي تم تغييرها عن مجموعة الصفحات بأكملها في مجموعة. نظرًا لحقيقة أن الخادم يمكنه القيام بهذه المهمة وتقديم معلومات حول الصفحات التي تم تغييرها بسرعة ، يتم تقليل وقت النسخ الاحتياطي التزايدي باستخدام PTRACK بشكل كبير.
يستخدم PTRACK 2.0 جدول تجزئة بحجم محدد في الذاكرة المشتركة ، متزامن بشكل دوري مع ملف ptrack.map.
نظرًا للتغير الجذري في آلية العمل الداخلية وواجهة المستخدم غير المتوافقة مع الإصدارات القديمة ، فإن امتداد ptrack متاح فقط في الإصدار الثاني عشر من PostgresPro Standard و Enterprise ، وسيكون متاحًا كتصحيح وملحق في PostgreSQL 12.
أوامر التحرير في psql لنظام التشغيل Windows
يتم تطبيق الدعم المتقدم لتحرير أوامر الإدخال في psql لنظام التشغيل Windows باستخدام WinEditLine. يمكنك الآن عرض أحرف الحروف الهجائية المختلفة في وقت واحد (على وجه الخصوص ، يتم عرض السيريلية عادة على نظام Windows غير الروسي).
هيكل حزمة موحدة
هيكل حزم الحزم الثنائية لجميع توزيعات Linux هو موحد من أجل تبسيط الترحيل بينها والسماح بتثبيت العديد من المنتجات المستندة إلى PostgreSQL معًا دون أي تعارض. يمكن العثور على هذا في
الفصل 16 من الوثائق.
الآن عن الإضافات:
dump_stat
بدا في وقت مبكر 9.5. عند نقل البيانات أو استعادتها ، لا يتم عادة نقل الإحصاءات المتراكمة. إذا قمت بإعادة تجميعها باستخدام أمر ANALYZE ، فسيتم تنفيذها لكامل المجموعة ، وليس لقاعدة البيانات المحددة. قد يتطلب هذا الكثير من الوقت الإضافي لقواعد البيانات الكبيرة.
يوفر ملحق dump_stat
الوظائف التي تتيح لك إلغاء تحميل واستعادة محتويات الجدول pg_statistic. عند إجراء تحميل / استرداد البيانات ، يمكنك استخدام dump_stat لنقل الإحصاءات الموجودة إلى خادم جديد ، دون الحاجة إلى تشغيل الأمر ANALYZE للمجموعة بأكملها.
تفريغ الدالة dump_statistic محتويات كتالوج النظام pg_statistic. ينتج INSERT لكل tuple باللغة pg_statistic ، باستثناء تلك التي تحتوي على إحصائيات حول الجداول في مخططات information_schema و pg_catalog.
jsquery
تذكر أن
هذا امتداد للعمل مع JSON (B) ، وليس JS. يوفر مجموعة من الوظائف لمعالجة أنواع البيانات هذه. هذه لغة استعلام خاصة من أجل الكفاءة ، باستخدام الفهارس ، البحث في JSON (B). في
المقالة على المحور ، يمكنك رؤية بعض الأمثلة على jsquery والأساليب البديلة للعمل مع JSON (B) ، على سبيل المثال JSONPath (كلاهما لتطوير شركتنا).
online_analyze
يوفر هذا الملحق مجموعة من الوظائف التي تقوم على الفور بتحديث الإحصاءات في الجداول المحددة بعد عمليات INSERT أو UPDATE أو DELETE أو SELECT INTO فيها. مؤلف التمديد هو فيدور سيغايف.
لاستخدام الوحدة النمطية عبر الإنترنت ، يجب عليك تحميل المكتبة المشتركة:
LOAD 'online_analyze';
إحصائيات التحديثات يمكن تخصيصها. على سبيل المثال ، قم بتعيين نسبة مئوية من حجم الجدول أو الحد الأدنى (الحد الأدنى) لتغييرات الصف ، وبعد ذلك سيتم جمع الإحصائيات على الفور.
pg_pathman
تم
إنشاء ملحق pg_pathman في Postgres Professional في وقت أبكر من PostgreSQL kernel ونفذ مجموعة كاملة تمامًا من الوظائف لإنشاء أقسام. لذلك ، يمكن إجراء العديد من العمليات مع الأقسام مع كل من والآلية الأخرى. من المستحسن فقط عدم خلط المقاطع التي تم إنشاؤها بواسطة التقسيم التعريفي و pg_pathman.
ومع ذلك ، لا تزال العديد من عمليات pg_pathman أسرع وبعض الميزات مفقودة في PostgreSQL. على سبيل المثال ، الإنشاء التلقائي (القطع) للأقسام. في PostgreSQL ، تحتاج إلى تعيين حدود كل قسم. إذا قمنا بملء البيانات التي لا يُعرف عنها مسبقًا عدد الأقسام التي يمكن وما ينبغي أن تكون مبعثرة ، فمن المناسب تعيين الفاصل الزمني ببساطة والسماح للبرنامج بقطع المقاطع بنفسه - حسب الحاجة. pg_pathman يعرف كيف ، PostgreSQL لا. ولكن ، بدءًا من PG 11 ، يوجد قسم افتراضي (افتراضي) ، حيث يمكنك تفريغ جميع السجلات التي لا تندرج في أقسام ذات حدود محددة.
هناك اتفاق أساسي مع قادة مجتمع PostgreSQL وهو الأفضل في المستقبل ، في حين أن الميزات الفريدة لـ pg_pathman ستندرج في الفرع الرئيسي. ولكن حتى ذلك الوقت ، يمكن أن تجعل pg_pathman الحياة أسهل لمسؤولي DB للتطبيق ومبرمجي التطبيقات.
إنشاء ملحق:
CREATE EXTENSION pg_pathman;
يسمح لك pg_pathman بتقسيم الجداول الكبيرة إلى أقسام ويوفر واجهة برمجة تطبيقات ملائمة - مجموعة من الوظائف لإنشاء أقسام والعمل معها. على سبيل المثال ، باستخدام الوظيفة
create_range_partitions(relation REGCLASS, expression TEXT, start_value ANYELEMENT, p_interval INTERVAL, p_count INTEGER DEFAULT NULL, partition_data BOOLEAN DEFAULT TRUE);
يمكننا أن نسأل
SELECT create_range_partitions('log', 'dt', NULL::date, '1 month'::interval);
بعد ذلك نضيف أقسام:
SELECT add_range_partition('log', NULL, '2017-01-01'::date, 'log_archive', 'ts0'); SELECT add_range_partition('log', '2017-01-01'::date, '2017-02-01'::date, 'log_1'); SELECT add_range_partition('log', '2017-02-01'::date, '2017-03-01'::date', log_2');
سيتم إنشاء سجل الأرشيف في مساحة الجدول ts0 ، والباقي بشكل افتراضي. لكن لا يمكنك تحديد المقاطع بشكل صريح ، ولكن يمكنك الوثوق بعملية DBMS هذه عن طريق تعيين الفاصل الزمني وإنشاء أقسام في خطوة واحدة:
SELECT create_range_partitions('log', 'dt', '2017-01-01'::date, '1 month'::interval);
على طاولة بسيطة ، سيبدو كما يلي:
CREATE TABLE pg_pathmania(id serial, val float); INSERT INTO pg_pathmania(val) SELECT random() * 1000 FROM generate_series(1, 1000); SELECT create_range_partitions('pg_pathmania', 'id', 0, 50); test_parti=# \d+ pg_pathmania Table "public.pg_pathmania" Column | Type | Collation | Nullable | Default | Storage | S tats target | Description
في PostgreSQL ، سيتعين علينا إنشاء كل قسم مع فريقنا الخاص. في مثل هذه الحالات ، وبطبيعة الحال ، يكتبون النصي الذي يولد رمز DDL المطلوب تلقائيا. لا تحتاج إلى كتابة البرامج النصية في pg_pathman ، كل شيء موجود بالفعل. ولكن هذا ليس هو الأكثر إثارة للاهتمام. سنقوم بإدراج سجل لا يقتصر فقط على معرفته في أي من الأقسام الحالية ، ولكنه لا يقع في أقرب قسم:
INSERT INTO pg_pathmania(id, val) VALUES (2000, 277.835794724524);
مرة أخرى ، تحقق من محتويات الجدول باستخدام \ d + pg_pathmania:
Child tables: pg_pathmania_1, pg_pathmania_10, ... pg_pathmania_39, pg_pathmania_4, pg_pathmania_40, pg_pathmania_41,
إليك ما حدث: رأى pg_pathman أن السجل ذي المعرف = 2000 لا يقع في الأقسام التي تم إنشاؤها بالفعل ، وحساب عدد ما يحتاجون إلى إنشائه ، ومعرفة الفاصل الزمني لـ RANGE الذي تم تقسيم الجدول من قبل إليه ، وإنشاء القسم الذي يقع فيه السجل الجديد ، وبالطبع ، جميع المقاطع بين الحد الأعلى للأقسام القديمة والحد الأدنى للقسم الجديد. هذا أمر مريح للغاية ، وفي الحالات التي يتم فيها التنبؤ بقيم مجال تقسيم البيانات المحدّثة بشكل سيء ، فهذه ميزة كبيرة لـ pg_pathman.
pg_query_state
يتيح لنا هذا الامتداد الذي قمنا بتطويره
معرفة الحالة الحالية للطلبات في عملية التقديم. لقد كان موجودًا منذ الإصدار 9.5 ويرجع تاريخ ميلاد العديد من طلبات مشرفي العملاء.
الحقيقة هي أن EXPLAIN ANALYZE يسمح لك بمشاهدة إحصائيات التنفيذ التي تم جمعها من كل عقدة من شجرة الخطة ، ولكن يتم جمع هذه الإحصائيات فقط بعد اكتمال الاستعلام. ولكن في الحياة ، للأسف ، هناك حالات تحتاج فيها إلى النظر في ما لم يكتمل الطلب بعد وربما لن ينتهي. يسمح لك pg_query_state بعرض الإحصاءات الحالية للاستعلام الجاري تشغيله في عملية صيانة خارجية. في هذه الحالة ، يكون تنسيق الإخراج الناتج مطابقًا تقريبًا لإخراج الأمر EXPLAIN ANALYZE المعتاد.
المرافق:
pgBouncer
هذا هو مجتذب اتصال شعبية أنه سيكون من الغريب أن نتحدث عن ذلك هنا. إنه مجرد جزء من Standard ، ويجب تثبيته بشكل منفصل في حالة الفانيليا PostgreSQL.
pg_probackup
pg_probackup هي واحدة من التطورات الأكثر شعبية لدينا. هذا هو مدير النسخ الاحتياطي والاسترداد التي يتم تطويرها وتحديثها في المقام الأول عن طريق Anastasia Lubennikova ، Grigory Smolkin ومجتمع المستخدمين.
المزايا التنافسية لـ pg_probackup: النسخ الاحتياطي التزايدي مع كتلة التحبب (8 كيلو بايت) ، ثلاثة أوضاع نسخ احتياطي تزايدي (PAGE ، DELTA ، PTRACK) ، التحقق من تكامل النسخ الاحتياطي عند الطلب ، التحقق من نظام PostgreSQL ، التحقق من النسخ الاحتياطي ، الاسترداد الجزئي ، إلخ.
أصبح وضع النسخ التراكمي PTRACK ، بالاعتماد على
الامتداد الذي يحمل نفس الاسم كجزء من الآلية المعاد تصميمها - PTRACK 2.0 - أسرع وأصبح الآن بشكل لا لبس فيه أسرع وأرخص أوضاع pg_probackup.
pg_repack
pg_repack هي أداة مساعدة شائعة ، ويشبه تشغيلها VACUUM FULL أو
CLUSTER . ليس فقط إعادة حزم الجداول ، وإزالة الفراغات ، ولكن يعرف أيضًا كيفية استعادة الترتيب الفعلي للفهارس المجمعة. على عكس CLUSTER و VACUUM FULL ، فإنه ينفذ هذه العمليات "أثناء التنقل" ، دون استخدام أقفال الطاولة الحصرية والعمل بشكل عام بكفاءة. لا يتم تضمينه في إصدار الفانيليا.
pg_variables
حول هذا التمديد على هابر هناك
مقالة مثيرة للاهتمام
من موظفنا إيفان فرولكوف. سبب التمديد هو أن العمل مع النتائج المتوسطة يكون أحيانًا غير مريح ومكلف. يستكشف المقال البدائل. الأكثر شيوعا من هذه الجداول المؤقتة.
كمستودع مؤقت للبيانات ، يكون امتداد pg_variables أكثر إنتاجية من الجداول المؤقتة (اختبارات pgbench موجودة في المقالة) ، وهي أكثر ملاءمة: يتم تعريف مجموعة البيانات بواسطة زوج متغير الحزمة ، والذي يمكن تمريره كمعلمات ، يتم إرجاعه من دالة ، إلخ. هناك مجموعة / الحصول على وظائف للعمل مع المتغيرات. لذلك ، على سبيل المثال ، يمكنك تخزين العديد من المتغيرات (الحزمة هي اسم الحزمة ، والتعبير بعد العلامة العشرية هو المتغيرات في هذه الحزمة:
SELECT pgv_set_int('package','#'||n,n), n FROM generate_series(1,1000000) AS gs(n);
تحتوي المتغيرات على خاصية مثيرة للاهتمام: ليس خطأ أو ميزة ، ولكن ميزة: البيانات المخزنة بواسطة الامتداد تعني وجود خارج المعاملات - يتم حفظها في حالة إصلاح معاملة وفي حالة الاستعادة ؛ علاوة على ذلك ، حتى عند تنفيذ أمر منفصل ، يمكن الحصول على بيانات جزئية:
SELECT pgv_insert('package', 'errs', row(n)) FROM generate_series(1,5) AS gs(n) WHERE 1.0/(n-3)<>0; ERROR: there is a record in the variable "errs" with same key test_parti=# SELECT * FROM pgv_select('package','errs') AS r(i int); i
من ناحية ، هذا ليس مناسبًا للغاية - في بعض الحالات ، من الضروري توفير حذف البيانات التي تم إدخالها بشكل غير صحيح ، ولكن في حالات أخرى ، قد يكون ذلك مفيدًا للغاية - على سبيل المثال ، حفظ بعض البيانات حتى في حالة التراجع عن المعاملة.
الوثائق لديها تفاصيل.
في الختام ، عدد قليل من الملحقات الإضافية:
sr_plan ، plantuner
sr_plan يحفظ ويستعيد خطط الاستعلام. ضمّنها مثل هذا:
SET sr_plan.write_mode = true;
بعد ذلك ، سيتم تخزين خطط جميع الاستعلامات اللاحقة في جدول sr_plans حتى يتم تعيين هذا المتغير على "خطأ". يتم حفظ خطط جميع الطلبات ، بما في ذلك الطلبات المتكررة.
تدعم أداة plantuner تلميحات لجدولة الاتصال أو فصل المؤشرات المحددة عند تنفيذ استعلام. لا يوجد سوى اثنين من متغيرات GUC: enable_index / desable_index:
SET plantuner.disable_index='id_idx2';
ملحقات للبحث عن النص الكامل: shared_ispell ، pg_tsparser
ملحق Shared_ispell ، الذي يسمح لك بوضع
القواميس في الذاكرة المشتركة ، موجود في Standard وليس في PostgreSQL. تحتوي مجموعة hunspell-dict على قواميس للغات:
- hunspell_en_us،
- hunspell_fr،
- hunspell_nl_nl،
- hunspell_ru_ru
ملحق pg_tsparser هو
محلل بحث عن نص
بديل . يغير هذا الامتداد إستراتيجية تحليل النص القياسي للكلمات التي تتضمن شرطات سفلية ، وكذلك الأرقام والحروف مفصولة بالشرطات السفلية. بالإضافة إلى الأجزاء الفردية للكلمة التي يتم إرجاعها افتراضيًا ، تُرجع pg_tsparser أيضًا الكلمة بأكملها. يعد هذا الأمر مهمًا جدًا للوثائق الفنية أو المقالات مثل هذا المقال ، حيث يتم العثور على رمز البرنامج ، وفيه توجد كلمات مثل "pg_tsparser" ، "pg_probackup" ، "jsonb_build_object". لا ينظر هذا المحلل اللغوي إلى هذه الكلمات فقط كمجموعة من المكونات ، ولكن أيضًا كرمز مميز واحد ، وبالتالي يحسن جودة البحث.
ملحقات ل 1 C
- mchar هو نوع بيانات اختياري للتوافق مع Microsoft SQL Server؛
- fulleq - يوفر عامل تكافؤ إضافي للتوافق مع Microsoft SQL Server ؛
- fasttrun - يوفر وظيفة غير آمنة للمعاملات لاقتطاع الجداول المؤقتة ، مما يمنع دليل pg_class من النمو.
هذا يختتم هذا الاستعراض القصير ، ولكن ليس الفرق بين PostgresPro Standard و PostgreSQL. ذكرنا الإصدارات الرئيسية ، ولكن يمكنك مقارنة الإصدارات بالتفصيل من خلال البدء ، على سبيل المثال ، من هذه الصفحة .