Tại sao phải tạo cơ sở dữ liệu Firebird cỡ 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à người lớn?”), và rất dễ 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 nghiên cứu 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.

Ngoài ra, lý do quan trọng mà chúng tôi nghĩ đến khi tạo cơ sở dữ liệu Firebird 1Tb là nhằm 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ơ sở dữ liệu nhỏ”. Huyền thoại này có vẻ đã chết, nhưng một số nhà phân tích và nhà báo thường xuyên khai quật nó từ mồ, và chúng tôi hy vọng cuối cùng sẽ chấm dứt nhận thức lố bịch này.


## 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ột 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)	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ề cơ bản, chúng tôi đã đặt ổ HDD 1.5Tb vào một trong những máy tính để bàn văn phòng của mình, không có bất kỳ sửa đổi nào khác. Ổ HDD này được định dạng với kích thước cluster 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 sự 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ả binary 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ư nó sẽ được chèn trong kịch bản thực tế: các bản ghi được chèn và nằm bên trong cơ sở dữ liệu (và tại các vùng đĩa vật lý) vào một số 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ó 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 thực tế kích thước cơ sở dữ liệu 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à ước tính 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ư cluster của HDD, để tối đa hóa hiệu suất đĩ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 và trỏ nó đến đĩa có 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 chỉ cho nhiệm vụ này, có lẽ nó sẽ nhanh hơn, vì vậy vui lòng coi các giá trị này chỉ là một 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: 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).

Bên dưới bạn có thể thấy sự tăng trưởng của cơ sở dữ liệu và động lực giao dịch trong FBDataGuard Viewer:

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 thích hợp của tệp tạm đượ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 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í 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à đo lường 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ố lượng 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 FBDataGuard Community Edition Viewer miễn phí để diễn giải dữ liệu văn bản và xem không chỉ 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 tính 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 đối với 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 đã rất ngạc nhiên với kết quả tốt như vậy. Hãy tự 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)) ------ Performance info —— Prepare time = 15ms Execute time = 79ms Avg fetch time = 6.08 ms Current memory = 272 264 476 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 82 Writes from cache to disk = 0 Fetches from cache = 3 648	Kết hợp đơn giản các bảng với 12400 và 372000000 bản ghi, không có điều kiện WHERE. “Avg fetch time = 6.08 ms” là để lấy 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)) ------ Performance info —— Prepare time = 16ms Execute time = 78ms Avg fetch time = 6.00 ms Current memory = 272 266 148 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 88 Writes from cache to disk = 0 Fetches from cache = 3 656	Kết hợp các bảng giống nhau với điều kiện buộc chọn các bản ghi gần đây. “Avg fetch time = 6.00 ms” là để lấy hàng đầu tiên.
select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Result = 30000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info —— Prepare time = 0ms Execute time = 453ms Avg fetch time = 453.00 ms Current memory = 272 263 844 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 1 048 Writes from cache to disk = 0 Fetches from cache = 60 024	Đếm bản ghi cho truy vấn trước đó

SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	Plan PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Performance info —— Prepare time = 0ms Execute time = 94ms Avg fetch time = 7.23 ms Current memory = 136 445 536 Max memory = 136 592 176 Memory buffers = 8 192 Reads from disk to cache = 150 Writes from cache to disk = 0 Fetches from cache = 2 402	Truy vấn đến bảng lớn nhất (3,8 tỷ bản ghi). “Avg fetch time = 7.23 ms” là để lấy hàng đầu tiên.

	`<br>Plan<br>` `<br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br>` `<br> <br>` `<br>------ Performance info ------<br>` `<br>Prepare time = 0ms<br>` `<br>Execute time = 3s 438ms<br>` `<br>Avg fetch time = 0.01 ms<br>` `<br>Current memory = 136 445 496<br>` `<br>Max memory = 136 592 176<br>` `<br>Memory buffers = 8 192<br>` `<br>Reads from disk to cache = 1 840<br>` `<br>Writes from cache to disk = 0<br>` `<br>Fetches from cache = 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 (đã lấy 299245 bản ghi). | | | | | 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 | Kết nối các bảng có 1240 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ể phủ nhận. 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 năng cao tương tự như đối 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à dung lượng chiếm dụng nhỏ đáng kinh ngạc. Cơ sở dữ liệu 1Tb được tạo trên một máy tính để bàn thông thường và, quan trọng hơn, nó có thể được 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 giống như đối với các cơ sở dữ liệu có kích thước vừa phải (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. Hãy tiếp tục theo dõi.

Liên hệ

Gửi mọi câu hỏi và yêu cầu của bạn tới [email protected]