🥇מה עדיף - אורקל או רדיס או איך להצדיק את בחירת הפלטפורמה

"זה הכרחי," היא אמרה בקול, לא פונה לאף אחד. - זה הכרחי! זה בדיוק מה שכתוב: המשימה העיקרית של חברה היא להרוויח לטובת בעלי המניות. ובכן, תחשוב על זה! הם לא מפחדים מכלום!
יולי דובוב, "רע פחות"

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

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

מוטיבציה

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

באופן טבעי, אתה רוצה לשלם פחות ולקבל יותר. עם זאת, עליך להחליט מה חשוב יותר - לשלם פחות או לקבל יותר, ולהקצות משקל לכל צומת. בוא נניח שפתרון איכותי חשוב לנו יותר מאשר זול, ואנו מייחסים לצומת "עלות" משקל של 40% ו-60% לצומת "הזדמנויות".

בתאגידים גדולים בדרך כלל ההפך הוא הנכון - משקל העלות לא יורד מתחת ל-50%, ואולי יותר מ-60%. בדוגמה של המודל, כל מה שחשוב הוא שהמשקל הכולל של צמתי הצאצא של כל צומת אב חייב להיות 100%.

תנאי ניתוק

אֲתַר db-engines.com ידועות כ-500 מערכות לניהול מסדי נתונים. מטבע הדברים, אם תבחרו בפלטפורמת יעד מתוך כל כך הרבה אפשרויות, אתם עלולים לקבל מאמר סקירה, אבל לא פרויקט מסחרי. על מנת לצמצם את מרחב הבחירה, מגובשים קריטריונים לחתוך, ובמידה והפלטפורמה אינה עומדת בקריטריונים אלו, אז היא אינה נחשבת.

קריטריונים לחתוך עשויים להתייחס לתכונות טכנולוגיות, למשל:

ערבויות ACID;
מודל נתונים יחסי;
תמיכה בשפת SQL (שים לב, זה לא זהה ל"מודל יחסי");
אפשרות של קנה מידה אופקי.

יתכנו קריטריונים כלליים:

זמינות תמיכה מסחרית ברוסיה;
קוד פתוח;
זמינות הפלטפורמה בפנקס משרד הטלקום ותקשורת ההמונים;
נוכחות של הפלטפורמה בדירוג מסוים (לדוגמה, במאה הראשונה של דירוג db-engines.com);
נוכחות של מומחים בשוק (לדוגמה, על סמך תוצאות החיפוש אחר שם הפלטפורמה בקורות חיים באתר hh.ru).

אחרי הכל, עשויים להיות קריטריונים ספציפיים לארגון:

זמינות של מומחים בצוות;
תאימות למערכת ניטור X או מערכת גיבוי Y, עליה מבוססת כל התמיכה...

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

הערכת מחיר

עלות הפתרון מורכבת כמובן מעלות הרישיונות, עלות התמיכה ועלות הציוד.

אם המערכות הן בערך אותה מחלקה (לדוגמה, Microsoft SQL Server ו-PostgreSQL), אז למען הפשטות נוכל להניח שכמות הציוד לשני הפתרונות תהיה זהה בערך. זה יאפשר לך לא להעריך את הציוד, ובכך לחסוך הרבה זמן ומאמץ. אם צריך להשוות בין מערכות שונות לגמרי (נניח, אורקל מול Redis), אז ברור שלצורך הערכה נכונה יש צורך לבצע sizing (חישוב כמות הציוד). הגדרת גודל של מערכת לא קיימת היא משימה חסרת תודה, אז הם עדיין מנסים להימנע מהשוואות כאלה. זה קל לעשות: בתנאי החתך נכתבים אפס אובדן נתונים ומודל יחסי, או להיפך - עומס של 50 אלף עסקאות בשנייה.

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

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

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

ניתן להשוות את תנאי החישוב בשלוש דרכים:

השתמש ב-Oracle ללא תמיכה (במציאות זה לא קורה).
קנה תמיכה עבור PostgreSQL - למשל, מ-Postgres Professional.
קח בחשבון את הסיכונים הכרוכים בחוסר תמיכה.

לדוגמה, חישוב סיכון עשוי להיראות כך: במקרה של כשל קטלני במסד הנתונים, זמן ההשבתה של המערכת יהיה יום עסקים אחד. הרווח החזוי משימוש במערכת הוא 1 מיליארד MNT בשנה, שיעור התאונות מוערך ב-40/1, ולכן הסיכון לחוסר תמיכה מוערך בכ-400 מיליון MNT בשנה. ברור ש"רווח מתוכנן" ו"תדירות תאונות משוערת" הם ערכים וירטואליים, אבל הרבה יותר טוב שיהיה מודל כזה מאשר לא.

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

נניח שאחרי כל החישובים, עלות תפעול פלטפורמה א' ל-5 שנים מסתבר כ-800 מיליון MNT, עלות תפעול פלטפורמה B היא 650 מיליון MNT, ועלות תפעול פלטפורמה C היא 600 מיליון MNT. פלטפורמה C, כמנצחת, זוכה לנקודה מלאה עבור המחיר, בעוד שפלטפורמות A ו-B מקבלות קצת פחות, ביחס לכמה שהן יקרות יותר. במקרה זה – 0.75 ו-0.92 נקודות, בהתאמה.

הערכת הזדמנות

הערכת ההזדמנויות מחולקת לקבוצות רבות, שמספרן מוגבל רק בדמיונו של עורך ההערכה. נראה שהאופציה האופטימלית היא לחלק את היכולות לצוותים שישתמשו ביכולות הללו; בדוגמה שלנו, אלה מפתחים, מנהלים וקציני אבטחת מידע. הבה נניח שהמשקלים של פונקציות אלה מחולקים כ-40:40:20.

פונקציות הפיתוח כוללות:

קלות מניפולציה של נתונים;
דֵרוּג;
נוכחות של אינדקסים משניים.

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

פונקציות הניהול כוללות:

יכולות מערכת גיבוי;
קלות ניטור;
קלות ניהול קיבולת - דיסקים וצמתים;
יכולות שכפול נתונים.

שימו לב כי שאלות חייבות להיות מנוסחות בצורה כמותית. אתה יכול אפילו להסכים כיצד להעריך פונקציה מסוימת. בואו, למשל, ננסה לדרג כלי גיבוי באמצעות הדוגמה של הכלים שסופקו עם ה-Oracle DBMS:

כלי
הערה
הערכה

imp/exp
העלאה וטעינת נתונים
0.1

התחל/סיים גיבוי
העתקת קבצים
0.3

RMAN
יכולת העתקה מצטברת
0.7

ZDLRA
רק העתקה מצטברת, השחזור המהיר ביותר לנקודה
1.0

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

לבסוף, אנו פשוט מפרטים את פונקציות אבטחת המידע:

זמינות מדיניות ניהול סיסמאות;
היכולת לחבר כלי אימות חיצוניים (LDAP, Kerberos);
מודל לחיקוי של גישה;
יכולות ביקורת;
הצפנה של נתונים בדיסק;
הצפנה במהלך שידור ברשת (TLS);
הגנת מידע מהמנהל.

בדיקת ביצועים

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

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

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

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

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

תוצאה

לבסוף, התוצאה של כל העבודה שנעשתה צריכה להיות גיליון אלקטרוני שבו כל האומדנים משולבים, מוכפלים ומסכמים:

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

מקור: www.habr.com