Kiểm tra hiệu suất HBase bằng YCSB

Khi chạy bất kỳ công cụ đo điểm chuẩn hiệu suất nào trên cụm của bạn, quyết định quan trọng luôn là kích thước tập dữ liệu nên được sử dụng để kiểm tra hiệu suất và ở đây chúng tôi giải thích lý do tại sao điều quan trọng là phải chọn kích thước tập dữ liệu “phù hợp tốt” khi chạy hiệu suất HBase kiểm tra trên cụm của bạn.

Cấu hình cụm HBase và kích thước của tập dữ liệu có thể thay đổi hiệu suất khối lượng công việc của bạn và kết quả kiểm tra trên cùng một cụm. Bạn nên chọn kích thước tập dữ liệu này dựa trên những gì bạn đang cố gắng hiểu về hiệu suất của cụm của mình. Để chỉ ra sự khác biệt giữa tập hợp hoạt động phù hợp với bộ nhớ đệm có sẵn và tập hợp phải được đọc từ bộ nhớ bên dưới, chúng tôi đã chạy 2 bài kiểm tra khối lượng công việc YCSB với kích thước tập dữ liệu được chọn phù hợp trên cùng một cụm Cơ sở dữ liệu hoạt động CDP Private Cloud Base 7.2.2. Chúng tôi đã sử dụng kích thước tập dữ liệu là 40GB so với 1TB và thông lượng cho các khối lượng công việc YCSB khác nhau được so sánh bên dưới, trong biểu đồ thanh càng cao thì thông lượng càng tốt.

Lưu ý:Thông lượng =Hoạt động mỗi giây

Khi một ứng dụng cố gắng thực hiện đọc từ một cụm HBase, Máy chủ Vùng xử lý yêu cầu trước tiên sẽ kiểm tra xem kết quả cần thiết có nằm trong khối dữ liệu đã cục bộ với quy trình của nó thông qua bộ đệm ẩn khối của nó hay không. Nếu khối dữ liệu hiện diện thì yêu cầu máy khách có thể được phục vụ trực tiếp từ bộ nhớ cache và điều này được tính là một lần truy cập bộ nhớ cache. Tuy nhiên, nếu khối hiện không cục bộ đối với quy trình Máy chủ Vùng thì đó được tính là lỗi bộ nhớ cache và nó phải được đọc từ HFile trong bộ nhớ HDFS. Tùy thuộc vào việc sử dụng bộ đệm mà khối đó sau đó sẽ được lưu trong bộ đệm cho các yêu cầu trong tương lai.

Như mong đợi và đã thấy trong biểu đồ tóm tắt, khối lượng công việc trong đó phần lớn tập dữ liệu nằm trong bộ nhớ cache có độ trễ thấp hơn và thông lượng cao hơn nhiều so với đợt chạy khối lượng công việc trong đó dữ liệu đang được truy cập từ HFiles trong bộ nhớ hdfs.

Để chọn kích thước tập dữ liệu khối lượng công việc của chúng tôi nhằm đáp ứng tốt các mục tiêu thử nghiệm của chúng tôi, điều quan trọng là phải kiểm tra kích thước của đống Vùng máy chủ, bộ nhớ đệm L1 và L2, bộ nhớ đệm hệ điều hành và sau đó đặt kích thước tập dữ liệu thích hợp. Sau khi chạy khối lượng công việc YCSB đã hoàn thành, một thông số tốt để kiểm tra như một cách xác minh rằng mọi thứ chạy như mong đợi là lượng dữ liệu đã được phục vụ từ bộ nhớ đệm (lần truy cập bộ nhớ cache) và lượng dữ liệu được truy cập từ bộ nhớ hdfs. Tỷ lệ số lần truy cập bộ nhớ cache của Máy chủ Vùng trên tổng số yêu cầu đọc là tỷ lệ số lần truy cập bộ nhớ đệm.

Bạn có thể tìm thấy thông tin này từ cấu hình “l1CacheHitRatio” trong cấu hình tỷ lệ truy cập bộ nhớ đệm L1. Nếu bạn có cả bộ đệm L1 và L2 trong cụm của mình thì bộ đệm L1 phục vụ các khối chỉ mục và bộ đệm L2 phục vụ các khối dữ liệu và bạn có thể ghi lại cả hai cấu hình L1 “l1CacheHitRatio” và L2 “l2CacheHitRatio” để tham khảo.

Phần còn lại của bài đăng blog này sẽ hướng dẫn chi tiết về thiết lập thử nghiệm của chúng tôi, chọn kích thước tập dữ liệu và sau đó chạy YCSB với các kích thước tập dữ liệu đó.

Cấu hình cụm HBase được sử dụng cho thử nghiệm này:

• Cụm được sử dụng: Cụm 6 nút (1 máy chủ chính + 5 máy chủ khu vực)
• Mô tả: Dell PowerEdge R430, 20c / 40t Xenon e5-2630 v4 @ 2.2Ghz, Ram 128GB, đĩa 4-2TB
• Bảo mật: Không có cấu hình nào (Không có Kerberos)
• Phiên bản CDP: CDP Private Cloud Base 7.2.2 Cụm HBase 6 nút với 1 Máy chủ Chính + 5 Máy chủ Vùng
• JDK đã sử dụng jdk1.8_232
• Máy chủ Vùng HBase đã được định cấu hình với 32GB heap
• HBase master đã được định cấu hình với 4GB heap
• Bộ nhớ đệm L1 với LruBlockCache được sử dụng với kích thước bộ nhớ đệm 12,3 GB
• Tổng bộ nhớ đệm L1 trong cụm là 61 GB (12,3 * 5 =61 GB)
• L2 off heap cache không được định cấu hình trên cụm

Trường hợp định kích thước 1:Dữ liệu hoàn toàn phù hợp với bộ nhớ cache có sẵn trên cụm

Trong cụm HBase của chúng tôi, chúng tôi đã định cấu hình tổng cộng 61GB (12,3GB * 5) trên 5 máy chủ khu vực được phân bổ cho bộ nhớ đệm khối L1. Để có tập dữ liệu hoàn toàn phù hợp với bộ nhớ cache, chúng tôi đã chọn tập dữ liệu là 40GB về kích thước.

Trường hợp kích thước 2:Tập dữ liệu lớn hơn bộ nhớ cache có sẵn trên cụm

Đối với trường hợp thứ hai, chúng tôi muốn dữ liệu lớn hơn nhiều so với bộ nhớ cache có sẵn. Để chọn kích thước tập dữ liệu thích hợp, chúng tôi đã xem xét cả bộ đệm ẩn khối HBase được định cấu hình và bộ đệm đệm hệ điều hành trong cụm. Trong cụm HBase đã cho của chúng tôi, bộ nhớ đệm khối L1 đã định cấu hình là 61G khi được tổng hợp trên các Máy chủ Vùng. Các nút máy chủ có tổng cộng 128G RAM mỗi nút và bất kỳ bộ nhớ nào không dành riêng cho quy trình máy chủ đều có thể được HĐH sử dụng để lưu vào bộ đệm hiệu quả các khối HDFS bên dưới và tăng thông lượng tổng thể. Trong cấu hình thử nghiệm của chúng tôi, có khoảng 96G bộ nhớ cache OS có sẵn trên mỗi nút máy chủ khu vực cho mục đích này (bỏ qua bộ nhớ được sử dụng bởi DataNode hoặc các quy trình OS để đơn giản hóa mọi thứ). Tổng hợp điều này trên 5 máy chủ khu vực, chúng tôi có tiềm năng gần 500G cho bộ đệm (máy chủ 96G * 5 khu vực). Do đó, chúng tôi đã chọn kích thước tập dữ liệu là 1TB, vượt quá cả bộ đệm ẩn khối đã định cấu hình và bộ đệm đệm hệ điều hành có sẵn.

Chuyển Kích thước Dữ liệu Mục tiêu thành các tham số YCSB

Trong YCSB, một hàng là 1KB theo mặc định, vì vậy tùy thuộc vào số lượng hàng bạn tải vào YCSB ‘có thể sử dụng’, bạn có thể dễ dàng ước tính kích thước dữ liệu bảng YCSB ‘có thể sử dụng’ của mình. Vì vậy, nếu bạn tải lên 1 triệu hàng, bạn đã tải 1.000.000 * 1KB =1GB dữ liệu lên YCSB ‘có thể sử dụng được’.

Kích thước tập dữ liệu được sử dụng cho hai thử nghiệm của chúng tôi là:

• Dữ liệu 40 GB với 40 triệu hàng
• 1 TB dữ liệu với 1 tỷ hàng

Phương pháp Kiểm tra

CDP Private Cloud Base 7.2.2 đã được cài đặt trên cụm 6 nút và dữ liệu khối lượng công việc với 40 triệu hàng (tổng kích thước tập dữ liệu => 40 GB) đã được tạo và khối lượng công việc YCSB đã được chạy. Sau khi tải, chúng tôi đợi tất cả các hoạt động nén hoàn tất trước khi bắt đầu kiểm tra khối lượng công việc.

Khối lượng công việc YCSB được chạy trên HBase là

1. Khối lượng công việc A:50% Đọc và 50% Cập nhật
2. Khối lượng công việc C:Đọc 100%
3. Khối lượng công việc F:50% Đọc và 50% Tỷ lệ cập nhật / Đọc-Sửa-Ghi:50/50
4. Khối lượng công việc Chỉ cập nhật tùy chỉnh:Cập nhật 100%
   

Mỗi khối lượng công việc YCSB (A, C, F và UpdateOnly) được chạy trong 15 phút mỗi lần và quá trình chạy hoàn chỉnh được lặp lại 5 lần mà không cần khởi động lại giữa các lần chạy để đo thông lượng YCSB *. Kết quả được hiển thị là giá trị trung bình được thực hiện cho 3 lần chạy cuối cùng từ 5 lần chạy. 2 lần chạy thử đầu tiên được bỏ qua để tránh bị phạt lần chạy thứ nhất và thứ hai.

Sau khi hoàn tất 40GB chạy, chúng tôi đã loại bỏ 1 tỷ hàng có thể sử dụng và tạo lại để tạo kích thước tập dữ liệu 1TB và chạy lại các thử nghiệm với cùng một phương pháp trên cùng một cụm.

Kết quả Kiểm tra

Kết quả YCSB với 40GB

Trong trường hợp 40GB, dữ liệu hoàn toàn có thể nằm gọn trong bộ đệm 61GB L1 trên cụm. Tỷ lệ truy cập bộ nhớ cache L1 quan sát được trong cụm trong quá trình thử nghiệm là gần 99%.

Mẹo: Đối với các tập dữ liệu nhỏ hơn, nơi dữ liệu có thể vừa với bộ đệm, chúng tôi cũng có thể sử dụng tùy chọn bộ đệm khi tải và làm ấm trước bộ đệm để có được tỷ lệ truy cập bộ nhớ cache 100% bằng cách sử dụng tùy chọn bảng PREFETCH_BLOCKS_ON_OPEN

Chúng tôi đã chạy mỗi khối lượng công việc YCSB trong 15 phút mỗi 5 lần và lấy giá trị trung bình từ 3 lần chạy cuối cùng để tránh bị phạt ở lần chạy đầu tiên.

Kết quả được nhìn thấy với tỷ lệ truy cập bộ nhớ đệm L1 40G là 99% trên các máy chủ khu vực được hiển thị bên dưới trong bảng:

Kết quả YCSB với tập dữ liệu 1TB

Trong trường hợp 1TB, dữ liệu không vừa với bộ đệm 61 GB L1 trên cụm hoặc bộ đệm 500 GB bộ đệm hệ điều hành. Tỷ lệ truy cập bộ nhớ cache L1 trong cụm được quan sát trong quá trình thử nghiệm là 82-84%.

Chúng tôi chạy mỗi khối lượng công việc trong 15 phút mỗi 5 lần và lấy trung bình từ 3 lần chạy cuối cùng để tránh bị phạt ở lần chạy đầu tiên.

Kết quả được nhìn thấy với 1TB Tỷ lệ truy cập bộ nhớ đệm L1 82-84% trên các máy chủ khu vực được hiển thị bên dưới trong bảng:

* Thông lượng (ops / giây) =Số hoạt động mỗi giây

Phân tích:

So sánh kết quả kiểm tra cho hai kích thước tập dữ liệu khác nhau ở trên, chúng ta có thể thấy thông lượng khối lượng công việc giống nhau có thể thay đổi như thế nào từ 3K thao tác mỗi giây đến 165K thao tác mỗi giây khi dữ liệu được truy cập nhanh hơn từ tập dữ liệu 40G với bộ nhớ đệm được làm ấm so với từ bộ nhớ hdfs.

Biểu đồ bên dưới cho thấy thông lượng và so sánh thông lượng đã thay đổi như thế nào đối với các khối lượng công việc khác nhau khi chạy với 2 tập dữ liệu kích thước khác nhau. Trong biểu đồ, thanh càng cao thì thông lượng càng tốt.

Lưu ý:Thông lượng =Hoạt động mỗi giây

Như đã thấy trong biểu đồ, khối lượng công việc YCSB đọc dữ liệu như Khối lượng công việc A, Khối lượng công việc C và Khối lượng công việc F có thông lượng tốt hơn nhiều trong trường hợp 40G trong đó dữ liệu dễ dàng vừa với bộ nhớ cache so với trường hợp kích thước dữ liệu 1TB trong đó dữ liệu HFile phải được truy cập từ HDFS

Xem xét tỷ lệ truy cập bộ nhớ cache, tập dữ liệu 40G có tỷ lệ truy cập bộ nhớ cache gần 99% và tập dữ liệu 1TB có tỷ lệ truy cập bộ nhớ cache khoảng 85%, vì vậy 15% dữ liệu trong hộp 1TB được truy cập từ bộ nhớ hdfs .

Khối lượng công việc chỉ cập nhật tùy chỉnh YCSB mà chúng tôi chạy có cùng thông lượng trong cả hai trường hợp vì nó chỉ cập nhật và không đọc.

Trong quá trình hoạt động của HBase, chúng tôi xem xét kỹ độ trễ phân vị thứ 95 và 99. Độ trễ trung bình chỉ là tổng lưu lượng chia cho tổng thời gian. Tuy nhiên, phân vị thứ 95 và phân vị thứ 99 cho thấy các giá trị ngoại lệ thực sự ảnh hưởng đến tổng lưu lượng công việc. Trong trường hợp 1TB, các giá trị ngoại lệ độ trễ cao ở phân vị thứ 95 và 99 khiến thông lượng chậm lại và trong trường hợp 40GB, bộ nhớ đệm có độ trễ thấp chạm vào phân vị thứ 99 dẫn đến tổng thông lượng tăng lên.

Biểu đồ bên dưới hiển thị so sánh độ trễ cho độ trễ trung bình, độ trễ phần trăm thứ 95 và độ trễ phần trăm thứ 99 và độ trễ này khác nhau như thế nào đối với các khối lượng công việc khác nhau khi chạy với các tập dữ liệu kích thước khác nhau.

Trong biểu đồ trên, khó có thể thấy các thanh biểu thị độ trễ cho tập dữ liệu 40GB vì chúng cực kỳ thấp so với độ trễ quan sát được đối với tập dữ liệu 1TB khi truy cập dữ liệu từ hdfs.

Chúng tôi vẽ biểu đồ độ trễ bằng cách sử dụng nhật ký của các giá trị độ trễ để hiển thị sự khác biệt trong biểu đồ bên dưới

Như đã thấy ở trên, độ trễ thấp hơn nhiều trong trường hợp 40GB, nơi tỷ lệ truy cập bộ nhớ cache là gần 99% và hầu hết dữ liệu khối lượng công việc đều có sẵn trong bộ nhớ cache. So với tập dữ liệu 1TB, tỷ lệ truy cập bộ nhớ cache là khoảng 85% vì dữ liệu HFile phải được truy cập từ bộ nhớ HDFS.

Độ trễ trung bình và 99 độ trễ cho Workload C trong trường hợp 40G trong đó 99% dữ liệu được trả về từ bộ đệm được làm ấm là khoảng 2 - 4 ms. Độ trễ phần trăm thứ 99 cho cùng một khối lượng công việc C trong trường hợp 1TB là khoảng 100 mili giây cho khối lượng công việc C (chỉ đọc khối lượng công việc).

Điều này cho thấy rằng một lần truy cập vào bộ nhớ cache từ bộ nhớ cache khối trên heap trả về một lần đọc trong khoảng 2 mili giây và một lần bỏ lỡ bộ nhớ cache và nhận bản ghi từ HDFS có thể mất khoảng 100 mili giây trên cụm này.

Đề xuất:

Khi chạy thử nghiệm đo điểm chuẩn YCSB, kích thước tập dữ liệu tạo ra sự khác biệt đáng kể trong kết quả hiệu suất và do đó định cỡ thử nghiệm một cách thích hợp là rất quan trọng. Đồng thời, việc xem xét tỷ lệ truy cập bộ nhớ cache và sự khác biệt về độ trễ giữa độ trễ tối thiểu và độ trễ thứ 99 sẽ giúp bạn tìm thấy độ trễ của lần truy cập bộ nhớ cache so với khi dữ liệu được truy cập từ bộ nhớ cơ bản trong cụm.

Mẹo:

Để kiểm tra tỷ lệ truy cập bộ nhớ cache của khối lượng công việc của bạn trên máy chủ khu vực, bạn có thể sử dụng lệnh dưới đây

curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio

Bạn cũng có thể xem tỷ lệ truy cập bộ nhớ cache từ giao diện người dùng web HBase theo các bước sau:

1. Từ giao diện người dùng Web HBase, hãy nhấp vào máy chủ khu vực
2. Trong phần Chặn bộ đệm, chọn L1 (và L2 nếu L2 được định cấu hình) để xem lại tỷ lệ truy cập bộ nhớ cache.

Ảnh chụp màn hình hiển thị tỷ lệ truy cập bộ nhớ cache từ bộ nhớ cache khối L1 được hiển thị bên dưới:

Đây là liên kết để biết thêm thông tin về ảnh chụp màn hình HBase được hiển thị ở trên và chặn bộ nhớ cache https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

Giới thiệu về YCSB

YCSB là một bộ chương trình và đặc tả mã nguồn mở để đánh giá khả năng truy xuất và bảo trì của các chương trình máy tính. Nó là một công cụ rất phổ biến được sử dụng để so sánh hiệu suất tương đối của các hệ quản trị cơ sở dữ liệu NoSQL.

Để sử dụng YCSB để kiểm tra hiệu suất của Cơ sở dữ liệu hoạt động, hãy xem blog Cách chạy YCSB cho HBase