האם POSIX באמת לא מתאים לחנויות אובייקטים? תשובה מבוססת על נתונים

הפורטל מערער על הנקודת המבט שהוצגה במאמר של MinIO, שמציע ש-POSIX אינו מתאים לאחסון אובייקטים. הוא ביצע בדיקות מקיפות הכוללות את MinIO s3fs-fuse ו-JuiceFS. התוצאות מצביעות על כך ש-MinIO ו-JuiceFS מספקים ביצועים מצוינים בעוד s3fs-fuse מגרד. בתרחישי החלפת קבצים קטנים, JuiceFS FUSE-POSIX עוקף אחרות פתרונות.

לאחרונה נתקלתי במאמר בבלוג MinIO בשם "לשים מערכת קבצים מעל אחסון אובייקט הוא רעיון רע. הנה למה." הפורטל השתמש ב-s3fs-fuse כדוגמה לאתגרי הביצועים שנתקלים כשמשתמשים בשיטות POSIX של מערכת ההפעלה הניידת (POSIX) לגשת לנתוני MinIO, והדגיש שהביצועים נגררו מאחור באופן משמעותי מגישת MinIO ישירה. הפורטל קיבל את הבעיות הללו בגלל פגמים מוכרחים ב-POSIX. עם זאת, החוויה שלנו מספרת סיפור שונה במקצת.

POSIX היא תקן שימושי ונפוץ ביותר. פיתוח תוכנה שמתאים לתקן POSIX מבטיח תאימות וניידות בין מערכות הפעלה שונות. רוב היישומים בתעשיות שונות מקישרים לתקן POSIX. עם התקדמות חיבור הענן, נתונים גדולים וטכנולוגיות AI, והגודל ההולך וגדל של הנתונים המאוחסנים, קיימת דרישה גדולה יותר לפתרונות אחסון גמישים כמו חנויות עצמים. למרות שחנויות עצמים כמו MinIO מספקים SDK בשפות רבות, רבים מהיישומים המסורתיים נאבקים להתאים את הקוד שלהם לשימוש ב-APIs של אחסון עצמים. זה הוביל לפיתוח מוצרי אחסון המיישמים ממשקי POSIX מעל חנויות עצמים כדי לענות על הדרישה הבוחרת הזו.

מוצרים רבים בתעשייה, כגון Ceph, JuiceFS ו-Weka, השיגו הצלחה ביישום ממשקי POSIX על חנויות עצמים. לפיתרונות אלה קהל משתמשים גדול ונרשמים סיפורי הצלחה, והם מתנהגים היטב מבחינת ביצועים.

למרות שברור של-POSIX יש מורכבות משמעותית, הבעיות המשוייכות אינן בלתי ניתנות לשליטה. בכבוד וברצון לאמת את הטענות הללו, הקמתי סביבת בדיקה, השתמשתי באותם נתוני דוגמה ושיטות בדיקה כמו במאמר של MinIO, וביצעתי אימות.

מוצרים מושווים ומטרות הבדיקה

כדי לספק הערכה מקיפה, הכנסתי את JuiceFS להשוואה.

JuiceFS היא מערכת הפלטפורמה הפתוחה, הממוקדת בענן המפיקה מערכת קבצים מרוחקת. היא משתמשת באחסון אובייקטים כשכבה של אחסון נתונים ומסתמכת על מסד נתונים נפרד לאחסון מטא-נתונים. היא מציעה שיטות גישה רבות, כולל API POSIX, API S3, נהג CSI, API HDFS ו-WebDAV, יחד עם מנגנונים ייחודיים לחיתוך נתונים, אפנון וקריאה/כתיבה מקבילים. JuiceFS היא מערכת קבצים, שונה ביסודה מכלים כמו s3fs-fuse, שפשוט ממירים מאחסון אובייקטים לפרוטוקולי POSIX.

על ידי ביצוע השוואה עם JuiceFS, ביצעתי ביקורת אוביקטיבית על היתרונות והחסרונות של יישום פרוטוקולים כמו POSIX על פני אחסון אובייקטים.

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

• כתיבת קובץ בגודל 10 GB
• החלפת קבצים קטנים עם Pandas

שלוש הפתרונות השתמשו במצביע MinIO שהופעל על שרתים נפרדים כשכבת אחסון בסיסית. לדוגמאות המבחן השתמשו בקובץ בגודל 10 GB, שהיה אותו קובץ CSV שהוזכר במאמר MinIO.

כל הסביבות, התוכנה, התסריטים והנתונים הדוגמא במאמר זה מגיעים עם קוד מלא והוראות להדגמה כדי להבטיח שתוכלו לשחזר את הסביבה ותוצאות המבחן.

הגדרת שרת וסביבת הבדיקה

שני שרתים בענן עם תכונות זהות:

• מערכת: Ubuntu 22.04 x64
• CPU: 8 תְּ核心
• RAM: 16 GB
• SSD: 500 GB
• רשת: 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 בשורת הפקודה של לינוקס. הפקודה 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 API הנפוצות יותר ובדקתי את הביצועים שלהם.

# יצירת ספריות להתקנה.
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 API מבוססת רשת.

בדיקות ותוצאות

הנה סיכום מהיר של הבדיקות והתוצאות שלי:

בדיקה 1: כתיבת קובץ בגודל 10 ג'יגה-בייט

בדיקה זו עורכת להערכת ביצועים של כתיבת קבצים גדולים. ככל שהזמן שנדרש הוא קצר יותר, הביצועים טובים יותר. השתמשתי בפקודה time למדידת משך פעולות הכתיבה, ומספקת שלושה מדדים:

• real: הזמן האמיתי מההתחלה עד הסוף של הפקודה. הוא כלל את כל זמני ההמתנה, כמו המתנה להשלמת פעולות I/O, המתנה למעברי תהליך, והמתנה לפני משאבים.
• user: הזמן שביצע במצב משתמש, מציין את זמן ה-CPU המשמש לביצוע קוד המשתמש. הוא בדרך כלל מייצג את עומס המיחשוב של הפקודה.
• sys: הזמן שביצע במצב גרעין, מציין את זמן ה-CPU המשמש לביצוע קוד הגרעין. הוא בדרך כלל מייצג את העומס הקשור לקריאות מערכת, כמו 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 GB ישירות ל-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 GB ישירות ל-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 GB ב-JuiceFS באמצעות כתיבה POSIX:

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

תוצאות לכתוב קובץ של 10 GB ב-JuiceFS באמצעות כתיבה API S3:

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

סיכום תוצאות כתיבת קובץ גדול

התרשים הבא מציג את תוצאות הבדיקה:

תוצאות הבדיקה מראות שכתיבה ישירה ל-MinIO ול-JuiceFS הביאו ביצועים דומים, והשלימו את המשימה תוך כ-30 שניות. לעומתם, s3fs-fuse לקח יותר מ-3 דקות לכתוב קובץ של 10 GB, מה שהיה בערך פי שש איטיים מהשניים הקודמים.

כאשר כותבים קבצים גדולים, mc משתמש ב-API המרותק כדי להעלות קבצים בחלקים לממשק S3. לעומת זאת, s3fs-fuse יכול רק לכתוב ל-POSIX באחד גרם שניוני. JuiceFS גם מחלקת באופן אוטומטי קבצים גדולים לחלקים וכותבת אותם במקביל ל-MinIO בכתיבה רצופה, ובכך מבטיחה ביצועים דומים לכתיבה ישירה ל-MinIO. S3FS, לעומת זאת, כותבת קודם לכתבים לדיסק מטמעכות בגרם שניוני אחד ולאחר מכן מעלה את הקובץ בחלקים ל-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

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, עשויות לחוות התדרדרות בביצועים בעת המרת בין API S3 לבין ממשקי POSIX. בעוד שזה יכול להיות כלי נוח לגישה זמנית ל-S3, לשימוש ארוך טווח יציב ובעל ביצועים גבוהים, נדרשת מחקר ואימות קפדניים כדי לבחור פתרונות מתאימים יותר.

לאחסון פשוט ולא מובנה של קבצים, השימוש הישיר ב-MinIO או באחסון אובייקטים ענק עלול להיות בחירה טובה. עם זאת, לתרחישים הכרוכים באחסון ועיבוד מידע בקנה מידה גדול, כגון כשרוצים להכשיר מודלים אינטליגנטיים (AI), ניתוח גדול של מידע, קיוברנטים לקיום מידע, ופעילויות קריאה וכתיבה שוטפות, JuiceFS מספק ניהול מטא-נתונים עצמאי, יכולות קריאה וכתיבה מקבילות, ומנגנוני מטמון שמשפרים את הביצועים. זהו פתרון מערכת הקבצים בעל ביצועים גבוהים שראוי לשקול.