Database Architecture לעידן AI — SQL + Vector + Search + Graph

מאת צוות מדיה דיל · 09.08.2026 · Technology · 8 דק׳

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

צוות פיתוח שמקים feature חדש מבוסס AI מגלה בשלב מוקדם שהוא צריך ארבעה דברים בו-זמנית: שאילתות SQL רגילות על נתוני לקוחות והזמנות, חיפוש דמיון סמנטי על טקסט חופשי, חיפוש טקסט מלא לשמות מוצרים ומספרי הזמנה, ולעיתים גם שאילתת "מי מחובר למי" שדורשת מעבר על גרף קשרים. הפתרון הנאיבי - להוסיף עוד ועוד טבלאות ואינדקסים למסד קיים עד שהוא נושם בכבדות - עובד עד גבול מסוים, ואחריו מגיע רגע שבו צריך להחליט במודע: להישאר עם מסד נתונים אחד רב-תכליתי, או לעבור ל-polyglot persistence - כמה מנועי אחסון שכל אחד עושה דבר אחד טוב.

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

למה עידן ה-AI שינה את דרישות ה-Database

מסדי נתונים רלציוניים נבנו סביב הנחת יסוד: הנתונים מובנים, השאילתות ידועות מראש, וה-consistency הוא ערך עליון. AI הפך את שלוש ההנחות האלה לפחות נכונות. חלק גדול מהמידע שמערכות AI עובדות איתו הוא לא מובנה - טקסט חופשי, מסמכים, תמלולים - והשאילתות עליו הן "מה הכי דומה למשמעות הזו" ולא "מה שווה לערך הזה". זה דורש ייצוג וקטורי (embeddings) וחיפוש דמיון, לא רק אינדקס B-tree קלאסי.

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

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

שכבת ה-SQL: מה נשאר ומה משתנה

ה-SQL לא נעלם - הוא עדיין הבסיס לכל מה שדורש עקביות חזקה: יתרות חשבון, מצב הזמנה, הרשאות משתמשים. מה שכן משתנה זה התפקיד שלו במערכת: SQL הופך לעיתים קרובות ל"מקור האמת" (source of truth) שממנו נגזרים ונבנים ייצוגים אחרים - embeddings, אינדקסי חיפוש, תצוגות גרף. חשוב לתכנן את הסכימה כך שהיא ניתנת להסבר ל-LLM (ראו את המדריך על Natural Language to SQL), עם שמות עמודות ברורים, foreign keys מפורשים והערות בסכימה עצמה.

עיקרון נוסף שכדאי לאמץ מוקדם: הפרדה ברורה בין טבלאות שמייצגות state עסקי (מה שחייב להיות עקבי בכל רגע נתון) לבין טבלאות שמייצגות תוכן (טקסט חופשי, תיאורים, הערות) שממנו נגזרים embeddings ואינדקסי חיפוש. ההפרדה הזו מקלה מאוד על agent שמנסה להבין את הסכימה - הוא יכול לדעת מראש שטבלאות ה-state דורשות זהירות, בעוד טבלאות התוכן הן מקור להעשרה סמנטית.

סכימה ידידותית ל-AI לעומת סכימה מיטבית לאחסון

יש כאן מתח אמיתי: סכימה מנורמלת עד הסוף חוסכת אחסון וכפילות, אבל דורשת מ-LLM לבצע joins מסובכים כדי להבין תמונה שלמה. לעיתים משתלם לשמור, לצד הסכימה המנורמלת, שכבת views דנורמלית שמיועדת ספציפית לצריכה על ידי שכבת ה-AI - כך שני העולמות מקבלים את מה שמתאים להם בלי לפגוע זה בזה.

Vector כאזרח שווה זכויות

ההחלטה הראשונה היא איפה לשים את הווקטורים: מנוע וקטורי ייעודי (Pinecone, Weaviate, Qdrant) או הרחבה בתוך מסד קיים כמו pgvector ב-Postgres. הכלל הפרקטי: אם הווקטורים חיים לצד נתונים טרנזקציוניים שצריך לשלב איתם בשאילתה אחת, עדיף מסד משולב - זה חוסך round-trip בין שני מערכות ושומר על עקביות. אם מדובר בעומס וקטורי אדיר עם דרישות scale קיצוניות, מנוע ייעודי מנצח. הרחבה מלאה במדריך ארכיטקטורת מסדי נתונים וקטוריים ובמדריך pgvector המעמיק.

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

SELECT id, title, content
FROM documents
WHERE tenant_id = $1 AND status = 'active'
ORDER BY embedding <=> $2
LIMIT 10;

Full-Text, Hybrid Search ו-Graph

חיפוש סמנטי טהור נכשל דווקא במקרים הפשוטים - מספרי הזמנה, קודי SKU, שמות מדויקים. שם נכנס Hybrid Search: שילוב חיפוש וקטורי עם חיפוש טקסטואלי קלאסי (BM25 או full-text index) ומיזוג הדירוגים. זה הכרחי לכל מערכת חיפוש או RAG בפרודקשן - הרחבה מלאה במדריך Hybrid Search, ולשיפור הדירוג לאחר האחזור כדאי להכיר גם Reranking ב-RAG.

גרף (Neo4j, או graph extension מעל Postgres) שווה את המורכבות הנוספת כשהשאלה העסקית היא באמת על קשרים מרובי-שלבים - זיהוי הונאות דרך רשתות קשרים, או מיפוי ידע ארגוני. אם השאלות שלכם הן בעיקר "מצא דומה" או "מצא לפי ערך", גרף הוא over-engineering. הרחבה במדריך Knowledge Graphs ובGraphRAG.

סנכרון ועקביות בין השכבות

ברגע שיש יותר ממנוע אחד, מתעורר אתגר ה-eventual consistency: מתי בדיוק ה-embedding של רשומה מתעדכן אחרי שהטקסט המקורי השתנה ב-SQL? התשובה הנפוצה היא Change Data Capture (CDC) - מאזין לשינויים ב-write-ahead log ומזרים אותם לעדכון האינדקסים המשניים באופן אסינכרוני, עם תור שסופג עומס ומבטיח idempotency.

חשוב להגדיר במפורש עד כמה "טרי" מותר לאינדקס המשני להיות, ולתכנן לפי זה במקום להניח consistency מיידית שלא קיימת בפועל. תבנית ה-CDC הזו היא גם הבסיס לארכיטקטורות streaming רחבות יותר, שמפורטות במדריך AI Analytics בזמן אמת ובAI Data Pipelines.

ביצועים, אינדקסים ועלויות

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

שיקול שכדאי לבחון מוקדם הוא ממד הווקטור עצמו - מודל embedding עם 1536 ממדים צורך פי כמה זיכרון ואחסון ממודל עם 384 ממדים, ולא תמיד השיפור באיכות מצדיק את העלות הנוספת. שווה לבדוק אמפירית האם מודל embedding קטן יותר נותן דיוק retrieval דומה מספיק - זו בדיוק סוג ההחלטה שדורשת ערכת evals (ראו מדריך LLM Evals) ולא ניחוש.

Multi-Tenancy בשכבת הנתונים

כשמדובר במוצר SaaS עם כמה לקוחות (tenants) שחולקים אותה תשתית, בידוד הנתונים הופך מורכב יותר ברגע שנכנסים embeddings לתמונה. לא מספיק שורת tenant_id בטבלה רגילה - צריך לוודא שגם אינדקס הווקטורים עצמו מכבד את הגבול הזה, כדי שחיפוש דמיון סמנטי של לקוח אחד לא "יזלוג" בטעות לתוצאות ממאגר של לקוח אחר. הפתרון הנפוץ הוא namespace נפרד או פילטר metadata קשיח שנאכף ברמת השאילתה עצמה, לא רק ברמת האפליקציה - עקרון שמפורט בהרחבה במדריך AI-Native SaaS Architecture.

נקודה נוספת שקל לפספס: כשמריצים migration על סכימה משותפת בין tenants, כל שינוי במבנה טבלה שממנה נגזרים embeddings דורש גם תכנון מחדש - האם צריך לחשב embeddings מחדש לכל הרשומות הקיימות, ובאיזה קצב, בלי להעמיס על המסד בזמן החישוב מחדש. תכנון מוקדם של תהליך re-embedding אצווה (batch) חוסך הפתעות לא נעימות בשדרוגי גרסה עתידיים.

בחירת מנוע: רשימת בדיקה מעשית

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

טעויות נפוצות

• פיצול מוקדם מדי - הוספת מנוע וקטורי ייעודי לפני שיש הוכחה בפועל שהעומס דורש זאת, רק כי "כך עושים בתעשייה".
• הזנחת ה-CDC - הנחה שה-embedding יתעדכן "מתישהו" בלי לתכנן מנגנון סנכרון מפורש, מה שמוביל לתוצאות retrieval מיושנות שקשה לאבחן.
• התעלמות מ-multi-tenancy באינדקס הווקטורי - סינון tenant רק ברמת האפליקציה במקום ברמת השאילתה עצמה, מה שיוצר סיכון דליפת נתונים.
• סכימה חסכונית מדי - שמות עמודות מקוצרים ו-denormalization אגרסיבי שהופכים את הסכימה לבלתי קריאה ל-agent שמנסה להבין אותה.
• התעלמות מממד ה-embedding - בחירת מודל embedding גדול "כי הוא הכי טוב" בלי לבדוק אם מודל קטן מספיק לצורך בפועל.

דוגמה מהשטח

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

שאלות נפוצות

האם pgvector מספיק לפרודקשן בקנה מידה גדול?

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

מתי עדיף מנוע וקטורי ייעודי?

כשיש עשרות מיליוני וקטורים ומעלה, דרישת latency קיצונית, או צורך בפיצ'רים מתקדמים כמו namespace multi-tenancy בקנה מידה גדול.

איך מתחילים לתכנן ארכיטקטורת נתונים למערכת AI חדשה?

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

מה קורה כשיש כמה מקורות אמת שסותרים זה את זה?

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

איך מודדים אם הגיע הזמן לפצל את המסד?

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

האם HNSW תמיד עדיף על IVFFlat?

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

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

תגיות: database architecture · pgvector · vector database · polyglot persistence · hybrid search · AI infrastructure · PostgreSQL

← חזרה לבלוג · צור קשר