# SYNC_DOMAIN.md — מסמך הנדסי: מדומיין דיגיטלי ברשת למטמון בינארי חכם
גרסה 1 · 15.9.2026 · נכתב אחרי ארבעה דומיינים חיים (ויקיפדיה 364 מהדורות, ויקימילון 198, הספרייה היהודית, ויקינתונים-חלקי). המספרים "אצלנו" נמדדו; המספרים "אצלם" הם הערכות מסומנות.

---
## חלק א — כמה מידע צריך כדי להפעיל את ויקיפדיה, וכמה יש אצלנו

### א.1 מה קרן-ויקימדיה מחזיקה כדי להפעיל את המערכות (הערכה, 2025–2026)
| מרכיב | תפקיד | גודל משוער | ודאות |
|---|---|---|---|
| **MariaDB — מסדי-הליבה** (s1–s8, x1, es) | כל הטבלאות: page, revision, links, categories, user, logging, watchlist… לכל 900+ ויקי | ~30–40 TB לעותק (enwiki לבדו ~4–5 TB); ×2 מרכזי-נתונים ×~5 רפליקות → **~300–400 TB** בפועל | בינונית |
| **External Storage (טקסט-הגרסאות)** | כל גרסה שאי-פעם נשמרה, דחוסה בבלוקים | ~100–150 TB לוגי (דאמפ pages-meta-history של enwiki: ~20–25 TB XML גולמי, ~1.3 TB 7z) | בינונית |
| **Swift — מדיה (Commons)** | 110M+ קבצים, מקוריים + גזירות | **~500–600 TB** × 2 DC | גבוהה יחסית |
| **CirrusSearch (Elasticsearch)** | אינדקס טקסט-מלא לכל השפות | ~100–150 TB (עם רפליקות) | בינונית |
| **Wikidata** (SQL + Blazegraph/WDQS) | 123M ישויות, 2.5B עריכות, גרף RDF | SQL ~2 TB · גרף ~1.5–2 TB × כמה עותקים | גבוהה |
| **מטמונים** (ATS/Varnish, Memcached, ParserCache) | תגובה בפחות מ-100ms | ~10–20 TB SSD/RAM לכל DC | בינונית |
| **גיבויים, Analytics (Hadoop), לוגים** | | פטה-בייטים (Analytics לבדו >2 PB) | נמוכה |
| **סה"כ תפעולי** (ללא analytics/גיבויים) | | **~1.5–2.5 PB** ברוטו, על ~1,500+ שרתים בשני DC | — |

### א.2 מה יש אצלנו (נמדד היום)
| מרכיב | גודל |
|---|---|
| דאמפים שהורדנו (bz2, current revision only) | 104 GB (364 מהדורות) + 6.4 GB (198 מילונים) + 3.3 GB (ספרייה) |
| **המוצר הבינארי** — טקסט UTF-8 + מישור-18-ביט + אינדקסים + גרף + שכבות-עזר | **~1,006 GB לוגי · 471 GB פיזי** (דחיסת ZFS ×2.1) |
| רשומות | 2.74 מיליארד |
| מכונה אחת: 12 ליבות, 64 GB, 477 GB SSD + 5 TB Storage Box | |

### א.3 למה אצלנו ~1 TB ואצלם ~2 PB — הסיבה לפער (×2,000)
1. **גרסה אחת בלבד.** אנחנו שומרים את הגרסה הנוכחית של כל ערך; הם — כל 2.5 מיליארד העריכות. זה לבדו ×20–50.
2. **בלי מדיה.** 500+ TB של תמונות/וידאו/אודיו. אנחנו: קישורים + 15K תמונות-מוקטנות בעברית.
3. **בלי רפליקציה.** אין לנו 5 עותקים בשני מרכזי-נתונים; יש עותק אחד + Storage Box.
4. **בלי אינדקס-חיפוש חי.** Elasticsearch מחזיק ×3–5 מהטקסט; אצלנו postings בינארי רק לעברית (2.1 GB) והשאר קידומת/גדר.
5. **בלי טבלאות-משתמשים, לוגים, watchlists, הרשאות** — כלום.
6. **בלי מטמונים** — ה-Range עצמו הוא המטמון; אין ParserCache כי אין רינדור בשרת.

### א.4 למה אצלנו ×9 מהדאמפ (ולא ×3.3 כמו UTF-8 בלבד)
| שכבה | יחס לדאמפ bz2 | הערה |
|---|---|---|
| טקסט UTF-8 (pool) | ×3.3 | הדחיסה של bz2 |
| **מישור-18-ביט** | ×2.6 | 2.25 B/תו קבוע; ללטינית זה יקר יותר מ-UTF-8 (1 B/תו), לעברית/CJK זול יותר (2–3 B/תו) — המחיר של גישה O(1) לתו |
| אינדקסים (כותרות, מיון, גדר, cpos) | ×0.6 | |
| שכבות-עזר (langlinks, page_props, geo, cats) | ×0.4 | לאחר השלמה ×1 |
| גרף/postings (עברית בלבד כרגע) | ×0.3 | לכל השפות: ×3 |
| **סה"כ** | **~×7–9** | ובקופסה, אחרי ZFS: ×3.5–4 בפועל |

**המסקנה:** את מה שוויקימדיה מפעילה ב-2 PB, אנחנו מחזיקים ב-1 TB לוגי — כי אנחנו לא מפעילים ויקי; אנחנו מחזיקים **את הידע**, ברמת-גישה של בייט, בלי שרת.

---
## חלק ב — יכולות-שאילתה על החומר המקומי (היום), מול האינטרנט

### ב.1 מה עובד עכשיו ב-Range בלבד (בלי שרת-חכם)
| יכולת | איך | דומיינים |
|---|---|---|
| ערך לפי כותרת (מדויק/קידומת/מפתח-פרופיל) | גדר → דלי → tsorted → index → text | 364 wiki · 198 wikt |
| ערך לפי מספר (k) | index[k] → text | כולם |
| ערך אקראי, ניווט קדימה/אחורה | index | כולם |
| קישורים יוצאים/נכנסים ("מה מקשר לכאן") | links/linkidx/back/backidx | he (מלא) |
| סעיפים, קטגוריות, תבניות-מידע, מבנה | sections/cats/struct | he |
| חיפוש-מילה בגוף הטקסט (postings עם מיקום) | tokens/tpos/post/postidx | he (277M טוקנים) |
| פירוש-מילה (POS, שורש, הגדרה) | gloss/glossidx | he (28.5K) |
| תו מס' i בכל טקסט (O(1)) | chars (18-bit) + cpos | 330 wiki · 170+ wikt · ספרייה |
| "אותו ערך בשפות אחרות" | langlinks (32 שפות עד כה) | חלקי |
| Q-id של ויקינתונים לכל ערך | page_props | חלקי |
| קואורדינטות לכל ערך-מקום | geo_tags | חלקי |
| פסוק → מפרשים/מקבילות/ציטוטים | lib_links + linkidx (5.4M קשתות, 1,537 סוגים) | ספרייה |
| כותרת בכל השפות בבת-אחת | read.html: גדר לכל מהדורה, 8 במקביל | 338 |

### ב.2 מה עדיין לא (ומה זה ידרוש)
- **טקסט-מלא בכל שפה** — postings לכל מהדורה: ~×3 מהטקסט (2.5 TB), או n-gram על כותרות בלבד (200 MB).
- **שאילתה על עובדות** ("כל הערים שנוסדו לפני 1500") — דורש truthy (40 GB) כגרף ממוין + gשר page_props (בבנייה).
- **חיפוש סמנטי** — לא בתחום (CPU-only, ללא embeddings) עד שיוחלט.
- **מחקר מול האינטרנט:** היום — השוואה נקודתית (API של המקור מול השבב, כמו ב-verify); לא crawling. הכיוון: כל השוואה כזו נכנסת כעץ-מקור נוסף.

### ב.3 דוגמה: מחקר-שפה שאפשר לעשות היום מקומית ב-Python בלי רשת
"אילו ערכים קיימים בעברית ובערבית אבל לא באנגלית?" = langlinks(he) ∩ langlinks(ar) − langlinks(en): שלוש קריאות-Range על שלושה שבבים של ~100 MB, חיתוך במיליוני רשומות של 24 B — שניות.

---
## חלק ג — הפרוטוקול: מדומיין ברשת למטמון בינארי חכם (12 שלבים)

### ג.0 עקרונות שלא זזים
1. **בינארי טהור, רשומה קבועה, כתובת = היסט.** כל שבב: כותרת `<III` (מגיק · count · pool_len), pool מחרוזות, רשומות. sha8 (8 בייט ראשונים של SHA-256) בכל רשומה שמצביעה לתוכן.
2. **המקור הוא עץ.** לפני שמורידים בייט — עץ-מקור (`<domain>_tree.bin`, 64 B/צומת) שאומר מה יש, בגרסה איזו, בגודל איזה. הסנכרון הוא השוואת עצים.
3. **אורקל לכל שלב.** נוסחת-אורך · זרוע-B (הופכים ביט ומוכיחים שהבדיקה נכשלת) · בדיקת-נקודה (300 רשומות אקראיות מול ה-pool). שלב בלי אורקל = לא בוצע.
4. **הכל אחרי-הקידוד — לאחסון-הכבד** (קופסה), **קופסה-קודם** לדאמפים גדולים; המקומי הוא שטח-עבודה בלבד, עם מטאטא.
5. **append-only.** סנכרון-דלתא מוסיף רשומות עם דגל-דלתא; לעולם לא משכתב באמצע. גרסה חדשה של המקור = קובץ חדש בשם-גרסה, קישור-סימבולי/`layers.json` מחליף.
6. **CPU בלבד, Range בלבד.** הקורא הוא HTML סטטי שמבצע את כל הלוגיקה מול `Range:` — אם משהו דורש שרת-חכם, הוא לא שייך לשכבת-המטמון.
7. **דרך מחזור.** כל פעולה = משימה בתיבה → runner → לוג → הודעה בקבוצה. אין הרצות ידניות.

### ג.1 גילוי (Discovery)
- מצא את **הדאמפ הרשמי** לפני ה-API: ויקימדיה — `dumps.wikimedia.org/<db>/latest/` + `md5sums.txt`; ספריא — דלי GCS `sefaria-export` עם `md5Hash/updated`; ויקינתונים — `entities/`. API הוא לדלתא ולאימות-נקודה, לא לסבב-ראשון.
- מדוד: `HEAD` לכל קובץ (Content-Length, Last-Modified), ורשום את **הפורמט הפנימי** (XML multistream? JSON-lines? SQL INSERT? CSV?).
- **מינוס:** מקורות עם רישום זול (רשימת-אובייקטים עם md5) מקבלים דלתא אמיתית; מקורות בלי (רק "latest") מקבלים דלתא חודשית לפי תאריך.

### ג.2 עץ-המקור
- `tree_build_<domain>` בונה `<domain>_tree.bin` ישירות מהמקור: קטגוריה → פריט → תת-פריט, עם `src_ref`, `src_ver`, `src_bytes`, status (חסר/מסונכרן/השתנה/נכשל/אין-במקור).
- הרצה: מלאה פעם בחודש (וכל שינוי-סכימה), **יומית** לפני סנכרוני-הטקסט. אורקל: 0 פריטים לא-מסווגים; מספר-הפריטים = מקור עצמאי (sitematrix / ToC / רשימה).
- **המשגר קורא רק מהעץ** (`tree_diff_<domain>.json`). קובצי skip/inventory אסורים — הם הזדהמו פעמיים.

### ג.3 הורדה
- מראות (your.org, accum.se, umu.se, clarkson, c3sl) עם נפילה-חזרה; `download_parallel(url, dst, conns)` — 2–8 חיבורי-Range; md5 **מהמקור** (לא מהמראה) **לפני** שמסמנים "מוכן".
- ענקים: הורדה אחת משותפת, `.ready` רק אחרי md5, נתחים ממתינים עד 3 שעות.
- **מינוס ידוע:** ניתוק-SMB רגעי הורג כל מי שכותב לקופסה באותו רגע — נתחי-עבודה נכתבים מקומית, רק התוצר הסופי לקופסה.

### ג.4 פענוח מקבילי
- `ingest_fast.parallel_pages(dump, index)`: זרמי-bz2 עצמאיים (multistream) לתהליכי-עובד; האב כותב ברצף. ×13 מול זרם יחיד. הצוואר הבא הוא תהליך-האב → פיצול ל-N נתחים עם pool לכל נתח, ומיזוג (רה-בסיס היסטים) — ×4 נוספים.
- לכל פורמט — פרסר אחד: XML (expat), SQL INSERT (מפצל-ערכים עם מרכאות), JSON מקונן (flatten עם כתובת), CSV.

### ג.5 קידוד
- שבבי-ליבה לכל דומיין: `pages` (48 B: id, rev, flags, ts, title(off,len), text(off,len), sha8) · `text` (pool) · `index` (24 B, רק פריטים "אמיתיים") · `meta` (מקור-סנכרון, סימן-מים, רישיון).
- **מגיקים** רשומים ב-MAGNET-DEV: `C0DE0Exx` ויקי, `C0DE0Fxx` מילון, `C0DE1xxx` עזר, `5EFA` ספרייה, `5EED` בית, `7EEE` עצים.
- שמות: `<db>_<kind>.bin`; שדות u16 מקבלים `min(x, 65535)` — לעולם לא קריסה על גלישה; `4x`/`2x` ריפוד עד גודל עגול.
- **הכלל שנלמד בדם:** זהות-פריט = (חיבור, שפה, מיקום-בקובץ), לא כתובת אנושית. כתובות חוזרות.

### ג.6 אימות
- שלושת האורקלים בכל שבב; לוג מדפיס `VERIFY ok=… why=…` עם הסיבה המדויקת (לא "נכשל").
- **חתימות-כשל מוכרות:** זרוע-B בהיסט שגוי (חשב מה-struct!) · cp1252 ב-Windows (`encoding="utf-8"` בכל open) · PermissionError על החלפת קובץ ענק (Defender; retry 12 דק' או קופסה-קודם) · multistream בלי אינדקס (נפילה לזרם) · `.ready` לפני md5 · שני מופעים כותבים לאותו json (`raw_decode`) · שם-קובץ שכבר רץ (ה-runner מזהה לפי **hash-תוכן** — החותמת חייבת להיות בתוכן).

### ג.7 אינדקסים
- כותרות: `titles` (מפתח-פרופיל לפי שפה: NFC, הסרת-סימנים, איחודים, רישיות) → `tsorted` → `fence` (כל 256) → בוטסטרפ בדפדפן ~100 KB. מעל 10M כותרות — גדר דו-שכבתית.
- גרף: קשתות ממוינות לפי מקור + טבלת-היסט לכל צומת (12 B). "מה מקשר לכאן" = אותו דבר הפוך.
- תוכן: טוקנים → צורות → postings עם מיקום (עברית: 277M טוקנים, 2.1 GB). לכל שפה: אותו צינור עם הטוקנייזר מהפרופיל.

### ג.8 מישור-18-ביט
- `plane18.exe text.bin index.bin chars alphabet cpos`: אלפבית (עד 262,144 סימנים), 2.25 B/תו, `cpos` = תו-התחלה לכל פריט, סבב-חזרה 65/65 מדויק. **שים לב:** plane18 שומר רשומה אחרונה לכל מזהה — לפריטים רבים תחת מזהה אחד (קטעים) תן מזהה ייחודי לכל קטע.

### ג.9 קורא
- HTML אחד לדומיין, RTL/LTR לפי הפרופיל, טוען בוטסטרפ, מבצע גדר→דלי→Range. קישור-עומק (#כותרת/מיקום). מאחד Range סמוכים לבקשה אחת. אף שורת-קוד בשרת.

### ג.10 פרסום
- `shelf\shelf\<db>\` — קובץ מקומי → hardlink; קובץ בקופסה → symlink ליעד (**לעולם לא copyfile דרך symlink**). `layers.json` מצביע לגרסאות-הקבצים הפעילות. `home.bin` מגלה כל קובץ חדש (יומי) ו-`pages.json` ממפה כל דף; סרגל-ניווט מוזרק לכל HTML.

### ג.11 סנכרון
- **ראשון:** מהעץ, עד `tree_diff` ריק (פרט ל"אין-במקור" מוכח). **יומי:** קודם עץ (04:00Z), ואז לכל פריט מסונכרן — מנגנון-הדלתא של המקור (ויקימדיה: `recentchanges` מאז סימן-המים; ספריא: md5 של הדלי מול המניפסט; ויקינתונים: דאמפ שבועי). דלתא = append + דגל; אינדקס-קורא מחדש; דגימה מול ה-API (3–10 פריטים) כאורקל.
- **חודשי:** דאמפים חדשים (1 ו-20 לחודש) → העץ מסמן "השתנה" → טעינה מחדש בשם-גרסה, החלפת-קישור.
- **חובה:** כל טוען/מיזוג רושם בעצמו את משימת-הסנכרון-היומית של הפריט (הפספוס הזה השאיר 18 מהדורות בלי סנכרון).

### ג.12 ניטור
- קובצי-מצב JSON (כל דקה): `live_status` (רץ/תור-אמיתי/כשלים/הפסקות), `host_status` (מעבד/זיכרון/רשת/דיסק/תהליכים/שימוש-פיזי-בקופסה), `<domain>_status`, `asset_ledger` (מקור/אצלנו/כיסוי/יומי), `tree_status`, `audit` (יומי: מגיק/אורך/sha8/מיקום/קוראים/סנכרון).
- דשבורדים: חדר-בקרה (10 שניות), נכסים, מפרט, דומיין, קריאה, כל-הדפים — **כל תג-טריות מראה מתי הנתון נמדד**; זמן מוצג בברלין, נשמר UTC.
- runner: מכסות לפי מחלקה (`# CLASS:`), נעילות (`# LOCK:`), `rc=0xC000013A` = הופסק ולא כשל; worker: ניקוי-רפאים בכל סבב.

---
## חלק ד — צ'ק-ליסט לדומיין חדש (מוזיקה, משפט, רפואה…)
1. מקור-דאמפ רשמי? רישום עם md5? מנגנון-דלתא? רישיון? → נכתב ב-`meta`.
2. עץ-מקור מלא (ג.2) — ואורקל: מספר-פריטים ממקור עצמאי.
3. פרסר לפורמט → רשומה קבועה, מגיק חדש רשום, u16 עם תקרה.
4. סבב-ראשון בנתחים מקבילים ישר לקופסה; מיזוג; 3 אורקלים; `VERIFY` בלוג.
5. אינדקסי-כותרת לפי פרופיל-שפה; מישור-18-ביט; קורא.
6. פרסום + `layers.json` + רישום ב-`home.bin`; משימת-סנכרון-יומית + עץ-יומי.
7. כרטיס-דומיין: מקור / אצלנו / כיסוי / יומי; ביקורת-מדף יומית מכסה אותו אוטומטית.
8. ישיבת-מומחים רק אחרי 100% מול המקור.

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