benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability כאשר בוחרים מסד נתונים NoSQL, האפשרויות יכולות להיות ענקות. אחת הבחירות הפופולריות ביותר היא MongoDB, הידועה בקלות השימוש שלה. הדו"ח מתבונן מקרוב יותר בטכניקה של שתי מסדי הנתונים – בהשוואה בין ארכיטקטורותיהן מנקודת מבט טכנית עצמאית. benchant MongoDB ו- ScyllaDB מבטיחים ארכיטקטורות זמינות, ביצועיות וגמישות, אך הדרך שבה הם משיגים את המטרות הללו שונה הרבה יותר ממה שאתם עשויים לחשוב במבט ראשון. לדוגמה, דוח ניסיון מראה כיצד ניתן לנהל בקלות את ScyllaDB בהזדמנויות מקומיות של AWS EC2 הודות לארכיטקטורה המופצה שלה, בעוד ארכיטקטורת ההפצה של MongoDB הופכת את זה למשימה מאתגרת מאוד. כדי להדגיש את ההבדלים האלה, אנו מספקים דיון מעמיק על ארכיטקטורת האחסון הפנימית והארכיטקטורות המופצות המאפשרות זמינות גבוהה ופיתוח אופקי. כמו כן, פרסמנו רק מדד מדד המגדיר את ההשפעה של ההבדלים האלה. Note: עקבו אחרי DynamoDB vs MongoDB Benchmark הורד את דוח ההשוואה Read the DynamoDB vs MongoDB Benchmark Summary עקבו אחרי DynamoDB vs MongoDB Benchmark Download this Comparison Report הורד את דוח ההשוואה נקודת מבט על ביצועים על ארכיטקטורת אחסון של MongoDB vs ScyllaDB שני מסדי הנתונים מיושמים ב- C++ וממליצים על השימוש במערכת הקבצים XFS. יתר על כן, MongoDB ו- ScyllaDB מבוססים על , Commit Log ב ScyllaDB Terminology ו- Oplog ב MongoDB Terminology. With write-ahead-logging, all operations are written to a log table before the operation is executed. The write-ahead-log serves as a source to replicate the data to other nodes, and it is used to restore data in case of failures because it is possible to 'replay' the operations to restore the data. עקבו אחרי write-ahead-logging MongoDB משתמש כמנוע אחסון ברירת המחדל באינדקס B+-Tree (Wired Tiger) לאחסון וחיפוש נתונים. אינדקס B+-Tree הם מבנים נתונים עץ מאוזנים המאחסנים נתונים בסדר מסודר, מה שהופך את זה קל לבצע שאילתות המבוססות על טווח. MongoDB תומך באינדקסים מרובים על אוסף, כולל אינדקסים מורכבים, אינדקסים טקסטים ואינדקסים גיאוספסיאליים. אינדקס של אלמנטים מסדרה ושדות מחוברים, המאפשרים שאילתות יעילות על מבנים נתונים מורכבים, אפשריים גם כן. ScyllaDB מחלק את הנתונים לחתיכות על-ידי הקצאת חלקיק של הנתונים הכוללים ב-node ל-CPU ספציפי, יחד עם הזיכרון הקשור (RAM) והאחסון הקבוע שלה (כמו NVMe SSD). מנוע האחסון הפנימי של ScyllaDB עוקב אחר מושג ה- write-ahead-logging על-ידי יישום יומן קביעת דיסק קבוע יחד עם הזיכרונות המבוססים על הזיכרון המוצפים על-ידי הדיסק לאורך זמן. ScyllaDB תומך באינדקסים ראשוניים, משני ומורכבים, הן מקומיים על-ידי ה-node והן גלובליים על-ידי קבוצה. האינדקס העיקרי מורכב ממעגל hashing שבו מאוחסן המפתח המ ארכיטקטורות אחסון שונות אלה גורמות לשימוש שונה של החומרה הזמינה כדי להתמודד עם עומס העבודה. MongoDB אינו מקשר חוטים פנימיים ליבשות ה-CPU הזמינות, אלא מיישם גישה לא קשורה לחוטים מפוזרים ליבשות. ארכיטקטורות CPU, זה יכול לגרום לירידה ביצועים, במיוחד עבור שרתים גדולים, כי חוטים יכולים להיות מיועדים באופן דינמי ליבשות על מגעים שונים עם מערכות זיכרון שונות. זה מאפשר לו להדביק את החוטים האחראים ליבשות ספציפיות ומונע החלפת בין ליבשות שונות וחלקי זיכרון. כתוצאה מכך, יש לבחור בקפידה את מפתח ה-shard כדי להבטיח חלוקת נתונים שווה בין החלקים ולמנוע חצוצות חמות. זה מספק כיתות עדיפות מובנות עבור שאילתות רגישות ושאלות לא רגישות, כמו גם תזמון I/O מתואם בין הפריטים על צינור אחד כדי למקסם את הביצועים של הדיסק. לבסוף, סקריפטים ההתקנה של ScyllaDB מגיעים עם שלב התאם אוטומטי ביצועים על ידי יישום הגדרת מסד הנתונים האופטימלית המבוססת על המשאבים הזמינים. מספר מבוסס Shard Per Core גישה לוח זמנים I/O ScyllaDB מאפשר למשתמש לשלוט אם הנתונים צריכים להישאר ב- DB Cache או לעקוף אותו עבור מקטעי גישה נדירים. ScyllaDB מאפשר ללקוח להגיע ל- node ו- cpu core (shard) אשר הבעלים של הנתונים.זה מספק עתירות נמוכה יותר, ביצועים עקביים ומשוואת עומס מושלמת. ScyllaDB גם מספק 'פריטיזציה עומס עבודה' המספקת למשתמש הסכמים שונים עבור עומס עבודה שונים כדי להבטיח עתירות נמוכה יותר עבור עומס עבודה קריטי מסויים. ארכיטקטורת ההפצה של MongoDB – שתי מצבי פעולה לגישה גבוהה ופיתוח ארכיטקטורת מסד הנתונים של MongoDB מציעה שתי מצבי קבוצה המתוארות בסעיפים הבאים: קבוצת קבוצה של עותקים מכוונת זמינות גבוהה, בעוד קבוצת קבוצה משותפת מכוונת זמינות גבוהה. Replica Set Cluster: זמינות גבוהה עם גמישות מוגבלת ארכיטקטורת MongoDB מאפשרת זמינות גבוהה על-ידי המושג של קבוצות רבייה. קבוצות רבייה MongoDB עוקבות אחר המושג של כפתורים ראשוניים-שניים, שבהם רק העיקריים מטפלים בפעולות ה- WRITE. הספציפיים מחזיקים עותק של הנתונים וניתן להפעיל אותם כדי לטפל בפעולות READ בלבד. הפצה של קבוצת רבייה משותפת מורכבת משני ספציפיים, אך ניתן להוסיף ספציפיות נוספות כדי להגדיל את הזמינות או להגדיל עומסי עבודה כבדים. MongoDB תומך עד 50 ספציפיות בתוך קבוצת רבייה אחת. במונחים של הפצה גיאוגרפית, MongoDB תומך בהפצה גיאוגרפית עבור קבוצות רבייה כדי להבטיח זמינות גבוהה במקרה של כישלונות במרכז נתונים.בהקשר זה, ניתן להפיץ דוגמאות משניות למספר מרכזי נתונים, כפי שמוצג בתמונה הבאה.בנוסף, ניתן להגדיר דוגמאות משניות עם משאבים מוגבלים או מגבלות רשת עם עדיפות כדי לשלוט בחירה שלהם כראשונה במקרה של כישלון. קבוצה משולבת: גמישות אופקית והזמינות גבוהה עם מורכבות תפעולית MongoDB תומך בקנה מידה אופקי על-ידי חיתוך נתונים במספר מקרים ראשוניים כדי להתמודד עם עומסי עבודה אינטנסיביים כתיבה וגודל נתונים גדל. כדי לאפשר sharding, סוגים נוספים של כפתורים MongoDB נדרשים: מקרה של mongos פועל כמסלול שאילתות, ומספק ממשק בין יישומי הלקוח לבין הקבוצות המפוזרות. כתוצאה מכך, הלקוחות לעולם אינם מתקשרים ישירות עם הפריטים, אלא תמיד באמצעות מסלול שאילתות. מדריכי query (mongos) מומלץ להפעיל מספר רב של מעבדי שאילתות כדי להבטיח את נגישות הקלאסטר, מכיוון שמעבדי שאילתות הם הממשק הישיר עבור מנהלי הלקוח. אין גבול למספר מעבדי שאילתות, אך מכיוון שהם מתקשרים לעתים קרובות עם שרתים של config, יש לציין כי יותר מדי מעבדי שאילתות יכולים להכעיס את שרתים של config. שרתים של Config מאחסנים את המטא-נתונים של קבוצה משולבת, כולל מצב וארגון עבור כל הנתונים והרכיבים. MongoDB משתמש במפתח shard כדי לקבוע אילו מסמכים שייכים לאיזה shard. בחירות מפתח shard נפוצות כוללות את שדה _id ושדה עם קרדינליות גבוהה, כגון סימן זמן או מזהה משתמש. MongoDB תומך בשלוש אסטרטגיות sharding: מבוסס טווח, מבוסס hash ובוסס אזור. חלוקת sharding ממוקדת מסמכים בין חלקיקים על פי ערך מפתח shard. זה שומר מסמכים עם ערכי מפתח shard קרוב אחד לשני ועובד היטב עבור שאילתות מבוססות טווח, למשל על נתוני סדרת זמן. sharding hashed מבטיח חלוקת sharding שווה בין חלקיקים, אשר מעדיף כתיבת עומסי עבודה. zoned sharding מאפשר למפתחים להגדיר כללים sharding מותאמים אישית, לדוגמה כדי להבטיח כי הנתונים הרלוונטיים ביותר נמצאים על חלקיקים הקרובים ביותר מבחינה גיאוגרפית לשרת היישום. כמו כן, ניתן להפעיל קבוצות שבורות בהגדרה גיאוגרפית כדי להתגבר על כישלונות במרכז נתונים, כפי שמתואר בתמונה הבאה. ארכיטקטורת ScyllaDB - Multi-Primary עבור זמינות גבוהה ופיתוח אופקי שלא כמו MongoDB, ScyllaDB אינו עוקב אחר ארכיטקטורות RDBMS הקלאסיות עם כבל ראשוני אחד וכמעט כוכבים משניים, אלא משתמש במבנה מפוזר, שבו כל הנתונים מפוזרים באופן שיטתי ומייצגים בין כוכבים מרובים המייצגים קבוצה. קבוצה היא אוסף של כבלים מחוברים ביניהם מאורגנים לארכיטקטורה טבעת וירטואלית, שעל פניו נתונים מפוזרים. הטבעת מחולקת ל-vNodes, המייצגים מגוון של תוויות המוענקות לכונן פיזי, והם מתפשטים בין כוננים פיזיים על פי גורם ההפקה המוגדר עבור מרחב המפתח. כל הכוננים נחשבים שווים, במובן רב ראשוני. ללא מנהיג מוגדר, לכונן אין נקודה אחת של כישלון. הכוננים יכולים להיות שרתים מקומיים בודדים, או שרתים וירטואליים (מקרים ענן ציבוריים) המורכבים מחלקה חלקית של חומרה על שרת פיזי גדול יותר. בכל כונן נתונים מחולקים כל המשתמשים מתקשרים זה עם זה באמצעות פרוטוקול זה מחליט באיזו מחלקה נתונים נכתבים ומחפש את רשומות הנתונים במחלקה הנכונה באמצעות האינדקסים. פרוטוקול GOSIP כשמדובר בקנה מידה, ארכיטקטורה של ScyllaDB מיועדת לגיזום אופקי בקלות במשרתים ובאזורים מרובים. Sharding ב- ScyllaDB נעשה ברמה של הטבלה, וטבלה יכולה להיות sharded בהתבסס על מפתח מחלקה. המפתח לגיזום יכול להיות עמודה אחת או מורכב של עמדות מרובות. ScyllaDB תומך גם sharding מבוסס טווח, שבו שורות מחולקות בין חתיכות בהתבסס על טווח הערכים של מפתח מחלקה, כמו גם sharding מבוסס hash כדי להפיץ את הנתונים באופן שווה ולהימנע מקומות חמים. בנוסף, ScyllaDB מאפשר לדירוג נתונים בין מרכזי נתונים מרובים כדי להבטיח זמינות גבוהה יותר ועיכובים נמוכים יותר. מצד הלקוח, יישומים עשויים או לא עשויים להיות מודעים לביצוע מרכזי נתונים מרובים, וזה תלוי בפיתוח היישומים להחליט על ההכרה למרכזי נתונים אחוריים. זה ניתן להגדיר באמצעות אפשרויות עקביות קריאה וכתיבה אשר קובעים אם שאילתות מתבצעות נגד מרכזי נתונים יחידים או בכל מרכזי נתונים. נקודת מבט השוואתית על גודל על ארכיטקטורות מפוזרות של MongoDB ו- ScyllaDB כשמדובר בהרחבה, יש לשקול את הגישות ההפצה השונות באופן משמעותי של ScyllaDB ו- MongoDB, במיוחד עבור קבוצות מנוהלות באופן עצמאי הפועלות במקום או על IaaS. האדריכלות של MongoDB מאפשרת בקלות להגדלת עומסי עבודה כבדים קריאה על-ידי הגדלת מספר המשלימים בסדרת עותקים. עם זאת, על מנת להגדיל את עומסי העבודה עם יחס כתיבה משמעותי, יש צורך להמיר את קבוצת העתקים לקבוצת העתקים, וזה מביא אתגרים רבים. ראשית, יש צורך בשני שירותים נוספים של MongoDB: n routers לשאילתה (mongos) ו- replica set of config servers כדי להבטיח זמינות גבוהה. כתוצאה מכך, משאבים רבים יותר נדרשים כדי לאפשר חלוקת במקום הראשון. יתר על כן, המורכבות המבצעית גדלה בבירור. לדוגמה, קבוצה חלוקת עם שלושה חלקיקים דורשת קבוצת חלוקת של שלושה מקבילים של מונגו, קבוצת חלוקת של שלושה שרתים ושלושה חלקיקים – כל חלקיק מורכב אחד עיקרי ושני האתגר השני הוא חלוקת נתונים בקבוצת החולצות. כאן, MongoDB מיישם משימה רקע מתמשכת המתבצעת באופן אוטונומי, אשר מפעילה מחדש את חלוקת הנתונים בין החולצות. ההחלוקה לא מתרחשת ברגע שהחולצה חדשה נוספת מוסיפה לקבוצת, אלא ברגע שהגבולות הפנימיים מסוימים מגיעים. כתוצאה מכך, הגדלת מספר החולצות תגדיל את הקבוצת באופן מיידי, אך עשויה להיות בעלת אפקט גודל מתעכב. עד ל- MongoDB גירסה 5.0, מהנדסי MongoDB עצמם ממליצים לא לחולל, אלא להגדיל באופן אנכי עם מכונות גדולות יותר אם אפשר. הגדלת קבוצת ScyllaDB היא פשוטה וקלה למשתמש הודות לארכיטקטורה מרובה ראשונית של ScyllaDB. כאן, כל צומת שווה, ואין צורך בשירותים נוספים כדי להגדיל את הקבוצה למאות צורות. יתר על כן, חלוקת נתונים מופעלת מיד לאחר הוספת צומת חדש לקבוצת. בהקשר זה, ScyllaDB מציעה יתרונות ברורים לעומת MongoDB. ראשית, הודות להתייחסות hashing עקבית, נתונים לא צריכים להיות מחולקים ברחבי הקבוצת המלאה, רק בין תת קבוצה של צורות. שנית, חלוקת נתונים מתחילה עם הוספת הצומת החדשה, אשר מרחיבה את זמן הפעולה של הגדלת. ההבדלים העיקריים ביכולת הסקלאות מצטברים בטבלה הבאה: מסקנות ו Outlook כאשר אתה משווה את שני המשתתפים בסיס נתונים, אתה תמיד לגלות כמה מקבילים, אבל גם מספר הבדלים משמעותיים. . שני מסדי הנתונים מתייחסים למקרים של שימוש דומים ויש להם אסטרטגיה דומה למוצר ולקהילה. אבל כשמדובר בצד הטכני, אתה יכול לראות את הגישות השונות ואת המוקד. שני מסדי הנתונים בנויים כדי לאפשר זמינות גבוהה באמצעות ארכיטקטורה מפוזרת. אבל כשמדובר על עומסי עבודה היעד, MongoDB מאפשר להתחיל בקלות עם הפעלת ערך יחיד או קבוצת עותקים המתאימים היטב עבור עומסי עבודה קטנים ובינוניים, בעוד פתרון עומסי עבודה גדולים ומערכות נתונים הופך לאתגר עקב ארכיטקטורה טכנית. NoSQL ScyllaDB נגד MongoDB ScyllaDB מטפל בבירור בלוחות עבודה קריטיים ביצועים הדורשים גמישות קלה וגבוהה, ביצועים גבוהים, עיכוב נמוך ויציב, וכל דבר בהתקנה מרובה מרכזי נתונים. כדי לספק תובנות נוספות על יכולות הביצועים השונות שלהם, אנו מספקים השוואת ביצועים גלויה ומשכפלת בדו"ח ביקורות נפרד המחקר את הביצועים, הגדלת היכולת ואת העלויות עבור MongoDB Atlas ו- ScyllaDB Cloud. תוספת ScyllaDB vs. MongoDB השוואה פרטים לראות את המלא עבור גרסה מורחבת של השוואה טכנית זו, כולל פרטים השוואה: BenchANT MongoDB vs ScyllaDB השוואה מודל נתונים שפת Query דוגמאות למשתמשים ודוגמאות לקוח אפשרויות עקביות נתונים ניסיון פעיל ממקור ראשון
