Oracle vs. MS SQL Server

רץ ברשת

New member
../images/Emo41.gif Oracle vs. MS SQL Server

התלבטות בין MS SQL Server 2005 לבין Oracle 10G (או אולי 11) מדובר במערכת ענק, מידע רב וקריטי, יכולות שרידות וזמינות גבוהות מאוד. השאלה הספציפית שאני מעוניין לשאול היא בנושא Clustering. לאורקל יש פתרון מובנה המהווה Cluster במובן המיידי של המילה : אוסף של שרתים לטובת בסיס הנתונים, החולקים בינהם את העבודה, וחושפים ממשק אחיד עבור מי שמשתמש בבסיס הנתונים, וכאשר מתקרבים לסף היכולת מבחינת ביצועים, אין בעיה פשוט להוסיף עוד שרתים למערכה. הפתרון של MS SQL Server 2005 הוא (למיטב הבנתי) : ביצוע Replication לבסיס הנתונים. כלומר, אם אני צריך להוריד עומס, אני מוסיף שרת נוסף, המתבצעת אליו רפליקציה (על בסיס זמן) של כל ה DB הקיים.
אשמח לקבל כל מידע נוסף בנושא
במיוחד אשמח לקבל חומר לגבי טיב הפתרון דל MS לנושא ה Clustering
 

Ice Age

New member
לא בדיוק

יש כמה פתרונות: 1. P2P replication שמאפשר לך לשים כמה שרתים ולסנכרן ביניהם. זה פתרון אפילו יותר רובסטי מזה של אורקל כי אין שום דבר משותף (באורקל ה-storage הוא נקודת כשל). תוכל לראות את המצגת שהעברתי בנושא כאן (לקראת הסוף). 2. פתרונות צד שלישי שמאפשרים רפליקציה וחלוקה על פני מספר בסיסי נתונים פיזיים. 3. עבודה עם Distributed partitinoed views - מנגנון קצת מיושן אבל עובד ועוזר לחלוקת עומסים. 4. Merge Replicatino שמאפשר עבודה במקביל על מספר שרתים והם מסתנכרנים ביניהם (דומה ל-P2P אבל יש דקויות). ואחרי שאמרתי את כל זה - אני לא בטוח שאתה באמת צריך ביזור של המערכת. על איזה נפחים/עומסים מדובר? כיום הרבה מהאכיטקטורות מתבססות על שרת יחיד (למעט עניין ה-DRP שבשבילו לא צריך עותק קריא).
 

רץ ברשת

New member
../images/Emo51.gif הבהרות :

1. מבחינת נושא ה Clustering - האם הסברתי אותו נכון ("אוסף של שרתים..."), או שטעיתי בהגדרה ? 2. לגבי ה P2P replication, האם אתה מדבר על הרפליקציות שאני הזכרתי, כפתרון של מיקרוסופט לנושא ה Clustering ? כלומר, כמה שרתים, שעל כל אחד מהם מותקן ה DB, וכל אחד הוא העתק של השני, בזמן אמת ? 3. תוכל להרחיב על נקודת הכשל של אורקל (המצגת נתקעת...
) לגבי Partitined Views ופתרונות צד שלישי - הן נדונו ונדחו (אין לי את כל הפרטים לצערי). מדובר במערכת ענק, למיליוני משתמשים בעולם, עם הרבה מאוד מידע (טרות על גבי טרות) ב DB, שחייב להיות בשרידות וזמינות גבוהה.
 

Ice Age

New member
תשובות

1. מבחינת נושא ה Clustering - האם הסברתי אותו נכון ("אוסף של שרתים..."), או שטעיתי בהגדרה ? --- באורקל זה נכון. ב-MS יש Clustering מסוג שונה, שמיועד ל-DRP ולא לחלוקת עומסים. גם שם זה עם שרתים שונים ו-storage משותף, אבל רק אחד פעיל בזמן נתון. 2. לגבי ה P2P replication, האם אתה מדבר על הרפליקציות שאני הזכרתי, כפתרון של מיקרוסופט לנושא ה Clustering ? כלומר, כמה שרתים, שעל כל אחד מהם מותקן ה DB, וכל אחד הוא העתק של השני, בזמן אמת ? --- כן, כל השרתים מסונכרנים וניתן לעבוד מול כל אחד מהם. תזכור שמדובר בפתרון א-סינכרוני ולכן ייתכן latency של בד"כ מספר שניות בין השרתים. 3. תוכל להרחיב על נקודת הכשל של אורקל (המצגת נתקעת... ) --- המצגת היא לא על החסרונות של אורקל...
אבל בכל מקרה באורקל יש לך דיסק יחיד (או יותר נכון - פתרון storage יחיד). אם הוא קורס אז זה לא יעזור שיש 10 שרתים ב-cluster. אם כי צריך לזכור שגם ל-storage יש redundancy טובה מאוד. לגבי Partitined Views ופתרונות צד שלישי - הן נדונו ונדחו (אין לי את כל הפרטים לצערי). מדובר במערכת ענק, למיליוני משתמשים בעולם, עם הרבה מאוד מידע (טרות על גבי טרות) ב DB, שחייב להיות בשרידות וזמינות גבוהה. --- נשמע מעניין. אני עובד עם מערכות של כמה טרות על שרת אחד וזה אפשרי. ניתן למצוא פתרונות נוספים לצרכי דוחות וכו', אבל זה דיון כבד מדי לפורום.
 

רץ ברשת

New member
המממ....

כאשר מדברים על P2P replication,האם החסרון העיקרי שלהם הוא ה latency של המידע, או עצם שכפול המידע, מהווה חסרון ? למרות שאם מסתכלים על פתרון Storage יחיד, אז הנ"ל הופך להיות יתרון של ה P2P replication, לא ? ואגב, אם החסרון של ה Clustering של אורקל זה ה Storage, אפשר גם את ה Storage להכיל בתוך מערך RAID כלשהו, ובכך לבטל את הבעיה, לא ?
 

Ice Age

New member
הממ הממ

כאשר מדברים על P2P replication,האם החסרון העיקרי שלהם הוא ה latency של המידע, או עצם שכפול המידע, מהווה חסרון ? --- זה לא בהכרח חסרון, עבודה בצורה סנכרונית גובה קורבנות בצורת השפעה על ביצועים בשרת המקור ולרוב המערכות דווקא עבודה א-סינכרונית עדיפה. זה גם פתרון מעט מורכב יותר מבחינה טכנולוגית לעומת windows clustering למשל. למרות שאם מסתכלים על פתרון Storage יחיד, אז הנ"ל הופך להיות יתרון של ה P2P replication, לא ? --- כן, בהחלט. ואגב, אם החסרון של ה Clustering של אורקל זה ה Storage, אפשר גם את ה Storage להכיל בתוך מערך RAID כלשהו, ובכך לבטל את הבעיה, לא ? --- לא רק שאפשר, אלא שאם אתה כבר עושה את זה אתה משתמש בפתרון storage חיצוני דוגמת NetApp,EMC וכו' שבוודאי שיש להם את ה-redundancy שלהם. אבל כל זה לא עוזר אם נופל טיל על חוות השרתים שלך. גם לזה יש להם פתרונות כמובן, אבל במקרה כזה פתרונות שמבזרים את המידע על שרתים שונים שלא בהכרח באותה חווה הם טובים.
 

רץ ברשת

New member
../images/Emo51.gif נסכם בהמלצה שלך :

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

Ice Age

New member
סיכום לא מחייב

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

רץ ברשת

New member
ע"פ תכנון הארכיטקטורה, ברור שיהיו שרתים

רבים, ולא שרת אחד. לכן כל נושא ה Clustering vs. Replications צץ...
 

רץ ברשת

New member
הכוונה הייתה...

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

Ice Age

New member
דעתי

הקצת משוחדת אבל משתדלת להיות אובייקטיבית (אף אחד לא אובייקטיבי לגמרי
): SQL Server.
 

רץ ברשת

New member
../images/Emo13.gif ../images/Emo51.gif רק הבהרה קטנה :

הטיעון המוביל כרגע שעומד מולי הוא שמכיוון שצריך יכולת גדילה ו Clustering, אז הפתרון הטבעי של אורקל הוא בדיוק הפתרון הדרוש (ניתן לזרוק עוד ועוד שרתים כדי לשפר ביצועים). והתשובה לנושא כשל ה Storage הוא שימוש במערך RAID רציני. מה אני יכול להשיב לטענות הנ"ל כדי להצדיק את MS SQL ?
 

Ice Age

New member
ב-SQL Server

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