การประมวลผลข้อมูลขนาดใหญ่ Hbase เทียบกับ Cassandra [ปิด]

ฉันเกือบจะถึงที่ Cassandra หลังจากค้นคว้าเกี่ยวกับโซลูชันการจัดเก็บข้อมูลขนาดใหญ่ แต่โดยทั่วไปกล่าวว่า Hbase เป็นทางออกที่ดีกว่าสำหรับการประมวลผลและวิเคราะห์ข้อมูลขนาดใหญ่

ในขณะที่ทั้งสองเป็นที่เก็บคีย์ / ค่าเดียวกันและทั้งคู่ / สามารถรันได้ (Cassandra เมื่อเร็ว ๆ นี้) เลเยอร์ Hadoop สิ่งที่ทำให้ Hadoop เป็นผู้สมัครที่ดีกว่าเมื่อต้องประมวลผล / วิเคราะห์ข้อมูลขนาดใหญ่

ฉันยังพบรายละเอียดที่ดีเกี่ยวกับทั้งสองอย่างที่ http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

แต่ฉันยังคงมองหาข้อดีที่เป็นรูปธรรมของ Hbase

ในขณะที่ฉันเชื่อมั่นมากขึ้นเกี่ยวกับ Cassandra เพราะความเรียบง่ายในการเพิ่มโหนดและการจำลองแบบที่ราบรื่นและไม่มีจุดบกพร่อง และยังคงคุณสมบัติดัชนีทุติยภูมิเพื่อให้เป็นบวกที่ดี

การพยายามพิจารณาว่าสิ่งใดดีที่สุดสำหรับคุณนั้นขึ้นอยู่กับว่าคุณจะใช้มันเพื่ออะไรพวกเขาแต่ละคนมีข้อดีและไม่มีรายละเอียดเพิ่มเติมมันจะกลายเป็นสงครามศาสนามากกว่า โพสต์ที่คุณอ้างถึงนั้นมีอายุมากกว่าหนึ่งปีและทั้งสองได้ผ่านการเปลี่ยนแปลงมากมายตั้งแต่นั้น โปรดทราบว่าฉันไม่คุ้นเคยกับการพัฒนาล่าสุดของ Cassandra

ต้องบอกว่าฉันจะถอดความ HBase committer Andrew Purtell และเพิ่มประสบการณ์ของตัวเอง:

• HBase อยู่ในสภาพแวดล้อมการผลิตที่ใหญ่กว่า (1,000 โหนด) แม้ว่าจะยังอยู่ใน ballpark ของการติดตั้ง ~ 400 โหนดของ Cassandra ดังนั้นจึงมีความแตกต่างเล็กน้อย

• HBase และ Cassandra รองรับการจำลองแบบระหว่างคลัสเตอร์ / ศูนย์ข้อมูล ฉันเชื่อว่า HBase เปิดเผยต่อผู้ใช้มากขึ้นดังนั้นจึงดูซับซ้อนมากขึ้น แต่คุณจะได้รับความยืดหยุ่นมากขึ้นด้วย

• หากความสม่ำเสมอที่ดีคือสิ่งที่แอปพลิเคชันของคุณต้องการ HBase ก็น่าจะเหมาะสมกว่า ได้รับการออกแบบจากพื้นดินขึ้นเพื่อให้สอดคล้องกัน ตัวอย่างเช่นช่วยให้สามารถใช้งานตัวนับอะตอมได้ง่ายขึ้น (ฉันคิดว่า Cassandra เพิ่งได้มา) รวมถึงการดำเนินการ Check and Put

• ประสิทธิภาพการเขียนดีมากจากสิ่งที่ฉันเข้าใจนั่นเป็นเหตุผลหนึ่งที่ Facebook ใช้ HBase สำหรับผู้ส่งสารของพวกเขา

• ฉันไม่แน่ใจเกี่ยวกับสถานะปัจจุบันของพาร์ติชันเนอร์ที่สั่งซื้อของ Cassandra แต่ในอดีตต้องมีการปรับสมดุลด้วยตนเอง HBase จัดการให้คุณถ้าคุณต้องการ พาร์ติชันที่สั่งมีความสำคัญสำหรับการประมวลผลสไตล์ Hadoop

• Cassandra และ HBase มีความซับซ้อนทั้งคู่ Cassandra ซ่อนไว้ได้ดีกว่า HBase แสดงให้เห็นมากขึ้นผ่านการใช้ HDFS สำหรับการจัดเก็บหากคุณดูที่ codebase Cassandra นั้นเป็นเลเยอร์ หากคุณเปรียบเทียบเอกสาร Dynamo และ Bigtable คุณจะเห็นว่าทฤษฎีการดำเนินงานของ Cassandra นั้นซับซ้อนกว่าจริงๆ

• HBase มีการทดสอบหน่วยเพิ่มเติม FWIW

• Cassandra RPC ทั้งหมดเป็น Thrift, HBase มี Thrift, REST และ Java ดั้งเดิม Thrift และ REST เสนอเฉพาะส่วนย่อยของไคลเอ็นต์ API ทั้งหมด แต่ถ้าคุณต้องการความเร็วที่แท้จริงไคลเอ็นต์ Java ดั้งเดิมจะอยู่ที่นั่น

• มีข้อดีทั้งแบบ peer to peer และ master to slave โดยทั่วไปแล้วการตั้งค่า Master - Slave จะทำให้การดีบักง่ายขึ้นและลดความซับซ้อนลงได้เล็กน้อย

• HBase ไม่ได้เชื่อมโยงกับ HDFS แบบเดิมเท่านั้นคุณสามารถเปลี่ยนพื้นที่เก็บข้อมูลพื้นฐานของคุณได้ MapRดูน่าสนใจมากและฉันได้ยินสิ่งดีๆแม้ว่าฉันจะไม่ได้ใช้มันด้วยตัวเอง

ในฐานะผู้พัฒนา Cassandra ฉันตอบคำถามอีกด้านได้ดีกว่า:

• คาสซานดราสเกลดีขึ้น คาสซานดราเป็นที่รู้จักกันขนาดไปกว่า 400 โหนดในคลัสเตอร์ ; เมื่อนำไปใช้งาน Facebook การส่งข้อความด้านบนของ HBase พวกเขาจะต้องแตกออกมามันข้าม100 โหนด HBase กลุ่มย่อย
• Cassandra สนับสนุน ColumnFamilies นับร้อยหรือหลายพันรายการ " HBase ไม่สามารถใช้ได้ดีกับสิ่งที่อยู่เหนือตระกูลคอลัมน์สองหรือสามคอลัมน์ "
• เนื่องจากระบบกระจายเต็มรูปแบบโดยไม่มีโหนดหรือกระบวนการ "พิเศษ" Cassandra จึงง่ายกว่าในการตั้งค่าและใช้งานแก้ไขปัญหาได้ง่ายขึ้นและมีประสิทธิภาพมากขึ้น
• การสนับสนุนของ Cassandra สำหรับการจำลองแบบหลายหลักหมายความว่าไม่เพียง แต่คุณจะได้รับพลังที่ชัดเจนของศูนย์ข้อมูลหลายแห่งเท่านั้น - ความซ้ำซ้อนทางภูมิศาสตร์, เวลาแฝงในพื้นที่ - แต่คุณยังสามารถแยกปริมาณงานแบบเรียลไทม์และการวิเคราะห์ออกเป็นกลุ่มแยกกันได้ด้วยการจำลองแบบสองทิศทางแบบเรียลไทม์ระหว่างกัน หากคุณไม่แยกภาระงานเหล่านั้นออกจากกัน
• เนื่องจากโหนด Cassandra แต่ละโหนดจัดการหน่วยเก็บข้อมูลในเครื่องของตนเอง Cassandra จึงมีข้อได้เปรียบด้านประสิทธิภาพที่สำคัญซึ่งไม่น่าจะถูก จำกัด ให้แคบลงอย่างมีนัยสำคัญ (เช่นเป็นแนวทางปฏิบัติมาตรฐานในการวาง Cassandra คอมมิตล็อกบนอุปกรณ์ที่แยกจากกันเพื่อให้สามารถเขียนตามลำดับได้โดยไม่ถูก จำกัด โดย i / o แบบสุ่มจากคำขออ่าน)
• Cassandra ช่วยให้คุณสามารถเลือกความแข็งแกร่งที่คุณต้องการต้องการความสม่ำเสมอในแต่ละการดำเนินการ บางครั้งสิ่งนี้ถูกเข้าใจผิดว่า "คาสซานดราไม่ได้ให้ความมั่นคงแข็งแรงแก่คุณ" แต่นั่นไม่ถูกต้อง
• Cassandra นำเสนอ RandomPartitioner และ OrderPartitioner ที่เหมือน Bigtable มากขึ้น RandomPartitioner มีแนวโน้มที่จะเกิดฮอตสปอตน้อยกว่ามาก
• Cassandra นำเสนอการแคชแบบเปิดหรือปิดด้วยประสิทธิภาพที่เทียบเท่ากับ memcached แต่ไม่มีปัญหาความสอดคล้องของแคชหรือความซับซ้อนในการต้องการชิ้นส่วนที่เคลื่อนไหวเพิ่มเติม
• ไคลเอนต์ที่ไม่ใช่ Java ไม่ใช่พลเมืองชั้นสอง

จากความรู้ของฉันตอนนี้ข้อได้เปรียบหลักของ HBase (HBase 0.90.4 และ Cassandra 0.8.4) คือ Cassandra ยังไม่รองรับการบีบอัดข้อมูลแบบโปร่งใส (สิ่งนี้ถูกเพิ่มเข้ามาสำหรับ Cassandra 1.0ซึ่งจะครบกำหนดในช่วงต้นเดือนตุลาคม แต่วันนี้เป็นข้อได้เปรียบที่แท้จริงสำหรับ HBase) HBase อาจได้รับการปรับให้เหมาะสมที่สุดสำหรับประเภทของการสแกนช่วงที่ทำโดยการประมวลผลแบทช์ Hadoop

นอกจากนี้ยังมีบางสิ่งที่ไม่จำเป็นต้องดีขึ้นหรือแย่ลงเพียง แต่ต่างกัน HBase ปฏิบัติตามแบบจำลองข้อมูล Bigtable อย่างเคร่งครัดมากขึ้นโดยที่แต่ละคอลัมน์จะถูกกำหนดเวอร์ชันโดยปริยาย Cassandra ยกเลิกการกำหนดเวอร์ชันและเพิ่ม SuperColumns แทน

หวังว่าจะช่วยได้!

สาเหตุที่ใช้คลัสเตอร์ hBase 100 โหนดไม่ใช่เพราะ HBase ไม่ปรับขนาดให้ใหญ่ขึ้น เป็นเพราะการอัปเกรดซอฟต์แวร์ hBase / HDFS เป็นเรื่องง่ายกว่าโดยไม่ต้องลดบริการทั้งหมดลง อีกเหตุผลหนึ่งคือการป้องกันไม่ให้ NameNode เดียวเป็น SPOF สำหรับบริการทั้งหมด นอกจากนี้ HBase ยังถูกใช้สำหรับบริการต่างๆ (ไม่ใช่แค่ข้อความ FB) และควรมีวิธีการตัดคุกกี้เพื่อตั้งค่าคลัสเตอร์ HBase จำนวนมากโดยใช้วิธีการพ็อด 100 โหนด หมายเลข 100 คือ adhoc เราไม่ได้เน้นว่า 100 เหมาะสมหรือไม่