Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. בתוך תחום NoSQL, ScyllaDB ו- MongoDB הם שני בעלי חיים שונים לחלוטין. MongoDB אינו זקוק להכרה. ארכיטקטורה קרובה למכשירי המתכת של ScyllaDB מאפשרת עיכוב נמוך צפוי בביצועים גבוהים. , ואחרים רבים שמשתלבים ולפוצץ את הקיר עם מסדי הנתונים הקיימים שלהם. NoSQL מחלוקת טרקטור יישומי נתונים אינטנסיביים במקום זאת, בואו נסתכל על איך שני מסדי הנתונים השונים הללו עשויים להתקיים יחד בתוך אותה שורה של טכנולוגיות - כיצד הם שונים באופן יסודי, ואת המקרים הטובים ביותר לשימוש עבור כל אחד. אז מתי אתה צריך להשתמש ScyllaDB לעומת MongoDB ולמה? במקום לספק את נקודת המבט של הספק, אנחנו הולכים לשתף את התובנות של חובב קוד פתוח שיש לו ניסיון נרחב בשימוש בשני ScyllaDB ו MongoDB בייצור: אלכסיס ג'ייקוב, CTO של Numberly. הנה שלוש נקודות מפתח מהדיון הטכנולוגי המפורט שלו: הגדלת כתיבה מורכבת יותר ב- MongoDB היחידה הבסיסית של טופולוגיה של MongoDB נקראת קבוצה של עותקים, המורכבת מאחד החלקים העיקריים, ולעתים קרובות מספר חלקים משניים (חשוב על עותקים חמים). רק החלק העיקרי מותר לכתוב נתונים. חלוקת נתונים על כל קבוצת העתקה של MongoDB דורשת שימוש במפתח מיוחד כדי לציין איזה נתונים כל קבוצת העתקה אחראית, כמו גם יצירת קבוצת העתקה של מטא-נתונים אשר עוקבת אחר איזה חלק של נתונים חי על כל עתקה (השולש הכחול בתרשים למטה). המורכבות של הסקלינג כותבים ב MongoDB יש את כל הצמיגים האלה מוביל עלויות תפעול ותחזוקה גבוהות יותר, כמו גם משאבים מבוזבזים כי אתה לא יכול ללחוץ על IO של הצמיגים של הצמיגים, מה שהופך את קבוצות MongoDB מופרזות האויב הגרוע ביותר של העלות הכוללת של הבעלות שלך כמו אלכסיס ציין. עבור ScyllaDB, הסקלינג כותבים הרבה יותר פשוט. הוא הסביר, "בצד של ScyllaDB, אם אתה רוצה להוסיף יותר עוצמה, אתה פשוט להוסיף כפתורים. אלכסיס קשור את הסטרימינג הזה: "אני יכול לכתוב ספר עם סיפורי מלחמה על נושא זה בדיוק. הסיבה העיקרית לכך היא העובדה MongoDB אינו מחבר את עומס העבודה ל-CPUs. וההחלקה, ההפצה של נתונים בין קבוצות רבייה בקבוצות נעשית על ידי עבודה ברקע (התאמה). מתאם זה תמיד פועל, תמיד מסתכל על איך החלקה צריכה להיעשות, ותמיד מבטיח כי הנתונים מתפשטים ומאוזנים ברחבי הקבוצות. זה לא טבעי כי זה לא מבוסס על חיתוך עקבי. זה משהו שצריך לחשב שוב ושוב. זה מחלק את הנתונים לחתיכות ולאחר מכן מעביר אותו סביב. זה יש השפעה ישירה על הביצועים של הקבוצת MongoDB שלך כי אין בידוד של עומס העבודה הזה לעומת עומס העבודה בפועל שלך MongoDB מעדיפה גמישות על פני ביצועים, בעוד ScyllaDB מעדיפה ביצועים עקביים על פני גמישות ל-ScyllaDB ול-MongoDB יש עדיפויות שונות במונחים של גמישות וביצועים. בחלק הקדמי של מודל הנתונים, MongoDB תומך באופן מקורי בשאלות גיאוגרפיות, חיפוש טקסט, צינורות אגרגציה, שאילתות גרף וזרמים של שינויים. למרות ש- ScyllaDB – חנות עמודה רחבה (נקראת ערך מפתח) – תומכת בסוגים מוגדרים על-ידי המשתמש, במחשבים ובעסקאות קלות, האפשרויות למודל נתונים מוגבלות יותר מאשר ב- MongoDB. אימות תוכנה לפני הזנת נתונים, ScyllaDB הנתונים הללו מתאימים לתכנית המוגדרת. אופציה דורש שאלה היא גם פשוטה יותר עם MongoDB מכיוון שאתה רק מסנן ואינטראקציה עם JSON. זה גם גמיש יותר, טוב יותר או גרוע יותר. MongoDB מאפשר לך להוציא כל סוג של שאלה, כולל שאילתות שגורמות ביצועים לא אופטימליים עם עומס העבודה הייצור שלך. ScyllaDB לא יאפשר את זה. אם אתה מנסה, ScyllaDB יזהר אותך. אלקסיס סיכם את ההבדלים העיקריים מנקודת מבט של פיתוח: "MongoDB מעדיף גמישות על פני ביצועים. זה קל לתקשר עם זה וזה לא יפריע לך. אבל זה יש השפעות על הביצועים - השפעות כי הם טובים עבור כמה עומסי עבודה, אבל בלתי מקובלים עבור אחרים. מצד שני, ScyllaDB מעדיף ביצועים עקביים על פני גמישות. זה נראה קצת יותר קבוע קצת יותר קשיח מבחוץ. אבל שוב, זה לטובת עצמך, כך שאתה יכול לקבל ביצועים עקביים, לפעול היטב ואינטראקציה טובה עם המערכת. חשוב לציין שגם שאילתות שעוקבות אחר נוהלי ביצועים הטובים ביותר יתנהגו באופן שונה ב- MongoDB מאשר ב- ScyllaDB. לא משנה כמה אתה זהיר, לא תוכל להתגבר על העונש על ביצועים הנובע מההבדלים האדריכליים הבסיסיים. יחד, ScyllaDB ו- MongoDB הם שילוב גדול של NoSQL "זה לא משחק מוות; אנחנו משתמשים מאושרים של שניהם MongoDB ו ScyllaDB," Alexys המשיך. המספרים בוחרים את מסד הנתונים הטוב ביותר עבור דרישות הטכניות של כל מקרה שימוש. ב Numerly, MongoDB משמש לשני סוגים של מקרים של שימוש: Web backends עם REST APIs ואולי תוכניות גמישות. שאלות בזמן אמת על נתונים התנהגותיים בלתי צפויים. לדוגמה, חלק מהיישומים של Numberly מתפוצצים עם נתוני מעקב אינטרנט שהלקוחות שלהם אוספים ומשלחים (כל לקוח עם יישומים משלו המפותחים באופן פנימי). Numberly אין דרך להטיל תוכנית קפדנית על נתונים אלה, אבל היא צריכה להיות מסוגלת לבקש ולעבד אותם. ScyllaDB משמש לשלושה סוגים של מקרים של שימוש ב- Numberly: צינורות נתונים רגישות לעיכוב בזמן אמת.זה כרוך בהעשיית נתונים רבה, שם ישנם מקורות נתונים מרובים שצריכים להיות מקושרים, בזמן אמת, על צינורות נתונים.לפי אלקסיס, "זה קשה לעשות ... ואתה צריך להבטיח אבטחת עיכוב חזקה כדי לא לשבור את SLAs [הסכמים ברמת השירות] של היישומים והתהליכים של נתונים שהלקוחות שלך מסתמכים עליהם." Numberly גם מערבבת הרבה עומסי עבודה במלאי ובזמן אמיתי ב- ScyllaDB כיוון שהיא מספקת את הטוב ביותר משני העולמות (כפי שפרסם Numberly בעבר). "היינו Hive על מסלול אחד ו- MongoDB על השני. אחסון אינטרנט באמצעות GraphQL, אשר מחייב תוכנית קפדנית. חלק מהאחסון האינטרנט של Numberly מיושמים ב- GraphQL. בעת עבודה עם APIs המבוססים על תוכניות, זה הגיוני שיש מסד נתונים המבוסס על תוכניות עם עיכוב נמוך וזמינות גבוהה. אלכסיס מסכם: "הרבה מההנדסים האחוריים שלנו, כמו גם מהנדסי החזית, מקבלים את ScyllaDB. אנו רואים מגמה של אנשים שמקבלים את ScyllaDB, יותר ויותר אנשים טכנולוגיים שואלים 'יש לי תיק שימוש זה, האם ScyllaDB יהיה מתאים טוב?' רוב הזמן, התשובה היא 'כן'. Bonus: More Insights from אלכסיס ג'ייקוב אלקסיס הוא תורם נדיב מאוד לקהילות קוד פתוח, ביחס לקוד ולשיחות כנס. https://ultrabug.fr/ אודות סינתה דאנלופ סינתה היא מנהל בכיר של אסטרטגיה תוכן ב ScyllaDB. היא כותבת על פיתוח תוכנה והנדסת איכות במשך 20+ שנים.
