🌶️ 😒 🚨 نحن نختبر PostgreSQL على مصفوفة SSD RAID-0 مع جدول من 10 مليار إدخال. (الجزء 1) 🎅🏾 👩‍❤️‍💋‍👨 ✝️

أثناء تطوير الخدمة لتحسين تكلفة الاتصالات الخلوية د. التعرفة ( iOS ، Android ) لتجربة مشتركة مع أحد الشركاء كنا بحاجة إلى قاعدة بيانات علائقية كبيرة ومنتجة.

من الواضح أن أداء القرص الصلب لم يكن كافياً. كان من المفترض أن يكون حجم قاعدة البيانات عدة مئات غيغابايت ، لذلك فإن وضعها في ذاكرة الوصول العشوائي سيكون مكلفًا للغاية. يعتبر SSD هو الأنسب لهذه المهمة. ولكن قد لا يكون محرك أقراص SSD واحدًا كافيًا ، لذلك تقرر تجميع مجموعة RAID-0 من محركي أقراص. اغتنام هذه الفرصة ، قررنا إجراء اختبار أداء PostgreSQL على قرص واحد واثنين من أقراص SSD.

الأهداف الرئيسية للاختبار

1. قارن أداء PostgreSQL على صفيف SSD RAID-0 بالأداء على SSD واحد.
2. لدراسة أداء العمليات الأساسية (SELECT و UPDATE) اعتمادًا على حجم الجدول وعدد الاتصالات وإعدادات الخادم وغيرها من المعلمات.

تم إجراء الاختبار في العديد من التكرارات. لكل جزء ، تقرر كتابة مقالة مفصلة مع التقارير:

اختبار محرك أقراص SSD واحد
اختبار مجموعة RAID-0 من محركي أقراص SSD
تأثير إعدادات الخادم على أداء قاعدة البيانات
مقارنة SSD مع HDD

الجزء الحديدي

تم إجراء جميع الاختبارات في التكوين التالي:

انتل i7 4770.
16 جيجا بايت رام.
إنتل SSD لمحرك النظام.
سلسلة Intel SSD 480 Gb 530 لمحرك الأقراص بقاعدة بيانات. الطراز - SSDSC2BW480A401
توشيبا HDD 3000 جيجابايت. نموذج - DT01ACA300
نظام الملفات لجميع الأقسام هو Ext4. يتم توصيل الأقراص عبر SATA 3.

ناعم

يتم تثبيت نظام التشغيل Linux Mint 17.2 على كمبيوتر الاختبار. إصدار PostgreSQL هو "PostgreSQL 9.4.4 على x86_64-unknown-linux-gnu ، تم تجميعه بواسطة gcc (Ubuntu / Linaro 4.6.3-1ubuntu5) 4.6.3 ، 64 بت"

بعد التنسيق على SSD ، يتوفر 440 جيجابايت. يوضح الرسم البياني أدناه أداء محرك أقراص SSD واحد.

قراءة وكتابة أداء حوالي 500 ميجا بايت / ثانية ، الاختناق هو واجهة SATA.

إعدادات Postgres قياسية باستثناء المعلمات التالية:
Shared_buffers = 2048 Mb
port = 5400
max_connections = 1000

اختبارات

كانت هناك 3 خيارات كمصدر تحميل:

pg_bench قياسي
عميل Python مع Psycopg2
عميل Python مع SQLAlchemy

أظهرت اختبارات pgBench الأولى أداءً جيدًا ، لكنها عملت على جداول تم إنشاؤها حديثًا. أردنا أن يكون الاختبار قريبًا من الظروف الحقيقية قدر الإمكان. بالطبع ، يمكنك كتابة نص الاختبار الخاص بك ، لكن Python كان مفضلاً على العميل.

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

عند اختبار عميل Psycopg2 ، كان استهلاك المعالج حوالي 15 ٪ ، وهو أمر مقبول تمامًا للاختبار ، نظرًا لأن النظام الفرعي للقرص كان عنق الزجاجة في معظم الحالات. تم إجراء جميع الاختبارات الإضافية باستخدام عميل Python مع Psycopg2. تم إنشاء عملية Python منفصلة لكل اتصال قاعدة بيانات.

نمط الاختبار:

CREATE TABLE numbers
(
"number" bigserial NOT NULL,
operator smallint,
region smallint,
CONSTRAINT numbers_pkey PRIMARY KEY (number)
)

لاختبار القراءة ، تم استخدام الأمر:

'SELECT * FROM numbers WHERE number=%d'

تم اختيار الرقم بشكل عشوائي.

لاختبار السجل ، تم استخدام الأمر:

'UPDATE numbers set region=%d, operator=%d WHERE number=%d'

جميع المعلمات عشوائية من نطاقات صالحة. يقرأ UPDATE ويكتب البيانات على القرص دون تغيير حجم قاعدة البيانات ، لذلك تقرر استخدامها لتحميل كتابة معقد. لم يتم استخدام INSERT و DELETE أثناء الاختبار. استغرق كل اختبار فردي عدة دقائق. تم إجراء اختبارات منفصلة عدة مرات ، وتزامن الأداء الناتج مع دقة حوالي 1 ٪.

لإنشاء صفيف RAID-0 ، تم استخدام mdadm . تم إنشاء RAID باستخدام القرص بأكمله ، وليس عبر أقسام.

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

تم إجراء الاختبار على قرص SSD واحد مباشرة بعد ملء قاعدة البيانات. حجم الجدول 1 مليار سجل. على القرص ، احتلت الطاولة 42 جيجا بايت و 21 جيجا بايت لكل فهرس. الاختناق هو النظام الفرعي للقرص. دعنا نفكر في كيفية تغير أداء قاعدة البيانات اعتمادًا على عدد الاتصالات النشطة.

حدد الأداء

في البداية ، ينمو الأداء بالتساوي وفقًا لعدد الاتصالات. بدءًا من ما يقرب من 16 اتصالًا ، يستقر الأداء العام من خلال دعم القرص.

تحديث الأداء

عند تحديث السجلات ، تكون الصورة متشابهة. مع 16 مستخدمًا ، يستقر الأداء. عنق الزجاجة هو القرص.

يستخدم PostgreSQL MVCC لتوفير ACID . يوضح هذا ، على وجه الخصوص ، أنه عند تغيير قيمة عمود واحد في الجدول بأكمله ، يتغير حجم هذا الجدول بحوالي مرتين.

بعد تحديث العديد من السجلات في الجدول والفهارس ، كان هناك العديد من السجلات الميتة ، مما يؤثر على الأداء. فكر في كيفية تأثير ذلك على أداء القراءة.

كما ترى ، انخفض أداء القراءة بنسبة 15-20٪. كما زادت القاعدة قليلاً في الحجم. لزيادة الإنتاجية وتحرير المساحة ، يلزم الأمر VACUUM. هذا السؤال خارج نطاق المقال ؛ يمكن العثور على مزيد من التفاصيل حوله في الوثائق .

بعد كل الاختبارات وإيقاف PostgreSQL ، قررنا تكرار الاختبار لسرعة القراءة من القرص.

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

ملخص

من هذه الاختبارات يمكن ملاحظة أن قاعدة البيانات تعمل بشكل جيد على محرك أقراص SSD مع عدد الإدخالات في الجدول حتى 1 مليار.
كانت النتيجة السارة هي أن أداء قاعدة البيانات لم ينخفض عمليا حتى مع 980 اتصال نشط. على الأرجح ، سوف تستهلك العديد من الاتصالات النشطة المزيد من ذاكرة الوصول العشوائي والمعالج ، والاختناق مع عدد الاتصالات أقل من ألف هو النظام الفرعي للقرص ، ولكن هذا هو موضوع مقالة منفصلة.

ستقوم المقالة التالية باختبار أداء قاعدة البيانات على RAID-0 SSD وسيتم زيادة حجم الجدول إلى 10 مليار إدخال.

حسنًا ، الدكتور التعرفة على Android و iOS .

مقالات أخرى عن د. تحليلات خدمات التعريفة والخدمات الخلوية من مدونتنا

Dr. Tariff 4G ( 2)
Dr. Tariff 4G ( 1)
! — « !», « +», « +» ( )
, Dr. Tariff ( )
Dr. Tariff 2.0: ,
? Dr. Tariff
Dr. Tariff (3 ) — 80 Android iOS
Dr. Tariff ( ):

الاشتراك للحصول على الأخبار وتبادل المعلومات مع أصدقائك على فكونتاكتي و الفيسبوك .

نحن نختبر PostgreSQL على مصفوفة SSD RAID-0 مع جدول من 10 مليار إدخال. (الجزء 1)