אני עובד על יישום שמשתמש בעץ נתונים דיי גדול -
אמורים להיות בסביבות הכמה עשרות אלפים שורשים,
מתוך כל שורש ייצאו רמות אחדות של צאצאים (בסביבות 6 בממוצע).

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

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

מה עוד שמוזר לי שאין פתרון(או שלא מוכר לי פתרון) לעבודה על מבני נתונים היררכים גדולים.

מערכת הקבצים היא הדרך הטבעית לטיפול בנתונים היררכיים.

openldap

האם יהיה צורך לגשת אל המבנה מכמה שפות תכנות? מכמה מחשבים? (אם התשובות הן לא, אזי חפש ספרייה המממשת סוג כלשהו של paging)

צפריר :

מערכת הקבצים היא הדרך הטבעית לטיפול בנתונים היררכיים.

אתה צוחק?
אני חושב שמימוש של xml/doc מעל JavaScript יתקרוב לביצועים של דבר כזה. אולי, ואולי גדול, אם הספרייה הזאת יושבת מעל tmpfs יהיה שווה לשקול לעשות דבר כזה.

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

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

שרתי LDAP בהשוואה לשרתי SQL יעילים יותר בקריאה ופחות בכתיבת נתונים.

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

*הגישות שאני מדבר עליהן הן:
http://www.codeproject.com/cs/database/Trees_in_SQL_databases.asp
ו- Nested sets:
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

גם כאשר אתה עובד עם sqlite, או עם mysql, אתה בסופו של דבר ניגש לדיסק.

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

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

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

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

אתה יכול להשתמש גם ב־symlinks או ב־hard links כדי ליצור שמות כפולים לאותו הקובץ.

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

"מערכות קבצים עם מספר קבוע של inodes" הן ext2 ו־ext3 . ב־ext4 הולכים להפטר מזה. יש לך, לעומת־זאת, את reiserfs, reiserfs4, xfs ו־jfs שבהן אין את המגבלה הזו.