ארכיטקטורה של מערכות נתונים מודרניות עובר שינוי יסודי. שאלו מפתחים כיצד הם בונים מערכות נתונים היום, והתשובה נראית יותר ויותר כך: Postgres עבור היישום, אגם עבור אנליטיקה ומדעי נתונים. Postgres, המועדף במשך זמן רב עבור עומסי עבודה עסקיים, התפתח למסד נתונים תפעולי למטרות כלליות.זה אמין, גמיש וגמיש לחלוטין, תפעול הכל מהעסקאות הלקוחות ויישומים CRUD, לתיקיות בזמן אמת ותכונות מוצר נתמכות על ידי AI. האקולוגיה שלה גדלה כדי לתמוך בניתוח בזמן אמת ( ), נתונים גיאוגרפיים (PostGIS), חיפוש וקטור וטקסט מלא (pgvector ו pgvectorscale), ועוד. TimescaleDB במקביל, עליית טכנולוגיות אגם פתוחה הגדירה מחדש את האופן שבו ארגונים מנהלים ונתונים נתונים בקנה מידה.אחסון מחולק, פורמטים של שולחנות פתוחים כגון Iceberg, קטלוגים נתונים מאורגנים ומנועי שאילתות מורכבים מאפשרים לנתח נתונים בקנה מידה של פטבייט עם דיוק ובקרה.ארכיטקטורה זו יכולה להציע ניהול, להימנע מחסום ספקים, ועדיין לספק קבוצות נתונים גמישות בבחירת הכלים שלהם. מה שמדאיג הוא לא רק ההצלחה של הטכנולוגיות הללו בנפרד, אלא לעתים קרובות הם נמצאים כעת בשימוש יחד.ארגונים צריכים יותר ויותר לתמוך בשני עומסי עבודה תפעוליים (שנוהגים על ידי מסדי נתונים) ואל עומסי עבודה שאינם תפעוליים (שנוהגים על ידי אגם), לעתים קרובות באמצעות נתונים מאותם מקורות – אנשים, מכונות, מערכות דיגיטליות או סוכנים. למעשה, אנו חושבים שהארכיטקטורה החדשה, הקוהרנטית יותר, מתעוררת: זו מתייחסת לפוסטגרס ולבית האגם לא כעולמות נפרדים, אלא כככמוסות נפרדות של מערכת מודולרית אחת, שתוכננה לענות על הספקטרום המלא של הצרכים המבצעיים והאנליטיים. הגבולות של OLTP vs OLAP Dichotomy הדרך הישנה לחשוב על מסדי נתונים הייתה פשוטה: OLTP עבור עסקאות, OLAP לניתוח. השתמשת Postgres כדי להפעיל את היישום שלך, ושלחת את עבודות ETL ללילה לאחסון נתונים עבור דוחות פנימיים ודיסקים. ההבדל המסורתי הזה שימש אותנו היטב כאשר היישומים היו פשוטים יותר, והדוחות הפנימיים יכולים לחיות בקצב איטי הרבה יותר. יישומים מודרניים הם נתונים כבדים, לקוח מול, בזמן אמת על פי העיצוב. 
 
 
 
 אפליקציה פיננסית עשויה להפעיל מנוע מסחר הדורש גישה מילישניות לפורטפולי הלקוחות, תוך הזנת דיווחים על סיכונים בזמן אמת ובדפדפנים פנימיים. אפליקציית SaaS אינה רק מאחסנת קליקים – היא מחשבת מדדים לשימוש, מפעילה אזהרות ומספקת מודלים מותאמים אישית. מערכת מעקב תעשייתית עשויה לצרוך עשרות מיליוני קריאה של חיישנים לשעה, להפעיל את גילוי הפרעות והיגיון אזהרה, וארכיון שנים של טלמטיקה לניתוח לטווח ארוך וחינוך מודל AI. מקרים אלה של שימוש אינם חריגים – הם הופכים במהירות לנורמה. We increasingly see a more useful split: operational databases that power products, and lakehouses that power organizations. עם זאת, גם אם הבעלות על סוגים אלה של מערכות מחולקת – צוותי הנדסת מוצר האחראים על מערכות ההפעלה המניעות את המוצרים שלהם, צוותי נתונים האחראים לניהול מערכות אגם כשירותים ארגוניים – שניהם עדיין צריכים לדבר אחד עם השני. ארכיטקטורה של מדליה דפוס אחד שאנחנו רואים מקבל מתיחה הוא מה שאנחנו קוראים בהשראת המודלים המפורסמים בעולם הנדסת נתונים, דפוס זה כולל גם שכבות ברונזה, כסף וזהב – לא רק עבור ניתוח פנימי, אלא גם עבור כוח בזמן אמת, מערכות ממוקדות בפני המשתמש. ארכיטקטורה Medallion הנה איך זה נראה: 
 
 
 
 שכבה ברונזה: נתונים ירוקים חיים בקבצים של Parquet או Iceberg ב- AWS S3 או במערכות אחסון ללא יסוד בעלות נמוכה דומות. נתונים אלה הם בדרך כלל בלתי משתנים, רק בתוספים, וניתן לחפש על ידי כל דבר: מנועי שאילתות כמו AWS Athena, DuckDB, Trino, ClickHouse או Polars, או אפילו ישירות ממסד נתונים מפעיל כמו Postgres. שכבת הכסף המבצעית: נתונים נקיים, מסוננים, מאושרים ומוסתרים נכתבים ב-Postgres כדי להפעיל את האנליטיקה בזמן אמת, לוח המחשבים או ההיגיון של יישומי המשתמשים של המוצרים. שכבת זהב מפעילה: נתונים ממוקדים מראש על נתוני כסף (כגון תצוגות מתגלמות של Postgres או אגרגנטים מתמשכים של TimescaleDB) מספקים חוויות מוצרים בעלות עיכוב נמוך ותחרות גבוהה. באופן קריטי, כל שכבה ניתנת לביקורת, ותנועה זו של נתונים היא דו-כיוונית. אתה יכול למשוך נתונים גלויים או מעובדים מ- S3 ישירות ל- Postgres (אפילו ל- ETL הפוך משולב לחלוטין). אתה יכול לסנכרן aggregates מ- Iceberg ל- Postgres טבלאות (באמצעות שאילתות חד פעמיות או קבועות נגד קבצים של Iceberg מ- Postgres). אתה יכול לסנכרן באופן קבוע תוכנית מלאה או טבלה אחת מהבסיס ל- lakehouse. באותה מידה שבה ניתן לקרוא את הנתונים הכרוניים (או המהפכנים) מן שכבת אחסון אגם ב- S3 לתוך מסד הנתונים, ניתן לכתוב את הכסף והזהב במסד הנתונים לתוך פורמטים אלה של אחסון אגם. דפוס נפוץ אחד שראינו ביישומים הדורשים נתונים חדשים הוא כתיבה ממערכת סטרימינג למעלה כמו Kafka או Kinesis. לאחר מכן, טבלאות זהב אלה ואגודות הזהב הבאות במסד הנתונים ייצאו שוב ל- S3, כך שהקבוצות לנתונים יש כעת גישה ל"נתוני האמת על הקרקע" שהגישו ללקוחות. במקביל כעת, כל מערכת שומרת על הפרדה של דאגותיה.הבסיס המבצעי יכול לפעול נעול – הן למשתמשים והן לשאלות לא ידידותיות – בעוד שהנתונים עדיין זמינים כחלק מהאגם הפתוח בכל מקום בו הם נחוצים באורג. מדוע עכשיו?כוחות טכניים המניעים את השינוי מספר התפתחויות מחזקות את המעבר הזה ממסדי נתונים תפעוליים ומאגרי אגם מלהיות סילואד לאינטגרציה. ראשית, Iceberg התבגר לתוך פורמט טבלה יציב וגמיש התומך בהתפתחות של מערכות, עסקאות ACID וחיכוך יעיל.הוא מאפשר למנועי חישוב מרובים לקרוא ולכתוב מאותם קבוצות נתונים - עם שכבות קטטלוג שמחפשות מטא-נתונים וליישם ממשל ברחבי המאגר. שנית, Postgres המשיכה להתפתח כפלטפורמה.עם הרחבות לאחסון עמודי, נתוני סדרת זמן, חיפוש וקטור והיברידי - מה שאנחנו בונים ב- Timescale במשך שנים - Postgres משרתת עכשיו מוצרים רבים המשלבים באופן ישיר אנליטיקה בזמן אמת ותהליכים עבודה סוכנים.עם תמיכה מתפתחת לביקורת נתונים של S3 ו-Iceberg ישירות בתוך Postgres, ניתן יותר ויותר לכלול נתונים המארחים ב-S3 ישירות. זוהי לא רק שכבה של חיבוי נתונים עבור נתונים מחושבים מראש, אלא מסד נתונים SQL מלא עבור אגרגציות נוספות, העשירה, או JOINs בזמן השאילתה. now acts as the serving layer for products incorporating both transactional and analytical data שלישית, מפתחים מצפים להתקבלות.ארגונים מסוימים עשויים להיות תקועים עם פלטפורמות הנתונים המונוליטיות העתיקות שלהם, אבל רוב מפתחים ומדענים נתונים רוצים גמישות כדי להכין את העמודים שלהם, שילוב כלים מוכרים בדרכים המשקפים את הצרכים של היישום שלהם.המעבר לפורמטים פתוחים ומאחסון מחולק מתאים לחשיבה זו. Put differently: the market is moving toward modular, open, developer-friendly architectures. מה יבוא בהמשך אנו מאמינים כי העתיד של תשתית הנתונים ייבנה על ידי מערכות המשלבות שכבות תפעוליות ואנליטיות עמוקות יותר – מערכות שמתייחסות ל-Postgres ו-Lakehouse כאל שני צדדים של אותו מטבע. זה לא יקרה באמצעות מונוליט נוסף.זה יבוא ממשקיפים זהירים - סינכרון משתרע, קטלוגים משותפים, משטחי שאילתות מאוחדים - ושל פילוסופיה אדריכלית המקיפה את ההטרוגניות במקום להילחם בה. אנחנו עובדים על משהו חדש בתחום זה, משהו שמתבסס על היתרונות של Postgres ו-Iceberg, משולב באופן הדוק עם מערכות אגם קיימות, והופך את הבנייה של מערכות נתונים מלאות עם נאמנות מבצעית ואנליטית קלה באופן דרמטי. לא מדובר בשימוש ב- ETL כדי להעביר נתונים ממערכות עתיקות למערכות חדשות – מדובר בבניית ארכיטקטורה מודרנית של נתונים מתואמת שמשרתת מקרים של שימוש פעיל ובלתי פעיל. להישאר טונר

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

האודיו הזה מופק בשפת המקור של הסיפור!

Postgres והאגם הופכים למערכת אחת - הנה מה שמגיע הבא

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

The TechBeat: How to Implement a Merkle Tree in Solidity (10/26/2023)

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/16/2024)

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/18/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/20/2024)

The TechBeat: How to Implement a Merkle Tree in Solidity (10/26/2023)

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/16/2024)

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/18/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/20/2024)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps