מסד הנתונים הזה עולה באש...

תן לי לספר סיפור טכני.

לפני שנים רבות, פיתחתי אפליקציה עם תכונות שיתוף פעולה מובנות בה. זה היה מחסנית ניסיונית ידידותית למשתמש שניצלה את מלוא הפוטנציאל של React ו-CouchDB המוקדמים. זה סינכרן נתונים בזמן אמת באמצעות JSON OT. נעשה בו שימוש פנימי בתוך החברה, אך ישימותו הרחבה והפוטנציאל בתחומים אחרים היו ברורים.

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


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

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

עיצוב סנכרון יומיומי

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

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

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

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

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

הראשון נקרא מסד נתונים בזמן אמת של Firebase, ושנית - Firebase Cloud Firestore. שניהם מוצרים מ חבילת Firebase גוגל. ממשקי ה-API שלהם נקראים בהתאמה firebase.database(…) и firebase.firestore(…).

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

כי אתה צריך לציין Firebase בשאלת Firebase, ו חנות האש בשאלה על Firebase, לפחות לפני כמה שנים ב-Stack Overflow.

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

ניצחון פירוס

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

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

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

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

הוא הופיע מחדריו והכריז:

"מסמך JSON אחד גדול? לא. אתה תפצל את הנתונים למסמכים נפרדים, שכל אחד מהם יהיה בגודל של לא יותר מ-1 מגה-בייט".

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

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

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

אז אם קיווית להכניס את GeoJSON ל-Firestore שלך, תגלה שזה לא אפשרי. שום דבר לא חד מימדי אינו מקובל. אני מקווה שאתה אוהב את Base64 ו/או JSON בתוך JSON.

"יבוא וייצוא של JSON באמצעות HTTP, כלי שורת פקודה או פאנל ניהול? לא. תוכל לייצא ולייבא נתונים ל-Google Cloud Storage בלבד. ככה זה נקרא עכשיו, אני חושב. וכשאני אומר "אתה", אני פונה רק לאלה שיש להם אישורי בעלי פרויקט. כל השאר יכולים ללכת וליצור כרטיסים".

כפי שאתה יכול לראות, קל לתאר את מודל הנתונים של FireBase. הוא מכיל מסמך JSON ענק אחד שמשייך מפתחות JSON לנתיבי כתובת URL. אם אתה כותב עם HTTP PUT в / FireBase הוא הבא:

{
  "hello": "world"
}

ה GET /hello יחזור "world". בעיקרון זה עובד בדיוק כפי שהיית מצפה. אוסף אובייקטים של FireBase /my-collection/:id שווה ערך למילון JSON {"my-collection": {...}} בשורש, שתכולתו זמין ב /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

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

במילים אחרות, מסד הנתונים תואם 100% JSON(*) ועובד מצוין עם HTTP, כמו CouchDB. אבל בעצם אתה משתמש בו דרך ממשק API בזמן אמת שמפיק שקעי אינטרנט, הרשאות ומנויים. לפאנל הניהול יש את שתי היכולות, המאפשר גם עריכה בזמן אמת וגם ייבוא/ייצוא של JSON. אם תעשו את אותו הדבר בקוד שלכם, תופתעו לגלות כמה קוד מיוחד יתבזבז כשתבינו ש-patch and diff JSON פותר 90% מהמשימות השגרתיות של טיפול במצב מתמשך.

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

הם לקחו מסד נתונים NoSQL בזמן אמת והפכו אותו לבסיס איטי שאינו SQL עם חיבור אוטומטי ועמודה נפרדת ללא JSON. משהו כמו GraftQL.

ג'אווה חמה

אם Firestore הייתה אמורה להיות יותר אמינה וניתנת להרחבה, אז האירוניה היא שהמפתח הממוצע יקבל פתרון פחות אמין מאשר בחירת FireBase מחוץ לקופסה. סוג התוכנה ש-Grumpy Database Administrator צריך דורשת רמת מאמץ וקליבר של כישרון שהוא פשוט לא מציאותי עבור הנישה בה המוצר אמור להיות טוב. זה דומה לאופן שבו HTML5 Canvas אינו תחליף לפלאש כלל אם אין כלי פיתוח ונגן. יתרה מכך, Firestore שקועה בשאיפה לטוהר נתונים ואימות סטרילי שפשוט לא מתיישב עם האופן שבו המשתמש העסקי הממוצע אוהב לעבוד: מבחינתו הכל אופציונלי, כי עד הסוף הכל טיוטה.

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

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

אני לא יודע את כל ההיגיון מאחורי יצירת Firestore. ספקולציות לגבי המניעים שעולים בתוך הקופסה השחורה היא גם חלק מהכיף. הצמדה זו של שני מסדי נתונים דומים ביותר אך שאין להם השוואה היא נדירה למדי. זה כמו שמישהו חשב: "Firebase היא רק פונקציה שאנו יכולים לחקות ב-Google Cloud", אך עדיין לא גילה את הרעיון של זיהוי דרישות בעולם האמיתי או יצירת פתרונות שימושיים העונים על כל הדרישות הללו. "תנו למפתחים לחשוב על זה. פשוט תהפוך את ממשק המשתמש ליפה... האם אתה יכול להוסיף עוד אש?"

אני מבין כמה דברים לגבי מבני נתונים. אני בהחלט רואה את המושג "הכל בעץ JSON אחד גדול" כניסיון להפשט כל תחושה של מבנה בקנה מידה גדול ממסד הנתונים. לצפות מתוכנה פשוט להתמודד עם כל פרקטל מבנה נתונים מפוקפק זה פשוט מטורף. אני אפילו לא צריך לדמיין כמה דברים יכולים להיות רעים, עשיתי ביקורת קוד קפדנית ו ראיתי דברים שאתם לא חלמתם עליהם. אבל אני גם יודע איך נראים מבנים טובים, כיצד להשתמש בהם и למה זה צריך להיעשות. Я могу представить мир, в котором Firestore казалась бы вполне логичной, а создавшие её люди считали бы, что проделали хорошую работу. Но мы живём не в этом мире.

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

אם תחפש ב-Google Docs מידע על זה, מקווה שתופנה לכיוון של משהו כמו BigTable ו-BigQuery. עם זאת, כל הפתרונות הללו מלווים בז'רגון מכירות תאגידי צפוף כל כך עד שתחזרו במהירות ותתחילו לחפש משהו אחר.

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

(*) זו בדיחה, אין דבר כזה תואם 100% JSON.

על זכויות הפרסום

מחפש VDS לפרויקטים באגים, שרת לפיתוח ואירוח? אתה בהחלט הלקוח שלנו 🙂 תמחור יומי לשרתים בתצורות שונות, רישיונות אנטי-DDoS ו-Windows כבר כלולים במחיר.

מקור: www.habr.com