קסנדרה. איך לא למות אם אתה רק מכיר את אורקל

היי הבר.

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

מה כל כך טוב בקסנדרה? זהו מסד נתונים NoSQL שתוכנן ללא נקודת כשל אחת שמתרחב היטב. אם אתה צריך להוסיף כמה טרה-בייט עבור מסד נתונים כלשהו, ​​אתה פשוט מוסיף צמתים לטבעת. להרחיב אותו למרכז נתונים אחר? הוסף צמתים לאשכול. להגדיל את ה-RPS המעובד? הוסף צמתים לאשכול. זה עובד גם בכיוון ההפוך.

במה עוד היא טובה? מדובר בטיפול בהרבה בקשות. אבל כמה זה הרבה? 10, 20, 30, 40 אלף בקשות בשנייה זה לא הרבה. 100 אלף בקשות בשנייה להקלטה - גם כן. יש חברות שאמרו שהן שומרות 2 מיליון בקשות בשנייה. הם כנראה יצטרכו להאמין בזה.

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

לא כל מה שנראה אותו דבר עובד אותו הדבר

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

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

הסיבה לכך היא שקסנדרה היא מסד נתונים היברידי: הוא מספק בו זמנית ערך מפתח ומאחסן נתונים בעמודות רחבות. ב-Java או Kotlin, אפשר לתאר את זה כך:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

כלומר, מפה שמכילה גם מפה ממוינת. המפתח הראשון למפה זו הוא מקש Row או מפתח Partition - מפתח המחיצות. המפתח השני, שהוא המפתח למפה שכבר ממוינת, הוא מפתח Clustering.

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

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

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

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

כיצד יפעלו המשתמשים שלנו? חלקם ילכו לצומת אחד, חלקם לאחר, וחלקם לשלישי. התוצאה היא טבלת hash רגילה, המכונה גם מפה, הידועה גם כמילון ב-Python, או מבנה ערכי מפתח פשוט ממנו נוכל לקרוא את כל הערכים, לקרוא ולכתוב לפי מפתח.

בחר: כאשר אפשר סינון הופך לסריקה מלאה, או מה לא לעשות

בוא נכתוב משפט נבחר: select * from users where, userid = . מסתבר כמו באורקל: אנחנו כותבים select, מציינים את התנאים והכל עובד, המשתמשים מקבלים את זה. אבל אם תבחר, למשל, משתמש עם שנת לידה מסוימת, קסנדרה מתלוננת שהיא לא יכולה למלא את הבקשה. בגלל שהיא לא יודעת כלום על איך אנחנו מפיצים נתונים על שנת הלידה - יש לה רק עמודה אחת שמצוינת כמפתח. ואז היא אומרת, "בסדר, אני עדיין יכולה למלא את הבקשה הזו. הוסף אפשר סינון." אנחנו מוסיפים את ההנחיה, הכל עובד. וברגע הזה משהו נורא קורה.

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

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

ויש לה גם מפתח, שאנו קוראים לו מפתח האשכולות. מפתח זה, אשר, בתורו, מורכב מהעמודות שאנו בוחרים, בעזרתן קסנדרה מבינה כיצד הנתונים שלה ממוינים פיזית וימוקמו בכל צומת. כלומר, עבור מפתח Partition כלשהו, ​​מפתח Clustering יגיד לך בדיוק איך לדחוף את הנתונים לעץ הזה, באיזה מקום הוא יתפוס שם.

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

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

אנחנו קובעים מיון ומטילים הגבלות

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

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

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

בכל מצב לא ברור, צור טבלה חדשה

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

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

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

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

אנו בוחרים את המפתחות לחלוקה כך שהם יחולקו בצורה נורמלית. אנחנו לא רוצים שה-hash של המפתחות שלנו ייפול לטווח צר אחד. כלומר, שנת הלידה בדוגמה למעלה היא דוגמה רעה. ליתר דיוק, זה טוב אם המשתמשים שלנו מחולקים רגיל לפי שנת לידה, ורע אם אנחנו מדברים על תלמידי כיתות ה' - החלוקה שם לא תהיה טובה במיוחד.

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

והדבר הכי חשוב: אם נצטרך לשלוף את אותם נתונים ב-100 דרכים שונות, אז יהיו לנו 100 טבלאות שונות.

מקור: www.habr.com