ข้อดี ข้อเสีย และปัญหาคอขวดของประสิทธิภาพ 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

ที่นี่ เราจะเรียนรู้ว่าข้อดี/ประโยชน์ของ 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