---
layout: default
title: "מפרט טכני לניהול אוספים"
parent: "Hebrew (Beta)"
---

# מפרט טכני לניהול אוספים

> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

## סקירה כללית

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

1. **יצירת אוסף**: ליצור אוספים באופן מפורש לפני אחסון נתונים
2. **רשימת אוספים**: להציג את כל האוספים הקיימים במערכת
3. **ניהול מטא-נתונים של אוסף**: לעדכן שמות, תיאורים ותגיות של אוספים
4. **מחיקת אוסף**: להסיר אוספים ונתונים הקשורים אליהם בכל סוגי האחסון

## מטרות

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

## רקע

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

מודל יצירת האוספים המפורש פותר בעיות אלה על ידי:
דרישה ליצירת אוספים לפני השימוש באמצעות `tg-set-collection`
שידור יצירת אוסף לכל אחסני הנתונים
שמירה על מצב מסונכרן בין מטא-נתונים של הספרן ואחסון
מניעת כתיבה לאוספים שאינם קיימים
מתן ניהול ברור של מחזור החיים של האוסף

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

## עיצוב טכני

### ארכיטקטורה

מערכת ניהול האוספים תיושם בתוך התשתית הקיימת של TrustGraph:

1. **שילוב עם שירות הספרן**
   פעולות ניהול אוספים יתווספו לשירות הספרן הקיים
   לא נדרש שירות חדש - משתמש בדפוסי אימות וגישה קיימים
   מטפל ברשימת אוספים, מחיקה וניהול מטא-נתונים

   מודול: trustgraph-librarian

2. **טבלת מטא-נתונים של אוסף ב-Cassandra**
   טבלה חדשה במרחב המפתחות הקיים של הספרן
   מאחסנת מטא-נתונים של אוסף עם גישה מבוססת משתמש
   מפתח ראשי: (user_id, collection_id) עבור ריבוי שוכרים תקין

   מודול: trustgraph-librarian

3. **ממשק שורת פקודה לניהול אוספים**
   ממשק שורת פקודה לפעולות ניהול אוספים
   מספק פקודות לרשימה, מחיקה, תווית וניהול תגיות
   משתלב עם מסגרת שורת הפקודה הקיימת

   מודול: trustgraph-cli

### מודלים של נתונים

#### טבלת מטא-נתונים של אוסף ב-Cassandra

מטא-הנתונים של האוסף יאוחסנו בטבלה מובנית ב-Cassandra במרחב המפתחות של הספרן:

```sql
CREATE TABLE collections (
    user text,
    collection text,
    name text,
    description text,
    tags set<text>,
    created_at timestamp,
    updated_at timestamp,
    PRIMARY KEY (user, collection)
);
```

מבנה טבלה:
**user** + **collection**: מפתח ראשי מורכב המבטיח בידוד משתמשים
**name**: שם קריא לבן-אדם של האוסף
**description**: תיאור מפורט של מטרת האוסף
**tags**: קבוצת תגיות למיון וסינון
**created_at**: חותמת זמן של יצירת האוסף
**updated_at**: חותמת זמן של השינוי האחרון

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

#### מחזור החיים של אוסף

אוספים נוצרים באופן מפורש בספרן לפני שניתן לבצע פעולות נתונים:

1. **יצירת אוסף** (שני מסלולים):

   **מסלול א': יצירה על ידי משתמש** באמצעות `tg-set-collection`:
   המשתמש מספק מזהה אוסף, שם, תיאור ותגיות
   הספרן יוצר רשומת מטא-נתונים בטבלת `collections`
   הספרן משדר "create-collection" לכל מערכות האחסון
   כל מעבדי האחסון יוצרים את האוסף ומאשרים הצלחה
   האוסף מוכן כעת לפעולות נתונים

   **מסלול ב': יצירה אוטומטית בעת הגשת מסמך**:
   המשתמש מגיש מסמך המציין מזהה אוסף
   הספרן בודק אם האוסף קיים בטבלת המטא-נתונים
   אם לא קיים: הספרן יוצר מטא-נתונים עם ברירות מחדל (שם=מזהה האוסף, תיאור/תגיות ריקים)
   הספרן משדר "create-collection" לכל מערכות האחסון
   כל מעבדי האחסון יוצרים את האוסף ומאשרים הצלחה
   עיבוד המסמך ממשיך עם יצירת האוסף

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

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

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

4. **עדכוני מטא-נתונים**: משתמשים יכולים לעדכן מטא-נתונים של אוסף לאחר יצירתו:
   עדכון שם, תיאור ותגיות באמצעות `tg-set-collection`
   העדכונים חלים רק על מטא-נתונים של הספרן
   מערכות האחסון שומרות על האוסף, אך עדכוני מטא-נתונים אינם מועברים

5. **מחיקה מפורשת**: משתמשים מוחקים אוספים באמצעות `tg-delete-collection`:
   הספרן משדר "delete-collection" לכל מערכות האחסון
   ממתין לאישור מכל מעבדי האחסון
   מוחק רשומת מטא-נתונים של הספרן רק לאחר השלמת הניקוי של האחסון
   מבטיח שלא יישארו נתונים יתומים באחסון

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

פעולות נדרשות:
**יצירת אוסף**: פעולה של משתמש באמצעות `tg-set-collection` או אוטומטית בעת הגשת מסמך
**עדכון מטא-נתונים של אוסף**: פעולה של משתמש לשינוי שם, תיאור ותגיות
**מחיקת אוסף**: פעולה של משתמש להסרת אוסף ונתונים שלו בכל האחסונים
**רשימת אוספים**: פעולה של משתמש לצפייה באוספים עם סינון לפי תגיות

#### ניהול אוספים מרובי-חנות

אוספים קיימים על פני מספר מערכות אחסון ב-TrustGraph:
**מאגרי וקטורים** (Qdrant, Milvus, Pinecone): אחסון הטבעות ונתוני וקטור
**מאגרי אובייקטים** (Cassandra): אחסון מסמכים ונתוני קבצים
**מאגרי משולשים** (Cassandra, Neo4j, Memgraph, FalkorDB): אחסון נתוני גרף/RDF
פלט חוזה (יש לעקוב בדיוק אחר הפורמט הבא).
כל סוג חנות מיישם:
**מעקב אחר מצב איסוף**: שמירה על ידע אילו איסופים קיימים
**יצירת איסוף**: קבלת עיבוד פעולות "יצירת-איסוף"
**אימות איסוף**: בדיקת קיום האיסוף לפני קבלת כתיבות
**מחיקת איסוף**: הסרת כל הנתונים עבור איסוף מסוים

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

#### מעקב אחר מצב איסוף לפי סוג אחסון

כל backend אחסון עוקב אחר מצב איסוף בצורה שונה בהתאם ליכולותיו:

**Cassandra Triple Store:**
משתמש בטבלה קיימת `triples_collection`
יוצר טריפל מערכת כאשר איסוף נוצר
שאילתה: `SELECT collection FROM triples_collection WHERE collection = ? LIMIT 1`
בדיקה יעילה של מחיצה יחידה לקיום איסוף

**Qdrant/Milvus/Pinecone Vector Stores:**
ממשקי API מקוריים לאיסופים מספקים בדיקת קיום
איסופים נוצרים עם תצורת וקטור מתאימה
שיטה `collection_exists()` משתמשת ב-API של האחסון
יצירת איסוף מאמת דרישות מימד

**Neo4j/Memgraph/FalkorDB Graph Stores:**
משתמש בצמתים `:CollectionMetadata` כדי לעקוב אחר איסופים
מאפייני צומת: `{user, collection, created_at}`
שאילתה: `MATCH (c:CollectionMetadata {user: $user, collection: $collection})`
נפרד מצמתי נתונים לצורך הפרדה נקייה
מאפשר רישום ואימות יעילים של איסופים

**Cassandra Object Store:**
משתמש בטבלת מטא-נתונים של איסוף או שורות סימון
דפוס דומה ל-triple store
מאמת איסוף לפני כתיבת מסמכים

### ממשקים

ממשקי ניהול איסופים (ספרין):
**יצירת/עדכון איסוף**: יצירת איסוף חדש או עדכון מטא-נתונים קיימים באמצעות `tg-set-collection`
**רשימת איסופים**: שליפה של איסופים עבור משתמש עם סינון תגיות אופציונלי
**מחיקת איסוף**: הסרת איסוף ונתונים קשורים, עם העברה לכל סוגי החנויות

ממשקי ניהול אחסון (כל מעבדי אחסון):
**יצירת איסוף**: טיפול בפעולת "יצירת-איסוף", הקמת איסוף באחסון
**מחיקת איסוף**: טיפול בפעולת "מחיקת-איסוף", הסרת כל נתוני איסוף
**בדיקת קיום איסוף**: אימות פנימי לפני קבלת פעולות כתיבה

ממשקי פעולות נתונים (התנהגות משתנה):
**ממשקי כתיבה**: אימות קיום איסוף לפני קבלת נתונים, החזרת שגיאה אם לא קיים
**ממשקי שאילתה**: החזרת תוצאות ריקות עבור איסופים שאינם קיימים ללא שגיאה

### פרטי יישום

היישום יעקוב לדפוסי TrustGraph קיימים לשילוב שירותים ומבנה פקודות שורת פקודה.

#### מחיקת איסוף בשרשרת

כאשר משתמש יוזם מחיקת איסוף דרך שירות הספרין:

1. **אימות מטא-נתונים**: אימות קיום איסוף ושהמשתמש מורשה למחוק
2. **שרשרת אחסון**: הספרין מתאם מחיקה בכל כותבי האחסון:
   כותב אחסון וקטור: הסרת הטמעות ואינדקסים וקטוריים עבור המשתמש והאיסוף
   כותב אחסון אובייקטים: הסרת מסמכים וקבצים עבור המשתמש והאיסוף
   כותב triple store: הסרת נתוני גרף וטריפלים עבור המשתמש והאיסוף
3. **ניקוי מטא-נתונים**: הסרת רשומת מטא-נתונים של איסוף מ-Cassandra
4. **טיפול בשגיאות**: אם מחיקת אחסון כלשהי נכשלת, שמירה על עקביות באמצעות ביטול או מנגנוני ניסיון חוזר

#### ממשק ניהול איסופים

**⚠️ גישה מיושנת - הוחלפה בדפוס מבוסס תצורה**

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

~~כל כותבי האחסון מיישמים ממשק ניהול איסופים סטנדרטי עם סכימה משותפת:~~

~~**סכימת הודעה (`StorageManagementRequest`):**~~
```json
{
  "operation": "create-collection" | "delete-collection",
  "user": "user123",
  "collection": "documents-2024"
}
```

~~**ארכיטקטורת תורים:**~~
~~**תור ניהול מאגרי וקטורים** (`vector-storage-management`): מאגרי וקטורים/הטבעות~~
~~**תור ניהול אחסון אובייקטים** (`object-storage-management`): אחסון אובייקטים/מסמכים~~
~~**תור ניהול מאגרי טריפל** (`triples-storage-management`): מאגרי גרפים/RDF~~
~~**תור תגובות אחסון** (`storage-management-response`): כל התגובות נשלחות לכאן~~

**יישום נוכחי:**

כל מערכות האחסון משתמשות כעת ב-`CollectionConfigHandler`:
**אינטגרציה של דחיפת תצורה**: שירותי אחסון נרשמים לקבלת התראות על שינויי תצורה
**סנכרון אוטומטי**: אוספים נוצרים/נמחקים בהתבסס על שינויי תצורה
**מודל הצהרתי**: אוספים מוגדרים בשירות התצורה, מערכות האחסון מסתנכרנות כדי להתאים
**ללא בקשות/תגובות**: מבטל את התקורה של תיאום ומעקב אחר תגובות
**מעקב אחר מצב אוסף**: נשמר באמצעות מטמון `known_collections`
**פעולות אידמפוטנטיות**: בטוח לעבד את אותה תצורה מספר פעמים

כל מערכת אחסון מיישמת:
`create_collection(user: str, collection: str, metadata: dict)` - יצירת מבני אוסף
`delete_collection(user: str, collection: str)` - הסרת כל נתוני האוסף
`collection_exists(user: str, collection: str) -> bool` - אימות לפני כתיבה

#### שינוי מבנה מאגר טריפל של Cassandra

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

**ארכיטקטורה נוכחית:**
מרחב מפתחות לכל משתמש, טבלה נפרדת לכל אוסף
סכימה: `(s, p, o)` עם `PRIMARY KEY (s, p, o)`
שמות טבלאות: אוספי משתמשים הופכים לטבלאות Cassandra נפרדות

**ארכיטקטורה חדשה:**
מרחב מפתחות לכל משתמש, טבלה יחידה בשם "triples" לכל האוספים
סכימה: `(collection, s, p, o)` עם `PRIMARY KEY (collection, s, p, o)`
בידוד אוספים באמצעות חלוקה לאוספים

**שינויים נדרשים:**

1. **שינוי מבנה מחלקה TrustGraph** (`trustgraph/direct/cassandra.py`):
   הסרת פרמטר `table` מהקונסטרוקטור, שימוש בטבלה קבועה "triples"
   הוספת פרמטר `collection` לכל השיטות
   עדכון הסכימה כדי לכלול את האוסף בעמודה הראשונה
   **עדכוני אינדקסים**: ייוצרו אינדקסים חדשים לתמיכה בכל 8 דפוסי השאילתות:
     אינדקס על `(s)` עבור שאילתות מבוססות סובייקט
     אינדקס על `(p)` עבור שאילתות מבוססות פרידיקט
     אינדקס על `(o)` עבור שאילתות מבוססות אובייקט
     הערה: Cassandra אינה תומכת באינדקסים משניים רב-עמודתיים, לכן אלו הם אינדקסים בעמודה יחידה

   **ביצועי דפוסי שאילתות:**
     ✅ `get_all()` - סריקת מחיצה על `collection`
     ✅ `get_s(s)` - משתמשת ביעילות במפתח ראשי (`collection, s`)
     ✅ `get_p(p)` - משתמשת ב-`idx_p` עם סינון `collection`
     ✅ `get_o(o)` - משתמשת ב-`idx_o` עם סינון `collection`
     ✅ `get_sp(s, p)` - משתמשת ביעילות במפתח ראשי (`collection, s, p`)
     ⚠️ `get_po(p, o)` - דורשת `ALLOW FILTERING` (משתמשת או ב-`idx_p` או ב-`idx_o` בתוספת סינון)
     ✅ `get_os(o, s)` - משתמשת ב-`idx_o` עם סינון נוסף על `s`
     ✅ `get_spo(s, p, o)` - משתמשת ביעילות במפתח ראשי מלא

   **הערה על ALLOW FILTERING**: דפוס השאילתה `get_po` דורש `ALLOW FILTERING` מכיוון שהוא זקוק גם לאילוצי פרידיקט וגם לאובייקט ללא אינדקס מורכב מתאים. זה מקובל מכיוון שדפוס השאילתה הזה פחות נפוץ משאילתות מבוססות סובייקט בשימוש טיפוסי במאגר טריפל.

2. **עדכוני כותב אחסון** (`trustgraph/storage/triples/cassandra/write.py`):
   שמירה על חיבור TrustGraph יחיד לכל משתמש במקום לכל (משתמש, אוסף)
   העברת האוסף לפעולות הכנסה
   שיפור ניצול משאבים עם פחות חיבורים

3. **עדכוני שירות שאילתות** (`trustgraph/query/triples/cassandra/service.py`):
   חיבור TrustGraph יחיד לכל משתמש
   העברת האוסף לכל פעולות השאילתה
   שמירה על לוגיקת שאילתה זהה עם פרמטר האוסף

**יתרונות:**
**מחיקת אוספים מפושטת:** מחיקה באמצעות מפתח מחיצה `collection` בכל 4 הטבלאות
**יעילות משאבים:** פחות חיבורי מסד נתונים ואובייקטי טבלה
**פעולות חוצות אוספים:** קל יותר ליישם פעולות המשתרעות על פני מספר אוספים
**ארכיטקטורה עקבית:** מתאימה לגישה מאוחדת למטא-נתונים של אוספים
**אימות אוסף:** קל לבדוק את קיום האוסף באמצעות טבלת `triples_collection`

פעולות איסוף יהיו אטומיות במידת האפשר, ויספקו טיפול בשגיאות ואימות מתאימים.

## שיקולי אבטחה

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

## שיקולי ביצועים

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

## אסטרטגיית בדיקות

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

## סטטוס יישום

### ✅ רכיבים שהושלמו

1. **שירות ניהול איסופים של Librarian** (`trustgraph-flow/trustgraph/librarian/collection_manager.py`)
   פעולות CRUD של מטא-נתונים של איסוף (רשימה, עדכון, מחיקה)
   שילוב עם טבלת מטא-נתונים של איסוף ב-Cassandra באמצעות `LibraryTableStore`
   תיאום מחיקת איסוף עם השפעה על כל סוגי האחסון
   טיפול בבקשות/תגובות אסינכרוניות עם ניהול שגיאות מתאים

2. **סכימת מטא-נתונים של איסוף** (`trustgraph-base/trustgraph/schema/services/collection.py`)
   סכימות `CollectionManagementRequest` ו-`CollectionManagementResponse`
   סכימה `CollectionMetadata` עבור רשומות איסוף
   הגדרות נושא תורים עבור בקשות/תגובות של איסוף

3. **סכימת ניהול אחסון** (`trustgraph-base/trustgraph/schema/services/storage.py`)
   סכימות `StorageManagementRequest` ו-`StorageManagementResponse`
   נושאים של תורי ניהול אחסון הוגדרו
   פורמט הודעה עבור פעולות של איסוף ברמת האחסון

4. **סכימת 4-טבלאות של Cassandra** (`trustgraph-flow/trustgraph/direct/cassandra_kg.py`)
   מפתחות מחיצה מורכבים לביצועי שאילתה
   טבלה `triples_collection` עבור שאילתות SPO ומעקב אחר מחיקה
   יישום מחיקת איסוף עם דפוס של קריאה ולאחר מכן מחיקה

### ✅ מעבר לדפוס מבוסס תצורה - הושלם

**כל ה-backend של האחסון עברו מדפוס מבוסס תורים לדפוס מבוסס תצורה `CollectionConfigHandler`.**

מעברים שהושלמו:
✅ `trustgraph-flow/trustgraph/storage/triples/cassandra/write.py`
✅ `trustgraph-flow/trustgraph/storage/triples/neo4j/write.py`
✅ `trustgraph-flow/trustgraph/storage/triples/memgraph/write.py`
✅ `trustgraph-flow/trustgraph/storage/triples/falkordb/write.py`
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/qdrant/write.py`
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/qdrant/write.py`
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/milvus/write.py`
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/milvus/write.py`
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/pinecone/write.py`
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/pinecone/write.py`
✅ `trustgraph-flow/trustgraph/storage/objects/cassandra/write.py`

כל ה-backend כעת:
יורשים מ-`CollectionConfigHandler`
נרשמים לקבלת הודעות דחיפה של תצורה באמצעות `self.register_config_handler(self.on_collection_config)`
מיישמים `create_collection(user, collection, metadata)` ו-`delete_collection(user, collection)`
משתמשים ב-`collection_exists(user, collection)` לאימות לפני כתיבה
מסתנכרנים באופן אוטומטי עם שינויים בשירות התצורה

תשתית מבוססת תורים ישנה הוסרה:
✅ הוסרו סכימות `StorageManagementRequest` ו-`StorageManagementResponse`
✅ הוסרו הגדרות נושאים של תורי ניהול אחסון
✅ הוסר צרכן/מפיק תורים מכל ה-backend
✅ הוסרו מטפלים `on_storage_management` מכל ה-backend