“นี่เป็นสิ่งจำเป็น” เธอพูดเสียงดังโดยไม่พูดกับใครเลย - นี่เป็นสิ่งจำเป็น! นั่นคือสิ่งที่กล่าวไว้: ภารกิจหลักของบริษัทคือการทำกำไรเพื่อผลประโยชน์ของผู้ถือหุ้น คิดดูสิ! พวกเขาไม่กลัวสิ่งใดเลย!
Yuliy Dubov "ความชั่วร้ายน้อยกว่า"
เมื่อเห็นพาดหัวข่าวดังกล่าว คุณอาจตัดสินใจแล้วว่าบทความนี้เป็นบทความที่โง่เขลาหรือเป็นการยั่วยุ แต่อย่ารีบด่วนสรุป: พนักงานขององค์กรขนาดใหญ่ โดยเฉพาะองค์กรที่มีส่วนร่วมของรัฐ มักจะต้องเปรียบเทียบแพลตฟอร์มที่แตกต่างกัน รวมถึงแพลตฟอร์มที่แตกต่างกันโดยสิ้นเชิง - ตัวอย่างเช่น แพลตฟอร์มที่อยู่ในชื่อ
แน่นอนว่าไม่มีใครเปรียบเทียบ DBMS ในลักษณะนี้ เนื่องจากจุดแข็งและจุดอ่อนของพวกเขาเป็นที่รู้จักกันดี ตามกฎแล้ว แพลตฟอร์มที่แก้ไขปัญหาแอปพลิเคชันบางอย่างอาจมีการเปรียบเทียบ ในบทความฉันจะแสดงวิธีการที่ใช้ในกรณีนี้โดยใช้ตัวอย่างฐานข้อมูลเป็นหัวข้อที่ผู้อ่าน Habr คุ้นเคยโดยตรง ดังนั้น,
แรงจูงใจ
เมื่อคุณเริ่มโครงการด้านการศึกษาหรือโครงการงานอดิเรก แรงจูงใจในการเลือกแพลตฟอร์มอาจแตกต่างกันมาก: "นี่คือแพลตฟอร์มที่ฉันรู้จักดีที่สุด" "ฉันสนใจที่จะทำความเข้าใจสิ่งนี้" "นี่คือเอกสารที่ดีที่สุด" ... ในกรณีของบริษัทพาณิชยกรรม เกณฑ์การคัดเลือกจะเหมือนกัน คือ ต้องจ่ายเท่าไหร่ และจะได้อะไรจากเงินจำนวนนี้
แน่นอนว่าคุณต้องการจ่ายน้อยลงและได้รับมากขึ้น อย่างไรก็ตาม คุณต้องตัดสินใจว่าอะไรสำคัญกว่า - จ่ายน้อยลงหรือได้รับมากขึ้น และกำหนดน้ำหนักให้กับแต่ละโหนด สมมติว่าโซลูชันคุณภาพสูงมีความสำคัญสำหรับเรามากกว่าโซลูชันราคาถูก และเรากำหนดน้ำหนัก 40% ให้กับโหนด "ต้นทุน" และ 60% ให้กับโหนด "โอกาส"
ในองค์กรขนาดใหญ่ มักจะตรงกันข้าม - น้ำหนักต้นทุนไม่ต่ำกว่า 50% และอาจมากกว่า 60% ในตัวอย่างโมเดล สิ่งสำคัญคือน้ำหนักรวมของโหนดย่อยของโหนดพาเรนต์ต้องเป็น 100%
เงื่อนไขการตัด
เว็บไซต์ มีระบบจัดการฐานข้อมูลประมาณ 500 ระบบที่รู้จัก โดยปกติแล้ว หากคุณเลือกแพลตฟอร์มเป้าหมายจากตัวเลือกมากมาย คุณอาจได้รับบทความวิจารณ์ แต่ไม่ใช่โครงการเชิงพาณิชย์ เพื่อลดพื้นที่ตัวเลือก จึงมีการกำหนดเกณฑ์การตัดออก และหากแพลตฟอร์มไม่เป็นไปตามเกณฑ์เหล่านี้ ก็จะไม่ได้รับการพิจารณา
เกณฑ์การตัดออกอาจเกี่ยวข้องกับคุณลักษณะทางเทคโนโลยี เช่น:
- รับประกันกรด;
- แบบจำลองข้อมูลเชิงสัมพันธ์
- รองรับภาษา SQL (หมายเหตุ นี่ไม่เหมือนกับ "โมเดลเชิงสัมพันธ์");
- ความเป็นไปได้ของการปรับขนาดแนวนอน
อาจมีเกณฑ์ทั่วไป:
- ความพร้อมของการสนับสนุนเชิงพาณิชย์ในรัสเซีย
- โอเพ่นซอร์ส;
- ความพร้อมใช้งานของแพลตฟอร์มในทะเบียนกระทรวงโทรคมนาคมและสื่อสารมวลชน
- การปรากฏตัวของแพลตฟอร์มในระดับหนึ่ง (ตัวอย่างเช่นในร้อยแรกของการจัดอันดับ db-engines.com)
- การปรากฏตัวของผู้เชี่ยวชาญในตลาด (ตัวอย่างเช่น ขึ้นอยู่กับผลลัพธ์ของการค้นหาชื่อของแพลตฟอร์มในเรซูเม่บนเว็บไซต์ hh.ru)
ท้ายที่สุดแล้ว อาจมีเกณฑ์เฉพาะองค์กร:
- ความพร้อมของผู้เชี่ยวชาญในพนักงาน
- ความเข้ากันได้กับระบบตรวจสอบ X หรือระบบสำรอง Y ซึ่งรองรับทั้งหมด...
สิ่งที่สำคัญที่สุดคือมีรายการเกณฑ์การตัดออก มิฉะนั้นจะต้องมีผู้เชี่ยวชาญ (หรือ "ผู้เชี่ยวชาญ") ที่ได้รับความไว้วางใจเป็นพิเศษจากฝ่ายบริหารที่จะพูดว่า "ทำไมคุณไม่เลือกแพลตฟอร์ม Z ฉันรู้ว่ามันดีที่สุด"
ประมาณการต้นทุน
เห็นได้ชัดว่าต้นทุนของโซลูชันประกอบด้วยต้นทุนใบอนุญาต ต้นทุนการสนับสนุน และต้นทุนของอุปกรณ์
หากระบบมีคลาสเดียวกันโดยประมาณ (เช่น Microsoft SQL Server และ PostgreSQL) เพื่อความง่าย เราสามารถสรุปได้ว่าจำนวนอุปกรณ์สำหรับโซลูชันทั้งสองจะใกล้เคียงกัน สิ่งนี้จะช่วยให้คุณไม่ต้องประเมินอุปกรณ์ซึ่งช่วยประหยัดเวลาและความพยายามได้มาก หากคุณต้องเปรียบเทียบระบบที่แตกต่างกันโดยสิ้นเชิง (เช่น Oracle กับ Redis) เห็นได้ชัดว่าสำหรับการประเมินที่ถูกต้องจำเป็นต้องทำการปรับขนาด (การคำนวณจำนวนอุปกรณ์) การกำหนดขนาดระบบที่ไม่มีอยู่จริงนั้นเป็นงานที่ไร้ค่ามาก ดังนั้นพวกเขาจึงพยายามหลีกเลี่ยงการเปรียบเทียบดังกล่าว สิ่งนี้ทำได้ง่าย: ในสภาวะการตัดขาด จะมีการเขียนการสูญเสียข้อมูลเป็นศูนย์และแบบจำลองเชิงสัมพันธ์ หรือในทางกลับกัน - โหลดธุรกรรม 50 รายการต่อวินาที
ในการประเมินใบอนุญาต ก็เพียงพอที่จะสอบถามผู้จำหน่ายหรือคู่ค้าเกี่ยวกับต้นทุนใบอนุญาตสำหรับจำนวนคอร์คงที่และการสนับสนุนในช่วงเวลาที่กำหนด ตามกฎแล้ว บริษัทต่างๆ มีความสัมพันธ์ที่แน่นแฟ้นกับผู้จำหน่ายซอฟต์แวร์อยู่แล้ว และหากแผนกปฏิบัติการฐานข้อมูลไม่สามารถตอบคำถามด้านต้นทุนได้ด้วยตนเอง จดหมายฉบับเดียวก็เพียงพอที่จะรับข้อมูลนี้
ผู้จำหน่ายแต่ละรายอาจมีเกณฑ์ชี้วัดสิทธิ์การใช้งานที่แตกต่างกัน: ตามจำนวนคอร์ ปริมาณข้อมูล หรือจำนวนโหนด ฐานสแตนด์บายสามารถเป็นอิสระหรืออาจได้รับใบอนุญาตในลักษณะเดียวกับฐานหลัก หากค้นพบความแตกต่างในหน่วยวัด คุณจะต้องอธิบายรายละเอียดของโมเดลและคำนวณต้นทุนของใบอนุญาตสำหรับขาตั้ง
จุดสำคัญสำหรับการเปรียบเทียบที่ถูกต้องคือเงื่อนไขการสนับสนุนเดียวกัน ตัวอย่างเช่น การสนับสนุนของ Oracle มีค่าใช้จ่าย 22% ของราคาใบอนุญาตต่อปี แต่คุณไม่จำเป็นต้องจ่ายเงินสำหรับการสนับสนุน PostgreSQL เปรียบเทียบแบบนี้ถูกต้องไหมครับ? ไม่ เนื่องจากข้อผิดพลาดที่ไม่สามารถแก้ไขได้ด้วยตัวเองมีผลที่ตามมาที่แตกต่างไปจากเดิมอย่างสิ้นเชิง ในกรณีแรก ผู้เชี่ยวชาญด้านการสนับสนุนจะช่วยคุณแก้ไขอย่างรวดเร็ว แต่ในกรณีที่สอง มีความเสี่ยงที่จะทำให้โครงการล่าช้าหรือหยุดทำงานของงานที่เสร็จสิ้นแล้ว ระบบอย่างไม่มีกำหนด
คุณสามารถปรับเงื่อนไขการคำนวณให้เท่ากันได้สามวิธี:
- ใช้ Oracle โดยไม่มีการสนับสนุน (ในความเป็นจริงสิ่งนี้ไม่ได้เกิดขึ้น)
- ซื้อการสนับสนุนสำหรับ PostgreSQL - ตัวอย่างเช่น จาก Postgres Professional
- คำนึงถึงความเสี่ยงที่เกี่ยวข้องกับการขาดการสนับสนุน
ตัวอย่างเช่น การคำนวณความเสี่ยงอาจมีลักษณะดังนี้: ในกรณีที่ฐานข้อมูลล้มเหลวร้ายแรง ระบบจะหยุดทำงานเป็นเวลา 1 วันทำการ คาดการณ์กำไรจากการใช้ระบบ 40 หมื่นล้าน MNT ต่อปี อัตราอุบัติเหตุประมาณ 1/400 ดังนั้นความเสี่ยงขาดการสนับสนุนประมาณ 100 ล้าน MNT ต่อปี แน่นอนว่า "กำไรตามแผน" และ "ความถี่ของอุบัติเหตุโดยประมาณ" เป็นมูลค่าเสมือน แต่การมีโมเดลดังกล่าวยังดีกว่าไม่มีเลย
ในความเป็นจริง ระบบอาจมีความสำคัญเกินกว่าที่ต้นทุนด้านชื่อเสียงของการหยุดทำงานในระยะยาวจะยอมรับไม่ได้ ดังนั้นจึงต้องได้รับการสนับสนุน หากอนุญาตให้มีการหยุดทำงาน บางครั้งการปฏิเสธการสนับสนุนอาจเป็นวิธีที่ดีในการประหยัดเงิน
สมมติว่าหลังจากการคำนวณทั้งหมด ต้นทุนของแพลตฟอร์มปฏิบัติการ A เป็นเวลา 5 ปีกลายเป็น 800 ล้าน MNT ต้นทุนของแพลตฟอร์มปฏิบัติการ B คือ 650 ล้าน MNT และต้นทุนของแพลตฟอร์มปฏิบัติการ C คือ 600 ล้าน MNT แพลตฟอร์ม C ในฐานะผู้ชนะจะได้รับคะแนนเต็มสำหรับราคา ในขณะที่แพลตฟอร์ม A และ B จะได้รับคะแนนน้อยกว่าเล็กน้อยตามสัดส่วนของราคาที่แพงกว่า ในกรณีนี้ – 0.75 และ 0.92 จุด ตามลำดับ
การประเมินโอกาส
การประเมินโอกาสแบ่งออกเป็นหลายกลุ่ม ซึ่งจำนวนนั้นจำกัดด้วยจินตนาการของผู้ทำการประเมินเท่านั้น ดูเหมือนว่าตัวเลือกที่ดีที่สุดคือการแบ่งความสามารถออกเป็นทีมที่จะใช้ความสามารถเหล่านี้ ในตัวอย่างของเรา ได้แก่ นักพัฒนา ผู้ดูแลระบบ และเจ้าหน้าที่รักษาความปลอดภัยข้อมูล สมมติว่าน้ำหนักของฟังก์ชันเหล่านี้กระจายเป็น 40:40:20
ฟังก์ชันการพัฒนาประกอบด้วย:
- ความง่ายในการจัดการข้อมูล
- การปรับขนาด;
- การมีดัชนีรอง
รายการเกณฑ์ตลอดจนน้ำหนักนั้นเป็นเรื่องส่วนตัวมาก แม้ว่าจะแก้ไขปัญหาเดียวกัน รายการเหล่านี้ น้ำหนักรายการ และคำตอบจะแตกต่างกันอย่างมากขึ้นอยู่กับองค์ประกอบของทีมของคุณ ตัวอย่างเช่น Facebook ใช้ MySQL เพื่อจัดเก็บข้อมูล และ Instagram สร้างขึ้นบน Cassandra ไม่น่าเป็นไปได้ที่นักพัฒนาแอปพลิเคชันเหล่านี้จะกรอกตารางดังกล่าว ใครๆ ก็เดาได้เพียงว่า Mark Zuckerberg เลือกโมเดลเชิงสัมพันธ์เต็มรูปแบบ โดยจ่ายให้กับมันพร้อมกับความจำเป็นในการใช้การแบ่งส่วน ในขณะที่ Kevin Systrom สร้างการปรับขนาดโดยใช้แพลตฟอร์ม ซึ่งทำให้เข้าถึงข้อมูลได้ง่าย
ฟังก์ชั่นการบริหารรวมถึง:
- ความสามารถของระบบสำรองข้อมูล
- ความสะดวกในการตรวจสอบ
- ความง่ายในการจัดการความจุ – ดิสก์และโหนด
- ความสามารถในการจำลองข้อมูล
โปรดทราบว่าคำถามจะต้องใช้ถ้อยคำในลักษณะเชิงปริมาณ คุณสามารถตกลงเกี่ยวกับวิธีการประเมินฟังก์ชันเฉพาะได้ ตัวอย่างเช่น ลองให้คะแนนเครื่องมือสำรองข้อมูลโดยใช้ตัวอย่างของเครื่องมือที่มาพร้อมกับ Oracle DBMS:
เครื่องมือ
ความเห็น
การประเมินผล
การแสดงผล/ประสบการณ์
การอัพโหลดและการโหลดข้อมูล
0.1
เริ่มต้น/สิ้นสุดการสำรองข้อมูล
กำลังคัดลอกไฟล์
0.3
อาร์มัน
ความสามารถในการทำสำเนาที่เพิ่มขึ้น
0.7
ซดลรา
การคัดลอกแบบเพิ่มทีละขั้นเท่านั้น การฟื้นตัวที่รวดเร็วที่สุดถึงจุดที่กำหนด
1.0
หากไม่มีเกณฑ์การประเมินที่ชัดเจน ก็ควรขอให้ผู้เชี่ยวชาญหลายคนให้คะแนนแล้วจึงค่อยเฉลี่ย
สุดท้ายนี้ เราเพียงแค่แสดงรายการฟังก์ชันความปลอดภัยของข้อมูล:
- ความพร้อมใช้งานของนโยบายการจัดการรหัสผ่าน
- ความสามารถในการเชื่อมต่อเครื่องมือตรวจสอบสิทธิ์ภายนอก (LDAP, Kerberos)
- ต้นแบบการเข้าถึง
- ความสามารถในการตรวจสอบ
- การเข้ารหัสข้อมูลบนดิสก์
- การเข้ารหัสระหว่างการส่งผ่านเครือข่าย (TLS)
- การปกป้องข้อมูลจากผู้ดูแลระบบ
การทดสอบประสิทธิภาพ
ฉันอยากจะเตือนแยกต่างหากว่าอย่าใช้ผลลัพธ์ของการทดสอบโหลดใดๆ ที่คุณไม่ได้ทำไว้เป็นข้อโต้แย้ง
ประการแรก โครงสร้างข้อมูลและโปรไฟล์โหลดของแอปพลิเคชันที่กำลังทดสอบอาจแตกต่างกันอย่างมากจากปัญหาที่คุณกำลังแก้ไข ประมาณ 10-15 ปีที่แล้ว ผู้จำหน่ายฐานข้อมูลชอบที่จะอวดผลการทดสอบ TPC แต่ปัจจุบัน ดูเหมือนว่าไม่มีใครให้ความสำคัญกับผลลัพธ์เหล่านี้อย่างจริงจัง
ประการที่สอง ประสิทธิภาพของระบบขึ้นอยู่กับแพลตฟอร์มที่เขียนโค้ดในตอนแรกและอุปกรณ์ใดที่ทำการทดสอบ ฉันได้เห็นการทดสอบมากมายที่เปรียบเทียบ Oracle กับ PostgreSQL ผลลัพธ์มีตั้งแต่ความเหนือกว่าแบบไม่มีเงื่อนไขของระบบหนึ่งไปจนถึงความเหนือกว่าแบบไม่มีเงื่อนไขที่เท่าเทียมกันของระบบอื่น
และสุดท้าย ประการที่สาม คุณไม่รู้อะไรเลยว่าใครเป็นผู้ทำแบบทดสอบ คุณสมบัติทั้งสองมีความสำคัญ โดยมีอิทธิพลต่อคุณภาพของการตั้งค่าระบบปฏิบัติการและแพลตฟอร์ม ตลอดจนแรงจูงใจ ซึ่งมีอิทธิพลต่อผลการทดสอบมากกว่าปัจจัยอื่นๆ ทั้งหมดรวมกัน
หากประสิทธิภาพเป็นปัจจัยสำคัญ ให้ทำการทดสอบด้วยตัวเอง โดยควรได้รับความช่วยเหลือจากบุคลากรที่จะกำหนดค่าและบำรุงรักษาระบบการผลิต
ผล
สุดท้าย ผลลัพธ์ของงานทั้งหมดที่ทำควรเป็นสเปรดชีตที่รวมการประมาณการทั้งหมด คูณ และสรุป:
ดังที่คุณเข้าใจ โดยการเปลี่ยนมาตราส่วนและปรับการให้คะแนน คุณสามารถบรรลุผลลัพธ์ที่ต้องการได้ แต่นั่นเป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิง...
ที่มา: will.com