01-10-2010, 10:53
|
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
|
|
חבר מתאריך: 25.10.01
הודעות: 42,775
|
|
אתה שוב חוזר על המושג "רגע נתון". מה זה רגע נתון. אני יודע למדוד מספר פניות מקסימלי ביחידת זמן (נגיד - שנייה). אין מושג מדעי שנקרא "רגע" ...
השאלה הגדולה שלך צריכה להיות לגבי הקומפלקסיות של המידע - כמה מסובך למשוך את המידע הזה. האם אתה צריך לבנות חיפושים מסובכים אשר מאגדים מידע מכל מיני טבלאות בכל שאילתא? אתה צריך להבין שזה הגורם העיקרי כדי לענות על השאלה "כמה כאלה מסד הנתונים שלי יכול לעשות בשנייה..."
ויש גם את עניין ה concurrency - נעילת טבלאות וכו'. כמה עדכונים אתה עושה, יחסית לכמה שליפות?
כמה חשוב לך שהעדכון שנעשה, יהיה מיידי?
האם איכפת לך שמידע ילך לאיבוד אם קרס לך השרת? אם כן, עד לאיזו דרגה?
וראה גם: http://memcached.org
ספציפית לשאלות שלך:
1. שוב, תלוי באופי השאילתות וביחס בין כמות העדכונים לכמות הקריאות שלהם. אתה צריך להבין ש"בעיקר קריאה" זה הרבה יותר פשוט מבחינת מסד הנתונים, כי אין לך בעיות של נעילות. ומבחינת סקאלאביליות, אתה פשוט יכול להוסיף עוד ועוד node-ים של MySQL שעושים replication אחד עם השני - כאשר שאתה שולף, אתה שולף מה"ילדים", ועדכונים אתה עושה רק למסד האב (שוב, רלוונטי רק אם אתה בעיקר קורא ולא כותב...) ?
2. אתה עדיין תצטרך לאחסן נתונים בצורה קבועה במסד אמין, לדעתי. אם אתה מעוניין רק ב cache, האם memcached לא יספיק לך (בייחוד בהתחשב באינטגרציה עם MySQL שזה מיועד לה...)
3. על זה הכי קשה לענות בהתבסס על חוסר ידע באופי צריכת המשאבים של השאילתא שלך, לפי ה business logic שלה... אתה צריך להבין שאין דין אפליקציה שמציגה עדכון סטטוס אחרון עבור משתמש, כדין אפליקציה שגוזרת נתונים סטטיסטיים מ 80 מקומות עבור המשתמש...
|