טריק מוזר אחד להאצת צוותי פיצ'רים!
מהנדסים בכירים שונאים את זה!
Photo by Danny Howe on Unsplash
תוכן עניינים
כשמתכננים מערכת או תכונה חדשה, קל להיתקע בעיצוב הסכֵמה. במאמר זה אשתף טריק נחמד שהשתלם לאורך הקריירה שלי.
נסו את התמדת הנתונים הפשוטה ביותר האפשרית כשמתכנים מערכת או תכונה חדשה.
לעתים קרובות מדי, אני רואה צוותים שבוחרים ב-SQL או MongoDB כאפשרות היחידה לאחסון נתונים. ברור, אף אחד לא מפוטר על בחירה ב-SQL. אבל מה אם אגיד לכם שיש דרך פשוטה, מהירה וזולה יותר להתחיל?
ייתכן שחנות KV (מפתח-ערך) היא כל מה שצריך. משהו כמו Redis או S3.
זו לא תמיד הבחירה הנכונה, אבל אולי לעתים קרובות יותר ממה שאתם חושבים.
שכבת אחסון פשוטה יכולה להאיץ במידה מתונה את הפיתוח המוקדם על ידי שימוש חוזר בקוד שכבת הנתונים והימנעות מעלויות הקשורות לשינויים בעיצוב הסכֵמה ובהגירות. שינויים יקרו בכל מקרה; תנו לקוד להתמודד איתם כמה שיותר זמן. עדיף להימנע מטיפול בשינויים בשני מקומות.
רווחי ביצועים סבירים מכיוון שחיפושי key מותאמים היטב, וכתיבות יכולות להרוויח מעדכונים מצטברים.
חשיבה במפתחות
זה עלול להרגיש מוזר לתכנן עם תבנית מפתח-ערך קודם, במיוחד אם אתה רגיל לתכנן מערכות עם היררכיות אובייקטים או דיאגרמות ישויות-קשרים וליישם אותן ישירות ב-SQL.
כנראה השתמשת בתבניות מפתח-ערך בעבר! הן נמצאות בכל מקום, מקובצי תצורה וכתובות URL ועד לאחסון אובייקטים בסגנון S3! בכל פעם שאתה מתמודד עם נתונים דרך ערך ID ייחודי, נחש מה? עוד תבנית מפתח-ערך! (אם כי לא בהכרח מאגר מפתח-ערך.)
תכנון עם מפתחות
למעשה, ניתן לייצג כמעט את כל הנתונים באמצעות תבניות מפתח-ערך. (למעשה, מאגרי נתונים רבים מסדר גבוה יותר בנויים על תבניות מפתח-ערך ברמה נמוכה יותר.) בואו נסתכל על כמה דוגמאות:
user/123 {id: 123, ...}user/123/block ['user/456', 'user/789']user/123/groups ['admin', 'staff']user/420/friends ['user/456', 'user/789']
group/admin {user: '*:rw'}group/default {user: '*:r'}
product/42/discount/<UUID> {percentOff: '10%'}product/42/discount/<UUID> {percentOff: '20%', minTotal: 100.0}אולי שמתם לב, אבל ה-ID הוא לעתים קרובות מפתח בפני עצמו! זוהי תבנית נפוצה במאגרי מפתח-ערך. המפתח הוא לעתים קרובות מורכב מסוג הישות ומהמזהה הייחודי. (למשל user/123, user:456)
KVs כגרפים ועצים?
זה יכול להיות מועיל לייצג מבני נתונים מורכבים כמו גרפים או עצים באמצעות תבניות מפתח-ערך. (שוב, כתובות REST URL הן דוגמה מצוינת לכך.)
היררכיית המפתחות (user/420 -> user/420/friends) מקודדת באופן טבעי קשר גרפי בין ה-user לבין ה-friends שלו.
זוהי דרך מהירה וזולה לסריאליזציה של מבני נתונים גרפיים. במיוחד אם אינך זקוק למורכבות של מסד נתונים גרפי (כמו Neo4j).
מתי להשתמש בתבניות KV
- כשאתה זקוק לקנה מידה עצום. (מיליארדי או אפילו טריליוני זוגות KV.)
- כשאתה ניגש לנתונים בעיקר דרך מפתח ייחודי.
- כשאתה זקוק למבני נתונים פשוטים.
- כשהנתונים שלך בעלי היררכיה, מבנה גרף או עץ.
מתי להימנע מתבניות KV
אל תאחסן דברים כמו תגובות בבלוג בזוג KV בודד. לדוגמה, post/666 -> {comments: [...יותר מדי...]}. במקום זאת, השתמש ב-post/666/comments/1, או post/666/comments/<UUID> וכו’. או עבור לטבלת SQL.
- כשאתה צריך לחפש לפי מאפיינים (לא מפתח או מזהה) במערך הנתונים שלך.
- כשאתה צריך לבצע JOIN בין מספר ישויות.
- כשאתה צריך לאכוף אילוצים או קשרים מורכבים.
כשאתה צריך יותר מ-KV
כשדרישות הפרויקט מתפתחות באופן טבעי, ייתכן שתצטרך לעשות יותר ממה שמאגר ה-KV שלך תומך בו. בשלב זה תצטרך לשקול מעבר למאגר נתונים מורכב יותר.
החדשות הטובות הן שהעברה של מאגר KV יחיד ל-SQL קלה יחסית יותר מאשר העברת סכמת SQL מורכבת לתוך מאגר KV. (עם טבלאות מרובות, אינדקסים, אילוצים וכו’). עשיתי זאת פעמים רבות עם סקריפט בן 50 שורות.
מניסיון אישי, גיליתי שאיכות עיצובי SQL גבוהה יותר אם מתחילים תחילה עם תבנית KV. זה מאלץ אותך לחשוב על הנתונים בצורה שונה, ולהבין טוב יותר בדיוק מה אתה באמת צריך מ-SQL.
צעדים הבאים
הדרך הטובה ביותר ללמוד היא לנסות! אם אתה מעוניין לחקור תבנית זו עוד, אני ממליץ לבנות דברים עם Redis, DynamoDB או S3. כולם מאגרי KV מצוינים עם פשרות שונות.
Fact Service - פרויקט עזר
בדוק את “Fact Service,” פרויקט עזר בקוד פתוח ב-GitHub.
זהו API RESTful עצמאי המיישם שירות נתוני KV.
הוא כולל מתאמי נתונים רבים. כולל עבור Postgres, Redis, DynamoDB, Firestore ו-Cassandra! (עם פקודות Docker כדי להתחיל במהירות.)
Fact Service נועד להיות פרויקט התחלתי ולימוד, תפצלו אותו ובנו שירות נתוני KV משלכם!
סיכום
אני מקווה שמצאת מאמר זה מועיל! אם יש לך שאלות או משוב, אל תהסס להגיב או @ אותי ב-Twitter.