מחפש בסיס נתונים

[Guy Yafe]

מחפש בסיס נתונים

שלום לכולם,
מתייעץ באיזה בסיס נתונים הכי נכון להשתמש:
אני צריך לשמור עדכונים מהמשתמש, כאשר עדכונים מגיעים פעם בשנייה.
העדכונים הם אוסף מיקומים במרחב.
הדבר היחיד שחשוב הוא שמירה של העדכונים למשך 24 שעות אחורה. קצב השמירה קריטי, ואילו שליפות, שאילתות וניתוח נתונים לא רלוונטיים מבחינת ביצועים.
המחשבה שלי היא לשמור בבסיס נתונים key/value (אולי elastic?), ולשים בו 86,400 מפתחות שמייצגים את השנייה ב-24 שעות האחרונות.
בכל רשומה אני אכניס את כל הגילויים שהתקבלו בשנייה המתאימה
(מדובר במידע בינארי שניתן לדחוס לכמה מאות KB).

אשמח לתובנות נוספות,
גיא

 

[Guy Yafe]

עדכון: טעות במינוח

elastic כמובן לא קשור לעניין.

 

[eveik]

מה סוג השליפות שלך?

האם אתה תשלוף רק לפי השעה? או שלפעמים תרצה לעשות שליפות שדורשות ממך לעבור על כל הדאטה הקיים?
&nbsp
ואני משער שאולי התכוונת לredis במקום elastic?

 

[Guy Yafe]

לא יודע, לא אכפת

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

 

[אוהב להתווכח]

אם הביצויים לא מעניינים

אני הייתי שומר key value של timestamp "מלא" וערך.
אתה יכול להשתמש בדטה בייס כמו רדיס או בדטה בייס רלציוני רגיל ולשים שני עמודות.
ברדיס אתה יכול להגדיר זמן מחיקה אוטמטי אחרי X זמן - 24 שעות במקרה שלך. אם בא לך אתה יכול לשמור היסטוריה ולתשאל רק את ה-24 שעות אחרונות.
גם בדטה בייס רלציוני אצה יכול להגדיר JOB שמוחק כל מה שישן יותר מ-24 שעות.
אם כי לדעתי כדאי לך לשמור היסטוריה של לפחות יום אחד נוסף.

 

[Guy Yafe]

אני מעוניין להימנע כמה שיותר מ - cleanup

האם תחת ההנחה שאני שומר בדיוק 24 שעות אחורה, לא עדיף למספר את הרשומות מ0-86399, וכל הזמן לדרוס את הרשומה הרלוונטית (תוך ניהול של הרשומה הראשונה והאחרונה)?
לגבי כמות ההיסטוריה: כאן הכל תלוי בדרישות לקוח: במידת הצורך אגדיר עוד רשומות.
&nbsp
REDIS: ממה שאני רואה ברשת, הוא שומר רק יצוג טקסטואלי של נתונים. האם יש דרך לשמור יצוג בינארי?

 

[אוהב להתווכח]

מכה שאלות

מה רע במחיקה אוטומטית, זה אפשרי בDB רגיל גם באמצעות trigger.? מה רע אגב ב-cleanup? זה לא איזה המצאת הדור. job שעתי שמוחק היסטוריה.
מה יקרה אם יאבדו לך נקודות ולא יגיעו לשרת (וזה יקרה)? לפי הגישה שלך זה יהיה שם ערך מיום קודם. הצורה שאתה מציע גם מאוד לא נוחה לתשאול.
אם אתה רוצה דווקא לפי הגישה שהצעת אני חושב שכבר עדיף לך להשתמש ב-upsert.
&nbsp
אגב, מה רע לך בייצוג טקסטואלי?

 

[Guy Yafe]

תשובות

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

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

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

מחיקה אוטומטית: לא בקיא ביעילות של ה-cleanup, אבל האם זה לא יגרום לי לירידה בביצועים? אם כל 24 שעות אני מוחק 86400 רשומות, אני אשאר עם המון זבל לנקות.

 

[אוהב להתווכח]

key value לא מתאים לך

יהיה לך ממש קשה לתשאל ranges.
&nbsp
אם אתה עושה cleanup פעם ביום או פעם בשעה זה ממש לא יפגע בביצועים לכל מסד נתונים רציני זה כמויות מביכות. בכל מקרה מדובר בהגדלה של הדטה בסדר גודל של עד פי 2.
בנוסף אם אתה עושה טבלה שמסודרת ב-DB לפי ה-TS המחיקה כמעט ולא תשפיע על הביצועים.
אני לא יודע מה הסיכוי בדיוק שיקרה שנקודה תגיע אחרי חברתה או תיעלם לחלוטין אבל זה יקרה יותר ממה שאתה חושב. דווקא הגישה של טבלאות שמקבלות כל ערך שנשמר בהם יעזרו לך להתמודד עם כאלו מצבים אתה שומר כל נקודה שאתה מקבל וכשאתה מתשאל אתה מחליט האם הנקודות ולידיות לך או לא.
אם מהירות הכתיבה כל כך חשובה לך אתה יכול לכתוב ל-queue ברדיס ובמקביל שיהיה thread שיכתוב ל-DB הרצוי שלך בצורה הנכונה.

 

[אוהב להתווכח]

עוד שני שאלות

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

 

[Guy Yafe]

לצערי אני לא יודע

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

 

[אוהב להתווכח]

לא יודע זה לא תשובה

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

 

[user32]

נראה שכמעט כל DB מבוסס key-value יהיה טוב לכם

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

יש רשימה חלקית פה:
https://db-engines.com/en/ranking/key-value+store

ויש אחרים כמו Cassandra, HBase ורבים אחרים. כיוון שכתבת שהדאטה מגיע בJSON, שקול שימוש בMongoDB שהוא אמנם מיועד לdocuments (שם סמנטי לרשומה שמכילה מבנה שלם של properties ואובייקטים מקוננים) אבל במקרה שלך אולי יהיה נכון לבנות כל אובייקט כJSON ולשמור אותו עם הkey הנכון (למשל הtimestamp או hash של הts עם המשתמש או משהו כזה).

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

 

[selalerer]

אבל אפשר גם לא לשים indexים ל-DB רגיל.

ב-redis בכל מקרה הוא יוצר לך hash index על ה-key. מצד אחד זה עולה אבל מצד שני הוא גם מתשמש בזה בכדי לבזר את הגישות על כמה שרתים.
&nbsp
ב-DB רלציוני אתה יכול ליצור טבלה בלי שום אינדקס, גם בלי primary key, ואז אין צורך להכניס את הרשומה לשום אינדקס.
&nbsp
כמו כל דבר בביצועים, זה דורש בדיקות לדעת מה יותר מהיר

 

[user32]

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

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

 

[אוהב להתווכח]

מדובר ב 20K רשומות

גם access אוכל את זה בלי מלח. מי מדבר פה על ביזור.
כשיהיו לו צרות שיפתור אותם. כרגע מה שהוא יעשה יהיה טוב.
כל השאלה היא over engineering מוחלט.

 

[user32]

לכן אמרתי שכל DB יתאים

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

 

[HarmonicWave]

רוב הסיכויים שהמוצר שלכם לא יגיע לשלב הביזור

&nbsp
תמצא כלי שנוח לך לעבוד איתו ואל תמציא את הגלגל - DB זה מסוג הכלים שאתה לא רוצה לממש לבד.
תכתוב קוד מודלרי שלא יהיה כואב לשנות ותתמקד בלוגיקה העסקית.

 

[יבגניי34]

Redis + zest = fun and profit

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

 

[יבגניי34]

הכוונה ל ZSET כמובן.