Alexey Kovyazin, 16-05-2014

Bạn có thể tải bài viết này dưới định dạng PDF.

Gần đây, tại IBSurgeon chúng tôi đã thực hiện một loạt bài kiểm tra hiệu suất với Firebird 2.5.2. Firebird 2.5.2 là phiên bản phổ biến nhất của cơ sở dữ liệu Firebird, và người dùng của nó thường có những câu hỏi liên quan đến hiệu suất của Firebird.

Một trong những mối quan tâm quan trọng nhất về hiệu suất cơ sở dữ liệu là sự suy giảm hiệu suất. Nhiều người dùng cho rằng ứng dụng cơ sở dữ liệu của họ gặp vấn đề về hiệu suất khi đạt đến một giá trị ngưỡng nào đó: có thể là 3Gb, 5Gb, kích thước RAM, 20Gb, v.v. Tuyên bố phổ biến nhất là “kích thước cơ sở dữ liệu lớn hơn kích thước RAM”: khi kích thước cơ sở dữ liệu Firebird đạt đến kích thước RAM, nó được báo cáo là trở nên rất chậm… Điều đó có đúng không?

Chúng tôi quyết định thực hiện một loạt bài kiểm tra để xem liệu có sự suy giảm hiệu suất liên quan đến sự tăng trưởng của cơ sở dữ liệu hay không. Chúng tôi quyết định mô phỏng sự tăng trưởng theo thời gian của cơ sở dữ liệu với cùng một tải trên cùng một phần cứng, và để làm điều này, chúng tôi đã chạy 11 bài kiểm tra với các cơ sở dữ liệu có kích thước từ 9Gb đến 30Gb:

Hình 1. Kích thước cơ sở dữ liệu cho các bài kiểm tra

Phần cứng kiểm tra và cấu hình Firebird

Phần cứng kiểm tra có các đặc điểm chính sau:

CPU AMD-FX8350, RAM 16GB, SATA software RAID1 2x4Tb ổ Seagate, Hệ điều hành Windows Server 2008R2 (2008R2 là 64 bit).

Như bạn có thể thấy, đây là cấu hình phần cứng cấp thấp; nó có thể được mua với giá dưới 1000 USD tại thời điểm đó (tháng 5 năm 2014), và nó có thể được coi là cấu hình cấp thấp điển hình - có lẽ, ngoại trừ các ổ SATA lớn, nhưng theo báo cáo của nhà sản xuất, tốc độ của ổ SATA 1Tb và 4Tb gần như giống nhau.

Vì mục tiêu của bài kiểm tra là đo lường sự thay đổi hiệu suất của hệ thống điển hình, chúng tôi đã sử dụng Firebird (64 bit) với kiến trúc SuperServer, không phải Classic, để mô phỏng hoàn toàn tình huống trong công ty nhỏ - họ sử dụng những gì đã được cài đặt ban đầu trong nhiều năm. Như bạn đã biết, SuperServer chỉ sử dụng 1 lõi CPU, vì vậy có lẽ Classic hoặc SuperClassic (có thể sử dụng tất cả các lõi CPU) có thể cho kết quả tốt hơn về hiệu suất, nhưng mục tiêu của chúng tôi không phải là tinh chỉnh hiệu suất.

Tuy nhiên, chúng tôi đã tinh chỉnh firebird.conf với những thay đổi rõ ràng mà chúng tôi khuyên dùng cho tất cả các cài đặt Firebird SuperServer: tăng page buffers lên 10000 và không gian tạm cho việc sắp xếp.

Tất cả các cơ sở dữ liệu kiểm tra được tạo với kích thước trang 16384, chỉ để nhất quán.

Kiểm tra

Tải dữ liệu

Mỗi bài kiểm tra bao gồm 2 bước: tải dữ liệu và mô phỏng 20 thiết bị đầu cuối thực hiện các thao tác chèn, cập nhật và xóa.

Bước tải dữ liệu được thực hiện bởi ứng dụng tải (load.exe), chèn dữ liệu vào nhiều bảng. Như bạn có thể thấy trong hình 2, dữ liệu được tải với tốc độ khác nhau; nó dao động từ ~35Mb/giây đến 1mb/giây.

Hình 2. Tốc độ tải cơ sở dữ liệu (đồ thị màu đỏ)

Điều này liên quan đến thiết kế của ứng dụng tải, không phải với Firebird: trình tải nhanh chóng chèn 70% cơ sở dữ liệu và sau đó từ từ điền phần còn lại của dữ liệu, và điều này được lặp lại với các cơ sở dữ liệu ở mọi kích thước. Điều quan trọng đối với chúng tôi là trình tải thực hiện các thao tác giống nhau, vì vậy chúng tôi có thể sử dụng tốc độ trung bình của nó để đo tốc độ tải.

Điều quan trọng cần nói là trình tải chỉ chèn dữ liệu, và các chỉ mục được tạo sau khi quá trình tải hoàn tất.

Hãy nhìn vào bảng kết quả cho bước tải dữ liệu của 11 cơ sở dữ liệu từ 9 đến 30Gb:

#	kích thước cơ sở dữ liệu, gb	thời gian tải, giây	tốc độ tải SATA, Mb/giây
1	9,04	2535	3,65166075
2	10,80	3197	3,45924304
3	13,00	4057	3,281242297
4	15,50	4698	3,378458919
5	17,30	5455	3,24751604
6	19,90	6037	3,375451383
7	21,60	6473	3,417024564
8	24,20	7539	3,287014193
9	26,00	7779	3,422547885
10	28,60	8851	3,308823862
11	30,30	9266	3,348499892

Hình 3. Thời gian và tốc độ tải

Hoặc, tốt hơn là hiển thị trên đồ thị ở hình 4:

Hình 4. Kết quả kiểm tra: tốc độ tải.

Như bạn có thể thấy, có một đồ thị khá ổn định, và tốc độ trung bình cho quá trình tải dao động khoảng 3.3-3.4Mb/giây. Cũng không có dấu hiệu giảm tốc độ tải khi kích thước cơ sở dữ liệu vượt quá kích thước RAM (sau cơ sở dữ liệu #5, với kích thước 17.3Gb).

Hiệu suất

Vậy, thời gian tải trông khá hứa hẹn, còn kết quả hiệu suất thực tế thì sao?

Trước khi đi đến kết quả hiệu suất, hãy nhanh chóng xem xét quá trình mô phỏng.

Mô phỏng chạy 20 luồng, và mỗi luồng chạy ngẫu nhiên một số thao tác kinh doanh: tạo đơn hàng mới, xử lý thanh toán, đếm sản phẩm trong kho, xử lý giao hàng, v.v. (để biết chi tiết, bạn có thể xem các văn bản SQL của các stored procedures thực tế). Như bạn có thể thấy, đây là tập hợp các thao tác kinh doanh thông thường của một ứng dụng kho hàng/bán hàng trừu tượng.

Ứng dụng kiểm tra đo số lượng thao tác kinh doanh mỗi giây và báo cáo số trung bình. Tất nhiên, con số này là một tham số nhân tạo, nhưng nó đủ tốt để so sánh.

Kết quả kiểm tra hiệu suất:

#	kích thước cơ sở dữ liệu, gb	hiệu suất trên SATA
1	9,04	494,73
2	10,80	491,94
3	13,00	480,36
4	15,50	469,11
5	17,30	446,42
6	19,90	431,61
7	21,60	426,85
8	24,20	424,5
9	26,00	414,04
10	28,60	409,14
11	30,30	407,97

Hình 5. Bảng kết quả kiểm tra hiệu suất.

Hoặc, tốt hơn là xem kết quả dưới dạng biểu đồ:

Hình 6. Đồ thị kết quả hiệu suất

Như bạn có thể thấy, có sự suy giảm hiệu suất chậm khi kích thước cơ sở dữ liệu tăng lên - cơ sở dữ liệu càng lớn, nó sẽ hoạt động càng chậm (trên cùng một phần cứng). Cũng không có sự sụt giảm lớn về hiệu suất khi kích thước cơ sở dữ liệu vượt quá RAM. Sự tăng trưởng của cơ sở dữ liệu từ 9Gb lên 30Gb dẫn đến mất khoảng 20% hiệu suất.

Các cơ sở dữ liệu Firebird 30Gb hiện đang phổ biến khắp nơi, và chúng ngày càng phát triển theo thời gian. Tuy nhiên, điều gì sẽ xảy ra với hiệu suất cơ sở dữ liệu khi nó còn lớn hơn nữa? Chúng tôi có nghĩa là - LỚN HƠN NỮA! Điều gì sẽ xảy ra với hiệu suất khi cơ sở dữ liệu trở nên THỰC SỰ LỚN?

Mr.Big

Để trả lời câu hỏi này, chúng tôi quyết định nhìn vào phần cuối cùng của bảng kiểm tra và thực hiện bài kiểm tra với cơ sở dữ liệu 1.7Tb (1813 Gb), trên cùng một phần cứng, với cùng cài đặt.

Tải dữ liệu

Vì vậy, chúng tôi đã tạo một cơ sở dữ liệu như vậy:

Hình 7. Kích thước cơ sở dữ liệu - bây giờ với cơ sở dữ liệu 1813 Gb

Quá trình tải mất 566448 giây - 157 giờ, 6.55 ngày. Đây là một khoảng thời gian dài, nhưng tốc độ tải trung bình là… 3.28Mb/giây!

#	kích thước cơ sở dữ liệu, gb	thời gian tải, giây	tốc độ tải SATA, Mb/giây
12	1813,969025	566448	3,279214122

Hình 8. Thời gian và tốc độ tải cho cơ sở dữ liệu Firebird 1.7Tb

Trên đồ thị, nó trông rất tốt: điểm cuối cùng (#12). Vì vậy, Firebird cho thấy kết quả rất tốt của các thuật toán chèn của nó.

Hình 9. Tốc độ tải - điểm #12 là cho cơ sở dữ liệu Firebird 1.7Tb

Hiệu suất của Mr.Big

Sau đó, chúng tôi đã chạy cùng một bài kiểm tra hiệu suất - dòng 12 là cho cơ sở dữ liệu 1.7Tb.

#	kích thước cơ sở dữ liệu, gb	hiệu suất trên SATA
1	9,04	494,73
2	10,80	491,94
3	13,00	480,36
4	15,50	469,11
5	17,30	446,42
6	19,90	431,61
7	21,60	426,85
8	24,20	424,5
9	26,00	414,04
10	28,60	409,14
11	30,30	407,97
12	1813,969025	169,33

Hình 10. Kết quả kiểm tra hiệu suất - dòng 12 là cho cơ sở dữ liệu 1.7Tb

Và trên đồ thị:


Hình 11. Hiệu suất, điểm #12 là cho cơ sở dữ liệu 1.7Tb

Kết quả xác nhận rằng có sự suy giảm hiệu suất chậm và ổn định trong Firebird - trong khi kích thước cơ sở dữ liệu đã tăng 60 lần (từ 30Gb lên 1813Gb), mất hiệu suất là 2.4 lần (từ 407 xuống 169 điểm).

Đây không phải là tình huống thường gặp khi cơ sở dữ liệu (trên cùng một phần cứng cấp thấp) tăng từ 30Gb lên 1.7Tb, nhưng Firebird sẽ hoạt động ngay cả trong tình huống này.

Cơ sở dữ liệu lớn chi tiết

Để hiểu rõ hơn về cơ sở dữ liệu 1.7Tb, chúng tôi đã thu thập số liệu thống kê cơ sở dữ liệu cho cơ sở dữ liệu Mr.Big và phân tích trong IBAnalyst:

Hình 12. Các bảng của cơ sở dữ liệu 1.7Tb trong IBAnalyst

Như bạn có thể thấy, có 2 bảng lớn - ORDER_LINE (~600 Gb) với 6.3 tỷ bản ghi và STOCK (~GB680) với 2.1 tỷ bản ghi.

Và, đối với các bảng này có 2 chỉ mục với độ sâu = 4 - điều đó có nghĩa là mỗi yêu cầu thực hiện 4 lần đọc các trang chỉ mục trước khi đọc dữ liệu thực tế. Chỉ mục ORDER_LINE_PK có kích thước 50Gb.

Hình 13. Chỉ mục của cơ sở dữ liệu Firebird 1.7Tb

Mặc dù số lượng bản ghi khổng lồ, số liệu thống kê cơ sở dữ liệu trông tốt, vì vậy không có gì ngạc nhiên khi Firebird cho thấy kết quả khá tốt ngay cả với cơ sở dữ liệu lớn trên phần cứng cấp thấp.

Kiểm tra Firebird với ổ SSD

Sau khi hoàn thành loạt bài kiểm tra Firebird trên phần cứng cấp thấp, chúng tôi quyết định kiểm tra kết quả sẽ như thế nào ở đầu kia của công nghệ lưu trữ dữ liệu và đã cài đặt ổ SSD trên cùng một máy chủ.

Chúng tôi đã cài đặt ổ SSD Plextor PX-256M M5 Pro và chạy cùng một loạt bài kiểm tra (ngoại trừ cơ sở dữ liệu 1.7Tb), với cùng cài đặt. Kết quả đã được thêm vào các đồ thị với thiết bị SATA, xem bên dưới.

Tải dữ liệu

Như bạn có thể thấy, thời gian tải trên SSD giống như trên SATA. Đây là kết quả mong đợi: tốc độ của các thao tác ghi tuần tự gần như giống nhau trên ổ SATA và SSD.

Hình 14. Tải trên SSD và SATA

Hiệu suất

Xem kết quả hiệu suất:

Hình 15. Hiệu suất trên SSD và SATA

Như bạn có thể thấy, hiệu suất với các thao tác I/O ngẫu nhiên cho thấy kết quả tốt hơn ~8 lần cho ổ SSD. Chúng tôi biết từ kinh nghiệm với cơ sở dữ liệu của khách hàng rằng SSD nhanh hơn 30-50% với các ứng dụng thực tế, nhưng mức tăng 8 lần là rất cao.

Tuy nhiên, bài kiểm tra này là nhân tạo và được thiết kế đặc biệt để mô phỏng các thao tác OLTP tải cao, với nhiều cập nhật/xóa, nhưng không có các truy xuất lớn. Ứng dụng cơ sở dữ liệu thông thường không hoạt động ở chế độ này mọi lúc. Điều này giải thích tại sao SSD cho thấy kết quả cao như vậy trong trường hợp cụ thể này.

Tóm tắt

Vậy, chúng ta đã học được gì từ những bài kiểm tra này?

Trước hết - hiệu suất của Firebird không có sự giảm lớn liên quan đến một số giới hạn kích thước. Trên cùng một phần cứng, hiệu suất sẽ giảm chậm khi kích thước cơ sở dữ liệu tăng lên. Sự giảm hiệu suất như vậy có thể được bù đắp bằng cách tinh chỉnh cấu hình Firebird hoặc nâng cấp phần cứng thông minh.

Đây là nơi thích hợp để đề cập rằng IBSurgeon cung cấp dịch vụ tối ưu hóa hiệu suất Firebird - sử dụng dữ liệu thực nghiệm chúng tôi thu thập từ các bài kiểm tra như thế này, chúng tôi có thể tăng đáng kể hiệu suất của cơ sở dữ liệu Firebird và InterBase.

Sau đó, chúng tôi biết rằng ngay cả các cơ sở dữ liệu Firebird rất lớn (1.7 terabyte) sẽ hoạt động trên phần cứng cấp thấp với sự mất hiệu suất đáng kể nhưng chấp nhận được.

Và thứ ba, SSD thực sự tốt cho các ứng dụng OLTP. Có lẽ đây là cách rẻ nhất để nâng cấp hiệu suất cơ sở dữ liệu tại thời điểm hiện tại. Tất nhiên, sử dụng SSD sẽ không khắc phục được các vấn đề về kế hoạch truy vấn kém và chỉ mục không hiệu quả, nhưng nó có thể nâng cao hiệu suất nói chung.

Còn tiếp: Thêm chi tiết về cơ sở dữ liệu Firebird 1.7 Terabyte.