An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB רוצה להודות בפומבי ל-Dormando (Memcachediner) ו-Danny Kopping על תרומתם לפרויקט הזה, כמו גם להודות להם על תמיכתם וסבלנותם. שינה דני קופינג המהנדסים שמאחורי ScyllaDB - מסד הנתונים עבור ביצועים צפויים בקנה מידה - הצטרפו עם Memcached Mainer dormando כדי להשוות את שתי הטכנולוגיות פנים אל פנים, בצורה שיתופית, נייטרלית למשתמשים. התוצאות מגלות כי: הן Memcached והן ScyllaDB מקסיממו את הדיסקים ואת רוחב הקשר של הרשת תוך התמקדות בתנאים דומים, תוך שמירה על ביצועים דומים באופן כללי. בעוד ש-ScyllaDB דורש שינויים במודלים של נתונים כדי להכפיל לחלוטין את עוצמת הרשת, Memcached נדרש ערכות IO נוספות כדי להכפיל את I/O הדיסק. למרות ש-ScyllaDB הראה עיכובים טובים יותר בהשוואה לבקשות משולבות של Memcached לדיסק, עיכובים של Memcached היו טובים יותר לבקשות בודדות. מסמך זה מסביר את המוטיבציה שלנו עבור בדיקות אלה, מספק סיכום של התסריטים והתוצאות שנבדקו, ולאחר מכן מציג המלצות לכל מי שיכול להחליט בין ScyllaDB ל- Memcached. יש גם עם מבט מקיף יותר על הבדיקות והתוצאות וקישורים לקביעות הספציפיות שאתה יכול להשתמש לבצע את הבדיקות בעצמך. Gitbook מפורט עבור הפרויקט הזה, בונוס: dormando ואני דיברנו לאחרונה על הפרויקט הזה ב P99 CONF, כנס טכני מאוד על ביצועים ונדסת עיכוב נמוך. שימו לב לדרישה בונוס: dormando ואני דיברנו לאחרונה על הפרויקט הזה ב P99 CONF, כנס טכני מאוד על ביצועים ונדסת עיכוב נמוך. Watch on demand שימו לב לדרישה למה עשינו את זה? קודם כל, ScyllaDB השקיעה הרבה זמן ומשאבים הנדסיים אופטימיזציה של מסד הנתונים שלנו כדי לספק עיכובים נמוכים צפויים עבור יישומים אינטנסיביים נתונים בזמן אמת. ארכיטקטורה לא משותפת, ו (כמעט לחלוטין לעקוף את קישוריות הדף של לינוקס) הם כמה דוגמאות מדהימות של אופטימיזציות כאלה. Shard-Per-Core תגיות UserPace I/O לוח זמנים יישום cache פנימי שנית: ביצועים מתכנסים עם הזמן. קשיחים בזיכרון נחשבים ( במשך זמן רב) לאחד מרכיבי התשתית המהירים ביותר בעולם.עם זאת, עברו כמה שנים מאז פתרונות קשיח החלו להסתכל לתוך תחום כונני פלאש. If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? שלישית: דיברנו בעבר לאחרונה נבדק כיצד הצוותים הספציפיים הצליחו. . 7 סיבות לא לשים קח לפני מסד הנתונים שלך להחליף את ה-Cache שלהם עם ScyllaDB רביעי: בשנה שעברה P99 CONF, דני קופפינג נתן לנו נאום מעורר אור, , שם הוא הסביר כיצד Memcached Extstore עזר ל-Grafana Labs להגדיל את טביעת הקאש שלהם פי 42 תוך הפחתת עלויות. תסתיר אותי אם תוכל ולבסוף, למרות הביקורת (נכונה) שהביקורות ביצועיות מקבלות, הן עדיין ממלאות תפקיד חשוב בהובלת חדשנות. ועכשיו על ההשוואה. התקנת בתי המשפט בדיקות בוצעו באמצעות סוגי ההזדמנות הבאים של AWS: טעינה: c7i.16xlarge (64 vCPUs, 128GB RAM) Memcached: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) כל המדינות יכולות לספק יש לזכור כי במיוחד במהלך בדיקות של מקסימום יכולת הרשת המובטחת, שמנו לב . למעלה צמצם את רוחב הטווח עד ליכולת הקו הבסיסי של המקרים אופטימיזציה והגדרות כדי להתגבר על מחסומים פוטנציאליים, החלו ליישם את האופטימיזציות וההגדרות הבאות: הצד של AWS: כל האירועים השתמשו באסטרטגיית מיקום קבוצות, בעקבות מסמכי AWS: "אסטרטגיית זו מאפשרת לעומסי עבודה להשיג את הביצועים ברשת עם עיכוב נמוך הדרושים לתקשורת בין כפתורים מחוברת, אשר טיפוסית ליישומי מחשוב ביצועים גבוהים (HPC)." Memcached: Version 1.6.25, compiled with Extstore enabled. Except where denoted, run with 14 threads, pinned to specific CPUs. The remaining 2 vCPUs were assigned to CPU 0 (core & HT sibling) to handle Network IRQs, as specified by sq_split mode in seastar perftune.py. CAS operations were disabled to save space on per-item overhead. The full command line arguments were:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB: הגדרות ברירת המחדל כפי שהוגדרו על-ידי ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) ב- i4i.4xlarge. הלחץ עבור מונדיאלים, השתמשנו , חלק משולחן הבדיקות הרשמי של memcached. מחסן GitHub mcshredder דובדבנים / Shredders עבור ScyllaDB, השתמשנו , כפי שנשלח עם ScyllaDB, והוגדרו עומסי עבודה דומים כמו אלה המשמשים עבור Memcached. קוסמטיקה Stress בדיקות ותוצאות להלן סיכום של הבדיקות שביצענו והתוצאות שלהם.אם אתה רוצה תיאור ומבחן מפורט יותר, עבור אל . הכתבה המלאה של הפרויקט שיפור יעילות ה-RAM ככל שאתה יכול להתאים יותר פריטים ל-RAM, כך יש לך סיכוי טוב יותר להשיג הישגים ב-cache.The more cache hits result in significantly faster access than going to disk. הפרויקט הזה התחיל על ידי מדידה של כמה פריטים היינו יכולים לאחסן בכל אחסון נתונים.במהלך הבדיקות שלנו, המפתח היה בין 4 ל -12 בייטים (key0 .. keyN) עבור Memcached, ו -12 בייטים עבור ScyllaDB. תזכורת Memcached שמרה בערך 101 מיליון פריטים עד שהחילוץ החל.זה יעיל בזיכרון. מתוך הזיכרון המוקדש 114G של Memcached, זה בערך 101G ערך של ערכים, מבלי לקחת בחשבון את גודל המפתח ואת דגלים אחרים: ScyllaDB זה לא מפתיע, בהתחשב בכך שהפרוטוקול שלו דורש יותר נתונים כדי להיות מאוחסנים כחלק של כתיבה (כגון לוח זמנים של כתיבה מאז עידן, חיים בשורה, וכו '). Takeaways Memcached אחסון בערך 65% יותר פריטים בזיכרון מאשר ScyllaDB. שורות ScyllaDB יש מעלות גבוהה יותר לכל פריט כדי לתמוך אוריינטציה עמודה רחבה. ב-ScyllaDB, בלום פילטרים, אינדקס קח, ורכיבים אחרים מאוחסנים גם בזיכרון כדי לתמוך בחיפוש דיסק יעיל, תורם שכבה נוספת של עלייה. In-Memory Workload רק לקריאה The עומס העבודה (אם כי לא מציאותי) עבור קח הוא אחד שבו כל הנתונים מתאימים ל-RAM – כך שהקריאה אינה דורשת גישה לדיסק ואין פיטורים או פסוקים מתרחשים. אידיאל הוצאת הפסקות והפסקות קח מהתמונה עוזרת למדוד ולהגדיר נקודת בסיס של ביצועים עבור שני מחסני נתונים.היא מתמקדת במה שחשוב ביותר עבור סוגים אלה של עומסי עבודה: אורך קריאה ואורך הדרישה. במבחן זה חיממנו תחילה את שני החנויות באותן גדלים של משקל שימושי ששימשו במבחן הקודם. Memcached Memcached השיגה 3 מיליון Gets לשנייה, ומקסימום לחלוטין את רוחב הקשר של AWS NIC (25 Gbps)! Memcached שמרה על 3M RPS יציב, מקסימום לחלוטין את עוצמת ה- NIC הפרסום מראה כי p99.999 תשובות הושלמו תחת 1ms: תוצאות תגית: cmd_get סך הכל: 5503513496 קצב: 3060908/s === שעות mg === 1-10% 0 0 0 0 0 10-99us 343504394 6.238% 100-999us 5163057634 93.762% 1-2ms 11500 0.00021% ScyllaDB כדי לקרוא יותר שורות ב- ScyllaDB, היינו צריכים לעצב מודל נתונים טוב יותר עבור בקשות הלקוח בשל מאפייני הפרוטוקול (במיוחד ללא צינורות).עם מפתח קבוצתי, היינו יכולים למקסם לחלוטין את קאצ'ו של ScyllaDB, וכתוצאה מכך שיפור משמעותי במספר השורות המוקפאות. כתוצאה מכך, מספר הרשומות בתוך הקאש השתפר באופן משמעותי בהשוואה למספר הערכים המפתח שהוצגו בעבר. כפי שהדגיש dormando נכון (תודה!), תצורה זו שונה באופן משמעותי מההתקנה הקודמת של Memcached. בעוד שעון העבודה של Memcached תמיד פוגע בזוג ערכים מפתח בודד, בקשה אחת ב- ScyllaDB גורמת למספר שורות להיחזר. הסברנו את הסיבות לשינויים האלה. שם, דיברנו על מאפיינים של פרוטוקול CQL (כגון ה- per-item overhead [בהשוואה ל- memcached] ואין תמיכה ב- pipelining) שהופכים את חלקיקיקים רחבים ליעילים יותר ב- ScyllaDB מאשר קלטות מפתח יחיד. בכתבה המפורטת עם התאמות אלה, הטעינים שלנו פעלו בסך הכול 187K פעולות קריאה / שניה במשך 30 דקות. בדומה ל-memcached, ScyllaDB גם מקסימז את עוצמת ה-NIC. ScyllaDB חושף מידע על אינטנסיביות בצד השרת, אשר שימושי לניתוח אינטנסיביות ללא הרשת.במהלך הבדיקה, אינטנסיביות p99 בצד השרת של ScyllaDB נשארה בתוך גבולות של 1ms: הפנטסילים בצד הלקוח הם, ללא הפתעה, גבוהים יותר מאשר האחריות בצד השרת עם קריאה P99 של 0.9ms. Takeaways הן Memcached והן ScyllaDB סיטרו לחלוטין את הרשת; כדי למנוע סיטרוף של חבילות הרשת המקסימליות לשנייה, Memcached התבסס על צינור בקשות בעוד ScyllaDB עבר לכיוונון עמודה רחבה. הקאש של ScyllaDB הראה רווחים משמעותיים בעקבות תבנית עמודה רחבה, המסוגלת לאחסן יותר פריטים בהשוואה לכיוון הערך המפתח הפשוט הקודם. ברמה של הפרוטוקול, פרוטוקול של Memcached הוא פשוט יותר וקל יותר, בעוד CQL של ScyllaDB מספק תכונות עשירות יותר, אבל יכול להיות כבד יותר. הוספת דיסקים לתמונה מדידת ביצועי אחסון פלאש מציגה אתגרים משלה, מה שהופך את זה כמעט בלתי אפשרי לתאר את עומס העבודה נתון באופן מציאותי לחלוטין. עבור בדיקות הקשורות לדיסק, החלטנו למדוד את המצב הפסימי ביותר: השווה את שתי הפתרונות המשרתים נתונים (ברובם) מאחסון בלוק, בידיעה כי: הסיכוי של עומסי עבודה מציאותיים לעשות זאת הוא איפשהו קרוב לאפס משתמשים צריכים לצפות למספרים בין עומס העבודה האופטימי הקודם של ה-Cache לבין עומס העבודה הפסימי הקשור לדיסק בפועל. Memcached Extstore The ברמה גבוהה, היא מאפשרת ל-memcached לשמור את שולחן ההשקה שלה ואת המפתחות שלה בזיכרון, אך לאחסן ערכים לאחסון חיצוני. דף ויקי במהלך הבדיקות שלנו, עמקנו את memcached עם פריטים 1.25B עם גודל ערך של 1KB וגודל מפתח של עד 14 בייטים: עם Extstore, שמרנו כ- 11X את מספר הפריטים בהשוואה לעומק העבודה הקודם בזיכרון עד שהפריטים החלו להתחיל להתחיל (כפי שמוצג בפאנל הימני בתמונה לעיל). Read-Only Performance עבור מבחני הביצועים האמיתיים, הדגישו Extstore נגד גודל פריט של 1KB ו 8KB. Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms תגית: metaget_pipe 16 1 KB 32 188 ש"ח 4 - 5 ms תגית: metaget 1 1 KB 32 182 ש"ח 1 ms תגית: metaget_pipe 16 1 KB 64 261 ש"ח 5 עד 6 ms תגית: metaget 1 1 KB 64 256K / s 1 ~ 2ms תגית: metaget_pipe 16 8 KB 16 92 ש"ח 5 עד 6 ms תגית: metaget 1 8 KB 16 90 ש"ח 1 ms תגית: metaget_pipe 16 8 KB 32 110 ש"ח 3 - 4 ms תגית: metaget 1 8 KB 32 105K / s 1 ms ScyllaDB ספגנו את ScyllaDB עם אותו מספר פריטים ששימשו עבור memcached. למרות ש-ScyllaDB הראתה שיעורי GET גבוהים יותר מאשר memcached, היא עשתה זאת תחת עיכובים זנב גבוהים מעט יותר בהשוואה לעומסי העבודה שאינם צינורות של memcached. Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1KB קריאה 1 1 KB 268.8K / שניות 2ms 2.4 מ"ס 8 KB קריאה 1 8 KB 156.8 ק"ג 1.54 מ"מ 1.9 MS Takeaways Extstore נדרש התאמה משמעותית להגדרות שלה על מנת להרתיח לחלוטין I / O אחסון פלאש. בשל ארכיטקטורת Memcached, עומסי תשלום קטנים יותר אינם מסוגלים לנצל במלואם את שטח הדיסק הזמין, ומספקים רווחים קטנים יותר בהשוואה ל- ScyllaDB. שיעורי ScyllaDB היו גבוהים יותר מ-Memcached באופן כללי באוריינטציה של ערך מפתח, במיוחד בגדלים גבוהים יותר של משאבים שימושיים.Latencies were better than pipelined requests, but slightly higher than individual GETs in Memcached. Overwriting עבודה בעקבות תוצאות הדיסק הקודמות שלנו, השוואנו את שתי הפתרונות בעומס עבודה לרוב קריאה שמטרתו אותו עוצמה (250K ops/sec). ברוב המקרים מדובר ב"תסריט חצי גרוע ביותר" (half worst case scenario). מבחן 'בסיסי' עבור Extstore Memcached Memcached השיג שיעור של מעט מתחת ל- 249K במהלך הבדיקה, בעוד שיעורי הכתיבה נשארו יציבים לאורך כל תקופת הבדיקה, התברר כי הקריאה השתנה מעט. : לאורך כל המירוץ מצאנו גם מעט גבוה. מטריקות למרות יחסי הקריאה הנמוכים, אך האיחור נשאר נמוך.התוצאות האלה מצטברות להלן: חבילות נופש - I - I - I Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms תגית: GET 64 224K / s 1 - 2 ms CMD - קובץ 64 24.8K / שניות 1 ms ScyllaDB בדיקת ScyllaDB נערכה על ידי שימוש בשני מכשירי טעינה, כל אחד עם מחצית מהקצב היעד.אף על פי ש-ScyllaDB השיג עוצמה גבוהה מעט יותר (259.5K), עיכובים הכתיבה נשמרו נמוכים לאורך כל התהליך והעיכובים הקריאה היו גבוהים יותר (כמו עם memcached): הטבלה הבאה מציינת את תוצאות ההפעלה בצד הלקוח בין שני הטעינים: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms Loader1 124.9 ק"ג 1.4 מ"מ 2.6 מ"ס Loader2 124.6 ק"ג 1.3 מ"ס 2.6 מ"ס Takeaways שיעורי הכתיבה של Memcached ושל ScyllaDB היו יציבים, עם קריאה שונה במקצת לאורך כל התהליך. ScyllaDB כותבת עדיין את ה- commitlog overhead, אשר יושב במסלול הכתיבה החמה עיכובים בצד השרת של ScyllaDB היו דומים לאלה שנצפו בתוצאות של Memcached, אם כי עיכובים בצד הלקוח היו מעט גבוהים יותר. קראו ניתוח מפורט יותר ב-Gitbook עבור הפרויקט הזה חבילות Up הן memcached והן ScyllaDB הצליחו למקסם את השימוש בחומרה הבסיסית בכל הבדיקות ולשמור על עיכובים נמוכים באופן צפוי. אם עומס העבודה הנוכחי שלך יכול להכיל מודל ערך מפתח פשוט והוא מרוויח מן הצינור, אז memcached צריך להיות מתאים יותר לצרכים שלך. סיבה נוספת להישאר עם Memcached: זה בקלות לספק תנועה הרבה מעבר למה NIC יכול לתמוך. dormando ציין כי הוא יכול להגדיל את זה למעלה מעל 55 מיליון קריאה אופסים / שניות עבור שרת גדול בהרבה.בהתחשב בכך, אתה יכול לעשות שימוש בסוגים קטנים יותר ו / או זולים יותר של דוגמאות כדי לשמור על עומס עבודה דומה, בתנאי שהזיכרון הזמין ואת טביעת הדיסק מספיקים את צרכי עומס העבודה שלך. חדשות ה-Hacker Thread זווית שונה לשקול היא גודל קבוצת הנתונים. למרות Extstore מספק חיסכון עצום על ידי מאפשרת לך לאחסן פריטים מעבר ל-RAM, יש גבול לכמה מפתחות יכול להתאים ל-GB של זיכרון. עומסי עבודה עם פריטים קטנים מאוד צריכים לראות רווחים קטנים יותר בהשוואה לאלו עם פריטים גדולים יותר. חשוב גם לשקול אם יש צורך בהתמדה של נתונים.אם כן, אז הפעלת ScyllaDB כקלייה מפוזרת מתורגמת מספקת לך התנגדות גדולה יותר ופעולות ללא הפסקה, עם ההסכם להיות (והכמו לרוע המזל, Extstore אינו תומך בהפעלה מחדש חמה ולכן כישלון או תחזוקה של כבל יחיד נוטה להעלות את יחסי החסר הקאש שלך. אם זה מקובל או לא תלוי בסמנטיקה של היישום שלך: אם אובדן קאש מתאים לטיול סיבוב אל הנתונים, אז האינטנסיביות של קצה לקצה תהיה גבוהה באופן זמני. המדינות הנכונות למדינות במונחים של חיתוך עקבי, לקוחות memcached אחראים על הפצה של מפתחות בין השרתים המפוזרים שלך.זה עשוי להציג כמה hiccups, שכן תצורות שונות של לקוחות יגרמו למפתחות להיות מיועדים באופן שונה, וכמה יישומים לא עשויים להיות תואמים זה לזה. ScyllaDB לוקח גישה שונה: חיתוך עקבי מתבצע ברמת השרת ומתפשט ללקוחות כאשר החיבור נוצר לראשונה. ConfiguringClient wiki של Memcached אז מי זכה (או מי הפסיד)? ובכן... זה לא חייב להיות תחרות, ולא רשימה מקיפה המתארת כל חשיבה עבור כל פתרון. הן ScyllaDB והן memcached משתמשים בגישות שונות כדי לנצל את התשתית הבסיסית ביעילות. היינו שמחים לראות את ScyllaDB מתאימה למספרים של Memcached המוכרת בתעשייה. כמובן, לא ציפינו למסד הנתונים שלנו להיות "מהיר יותר".
