Tại sao tạo cơ sở dữ liệu Firebird terabyte?

Nhiều công ty làm việc với các cơ sở dữ liệu Firebird lớn và dựa vào chúng để hỗ trợ các hoạt động kinh doanh quan trọng. Một số cơ sở dữ liệu Firebird đã có kích thước hàng trăm gigabyte và tiếp tục tăng (xem phần “Ai lớn?”), và thật dễ dàng để dự đoán thời điểm chúng trở nên lớn gấp 2, 3 hoặc 5 lần. Vì vậy, các quản trị viên cơ sở dữ liệu và nhà cung cấp quan tâm đến việc điều tra hành vi của Firebird với các cơ sở dữ liệu lớn và nhận được một số khuyến nghị về cách quản lý chúng.

Cũng là lý do quan trọng mà chúng tôi đã cân nhắc khi tạo cơ sở dữ liệu Firebird 1Tb là loại bỏ hoàn toàn nhận thức phổ biến về Firebird như một công cụ cơ sở dữ liệu cho “các cơ sở dữ liệu nhỏ”. Huyền thoại này dường như đã chết, nhưng một số nhà phân tích và nhà báo thường xuyên khơi dậy nó từ nấm mồ, và chúng tôi hy vọng sẽ chấm dứt với nhận thức vô lý này cuối cùng.


## Phần cứng

Firebird nổi tiếng với khả năng mở rộng đáng kinh ngạc và cuộc điều tra này đã xác nhận điều đó một lần nữa. Mục đích ban đầu của thí nghiệm này chỉ là tạo cơ sở dữ liệu Firebird có kích thước 1Tb, vì vậy chúng tôi đã sử dụng máy tính để bàn thông thường:

Bảng 1: Phần cứng


Thành phần	Thông số
CPU	AMDAthlon 64 x2 5200
RAM	4GB
Bo mạch chủ	MSI K9N Platinum
HDD1 (hệ điều hành và tạm thời)	ST3160815AS, 160GB, SATA II
HDD2 (phụ trợ)	HDT721064SLA360, 640GB,SATAII
HDD2 (phụ trợ)	HDS728080PLA380, 80GB, SATA I
HDD3 (cơ sở dữ liệu)	ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

Về bản chất, chúng tôi đã đặt ổ cứng 1.5Tb vào một trong các máy tính để bàn văn phòng của mình, mà không có bất kỳ sửa đổi nào khác. Ổ cứng này được định dạng với kích thước cụm 16Kb (giống như kích thước trang của cơ sở dữ liệu, như bạn có thể thấy bên dưới).

Phần mềm

Vì đây là máy tính để bàn, hệ điều hành là Windows XP Professional SP3, 32bit. Để thực hiện bài kiểm tra, chúng tôi đã sử dụng trình tải từ bộ công cụ dựa trên TPC (tải xuống từ http://ibdeveloper.com/tests/tpc-c/, cả tệp nhị phân và mã nguồn đều có sẵn).

Chúng tôi muốn nhấn mạnh rằng trình tải chèn dữ liệu như thể nó được chèn trong kịch bản thực tế: các bản ghi đang được chèn và nằm bên trong cơ sở dữ liệu (và tại các khu vực đĩa vật lý) vào nhiều bảng master-detail-subdetail, không phải từng bảng một.

Bảng 2: Phần mềm


Phần mềm	Phiên bản
Hệ điều hành	Windows XP Professional SP3, 32bit
Firebird	2.1.3 SuperServer (snapshot)
Trình tải	Trình tải tùy chỉnh từ bài kiểm tra dựa trên tpc

Kế hoạch

Chúng tôi đã có một kế hoạch rất đơn giản cho thí nghiệm này:

Tạo cơ sở dữ liệu và tải nó với 1Tb dữ liệu, không có chỉ mục
Tạo khóa chính và các chỉ mục thích hợp (vì vậy kích thước cơ sở dữ liệu thực tế là hơn 1Tb)
Thu thập thống kê cơ sở dữ liệu
Chạy một số truy vấn SQL và đánh giá hiệu suất cơ sở dữ liệu

Cấu hình cơ sở dữ liệu và máy chủ Firebird

Cơ sở dữ liệu có kích thước trang 16384 byte, giống như cụm HDD, để tối đa hóa hiệu suất thông lượng đĩa (đọc/ghi 1 trang trong một chu kỳ I/O).

Trong cấu hình Firebird, chúng tôi đã cấu hình thư mục bổ sung cho không gian tạm thời và trỏ nó đến đĩa 640Gb (nơi có ~300Gb trống).

Bước tải

Dữ liệu được tải vào cơ sở dữ liệu này qua nhiều bước. Máy tính được sử dụng trong các hoạt động tải như một máy tính để bàn thông thường (chúng tôi có MS Office, Firefox, IBAnalyst, v.v. - khoảng 8-12 chương trình chạy cùng lúc). Nếu chúng tôi dành riêng phần cứng cho nhiệm vụ này, có lẽ nó sẽ nhanh hơn, vì vậy xin hãy coi những giá trị này chỉ là ví dụ cấp thấp; chúng chắc chắn không phải là kết quả hàng đầu.

Bảng 3: Các hoạt động tải

| |


Mô tả	Giá trị
Thời gian tải	~70 giờ
Tổng số bản ghi được chèn	6.2 tỷ
Tốc độ chèn trung bình	24500 bản ghi/giây
Kích thước bản ghi trung bình	146 byte (tối thiểu 13 byte, tối đa - 600 byte)
Giao dịch	646489

Chúng tôi đã dành ~4 ngày để tải, và sau đó chúng tôi có cơ sở dữ liệu Firebird với kích thước chính xác 1Tb (tức là 1 099 900 125 184 byte).

Dưới đây bạn có thể thấy sự tăng trưởng cơ sở dữ liệu và động lực giao dịch trong Trình xem FBDataGuard:

Chỉ mục

Chúng tôi đã tạo các chỉ mục từng cái một và đếm thời gian tạo của chúng và kích thước phù hợp của tệp tạm thời được sử dụng để sắp xếp.

Chỉ mục lớn nhất được tạo cho bảng ORDER_LINE. Khóa chính của nó chứa bốn trường (Smallint, Smallint, Integer và Smallint). Tệp tạm thời cho chỉ mục sắp xếp này là 182Gb, và kích thước chỉ mục cuối cùng trong cơ sở dữ liệu là 29.3Gb.

Thật thú vị khi thấy rằng ngay cả chỉ mục cho bảng có 3.8 tỷ bản ghi có độ sâu = 3, vì kích thước trang là 16384 byte, vì vậy không có chi phí khi tìm kiếm dữ liệu bằng khóa chính cho bảng này.

Thống kê

Sau đó, chúng tôi đã thu thập thống kê cơ sở dữ liệu. Mất 7 giờ 32 phút 45 giây.

Chúng tôi đã đưa thông tin thống kê chính vào một bảng và bao gồm một số truy vấn và phép đo thời gian:

Bảng 4: Thống kê tổng hợp cho cơ sở dữ liệu 1Tb


Tên bảng	Số bản ghi	Kích thước, gb	*Thời gian thực thi của select count()**	Thời gian tạo chỉ mục	Kích thước tệp tạm, Gb	Kích thước chỉ mục, Gb
WAREHOUSE	1240	0.002	0s	0	0	0.0
ITEM	100000	0.012	0.7s	-	-	0.0
DISTRICT	124000	0.017	0.7s	6	-	0.0
NEW_ORDER	111600000	32	20m 00s	23m 00s	4.56	0.8
CUSTOMER	372000000	224	-	41m 00s	-	2.6
customer_last				1h 52m 32s	12.4	2.3
fk_cust_ware				2h 10m 51s	-	2.3
HISTORY	372000000	32	-	-	-	-
ORDERS	372000000	25	32m 00s	45m 41s	15.2	2.5
STOCK	1240000000	404	-	3h 34m 44s	41.5	9.2
ORDER_LINE	3720051796	359	-	12h 6m 18s	182.0	29.3

Thống kê cơ sở dữ liệu có thể được tải xuống từ đây.

Bạn có thể sử dụng Trình xem FBDataGuard Community Edition miễn phí để diễn giải dữ liệu văn bản và không chỉ thấy các chỉ số hiệu suất cơ sở dữ liệu, mà còn cả mức tiêu thụ CPU và bộ nhớ.

Truy vấn

Trước hết, chúng tôi đã chạy các truy vấn select count(*) trên một số bảng (xem cột thứ 4 trong Bảng 4 ở trên). Như bạn đã biết, do bản chất đa phiên bản của Firebird, select count(*) cho toàn bộ bảng là một hoạt động tốn kém cho máy chủ vì nó yêu cầu truy cập mọi trang, và các nhà phát triển Firebird có kinh nghiệm không sử dụng select count(*), nhưng chúng tôi đã sử dụng nó để chứng minh tỷ lệ hiệu suất tổng thể của cơ sở dữ liệu và phần cứng.

Sau các truy vấn select count, chúng tôi đã chạy các truy vấn từ kịch bản thực tế và, thành thật mà nói, chúng tôi đã kinh ngạc với kết quả tốt như vậy. Hãy tự mình xem:


Truy vấn	Thống kê	Mô tả
select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id	PLAN JOIN (WAREHOUSE NATURAL, CUSTOMER INDEX (FK_CUST_WARE)) ------ Thông tin hiệu suất —— Thời gian chuẩn bị = 15ms Thời gian thực thi = 79ms Thời gian tìm nạp trung bình = 6.08 ms Bộ nhớ hiện tại = 272 264 476 Bộ nhớ tối đa = 272 514 048 Bộ đệm bộ nhớ = 16 384 Đọc từ đĩa vào bộ đệm = 82 Ghi từ bộ đệm ra đĩa = 0 Tìm nạp từ bộ đệm = 3 648	Kết nối đơn giản của các bảng với 12400 và 372000000 bản ghi, không có điều kiện WHERE. “Thời gian tìm nạp trung bình = 6.08 ms” là để tìm nạp hàng đầu tiên.
select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Thông tin hiệu suất —— Thời gian chuẩn bị = 16ms Thời gian thực thi = 78ms Thời gian tìm nạp trung bình = 6.00 ms Bộ nhớ hiện tại = 272 266 148 Bộ nhớ tối đa = 272 514 048 Bộ đệm bộ nhớ = 16 384 Đọc từ đĩa vào bộ đệm = 88 Ghi từ bộ đệm ra đĩa = 0 Tìm nạp từ bộ đệm = 3 656	Kết nối của cùng các bảng với điều kiện buộc chọn các bản ghi gần đây. “Thời gian tìm nạp trung bình = 6.00 ms” là để tìm nạp hàng đầu tiên.
select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Kết quả = 30000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Thông tin hiệu suất —— Thời gian chuẩn bị = 0ms Thời gian thực thi = 453ms Thời gian tìm nạp trung bình = 453.00 ms Bộ nhớ hiện tại = 272 263 844 Bộ nhớ tối đa = 272 514 048 Bộ đệm bộ nhớ = 16 384 Đọc từ đĩa vào bộ đệm = 1 048 Ghi từ bộ đệm ra đĩa = 0 Tìm nạp từ bộ đệm = 60 024	Đếm bản ghi cho truy vấn trước

SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	Kế hoạch PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Thông tin hiệu suất —— Thời gian chuẩn bị = 0ms Thời gian thực thi = 94ms Thời gian tìm nạp trung bình = 7.23 ms Bộ nhớ hiện tại = 136 445 536 Bộ nhớ tối đa = 136 592 176 Bộ đệm bộ nhớ = 8 192 Đọc từ đĩa vào bộ đệm = 150 Ghi từ bộ đệm ra đĩa = 0 Tìm nạp từ bộ đệm = 2 402	Truy vấn đến bảng lớn nhất (3.8B bản ghi). “Thời gian tìm nạp trung bình = 7.23 ms” là để tìm nạp hàng đầu tiên.

	`<br>Kế hoạch<br>` `<br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br>` `<br> <br>` `<br>------ Thông tin hiệu suất ------<br>` `<br>Thời gian chuẩn bị = 0ms<br>` `<br>Thời gian thực thi = 3s 438ms<br>` `<br>Thời gian tìm nạp trung bình = 0.01 ms<br>` `<br>Bộ nhớ hiện tại = 136 445 496<br>` `<br>Bộ nhớ tối đa = 136 592 176<br>` `<br>Bộ đệm bộ nhớ = 8 192<br>` `<br>Đọc từ đĩa vào bộ đệm = 1 840<br>` `<br>Ghi từ bộ đệm ra đĩa = 0<br>` `<br>Tìm nạp từ bộ đệm = 598 636<br>`

| SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500 | Truy vấn tương tự trên bảng lớn nhất (3,8 tỷ bản ghi), nhưng lần này chúng tôi đã lấy tất cả các bản ghi (299.245 bản ghi được lấy). | | | | | select w_id, w_name, c_id, c_last
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000) | Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Performance info ——
Prepare time = 0ms
Execute time = 125ms
Avg fetch time = 9.62 ms
Current memory = 272 270 824
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 91
Writes from cache to disk = 0
Fetches from cache = 3 659 | Nối các bảng với 1.240 bản ghi và 372 triệu bản ghi. | | select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)
Result = 59 970 000 | Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Performance info ——
Prepare time = 0ms
Execute time = 13m 4s 718ms
Avg fetch time = 784 718.00 ms
Current memory = 272 268 532
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 2 332 583
Writes from cache to disk = 0
Fetches from cache = 119 977 902 | Đếm số bản ghi cho truy vấn trước đó |

Tóm tắt

Trong thử nghiệm này, Firebird cho thấy các kết quả sau

Khả năng xử lý cơ sở dữ liệu lớn không thể nghi ngờ. Chúng tôi khá chắc chắn rằng có thể tạo và sử dụng cơ sở dữ liệu 32 Tb trên phần cứng phù hợp, và Firebird sẽ thể hiện hiệu suất cao tương tự như với các cơ sở dữ liệu nhỏ hơn (tức là 1Tb trở xuống).
Khả năng mở rộng tốt và mức sử dụng tài nguyên nhỏ đáng kinh ngạc. Cơ sở dữ liệu 1Tb được tạo trên máy tính để bàn thông thường và quan trọng hơn, nó có thể được sử dụng để thực hiện các truy vấn thông thường: nếu bạn không lấy hàng triệu bản ghi, tốc độ truy vấn vẫn tương tự như với các cơ sở dữ liệu có kích thước trung bình (10-15Gb).

Đây chưa phải là kết thúc của thử nghiệm này: chúng tôi dự định chạy thêm một số truy vấn, thu thập thêm số liệu thống kê và công bố báo cáo chi tiết hơn trong thời gian tới. Xin hãy theo dõi.

Liên hệ

Gửi tất cả câu hỏi và thắc mắc của bạn tới [email protected]