מסד הנתונים של Messenger (חלק 1): עיצוב מסגרת הבסיס

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

• חלק 1: עיצוב מסגרת הבסיס
• חלק 2: חלוקה "למטרות רווח"

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

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

שלב 1: כמה פרטים עסקיים

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

ומהן המשימות של עסק?.. נתבונן בדוגמה של וסילי, ראש מחלקת הפיתוח.

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

בואו נתעכב על רשימה זו של צרכים "ברורים" לעת עתה.

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

שלב 2: מעגל לוגי מינימלי

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

הבה נתקן את הדיאגרמה הלוגית שכבר התקבלה של קשרי ישויות. כדי להפוך את המודל שלנו לקל יותר להבנה, נשתמש באפשרות התצוגה הפרימיטיבית ביותר דגמי ER ללא הסיבוכים של סימוני UML או IDEF:

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

לצייר דיאגרמות פשוטות ככל האפשר - רוב האנשים שתראה אותם להם אינם מומחים בקריאת UML/IDEF. אבל הקפד לצייר.

שלב 3: שרטוט מבנה הטבלה

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

מבנה הטיוטה במסד הנתונים שלנו ייראה כך:
טבלאות: RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

טבלאות: EN

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

הדבר הפשוט ביותר בעת תיאור פורמט הוא להתחיל "להתיר" את גרף החיבור מטבלאות שאין להן הפניות את עצמם לאף אחד.

שלב 4: גלה צרכים לא ברורים

זהו, תכננו מאגר מידע בו תוכלו לכתוב בצורה מושלמת ו איכשהו לקרוא.

בואו לשים את עצמנו בנעלי המשתמש בשירות שלנו – מה אנחנו רוצים לעשות עם זה?

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

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

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

שלב 5: דנורמליזציה חכמה

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


טבלאות: RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

טבלאות: EN

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

כאן יישמנו שתי גישות טיפוסיות המשמשות בעת יצירת טבלאות עזר:

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

בחלק הבא של המאמר נדבר על יישום חלוקה לתוך המבנה של מסד הנתונים שלנו.

מקור: www.habr.com