לדלג לתוכן

מבני נתונים מתקדמים ברדיס

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

Hashes - כשהערך הוא בעצם אובייקט

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

Sets - חברות בקבוצה בלי כפילויות

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

Sorted Sets - כשצריך גם ייחודיות וגם סדר

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

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

מעבר ללוחות תוצאות, sorted sets שימושיים גם לתורי עדיפויות - למשל משימות שצריך לעבד לפי זמן תפוגה, כשה-score הוא חותמת הזמן, וכל פעם שולפים את המשימה עם הזמן הכי מוקדם.

Lists - תורים פשוטים בסדר הגעה

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

למה זה משנה בפועל

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

איך מתחילים לעבוד עם זה בפועל

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

מתלבטים איזה מבנה נתונים מתאים לבעיה שאתם פותרים? זה בדיוק סוג השאלה שכדאי לשאול בקהילה שלנו.

הצטרפו לקהילה בדיסקורד

לסיכום

Redis הרבה יותר עשיר ממה שנראה במבט ראשון. Hashes נותנים אחסון טבעי לאובייקטים, sets נותנים בדיקת חברות וחיתוכים מהירים, sorted sets נותנים סדר וייחודיות ביחד - בדיוק מה שצריך ללוחות תוצאות ותורי עדיפויות, ו-lists נותנים תורים פשוטים בלי תשתית נוספת. להכיר את המבנים האלה זה ההבדל בין להשתמש ברדיס לבין באמת לנצל אותו.