11 מסד הנתונים של הקוד הפתוח בראש הפרויקט הבא שלך

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


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

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

התוצאה?

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

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

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

אין MySQL

לתשומת לבך: רשימה זו לא תכיל את MySQL, אף על פי שהיא ללא ספק הפיתרון הפופולרי ביותר של מסד הנתונים הפתוח בחוץ..

למה? פשוט מכיוון ש- MySQL נמצא בכל מקום – זה מה שכל אחד לומד קודם, הוא נתמך על ידי כמעט כל CMS או מסגרת שם בחוץ, וזה מאוד מאוד טוב עבור רוב המקרים לשימוש. במילים אחרות, MySQL לא צריך “לגלות”. ��

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

הערה מיוחדת: תאימות

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

לדוגמה, אם אתה מפעיל WordPress, מאמר זה אינו מועיל לך. �� באופן דומה, מי שמריץ אתרים סטטיים ב- JAMStack לא ירוויח דבר על ידי חיפוש אלטרנטיבות ברצינות רבה מדי.

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

PostgreSQL

אם אתה מארץ PHP (וורדפרס, מג’נטו, דרופל וכו ‘), אז PostgreSQL יישמע לך זר. עם זאת, פיתרון בסיסי נתונים זה קיים מאז 1997 והוא הבחירה המובילה ביישובים כמו רובי, פייתון, גו וכו ‘..

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

יש הרבה לקוחות SQL טובים שאפשר להתחבר למסד הנתונים של PostgreSQL לצורך ניהול ופיתוח.

תכונות ייחודיות

ל- PostgreSQL כמה תכונות מרתקות לעומת מאגרי מידע יחסיים אחרים (ספציפית, MySQL), כגון:

  • סוגי נתונים מובנים עבור מערך, טווח, UUID, מיקום גיאוגרפי וכו ‘.
  • תמיכה מקורית באחסון מסמכים (סגנון JSON), XML ואחסון ערכי מפתח (Hstore)
  • שכפול סינכרוני ואסינכרוני
  • ניתן לתכנות ב- PL, Perl, Python ועוד
  • חיפוש טקסט מלא

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

מתי להשתמש ב- PostgreSQL

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

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

מתי לא להשתמש ב- PostgreSQL

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

במילים אחרות, השתמש תמיד ב- PostgreSQL, אלא אם כן אתה יודע 100% מה אתה עושה! ��

בדוק את זה SQL & קורס PostgreSQL למתחילים אם מעוניינים ללמוד עוד.

MariaDB

MariaDB נוצר כתחליף ל- MySQL, על ידי אותו אדם שפיתח את MySQL.

מבולבל?

ובכן, למעשה, לאחר שה MySQL השתלטה על ידי אורקל בשנת 2010 (על ידי רכישת חברת Sun Microsystems, שאגב היא גם הדרך בה אורקל הגיעה לשלוט ב- Java), יוצרת MySQL הקים פרויקט קוד פתוח חדש בשם MariaDB..

מדוע כל הפרט המשעמם הזה משנה, אתם שואלים? הסיבה לכך היא ש- MariaDB נוצר מאותו בסיס קוד זהה לזה של MySQL (בעולם הקוד הפתוח, זה ידוע כ”מזלג “פרויקט קיים). כתוצאה מכך, MariaDB מוצג כתחליף “drop-in” עבור MySQL.

כלומר, אם אתה משתמש ב- MySQL ורוצה לעבור ל- MariaDB, התהליך כל כך קל שפשוט לא תאמין לו.

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

תכונות ייחודיות

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

  • באמת חופשי ופתוח: מכיוון שאין אף גורם תאגידי אחד השולט ב- MariaDB, אתה יכול להיות חופשי מרישיונות טורפים פתאומיים ודאגות אחרות.
  • מספר אפשרויות נוספות של מנועי אחסון לצרכים מיוחדים: למשל, מנוע העכביש לעסקאות מבוזרות; ColumnStore לאחסון מסיבי של נתונים; מנוע ה- ColumnStore לאחסון מקביל ומופץ; ורבים, רבים אחרים.
  • שיפורי מהירות על פני MySQL, בעיקר בגלל מנוע האחסון Aria לשאילתות מורכבות.
  • עמודות דינמיות לשורות שונות בטבלה.
  • יכולות שכפול טובות יותר (לדוגמה, שכפול רב-מקורות)
  • מספר פונקציות של JSON
  • עמודות וירטואליות

. . . ועוד רבים, רבים אחרים. זה מתיש להמשיך עם כל התכונות של MariaDB. ��

מתי להשתמש ב- MariaDB

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

מתי לא להשתמש ב- MariaDB

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

ג’וק DB

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

ובכן, לא ממש.

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

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

גם כאשר שכפול ואשכול יצאו ב- MySQL, PostgreSQL, ו- MariaDB, זה היה כואב במקרה הטוב. CoackroachDB רוצה לשנות את זה, להביא את הגלישה ללא מאמץ, האשכול וזמינות גבוהה לעולם ה- SQL.

מתי להשתמש ב- CockroachDB

ג’וק DB הוא החלום של אדריכל המערכת. אם אתה נשבע על ידי SQL והצלחת את יכולות הגודל של MongoDB, תאהב את CockroachDB. כעת תוכלו להקים אשכול במהירות, לזרוק עליו שאילתות ולישון בשקט בלילה. ��

מתי לא להשתמש ב- CockroachDB

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

מעכשיו נשקול פתרונות מסד נתונים שאינם SQL (או NoSQL, כפי שהוא מכונה) לצרכים מיוחדים מאוד..

Neo4j

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

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

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

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

תכונות ייחודיות

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

  • תמיכה ביישומי עסקאות וניתוח גרפים.
  • יכולות שינוי נתונים לעיכול נתונים טבליים בקנה מידה גדול לתרשימים.
  • שפת שאילתה מתמחה (סייפר) לשאילתות במאגר הגרפים
  • תכונות הדמיה וגילוי

זוהי נקודה נרחבת לדון מתי להשתמש ב- Neo4j, ומתי לא. אם אתה זקוק לקשרים מבוססי גרף בין הנתונים שלך, אתה זקוק Neo4j. ��

MongoDB

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

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

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

תכונות ייחודיות

ל- MongoDB יש כמה רציניים (אני כמעט רוצה לכתוב “בעיטה בתחת” כדי להעביר את ההשפעה, אבל זה לא יתאים לאתר ציבורי, אולי) תכונות שגרמו למספר אדריכלים מנוסים לנטוש את האדמה ההתייחסותית לנצח:

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

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

מתי להשתמש ב- MongoDB

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

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

מתי לא להשתמש ב- MongoDB

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

אם אתה מפתח, אז תמצא זה שימושי.

RethinkDB

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

כאשר מסד נתונים מתעדכן, אין אפשרות ליישום לדעת זאת. הגישה המקובלת היא שהאפליקציה תפטר התראה ברגע שיש עדכון, שנדחף לקצה הקדמי דרך גשר מורכב (PHP) -> Redis -> צומת -> Socket.io הוא דוגמה אחת).

אבל מה אם ניתן היה לדחוף את העדכונים ישירות מהמאגר למסוף הפרונט?!

כן, זו ההבטחה של RethinkDB. אז אם אתם ממשיכים ליישם אפליקציה אמיתית בזמן אמת (משחק, שוק, ניתוחים וכו ‘), Rethink DB שווה להסתכל.

Redis

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

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

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

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

SQLite

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

SQLite היא ספריית C קלילה שסיפקה מנוע אחסון מסדי נתונים יחסי. כל מה שבמאגר נתונים זה חי בקובץ יחיד (עם סיומת .SQLite) שאתה יכול להכניס בכל מקום למערכת הקבצים שלך. וזה כל מה שאתה צריך כדי להשתמש בו! כן, אין תוכנת “שרת” להתקנה ושום שירות שאפשר להתחבר אליו.

תכונות שימושיות

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

  • תמיכה מלאה בעסקאות עם COMMIT, ROLLBACK ו- BEGIN.
  • תמיכה ב 32,000 עמודות בטבלה
  • תמיכה ב- JSON
  • תמיכה ב- 64 כיוונים
  • שאילתות משנה, חיפוש בטקסט מלא וכו ‘.
  • גודל מסד נתונים מרבי של 140 טרה-בתים!
  • גודל מקסימאלי בשורה של 1 ג’יגה-בתים!
  • מהיר יותר ב- 35% מהקלט / פלט של הקובץ

מתי להשתמש ב- SQLite

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

מתי לא להשתמש ב- SQLite

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

קסנדרה

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

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

תכונות ייחודיות

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

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

מתי להשתמש בקסנדרה

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

מתי לא להשתמש בקסנדרה

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

לוח זמנים

פיתוחים חדשים דורשים סוגים חדשים של מסדי נתונים, ו- Internet of Things (IoT) היא תופעה כזו. אחד ממאגרי המידע הפתוחים הטובים ביותר עבור זה הוא לוח זמנים.

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

מדוע לא להשתמש רק במסד נתונים מסורתי עם שדה חותמת זמן? ובכן, יש שתי סיבות עיקריות לכך:

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

תכונות ייחודיות

ל- Timescale DB יש כמה תכונות מרגשות המבדילות אותו ממאגרי מידע אחרים באותה קטגוריה:

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

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

CouchDB

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

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

תכונות ייחודיות

CouchDB הוא משהו מגזע ייחודי בכל הקשור למאגרי מידע.

  • יכולות סנכרון נתונים לא מקוונות ראשונות
  • גרסאות ייעודיות לדפדפני מובייל ודפדפני אינטרנט (PouchDB, CouchDB Lite וכו ‘)
  • מהימנות עמידה בפני התרסקות ונבדקת בקרב
  • אשכול קל עם אחסון נתונים מיותר

מתי להשתמש ב- CouchDB

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

מתי לא להשתמש ב- CouchDB

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

סיכום

הייתי צריך להשאיר מועמדים מעניינים רבים כמו ריאק, ולכן יש לקחת את הרשימה כמדריך ולא כמצווה. אני מקווה שהצלחתי להשיג את יעדי במאמר זה – להציג לא רק אוסף של המלצות בסיס נתונים, אלא גם לדון בקצרה היכן וכיצד יש להשתמש בהן (ולהימנע!).

אם אתה סקרן ללמוד בסיס נתונים, בדוק זאת אודמי לכמה מהקורסים המקוונים המבריקים.

תגיות:

  • מאגר מידע

  • קוד פתוח

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map