שאלה לתותחי SQL ו-DATABASE

15 בנובמבר 2010

5 comments

שלום לכולם,

יש לי שאלה לכול מומחי ה-SQL ו-DATABASE והשאלה היא:

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

1. האם לעבוד ב-DB שונים לכול שירות? כלומר: DB למשתמשים, DB למוצרים, DB להזמנות וכו'… ככה אין כמעט JOIN אבל יש לחבר את התוצאות מהשירותים השונים במקרה שיש צורך ב-JOIN.

2. האם בכול זאת עדיף לעבוד עם DB אחד לבצע JOIN שיכולים להיות מורכבים ורק להפריד את הנתונים ל-DB שונים לפי לוגיקה מסויימת

3. האם יש גישה אחרת מומלצת

 

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

תודה רותם

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

5 comments

  1. dan amiga15 בנובמבר 2010 ב 20:52

    Come to my TechED presentation on Windows Azure.

    In essence, even if you don't use cloud services at all; for the type, amount and usage patterns of the data you described you should not use a relational database. Facebook had been fighting with MySQL for years and they wish they could move to another database but the performance they get along with the investment they made is not worth switching.

    Read this – focus on Cassandara (Facebook original data storage open source project)

    http://blogs.msdn.com/b/windowsazure/archive/2010/11/11/thought-leaders-in-the-cloud-talking-with-jonathan-ellis-co-founder-of-riptano.aspx

    if you ended up working with a relational database you should partition your data into different databases. BUT; it has nothing to do with Products/Customers and the regular types analogy. you should focus on sharding and partion of data based on frequent access R/W etc. for example – you can end up having DB_US_CUSTOMERS and DB_EUROPE_CUSTOMERS instead of a single CUSTOMS DB.

    Hope it's a good start.

    dan.amiga@develop.com

    Reply
  2. מאיר דודאי15 בנובמבר 2010 ב 22:52

    זה קצת קשה לענות על רגל אחת, אתה מוזמן לבוא להרצאה שלי בטקאד ושם אני אדבר על הנושא הזה.
    בגדול:
    1. שינויים ארכיטקטוניים שגורמים ל-DB לעשות כמה שפחות (כמו caching, שימוש ב-BULK לטעינות, streaminsight לסביבות מסויימות וכו').
    2. שימוש בפיצ'רים שמאפשרים ל-DB לעשות מה שהוא כבר צריך בצורה המהירה ביותר ושמאפשרת concurrency גבוה (שיפורים במנגנון הנעילות, RCSI ועוד).

    Reply
  3. Rotem Bloom16 בנובמבר 2010 ב 10:52

    היי דן,
    תודה על התגובה אני מכיר את ה-Cassandara שפייסבוק משתמשים בו אבל הוא עדיין לא אמור להחליף לי DB אלה להיות בין ה-DB לאפליקצייה כי הוא יותר מהיר.

    לגבי הפרדה של ה-DB לא הבנתי אם התכוונת להפריד את ה-DB אבל עדיין להשתמש ב-JOINS בין טבלאות. כלומר DB שיהיו בו לקוחות של US יהיו בו גם טבלאת ORDERS וגם PRODUCTS וככה אני מתנהג כאילו כול המידע על DB אחד לפי איזורים שונים.

    Reply
  4. Rotem Bloom16 בנובמבר 2010 ב 10:56

    מאיר,
    תודה על התגובה אבל לא ממש הבנתי ממך איך היית ממליץ לשמור את הנתונים. האם ללכת על DB אחד שיטפל במדינה מסויימת למשל ולהתמש ב-JOINS או ללכת על DB לפי שירות כמו שתיארתי בשאלה.

    תודה רותם

    Reply
  5. מאיר דודאי16 בנובמבר 2010 ב 12:02

    זה תלוי בכמה מתוך הגישות ל-DB אתה צריך נתונים מאוחדים וכמה לא.
    אם ברוב הפעמים אתה ניגש רק למוצרים למשל, או לתאריכים מסויימים וכדומה, אז עדיף לחלק.
    את החלוקה אתה יכול לבצע על ידי partitions (כל בסיסי הנתונים הנפוצים היום תומכים בזה) או על ידי חלוקה לוגית לכמה שרתים נפרדים כשל אחד שומר נתח של הנתונים. את זה אתה יכול לבצע אפליקטיבית או על ידי פיצ'רים שנתמכים בחלק מבסיסי הנתונים.

    Reply