KeyDB כתחליף [פוטנציאלי] עבור Redis

לא היו ביקורות על "חלופה מהירה יותר לרדיס" ב-Habré - KeyDB. לאחר שצברתי ניסיון די עדכני בשימוש בו, ברצוני למלא את הפער הזה.

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

נושאים

על Redis באופן כללי

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

אינספור עותקים נשברו בנושא זה, אך מפתחי Redis מסרבים בעקשנות ליישם מקביליות מלאה, ומזכירים עד כמה זה יסבך את האפליקציה ויגדיל את עלויות התקורה, כמו גם יוסיף באגים נוספים. העמדה שלהם היא כזו: אם אתה מתמודד עם בעיה של ליבה אחת, יש לך בעיות עם ארכיטקטורת האפליקציה וצריך לשנות בה משהו. בין המשתמשים, לעומת זאת, יש גם "מחנה נוסף" - אלה שתקועים על ליבה אחת וטוענים שרדיס יוצרת לעצמה צוואר בקבוק. במקרה של עומסים גדולים באמת - במוקדם או במאוחר - אין מנוס מלהיתקל בבעיה זו, המטילה הגבלות משמעותיות על הארכיטקטורה ו/או סיבוכים מאולצים בה.

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

המקרה שלנו

באחד הפרויקטים, נתקלנו בעובדה שצוות הפיתוח הגדיר שמירה אגרסיבית ביותר של נתונים מבסיס הנתונים (PostgreSQL) באמצעות Redis. זו הייתה הדרך היחידה שבה, במהלך זרימת תנועה פתאומית, הצילה את PostgreSQL עצמה וכתוצאה מכך את האפליקציה ממוות.

לאחר סדרה של בדיקות עומס, ניתחנו את המצב וגילינו שרדיס מוגבלת לליבה אחת (מה שנקרא "מדף"), ואחריה התדרדרות מהירה למדי של היישום. ה"חנק" היה אקספוננציאלי: ברגע שהושג מגבלת הביצועים של רדיס, הכל הפסיק לעבוד.

זה נראה בערך כך:

New Relic זיהה בבירור את הבעיה:

להלן הנתונים הסטטיסטיים של הפעולה: get ברדיס:

לאחר שהבעיה דווחה לצוות הפיתוח בפירוט, התברר כי "לא ניתן לפתור את הבעיה כרגע". כך החל החיפוש אחר פתרון בצד התפעולי, וה-KeyDB שהוזכר כבר היה התשובה.

עם זאת, לפני שנתחיל בסקירה שלנו, ראוי להזכיר שהפרויקט משתמש ב-Redis עצמאי, מכיוון שפתרון האשכולות המבוסס על Sentinel נחות בהרבה מבחינת השהייה. פתרון אחד ברור היה ליצור מספר העתקים של המטמון: ולתת לאפליקציה ללכת לכל מקום עם איזון! עם זאת, לאחר התייעצות עם המפתחים, נאלצנו לבטל אפשרות זו עקב מנגנון אי תוקף המטמון הפעיל והמורכב של האפליקציה. אותה בעיה התרחבה גם לריסוק המטמון.

מבט מהיר על KeyDB

תוך כדי חיפוש אחר פתרון אפשרי לבעיה, גילינו אפליקציה בשם KeyDB. זהו מזלג Redis שפותח על ידי חברה קנדית ומופץ תחת רישיון BSD החינמי. הפרויקט צעיר מאוד: הוא קיים מתחילת 2019. ההיסטוריה שלו היא שגם המחברים נתקלו פעם במגבלות של רדיס... והחליטו להכין מזלג משלהם. יתר על כן, זה לא רק פתר בעיות ידועות, אלא גם קיבל תכונות נוספות שזמינות רק בגרסת הארגונית של Redis.

למי שרוצה להכיר את KeyDB ביתר פירוט, יש טוב מאמר מבוא על מדיום, המציגה את ה-DBMS ומדדים קצרים המשווים אותו ל"אב" שלו - Redis.

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

• השגת ריבוי השחלות מלא;
• תאימות מלאה ומוחלטת עם Redis (זה היה חשוב במיוחד עבורנו, מכיוון שלא ניתן היה לבצע שינויים כלשהם בצד האפליקציה), מה שגם הבטיח העברה ללא בעיות;
• מנגנון גיבוי מובנה באחסון S3;
• קל ליישם שכפול פעיל;
• קלסינג וריסוק פשוטים ללא Sentinel ותוכנות תומכות אחרות.

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

הגירה ותוצאות

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

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

החלו בדיקות שנמשכו כשבוע ולפרטיה לא צללנו. אנו יודעים רק שהלקוח בדק את הפונקציות הסטנדרטיות של עבודה עם Redis באמצעות מנהל התקן PHP phpredis, וכן ערכו בדיקות QA של ממשק המשתמש. לאחר מכן, קיבלנו אור ירוק: לא נמצאו תופעות לוואי בשימוש בתוכנה החדשה. זה מנקודת המבט של היישום, שום דבר לא השתנה כלל.

ראוי לציין שלא שינינו שום דבר בתצורה: פשוטו כמשמעו, פשוט החלפנו את התמונה שבה נעשה שימוש. אותו הדבר לגבי ניטור וייצוא מדדים ל-Prometheus: הנפוץ שבהם עובד בצורה מושלמת עם KeyDB וללא כל שינויים. לפיכך, אנו יכולים לומר בבטחה שמבחינה מבצעית, זהו פשוט מהלך אידיאלי.

הודות לכל זה, לאחר החלפת האפליקציה ל-DBMS חדש, אינך יכול לשנות דבר, אך כ"אמצעי ייצוב" אתה יכול להשאיר אותו בצורה זו כדי לעבוד בלחימה למשך זמן מה. עם זאת, אם אתה רוצה לראות עלייה בביצועים (או שינויים בכלל), אסור לך לשכוח זאת כברירת מחדל פרמטר KeyDB שאחראי על ריבוי ההליכים (server-threads), שווה לאחד, כלומר ה-DBMS עובד בדיוק כמו Redis.

לאחר החלפה, בדיקה וקצת זמן חיים באפליקציה החדשה (עם KeyDB), החלטנו לחזור על בדיקת העומס עם אותם פרמטרים ששימשו עבור Redis. מה היו תוצאותיו?...

על פי גרף צריכת ה-CPU, ביטול הבעיות ב"תקרה" של ליבה אחת נהיה מורגש מיד: התהליך החל להשתמש במשאבים זמינים:

ובהמשך ניסיתי "לענות" את האפליקציה די חזק וראיתי צריכה של עד שלוש ליבות...

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

זמן האחזור של מסד הנתונים החדש (KeyDB) החמיר אף הוא, אך נשאר בערכים מקובלים:

הגרף הבא מראה בבירור שמספר הבקשות ל-KeyDB עצמו דומה:

לסיכום בדיקות סינתטיות אלו, אנו יכולים לומר שגם Redis וגם KeyDB מציגים ירידה משמעותית בביצועים בהשהיה (40 ms+) עם עלייה משמעותית במספר החיבורים המקבילים (1000+). במקרה שלנו, אפליקציית האינטרנט הצליחה "לבזבז" את זמן ההשהיה של Redis אפילו עם מספר נמוך יותר של חיבורים (400+), אם כי עבור KeyDB עומס כזה נשאר מקובל.

ממצאים

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

אם כבר מדברים על ההגירה עצמה, שהיתה פשוטה להפתיע, לא קיבלנו כל כך הרבה עלייה משמעותית בביצועים, שניתן לצפות מהתבוננות בגרפים של מחברי KeyDB... עם זאת, זהו רק המקרה המיוחד שלנו, בו עשויות להיות סטיות רבות, כולל הארכיטקטורה הידועה לשמצה של האפליקציה (למשל , מספר עצום של פקודות get ב-Redis במקום האפשרות הביצועית יותר של שאילתות מצטברות mget...). למרות זאת, הצלחנו להשיג תוצאות חיוביות, ויחד איתם פונקציות שימושיות רבות שנטמיע בעתיד הקרוב.

באופן כללי, KeyDB נראה מבטיח: ככל שנרכוש ניסיון מעשי עם ה-DBMS הזה (ואנחנו עדיין צריכים לצבור אותו!) ולפתח את הפרויקט עצמו, נשקול את האפשרות להשתמש בו במצבים אחרים.

עם זאת, אין להתייחס למאמר זה כמדריך (שלא לדבר על קריאה) לפעולה לנטישה הנרחבת של Redis לטובת KeyDB. למרות הניסיון החיובי שלנו, ברור שלא מדובר בכדור כסף. המקרה היה מאוד ספציפי: דווקא לפתרון בעיה רגעית במצב בו היה צורך לעשות זאת במהירות ובעלות מינימלית, הפתרון הזה היה מוצדק. האם KeyDB יהיה שימושי במקרה שלך? לפחות עכשיו אתה יודע שקיימת אפשרות פוטנציאלית זו.

נ.ב.

קרא גם בבלוג שלנו:

• «מסדי נתונים ו-Kubernetes (סקירה ודוח וידאו)";
• «הגירה של קסנדרה ל-Kubernetes: תכונות ופתרונות";
• «העברה חלקה של MongoDB ל-Kubernetes";
• «העברה חלקה של RabbitMQ ל-Kubernetes".

מקור: www.habr.com