هل POSIX غير مناسب فعلاً لمخازن الكائنات؟ إجابة مدعومة بالبيانات

مؤلف هذا المنشور يشكك في المنظور المقدم في مقال MinIO، الذي يقترح أن POSIX ليس مناسبًا لمخازن الكائنات. لقد أجرى اختبارات شاملة تشمل MinIO s3fs-fuse و JuiceFS. أظهرت النتائج أن MinIO و JuiceFS يوفران أداءً ممتازًا بينما كان s3fs-fuse يتخلف. في سيناريو تجديد الملفات الصغيرة، يتفوق JuiceFS FUSE-POSIX على الحلول الأخرى.

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

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

العديد من المنتجات في الصناعة، مثل Ceph و JuiceFS و Weka، نجحت في تنفيذ واجهات POSIX على مستودعات الكائنات. تتمتع هذه الحلول بقاعدة أساتذة كبيرة وقصص نجاح كثيرة، وتؤدي بشكل جيد من حيث الأداء.

على الرغم من أن POSIX لديه مجموعة من التعقيدات الكبيرة، إلا أن المشاكل المرتبطة ليست لا مفر منها. باحترام ورغبة في التحقق من هذه المطالبات، قمت بإعداد بيئة تجريبية، استخدمت نفس بيانات العينة وطرق الاختبار كما في مقال MinIO، وأجريت تحقيق.

مقارنة المنتجات وأهداف الاختبار

لتقديم تقييم شامل، قمت بتقديم JuiceFS في المقارنة.

JuiceFS هو نظام أساسي للملفات مفتوح المصدر وموجه للغرض المختلف عن أدوات مثل s3fs-fuse، التي تحول ببساطة من تخزين الكائنات إلى بروتوكولات POSIX.

عن طريق إدخال JuiceFS في المقارنة، كان الهدف هو تقييم موضوعي للإيجابيات والسلبيات في تنفيذ بروتوكولات مثل POSIX فوق تخزين الكائنات.

I conducted the following two tests on MinIO, JuiceFS, and s3fs-fuse:

• كتابة ملف 10 جيجابايت
• إعادة كتابة ملفات صغيرة مع Pandas

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

تأتي جميع البيئات، والبرامج النصية، والبرامج، والبيانات العينة في هذا المقال مع الكود الكامل والتعليمات للتأكد من أنه يمكنك تكرار البيئة ونتائج الاختبار.

إعداد الخادم وبيئة الاختبار

خوادم الغرض المزدوجة المتكافئة:

• نظام: Ubuntu 22.04 x64
• معالج: 8 أجواء
• ذاكرة الوصول العشوائي: 16 جيجابايت
• الأقراص الصلبة: 500 جيجابايت
• الشبكة: VPC

المعلومات لكل خادم:

إعداد خادم A

1. قمت بتنفيذ MinIO على الخادم A باستخدام Docker باتباع الأوامر التالية:

# انشاء دليل مخصص والانتقال إليه.
mkdir minio && cd minio

# انشاء ملف تكوين.
mkdir config
touch config/minio

2. كتبت المعلومات التالية إلى ملف config/minio:

MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=abc123abc
MINIO_VOLUMES="/mnt/data"

3. قمت بإنشاء حاوية MinIO:

sudo docker run -d --name minio \
  -p 9000:9000 \
  -p 9090:9090 \
  -v /mnt/minio-data:/mnt/data \
  -v ./config/minio:/etc/config.env \
  -e "MINIO_CONFIG_ENV_FILE=/etc/config.env" \
  --restart unless-stopped \
  minio/minio server --console-address ":9090"

4. على وحدة التحكم الويب لـ MinIO، أنشأت ثلاثة اسطوانات مسبقة:

إعداد الخادم B

1. قمت بتنزيل ملف العينة الاختبارية البالغ 10 جيجابايت.

curl -LO https://data.cityofnewyork.us/api/views/t29m-gskq/rows.csv?accessType=DOWNLOAD

2. قمت بتثبيت عميل mc.

mc هو مدير ملفات سطر الأوامر تم تطويره من قبل مشروع MinIO. يسمح بعمليات القراءة والكتابة على التخزين المحلي والتخزين الشامل متوافق مع S3 في سطر الأوامر في Linux. توفر الأمر mc cp تحديثات التقدم والسرعة في الوقت الحقيقي أثناء نسخ البيانات، مما يسهم في مراقبة الاختبارات المختلفة.

ملاحظة: للحفاظ على عدل الاختبار، استخدمت جميع الطرق الثلاثة mc لاختبارات كتابة الملفات.

# تنزيل mc.
wget https://dl.min.io/client/mc/release/linux-amd64/mc

# فحص إصدار mc.
mc -v
mc version RELEASE.2023-09-20T15-22-31Z (commit-id=38b8665e9e8649f98e6162bdb5163172e6ecc187)
Runtime: go1.21.1 linux/amd64

# تثبيت mc.
sudo install mc /usr/bin

# تعيين اسم مستعار لـ MinIO.
mc alias set my http://172.16.254.18:9000 admin abc123abc

3. قمت بتنزيل s3fs-fuse.

sudo apt install s3fs

# فحص الإصدار.
s3fs --version
Amazon Simple Storage Service File System V1.93 (commit:unknown) with OpenSSL

# تعيين مفتاح كتابة التخزين الشامل.
echo admin:abc123abc >  ~/.passwd-s3fs

# تعديل أذونات ملف المفتاح.
chmod 600  ~/.passwd-s3fs

# انشاء دليل التوصيل.
mkdir mnt-s3fs

# توصيل التخزين الشامل.
s3fs test-s3fs:/ /root/mnt-s3fs -o url=http://172.16.254.18:9000 -o use_path_request_style

4. قمت بتثبيت JuiceFS.

I used the official script to install the latest JuiceFS Community Edition.

# سطر برمجة واحدة للتثبيت
curl -sSL https://d.juicefs.com/install | sh -

# فحص الإصدار.
juicefs version
juicefs version 1.1.0+2023-09-04.08c4ae6

5. قمت بإنشاء نظام ملفات. JuiceFS هو نظام ملفات يجب إنشاؤه قبل الاستخدام. بالإضافة إلى تخزين الكائنات، يتطلب قاعدة بيانات كمحرك بيانات الوصول. يدعم مختلف القواعد البيانات. هنا، استخدمت Redis الشائعة كمحرك بيانات الوصول.

ملاحظة: لقد قمت بتثبيت Redis على الخادم A، يمكن الوصول إليه عبر 172.16.254.18:6379 بدون كلمة مرور. يتم حذف إجراء التثبيت هنا. يمكنك الرجوع إلى وثائق Redis للتفاصيل.

# إنشاء نظام الملفات.
juicefs format --storage minio \
--bucket http://172.16.254.18:9000/test-juicefs \
--access-key admin \
--secret-key abc123abc \
--trash-days 0 \
redis://172.16.254.18/1 \
myjfs

6. لقد وصلت إلى JuiceFS باستخدام طرق POSIX وواجهة برمجة التطبيقات S3 الأكثر شيوعًا واختبرت أدائهم.

# إنشاء مجلدات التثبيت.
mkdir ~/mnt-juicefs

# تثبيت نظام الملفات بوضع POSIX.
juicefs mount redis://172.16.254.18/1 /root/mnt-juicefs

# الوصول إلى نظام الملفات باستخدام طريقة S3 API.
export MINIO_ROOT_USER=admin
export MINIO_ROOT_PASSWORD=abc123abc
juicefs gateway redis://172.16.254.18/1 0.0.0.0:9000

# تعيين اسم مستعار لواجهة برمجة التطبيقات S3 API لـ JuiceFS في mc.
mc alias set juicefs http://172.16.254.18:9000 admin abc123abc

ملاحظة: يمكن نشر بوابة JuiceFS أيضًا على الخادم A أو أي خادم آخر يمكن الوصول إليه عبر الإنترنت حيث تقدم واجهة برمجة التطبيقات S3 يقع على الشبكة.

الاختبارات والنتائج

إليكم ملخص سريع لاختباراتي ونتائجي:

اختبار 1: كتابة ملف 10 جيجا بايت

تم تصميم هذا الاختبار لتقييم أداء كتابة ملفات كبيرة. كلما قل الوقت المستغرق، كان الأداء أفضل. استخدمت الأمر time لقياس مدة العمليات الكتابة، مع إعطاء ثلاثة إحصائيات:

• real: الوقت الفعلي من بداية الأمر حتى نهايته. يشمل جميع فترات الانتظار، مثل انتظار اكتمال عمليات I/O، انتظار تبديل العمليات، والانتظار على الموارد.
• user: الوقت المنفذ في وضع المستخدم، ممثلاً الوقت المستخدم من المعالج لتنفيذ الشفرة المستخدم. عادةً ما يمثل العبء الحسابي للأمر.
• sys: الوقت المنفذ في وضع النواة، ممثلاً الوقت المستخدم من المعالج لتنفيذ شفرة النواة. عادةً ما يمثل العبء المتعلق بالمكالمات النظام، مثل عمليات I/O الملف وإدارة العمليات.

MinIO

I ran the following command to perform a copy test:

time mc cp ./2018_Yellow_Taxi_Trip_Data.csv  my/test-minio/

نتائج كتابة ملف 10 جيجا بايت مباشرة إلى MinIO:

real    0m27.651s
user    0m10.767s
sys 0m5.439s

s3fs-fuse

I ran the following command to perform a copy test:

time mc cp ./2018_Yellow_Taxi_Trip_Data.csv /root/mnt-s3fs/

نتائج كتابة ملف 10 جيجا بايت مباشرة إلى s3fs-fuse:

real 3m6.380s
user 0m0.012s
sys 0m5.459s

ملاحظة: على الرغم من أن وقت الكتابة كان 3 دقائق و 6 ثوان لـ s3fs-fuse، لم يكن هناك أي فشل في الكتابة كما ورد في مقال MinIO.

JuiceFS

I tested the performance of JuiceFS for large file writes using both the POSIX and S3 API methods:

# اختبار كتابة POSIX
time mc cp ./2018_Yellow_Taxi_Trip_Data.csv /root/mnt-juicefs/

# اختبار كتابة API S3
time mc cp ./2018_Yellow_Taxi_Trip_Data.csv  juicefs/myjfs/

نتائج كتابة ملف 10 جيجا بايت باستخدام JuiceFS POSIX:

real    0m28.107s
user    0m0.292s
sys 0m6.930s

نتائج كتابة ملف 10 جيجا بايت باستخدام API S3 لـ JuiceFS:

real    0m28.091s
user    0m13.643s
sys 0m4.142s

ملخص نتائج كتابة ملف كبير

الشكل التالي يظهر نتائج الاختبار:

تظهر نتائج الاختبار أن الكتابة المباشرة إلى MinIO وJuiceFS أعطت أداءً متشابهًا، حيث أكملت المهمة خلال حوالي 30 ثانية. ومن ناحية أخرى، استغرق s3fs-fuse أكثر من 3 دقائق لكتابة ملف 10 جيجا بايت، وهو أبطأ بمقدار حوالي ستة أضعاف من الاثنين الآخرين.

عند كتابة ملفات كبيرة، mc يستخدم واجهة برمجة التطبيقات (API) المتعددة الأجزاء لتحميل الملفات في أجزاء إلى واجهة S3. وعلى العكس من ذلك، s3fs-fuse يمكنه فقط كتابة إلى POSIX بواسطة تر thread. يقوم JuiceFS أيضًا تلقائيًا بتقسيم الملفات الكبيرة إلى أجزاء وكتابتها بشكل متوازي إلى MinIO أثناء الكتابة التسلسلية، مما يضمن أداء متناه مع الكتابة المباشرة إلى MinIO. من ناحية أخرى، يكتب S3FS أولاً إلى قرص ذاكرة مخزنة مؤقتة بواسطة تر thread وفيما بعد يقوم بتحميل الملف في أجزاء إلى MinIO، مما يؤدي إلى مدة كتابة أطول.

بناءً على الحساب الذي استغرق 30 ثانية لكتابة ملف 10 جيجا بايت، كانت السرعة المتوسطة 333 ميغا بايت/ثانية. كان هذا مقيدًا بتوافر شريط الترددات لأجهزة SSD السحابية. أظهرت نتائج هذه الاختبارات أن كل من MinIO وJuiceFS يمكنهما تحقيق أقصى قدر من شريط الترددات للSSD المحلي، وسيتحسن أداؤهما مع تطور أقراص السحابة الخادم وشريط الترددات الشبكي.

الاختبار 2: إعادة كتابة ملفات صغيرة باستخدام Pandas

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

MinIO

I got the test script and ran the test:

# احصل على البرنامج النصي للاختبار.
curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-minio.py

# قم بتشغيل الاختبار.
python3 pandas-minio.py

كانت النتيجة كما يلي:

Execution time: 0.83 seconds

s3fs-fuse

I got the test script and ran the test:

# احصل على البرنامج النصي للاختبار.
curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-s3fs.py

# قم بتشغيل الاختبار.
python3 pandas-s3fs.py

كانت نتيجة الاختبار كما يلي:

Execution time: 0.78 seconds

JuiceFS POSIX

I got the test script and ran the test:

# احصل على البرنامج النصي للاختبار.
curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-posix.py

# قم بتشغيل الاختبار.
python3 pandas-juicefs-posix.py

نتيجة الاختبار كانت كما يلي:

Execution time: 0.43 seconds

JuiceFS S3 API

I got the test script and ran the test:

# الحصول على السكربت الاختباري.
curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-s3api.py

# تشغيل الاختبار.
python3 pandas-juicefs-s3api.py

نتيجة الاختبار كانت كما يلي:

Execution time: 0.86 seconds

ملخص تدوير الملفات الصغيرة في Pandas

يوضح الشكل التالي نتائج الاختبار:

في هذا الاختبار، أظهر JuiceFS FUSE-POSIX سرعة أسرع بكثير، تقريبًا مرتين أسرع من الحلول الأخرى. MinIO، s3fs-fuse، وJuiceFS S3 Gateway تظهر أداءً مماثلًا. من وجهة نظر تدوير الملفات الصغيرة، أثبتت واجهة POSIX أنها أكثر فعالية، مما يوفر أداءً أفضل من واجهات تخزين الكائنات.

قضايا وتحليل

قضية 1: لماذا كان S3FS بطيء جدًا؟

تحليل: من بيانات الاختبار، من الواضح أنه عند كتابة نفس الملف 10 جيجا بايت، استغرق S3FS 3 دقائق، بينما أكمل MinIO وJuiceFS المهمة حوالي 30 ثانية. كان هذا الاختلاف الكبير في الأداء بشكل أساسي نتيجة التنفيذ الفني المختلف. عندما يكتب s3fs-fuse ملفًا، يكتب الملف أولاً إلى ملف مؤقت محلي ثم يقوم بتحميله إلى تخزين الكائنات في قطع. إذا لم يكن هناك مساحة أقراص محلية كافية، يتم التحميل بشكل متزامن. يحتاج إلى نسخ البيانات بين القرص المحلي وتخزين S3. لذلك، الملفات الكبيرة أو عدد كبير من الملفات تؤدي إلى تدهور في الأداء.

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

قضية 2: لماذا كانت JuiceFS أسرع؟

تحليل: في الاختبار، استخدمت كل من JuiceFS وS3FS FUSE للقراءة والكتابة. استغل JuiceFS سعة القرص مثل MinIO، لكنها لم تواجه مشاكل أداء مثل S3FS.

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

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

الخلاصة

توضح الاختبارات أعلاه أن استخدام تخزين الكائنات كأساس وتنفيذ واجهة POSIX فوقه لا يجعل بالضرورة خسارة في الأداء. سواء كتبت ملفات كبيرة أو صغيرة، يظهر JuiceFS أداءً يشبه إلى حد كبير كتابة MinIO مباشرة دون أي تدهور في أداء التخزين الأبعاد الكائنية تحت الوصول POSIX. علاوة على ذلك، فيما يتعلق بإعادة كتابة جداول Pandas، يظل أداء JuiceFS FUSE-POSIX متسقًا ويفوق MinIO بما يقرب من ضعف.

تشير نتائج الاختبارات إلى أن بعض البرامج، مثل s3fs-fuse، قد تعاني من تدهور في الأداء عند تحويل بين واجهة S3 API وواجهة POSIX. بينما يمكن أن تكون أداة مريحة للوصول العابر إلى S3، فإنه للاستخدام طويل الأمد ومستقر وعالي الأداء، من الضروري القيام ببحث وتحقق دقيق لاختيار حلول أكثر ملاءمة.

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