ข้อดี ข้อเสีย และปัญหาคอขวดของประสิทธิภาพ HBase
สถาปัตยกรรม HBase นั้นมีอยู่เสมอ “จุดเดียวของความล้มเหลว” และไม่มีกลไกการจัดการข้อยกเว้นที่เกี่ยวข้องด้วย
ที่นี่ เราจะเรียนรู้ว่าข้อดีและข้อเสียของ HBase และปัญหาคอขวดด้านประสิทธิภาพคืออะไร:
คอขวดประสิทธิภาพใน HBase
- ในสภาพแวดล้อมการผลิตใดๆ HBase จะทำงานด้วยคลัสเตอร์ที่มีโหนดมากกว่า 5000 โหนด มีเพียง Hmaster เท่านั้นที่ทำหน้าที่เป็นมาสเตอร์สำหรับเซิร์ฟเวอร์ Region ของสเลฟทั้งหมด หาก Hmaster ล่ม จะสามารถกู้คืนได้หลังจากผ่านไประยะเวลาหนึ่งเท่านั้น แม้ว่าไคลเอนต์จะสามารถเชื่อมต่อกับเซิร์ฟเวอร์ Region ได้ก็ตาม การมีมาสเตอร์อีกตัวนั้นเป็นไปได้ แต่จะมีเพียงหนึ่งตัวเท่านั้นที่ใช้งานได้ จะใช้เวลานานในการเปิดใช้งาน Hmaster ตัวที่สองหาก Hmaster หลักล่ม ดังนั้น Hmaster จึงเป็นคอขวดด้านประสิทธิภาพ
- ใน HBase เราไม่สามารถใช้การดำเนินการข้ามข้อมูลและการดำเนินการเข้าร่วมใดๆ ได้ แน่นอนว่าเราสามารถใช้การดำเนินการเข้าร่วมโดยใช้ แผนที่ลดซึ่งจะใช้เวลาในการออกแบบและพัฒนาค่อนข้างมาก การดำเนินการรวมตารางนั้นทำได้ยากใน HBase ในบางกรณีการใช้งาน ไม่สามารถสร้างการดำเนินการรวมที่เกี่ยวข้องกับตารางที่มีอยู่ใน HBase ได้
- HBase จะต้องมีการออกแบบใหม่เมื่อเราต้องการย้ายข้อมูลจากแหล่งภายนอก RDBMS ไปยังเซิร์ฟเวอร์ HBase อย่างไรก็ตาม กระบวนการนี้ใช้เวลานาน
- HBase นั้นยากมากสำหรับการสืบค้น เราอาจจะต้องรวม HBase เข้ากับบางส่วน SQL ชั้นเหมือน อาปาเช่ phoenix ซึ่งเราสามารถเขียนคำสั่งเพื่อทริกเกอร์ข้อมูลใน HBase เป็นเรื่องดีจริงๆ ที่มี Apache Phoenix อยู่บน HBase
- ข้อเสียเปรียบอีกประการหนึ่งของ HBase ก็คือ เราไม่สามารถมีดัชนีมากกว่าหนึ่งรายการในตารางได้ มีเพียงคอลัมน์คีย์แถวเท่านั้นที่ทำหน้าที่เป็นคีย์หลัก ดังนั้น ประสิทธิภาพจะช้าลงเมื่อเราต้องการค้นหามากกว่าหนึ่งฟิลด์หรือนอกเหนือจากคีย์แถว ปัญหานี้เราสามารถแก้ไขได้ด้วยการเขียนโค้ด MapReduce ร่วมกับ อาปาเช่ SOLR และกับอาปาเช่ฟีนิกซ์
- การปรับปรุงการรักษาความปลอดภัยที่ช้าสำหรับผู้ใช้ที่แตกต่างกันในการเข้าถึงข้อมูลจาก HBase
- HBase ไม่รองรับคีย์บางส่วนอย่างสมบูรณ์
- HBase อนุญาตให้มีการเรียงลำดับเริ่มต้นเพียงรายการเดียวต่อตาราง
- การเก็บไฟล์ไบนารี่ขนาดใหญ่ใน HBase เป็นเรื่องยากมาก
- พื้นที่เก็บข้อมูลของ HBase จะจำกัดการสืบค้นและการเรียงลำดับแบบเรียลไทม์
- การค้นหาคีย์และการค้นหาช่วงในแง่ของการค้นหาเนื้อหาตารางโดยใช้ค่าคีย์ จะจำกัดการค้นหาที่ทำงานแบบเรียลไทม์
- การจัดทำดัชนีเริ่มต้นไม่มีอยู่ใน HBase โปรแกรมเมอร์ต้องกำหนดโค้ดหรือสคริปต์หลายบรรทัดเพื่อดำเนินการฟังก์ชันการทำดัชนีใน HBase
- มีราคาแพงในแง่ของข้อกำหนดด้านฮาร์ดแวร์และการจัดสรรบล็อกหน่วยความจำ
- ควรติดตั้งเซิร์ฟเวอร์เพิ่มเติมสำหรับสภาพแวดล้อมคลัสเตอร์แบบกระจาย (เช่น เซิร์ฟเวอร์แต่ละตัวสำหรับ NameNode, DataNodes ZooKeeperและเซิร์ฟเวอร์ภูมิภาค)
- ด้านประสิทธิภาพการทำงานต้องใช้เครื่องที่มีหน่วยความจำสูง
- ในด้านต้นทุนและการบำรุงรักษาก็สูงกว่าเช่นกัน
ข้อดีของ HBase
ที่นี่ เราจะเรียนรู้ว่าข้อดี/ประโยชน์ของ HBase คืออะไร:
- สามารถจัดเก็บชุดข้อมูลขนาดใหญ่ไว้บนพื้นที่จัดเก็บไฟล์ HDFS และจะรวบรวมและวิเคราะห์แถวนับพันล้านแถวที่อยู่ในตาราง HBase
- ใน HBase สามารถแชร์ฐานข้อมูลได้
- Operaเช่นการอ่านและการประมวลผลข้อมูลจะใช้เวลาเพียงเล็กน้อยเมื่อเทียบกับโมเดลเชิงสัมพันธ์แบบดั้งเดิม
- การดำเนินการอ่านและเขียนแบบสุ่ม
- HBase ถูกใช้กันอย่างแพร่หลายสำหรับการดำเนินการวิเคราะห์แบบออนไลน์
- ตัวอย่างเช่น: ในแอปพลิเคชันของธนาคาร เช่น การอัพเดตข้อมูลแบบเรียลไทม์ในเครื่อง ATM สามารถใช้ HBase ได้
ข้อเสียของ HBase
นี่คือข้อเสีย/ข้อจำกัดที่สำคัญของ HBase:
- เราไม่สามารถคาดหวังได้อย่างสมบูรณ์ว่าจะใช้ HBase แทนรุ่นดั้งเดิมได้อย่างสมบูรณ์ คุณสมบัติรุ่นดั้งเดิมบางรุ่นไม่รองรับโดย HBase
- HBase ไม่สามารถทำหน้าที่เช่น SQL ได้ ไม่รองรับโครงสร้าง SQL ดังนั้นจึงไม่มีเครื่องมือเพิ่มประสิทธิภาพคิวรีใดๆ
- HBase เป็นระบบที่ใช้ CPU และหน่วยความจำจำนวนมาก โดยมีการเข้าถึงอินพุตหรือเอาต์พุตแบบต่อเนื่องจำนวนมาก ในขณะที่งาน Map Reduce นั้นส่วนใหญ่จะผูกกับอินพุตหรือเอาต์พุตด้วยหน่วยความจำคงที่ HBase ที่ผสานกับงาน Map-reduce จะส่งผลให้เกิดความล่าช้าที่ไม่สามารถคาดเดาได้
- HBase บูรณาการกับหมูและ รัง งานส่งผลให้บางครั้งเกิดปัญหาหน่วยความจำในคลัสเตอร์
- ในสภาพแวดล้อมคลัสเตอร์แบบใช้ร่วมกัน การตั้งค่าต้องใช้สล็อตงานน้อยลงต่อโหนดในการจัดสรรตามความต้องการ CPU ของ HBase