HBase
 sql >> Cơ Sở Dữ Liệu >  >> NoSQL >> HBase

Điểm chuẩn Apache HBase so với Apache Cassandra trên SSD trong môi trường đám mây

Bài đăng trên blog này đã được xuất bản trên Hortonworks.com trước khi hợp nhất với Cloudera. Một số liên kết, tài nguyên hoặc tham chiếu có thể không còn chính xác.

Tổng quan

Khi ngày càng có nhiều khối lượng công việc được đưa lên phần cứng hiện đại trên đám mây, điều quan trọng là chúng tôi phải hiểu cách chọn cơ sở dữ liệu tốt nhất có thể tận dụng phần cứng tốt nhất. Amazon đã giới thiệu các phiên bản có gắn trực tiếp SSD (Ổ cứng thể rắn). Cả Apache HBase và Apache Cassandra đều là cơ sở dữ liệu khóa-giá trị phổ biến. Trong điểm chuẩn này, chúng tôi hy vọng sẽ tìm hiểu thêm về cách họ tận dụng SSD được gắn trực tiếp trong môi trường đám mây.

Thiết kế điểm chuẩn

Điểm chuẩn được thiết kế để chạy Apache HBase và Apache Cassandra trong môi trường sản xuất tối ưu. Điều này có nghĩa là sử dụng máy được thiết kế riêng cho các hoạt động io cao với SSD được gắn trực tiếp. Chúng tôi đã đặt ghi nhật ký ghi trước / nhật ký cam kết cũng như lưu trữ dữ liệu trên SSD. Trước đây, nhiều điểm chuẩn đã xác nhận cả hai giải pháp đều có thể chia tỷ lệ tuyến tính, do đó kiểm tra tỷ lệ nằm ngoài phạm vi của điểm chuẩn này.

Kết quả

Phân tích

Trong suốt điểm chuẩn của chúng tôi, chúng tôi đã thấy HBase luôn vượt trội hơn Cassandra về khối lượng công việc đọc nhiều. Điều này phù hợp tốt với các trường hợp sử dụng chính của HBase như công cụ tìm kiếm, ứng dụng giao dịch tần suất cao, ứng dụng nhắn tin và phân tích dữ liệu nhật ký. HBase tỏa sáng ở các khối lượng công việc mà yêu cầu quét các bảng hai chiều, khổng lồ. Mặt khác, Cassandra đã làm việc tốt trong việc giải quyết khối lượng công việc nặng nề bằng tính nhất quán. Do đó, nó phù hợp hơn cho việc thu thập dữ liệu phân tích hoặc thu thập dữ liệu cảm biến khi có thể chấp nhận được tính nhất quán theo thời gian.

Một yếu tố khác cần xem xét khi chọn giải pháp là liệu có bộ công cụ tương ứng để phân tích dữ liệu hay không. Trong trường hợp của HBase, được xây dựng trên nền tảng Apache Hadoop, nó hỗ trợ Map Reduce và nhiều trình kết nối cho các giải pháp khác như Apache Hive và Apache Spark để cho phép các truy vấn tổng hợp lớn hơn và phân tích phức tạp.

Thiết lập thử nghiệm

Máy:

Cụm thi gồm 5 máy. Chi tiết máy:

AWS I3.xlarge

60GB GP2 để chạy hệ điều hành

Bộ nhớ NVMe được gắn trực tiếp, 0,95TB

4 vCPU, mỗi vCPU (CPU ảo) là một siêu luồng phần cứng trên bộ xử lý Intel E5-2686 v4 (Broadwell) chạy ở tốc độ 2,3 GHz.

RAM 30,5 GB

Để giảm thiểu sự cố hàng xóm ồn ào, chúng tôi đã chạy thử nghiệm trên các phiên bản AWS dành riêng.

Phần mềm điểm chuẩn:

Tập dữ liệu thử nghiệm:1TB được tạo qua YCSB

Bộ thử nghiệm:https://github.com/brianfrankcooper/YCSB

Tập lệnh thử nghiệm:https://github.com/2bethere/hbase-cassandra-bench

Phần mềm và môi trường:

HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8

Để sử dụng đầy đủ phần cứng, chúng tôi đã thay đổi Số lượng trình xử lý trên Máy chủ khu vực trong HBase thành 120. Tất cả các cài đặt khác được để làm mặc định. Toàn bộ danh sách cấu hình có sẵn ở cuối bài đăng này.

Trong quá trình triển khai, chúng tôi cũng đã làm theo hướng dẫn tối ưu hóa Cassandra được đăng tại đây:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html

Máy khách YCSB được đặt trên mỗi nút trong số 5 nút và chạy đồng thời để tạo tải. Trong quá trình tạo tập dữ liệu, chúng tôi đã giảm số luồng xuống 40.

Phương pháp thử nghiệm

Chúng tôi đang tải tập dữ liệu với 40 luồng cho mỗi khối lượng công việc do phân phối tập dữ liệu là khác nhau cho mỗi điểm chuẩn. Sau khi tải xong, chúng tôi đợi tất cả các hoạt động nén kết thúc trước khi bắt đầu kiểm tra khối lượng công việc. Mỗi khối lượng công việc được chạy 3 lần với 5.000.000 thao tác. Số trung bình được lấy từ 3 bài kiểm tra để đưa ra con số cuối cùng.

Giới thiệu về YCSB

YCSB, hoặc Yahoo! Cloud Serving Benchmark là một công cụ điểm chuẩn thường được sử dụng. Nó cung cấp kết quả so sánh giữa các giải pháp khác nhau. Chúng tôi đã chạy khối lượng công việc mặc định do YCSB cung cấp.

Khối lượng công việc A:Cập nhật nặng
Ví dụ ứng dụng:Lưu trữ phiên, ghi lại các hành động gần đây

Khối lượng công việc B:Đọc gần hết
Ví dụ ứng dụng:Gắn thẻ ảnh; thêm thẻ là một bản cập nhật, nhưng hầu hết các thao tác là để đọc thẻ

Khối lượng công việc C:Chỉ đọc
Ví dụ về ứng dụng:bộ nhớ cache của hồ sơ người dùng, nơi các hồ sơ được tạo ở nơi khác (ví dụ:Hadoop)

Khối lượng công việc D:Đọc khối lượng công việc mới nhất
Ví dụ ứng dụng:Cập nhật trạng thái người dùng; mọi người muốn đọc thông tin mới nhất

Khối lượng công việc E:Phạm vi ngắn
Ví dụ về ứng dụng:các cuộc hội thoại theo chuỗi, trong đó mỗi lần quét dành cho các bài đăng trong một chuỗi nhất định (giả sử được phân nhóm bằng id chuỗi)

Khối lượng công việc F:Khối lượng công việc đọc-sửa đổi-ghi
Ví dụ về ứng dụng:cơ sở dữ liệu người dùng, nơi các bản ghi người dùng được người dùng đọc và sửa đổi hoặc để ghi lại hoạt động của người dùng.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Cách thực hiện:Sử dụng Giao diện tiết kiệm HBase, Phần 2:Chèn / Bắt hàng

  2. Hạn chế của Hadoop, Cách giải quyết nhược điểm của Hadoop

  3. Bản phát hành CDH 6.2:Có gì mới trong HBase

  4. Cải thiện hiệu suất cơ sở dữ liệu hoạt động trong CDP Private Cloud Base 7 so với CDH5

  5. Cách thực hiện:Quản lý dữ liệu HBase qua Hue