|
||||
|
||||
0. לגבי SQL - המסקנה שלי הפוכה (כלומר, לא שהוא המלאך גבריאל, אבל הוא גם לא השטן). 1. לא (בד"כ לא מדובר בדפדפנים לא תומכים אלא במשתמשי IE/FF שמכבים את התמיכה). 2. לא הבנתי. יש כמה דרגות cache שונות. זה של עמודים שלמים מנוהל לחלוטין ע"י התוכנה שלי; זה של MySQL הוא "אוטומטי" (כלומר לא בשליטתי) אבל יש דרכים שונות לקנפג אותו. 3. (לכל האתרים גם יחד - האייל, עין הדג ואחרים) מעל 10GB (ל-DB בלבד, לא כולל cache למשל). |
|
||||
|
||||
"(כלומר, לא שהוא המלאך גבריאל, אבל הוא גם לא השטן)". עד כה לא הבנתי כלום מהדיון, אבל עכשיו אתם עוברים לתיאולוגיה? |
|
||||
|
||||
אם *זה* נראה לך מוזר, מה תגיד על זה שכשטל כתב (תגובה 380931) "טיפול בכמה עשרות משתמשים בו-זמנית [...] יוביל לגלישה מהירה מאוד לזיכרון וירטואלי (איטי)", פירוש הדבר שזה יוביל לגלישה *איטית* מאוד? |
|
||||
|
||||
אה, זה בסדר - את שני המובנים האלה של ''גלישה'' אני מבינה... הבעיה של היא עם מלים אחרות. |
|
||||
|
||||
10GB? פעם זה היה הרבה פחות... (אני זוכר תגובה שלך שבה ציינת פחות מ-100MB, <דמיין קישור כאן>). איך זה צמח כל כך הרבה? |
|
||||
|
||||
כל המאמרים עם צילומים של יצירות ארכיטקטוניות :) |
|
||||
|
||||
בלי להזכיר שמות (הם כבר יזכירו את עצמם), התגובות של אחדים מאיתנו עוברות סינגל קיבורדד את ה-100MB. |
|
||||
|
||||
מעניין אם יש מקום שבו קיימים הנתונים הללו, באמת. |
|
||||
|
||||
שכ''ג מחזיק את הנתונים האלה אצלו, במרתף של החשמנית. |
|
||||
|
||||
שינוי מבנה ה-DB (לא מבנה הטבלאות אלא סוג ה-DB, מבין הסוגים ש-MySQL תומך בהם), והוספת אינדקס מילים לחיפוש. |
|
||||
|
||||
"מאמרים: כ- 5.5MB, תגובות (לא כולל כאלה שהוסרו): כ- 74MB. המספרים מתייחסים לגוף הטקסט בלבד (לא כולל כותרות, שמות הכותבים, ומטא-מידע)." תגובה 190500 |
|
||||
|
||||
אה. לפי שיטת המדידה הזו, מאמרים: 7MB, תגובות (לא כולל מוסרות): כ-133MB. או במילים אחרות, המערכת הורידה קצב, הציבור הרחב דווקא לא. מפתיע מישהו? |
|
||||
|
||||
אחת ולתמיד: כמה מהמגה בייטים הללו תרם מופע האימים של דורון שדמי? |
|
||||
|
||||
עם הציור או בלי? |
|
||||
|
||||
אבל שאילתה לכל תגובה במקום שאילתה לכל צפייה זה מבחינתי זוועה שלא תעלה על הדעת. שאלה אחרונה: מאיזו סיבה מכבים את התמיכה בגאווהסקריפט? |
|
||||
|
||||
לא לכל תגובה, לכל דרגת עומק בעץ, או משהו. למה זוועה? כמות המידע שעובר כך מ-MySQL לתוכנה הוא קטן יותר מאשר בשאילתה אחת גדולה. הזמן שנדרש ע"י השרת לשם ביצוע parsing לשאילתה, וכו' הוא בטל ב-6,000. יוצא ששרת ה-SQL עושה עבורי את עבודת המיון והסינון שאחרת הייתי עושה בעצמי, ו(סביר להניח) שבביצועים טובים יותר ממה שאני הייתי משיג (ולו משום השרת כתוב ב-C, הקוד שלי ב-PHP לא מקומפל). אני אישית עובד עם FireFox, ומשתמש ב-plugin שנקרא NoScript. כך, JavaScript (וגם Flash) כבוי כברירת מחדל, אבל אני יכול להחליט להפעיל אותו פר-אתר, או רק באופן זמני לאתר מסוים. התוצאה: גלישה ללא אנימציות מציקות, ללא פרסומות קופצות, ללא יכולת לאתר לרמות אותי ולהציג בשורת הסטטוס יעד קישור השונה מהיעד האמיתי, וכו'. אם באתר מסוים אני זקוק ל-JS, אני יכול להפעילו בלחיצה זריזה – רק להפעם, או באופן קבוע לאתר זה. מאוד, מאוד נוח. אני מניח שלגולשים אחרים יש שיקולים נוספים. |
|
||||
|
||||
סליחה על הקטנוניות המתמשכת, אבל: "ולו משום השרת כתוב ב-C, הקוד שלי ב-PHP לא מקומפל" גם עכשיו הקוד שלך לא מקומפל, לא? הרי כל הפונקציות ב-php כתובות בסופו של דבר ב-c, לא רק של mysql. אז מה ההבדל בעצם, מהבחינה הזאת, בין תוכנית שמשתמשת ב-sql לתוכנית שמשתמשת, נגיד, במערכת נתונים מבוססת-קבצים? |
|
||||
|
||||
אני מעביר ל-MySQL בקשה. MySQL, בשל מבני הנתונים שלו (כגון אינקסים תומכים) מסוגל לבצע את החיפוש (כולל ה-parsing של הבקשה עצמה, מחרוזת SQL) מהר בהרבה מכפי שיכולתי אני לעשות זאת ב-PHP. מכמה סיבות - שפת התכנות, מומחיות כותבי הקוד בתחום, וכו'. גם אם יכולתי לעשות זאת ב-PHP ולהגיע לאותם ביצועים (ספק), או לביצועים טובים יותר (פנטזיה), המאמץ הנדרש היה כה רב שקשה להצדיק זאת. |
|
||||
|
||||
לדעתי אתה טועה - האלגוריתמים שמתבצעים במסד נתונים כמו באתר הזה הם פשוטים להפליא וקל מאוד להביא אותם לייעול מקסימלי, דבר ששום מסד נתונים מוכן לא יוכל להגיע אליו. זה גם הרבה יותר... מספק, כזה. (מניסיון: החלק הקשה בתכנון שכזה הוא בדיוק החלק שבו הוא שונה מ-sql, כלומר תכנון המבנה של הקבצים ככה שיותאם במיוחד ליישום הספציפי ויהיה יעיל לחפש בתוכם ולשנות אותם. זאת אומרת שאם אתה לא עושה כלום וקובע הכל שרירותית זה בעצם בדיוק כמו sql, ואפילו יותר טוב כי אתה לא צריך לטעון פונקציות לא הכרחיות ודברים כאלה. ) |
|
||||
|
||||
פשוט לא נכון. "האלגוריתמים שמתבצעים במסד נתונים... הם פשוטים להפליא"? מה מידת ההיכרות שלך עם תחום ניהול מסדי הנתונים, ובפרט את תחום האופטימיזציות? מסדי הנתונים משתמשים באלגוריתים חזקים מאוד, ועובדים עליהם טובי המומחים בתחום (זה אולי מוטל בספק לגבי MySQL, אבל בהחלט נכון לגבי DB2, אורקל וכו'). כשמדובר בפעילות יעילה, כולל נושאים מתקדמים כמו טרנזקציות (ביצוע כמה פעולות ברצף, כך שאם אחת נכשלת, כולן מתבטלות; וזאת, בשעה שתוכניות אחרות פועלות במקביל על אותם הנתונים), לא סביר שאוכל להתחרות בהם. שלא לדבר על זמינות מוגבלת של זמן חופשי: גם אם אשיג ביצועים טובים יותר, ודאי יידרשו עשרות שנים עד שההבדל בביצועי השרת, כפי שהוא נמדד ביחידות זמן, יצטבר לכדי כיסוי על השעות שאשקיע בכתיבת הקוד הנ"ל. בתור מי שהשקיע שעות (רבות מאוד מאוד) באופטימיזציה ידנית של קוד אסמבלר, כולל רבים מהטריקים המלוכלכים המקובלים באמנות הזו, הרשה לי לספר לך שהסיפוק ממצה את עצמו די מהר, לעומת הקושי שבתחזוקת הקוד, איתור ותיקון באגים, וכו'. כיום לפחות אני מוצא את הסיפוקים שלי במקומות אחרים, ודאי לא בהמצאה מחודשת של גלגלים קיימים. כדאי לקחת בחשבון שגם בפרוייקטים גדולים בהרבה, שם לביצועים משמעות גדולה בהרבה, עדיין משתמשים ב-SQL. כדאי לך לשאול את עצמך למה. [ההערה שלך על טעינת פונקציות לא הכרחיות מעידה על חוסר בקיאות מסוים באופן הפעולה של מערכות תוכנה גדולות בימינו. קוד נטען on-demand על-ידי מיפוי של קובץ ה-executable ל-page file של המערכת; אף פונקציה לא נטענת לפני שמשתמשים בה (עד כדי טעות בגודל דף, כלומר אולי הפונקציה נטענה במקרה כי היינו זקוקים לפונצקיה אחרת ששכנה באותם 4KB).] אבל באופן כללי יותר, נדמה לי שהטעות הבסיסית שלך היא ההנחה שאני סובל מעודף זמן... |
|
||||
|
||||
"מה מידת ההיכרות שלך עם תחום ניהול מסדי הנתונים, ובפרט את תחום האופטימיזציות?" אני כרגע בשלבים סופיים של תכנון מסד נתונים די דומה למה שיש פה, ואני באמת לא רואה איך מסד נתונים מוכן יכול לעלות על מה שעשיתי מבחינת יעילות. אין תחליף לדעתי לשליטה המוחלטת שיש לי בקשר לחלוקה לקבצים, המבנה של כל קובץ, האלגוריתמים עצמם כשהם מותאמים לשני אלה וכל מיני שיטות אינדקס וקיצורים שמסד נתונים מוכן לא יכול לדעת שהם אפשריים. מה הסיבוך שאתה רואה בתכנון כזה? האלגוריתמים החשובים היחידים הם חיפוש בתוך קובץ ושינוי של קובץ, עם תוספות של שמירה ב-cache וכו'. "מסדי הנתונים משתמשים באלגוריתים חזקים מאוד, ועובדים עליהם טובי המומחים בתחום (זה אולי מוטל בספק לגבי MySQL, אבל בהחלט נכון לגבי DB2, אורקל וכו'). כשמדובר בפעילות יעילה, כולל נושאים מתקדמים כמו טרנזקציות (ביצוע כמה פעולות ברצף, כך שאם אחת נכשלת, כולן מתבטלות; וזאת, בשעה שתוכניות אחרות פועלות במקביל על אותם הנתונים), לא סביר שאוכל להתחרות בהם. שלא לדבר על זמינות מוגבלת של זמן חופשי: גם אם אשיג ביצועים טובים יותר, ודאי יידרשו עשרות שנים עד שההבדל בביצועי השרת, כפי שהוא נמדד ביחידות זמן, יצטבר לכדי כיסוי על השעות שאשקיע בכתיבת הקוד הנ"ל. " לא הטלתי ספק במומחיותם של כותבי הקוד, פשוט קשה לי לראות איך משהו מוכן יכול לעלות בביצועיו על משהו מותאם אישית. נכון שזאת "עוד השקעה", אבל זה קצת מוגזם לדעתי להגיד שיידרשו עשרות שנים להגיע לזה, ושנדרש איזשהו מאמץ מיוחד בתחזוקה ועדכון של הקוד (בהנחה שאתה מבין מה אתה עושה). "כדאי לקחת בחשבון שגם בפרוייקטים גדולים בהרבה, שם לביצועים משמעות גדולה בהרבה, עדיין משתמשים ב-SQL. כדאי לך לשאול את עצמך למה. " העובדה שמשתמשים במשהו לא הופכת אותו ליעיל יותר. פרוייקטים גדולים מבוצעים בדרך כלל תוך התחשבות בזמן הפיתוח לא פחות מאיכות המוצר הסופי. אי-שימוש ב-sql יהיה בזבזני מאוד מהבחינה הזאת, והתועלת תהיה קטנה מאוד יחסית למחיר הזה. זה לא אומר שהתועלת לא קיימת. "[ההערה שלך על טעינת פונקציות לא הכרחיות מעידה על חוסר בקיאות מסוים באופן הפעולה של מערכות תוכנה גדולות בימינו. קוד נטען on-demand על-ידי מיפוי של קובץ ה-executable ל-page file של המערכת; אף פונקציה לא נטענת לפני שמשתמשים בה (עד כדי טעות בגודל דף, כלומר אולי הפונקציה נטענה במקרה כי היינו זקוקים לפונצקיה אחרת ששכנה באותם 4KB).]" כנראה שלא הסברתי את זה נכון. בוא ניקח דוגמה: איך אתה מבצע שאילתה? אתה מקבל נתונים, בונה לפיהם מחרוזת ומפעיל פונקצייה שתקרא את המחרוזת, תפרוס אותה ותקרא בתורה לפונקצייה שתפעיל את השאילתה הרצויה ותחזיר לפונקצייה הראשונה ערך כלשהו, שאותו היא תחזיר לתוכנית שלך (גם זה באופן בזבזני במיוחד, כמו שציינת בעצמך בתגובה 380931. שים לב, דרך אגב, שכל הרעות שציינת שם היו נפתרות אם היית בונה מסד נתונים בעצמך). אם היית מבצע את השאילתה ישירות היית חוסך את בניית המחרוזת והפריסה שלה ואת העברות הנתונים בין התוכנית שלך לפונקציות של sql. כמו כן, היית חוסך העברה של נתונים שאין לך צורך בהם. לסיכום, אני יכול לחשוב רק על 2 סיבות לשימוש ב-sql: 1. חוסר זמן או רצון. זה נכון גם ובעיקר עבור חברות שפועלות על בסיס רווח כספי, שם הזמן חשוב לפחות כמו האיכות. 2. עיקוף כלשהו של העברה מיותרת של נתונים. למשל, תוכנית אסמבלר שקולטת בקשות http ופולטת מה שצריך תהיה יעילה יותר משרת שקולט בקשות, מעביר אותן לתוכנית אחרת, מקבל את הפלט שלה ומעביר אותו הלאה. יכול להיות ששימוש ב-sql חוסך מהבחינה הזאת, לא בטוח. בכל מקרה, שאלתי מה ששאלתי מתוך סקרנות, כדי שאולי גם אני אשתכנע ואעבור להשתמש ב-sql. זה לא היה מתוך כוונה לשכנע אותך לבנות מחדש את האתר. |
חזרה לעמוד הראשי | המאמר המלא |
מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
RSS מאמרים | כתבו למערכת | אודות האתר | טרם התעדכנת | ארכיון | חיפוש | עזרה | תנאי שימוש | © כל הזכויות שמורות |