Chính xác thì điều đó có nghĩa là gì khi lưu trữ các đốm màu lớn trong cơ sở dữ liệu làm giảm hiệu suất của chế độ ăn uống?

Đối với một người biết nội bộ cơ sở dữ liệu, đây có thể là một câu hỏi dễ, nhưng ai đó có thể giải thích một cách rõ ràng tại sao lưu trữ các đốm màu lớn (nói phim 400 MB) trong cơ sở dữ liệu được cho là làm giảm hiệu suất và điều đó chính xác có nghĩa là gì? Đây là một yêu cầu thường được tìm thấy trên internet, nhưng tôi chưa bao giờ thấy nó thực sự được giải thích.

Cụ thể, tôi đang đề cập đến hiệu suất SharePoint / MSSQL, tức là hiệu suất tải tệp, duyệt trang, hiển thị danh sách, mở tài liệu, v.v. - các hoạt động được cho là chậm hơn khi cơ sở dữ liệu quá lớn. Sự xuất hiện của Blob sang hệ thống tập tin (trong SharePoint được gọi là Remote Blob Storage, hay còn gọi là di chuyển các tệp ra khỏi cơ sở dữ liệu, chỉ để lại một tham chiếu) được cho là giải quyết vấn đề này ở mức độ nào, nhưng chính xác - ở cấp độ dưới cùng - có phải là sự khác biệt? Rõ ràng là các bản sao lưu sẽ mất nhiều thời gian hơn với các tệp khổng lồ được lưu trữ trong cơ sở dữ liệu ... nhưng chính xác các hoạt động nào bị ảnh hưởng và cơ chế cơ bản của nó (nghĩa là các tệp được lưu trữ trên hệ thống tệp bên ngoài cơ sở dữ liệu được truy cập hoặc lưu trữ khác nhau như thế nào)?

Giả sử một bảng đơn giản chứa các cột ID(guid, PK), FileName(string), Data(varbinary(max))- liệu Datacột lớn có thực sự làm chậm các hoạt động như hiển thị danh sách các tệp trên trang web (mà tôi cho rằng bên trong có nghĩa là đang chạy SELECT FileName FROM table) hoặc chèn một hàng mới? Nó không giống như các cột nội dung nhị phân thực tế được lập chỉ mục.

Tôi biết đã có một số câu hỏi như thế này được hỏi, nhưng tôi không tìm thấy lời giải thích thỏa đáng.

Điều này thực sự phụ thuộc vào hệ thống DB, nhưng một điều quan trọng bạn phải xem xét với BLOB là xử lý giao dịch. Bằng cách bên ngoài vào hệ thống tập tin, người ta sẽ thay đổi dữ liệu nhị phân ra khỏi các giao dịch. Điều đó thường sẽ dẫn đến các hoạt động ghi nhanh hơn , trái ngược với tình huống DB đảm bảo cho bạn tuân thủ ACID với các cơ chế khôi phục hoàn toàn, v.v.

Các hoạt động đọc chậm hơn theo giả thuyết cũng có thể xảy ra, khi bạn truy xuất dữ liệu từ db của mình từ bảng BLOB mà không thực sự chọn dữ liệu BLOB, vì DB có thể lưu trữ các hàng còn lại được bản địa hóa nhiều hơn trên đĩa, điều này sẽ cho phép truy cập đọc nhanh hơn (nhưng tôi đoán là hầu hết Các sytems DB hiện đại đủ thông minh để lưu trữ dữ liệu nhị phân thực tế trong một vùng đĩa hoặc vùng bảng riêng biệt, do đó, không kiểm tra điều này với kịch bản trong thế giới thực, người ta không nên đưa ra bất kỳ giả định chung nào ở đây).

Nó thường là một vấn đề với băng thông. Nếu bạn đang phục vụ hàng trăm video mỗi giờ, thì bạn đang buộc băng thông vào và ra khỏi cơ sở dữ liệu, chủ yếu là sao chép bộ đệm. Đây cũng là một vấn đề nếu bạn có các truy vấn ngây thơ (có thể được tạo tự động bởi công cụ ORM) chỉ cần chọn tất cả các cột từ một bảng. Bạn cũng có thể bị phân mảnh tệp như một hệ thống tệp (ngoại trừ trong trường hợp này là phân mảnh ghi), nhưng (thường) không có bất kỳ công cụ nào để phân mảnh. Nếu bạn cũng đang sửa đổi BLOB (ví dụ: bạn đang hỗ trợ một số loại chỉnh sửa video), thì cơ sở dữ liệu sẽ sao chép toàn bộ BLOB sang phân đoạn rollback hoặc làm lại, sau đó ghi BLOB đã cập nhật vào cơ sở dữ liệu. Vì vậy, bây giờ bạn đang sao chép vài trăm megabyte xung quanh,

Bạn có thể muốn xem xét SQL Server FileTables . Ý tưởng là cung cấp tốt nhất cho cả hai thế giới: truy cập và hiệu suất ở cấp hệ thống tệp, cùng với truy cập cơ sở dữ liệu và bảo mật và dịch vụ tích hợp. Cơ sở dữ liệu có hiệu năng vượt trội trong một số trường hợp. Chỉ cần so sánh một tệp HTML được mã hóa cứng trên máy chủ web với một tệp phải lấy nội dung từ cơ sở dữ liệu.

Hãy tưởng tượng một ứng dụng không tìm thấy lưu trữ các đốm màu trong cơ sở dữ liệu là một giới hạn đáng kể đối với hiệu suất, nhưng sau đó ứng dụng đã phát triển đến mức nó tồn tại. Có ít thay đổi mã hóa bằng FileTables. Ngoài ra, bạn có thể quản lý giao dịch ở cấp cơ sở dữ liệu và cấp tệp mà không cần nhiều mã hóa. Tệp và dữ liệu meta có sẵn với SQL.

Trên Windows Server, một ổ đĩa chia sẻ được tạo để truy cập các tệp mà không cần sử dụng quá mức giao dịch cơ sở dữ liệu.

Đây là một vấn đề phổ biến mà Microsoft đã cố gắng xử lý "ngoài luồng" với SQL Server 2012. Không phải là một tính năng tồi để biện minh cho việc nâng cấp.

Để biết tại sao điều này xấu, bạn phải biết cách lưu cơ sở dữ liệu trên ổ cứng (cụ thể là các hàng). Nội dung vật lý của một hàng được lưu trên đĩa được chia thành các đối tác tĩnh và động của nó. Các trường như int, byte, char (n) có độ dài cố định được liệt kê đầu tiên. Điều gì sau đây là một số độ dài cố định trong đó đề cập đến số lượng các trường có chiều dài thay đổi để theo dõi. Tất cả các trường biến (bất kể thứ tự các cột được trình bày cho bạn, lập trình viên) được thêm vào cuối, mỗi trường có một số độ dài cố định xác định khoảng không gian mà trường có độ dài biến.

Để cho bạn một ví dụ cụ thể. Giả sử bảng của tôi là như sau:

char(3) A
varchar(4) B
int C

Bây giờ giả sử tôi làm INSERT INTO mytable (A, B, C) VALUES ('AAA', 'B', 256). Trên cơ sở dữ liệu, hàng đó có thể sẽ được lưu trữ như sau:

Trường A được lưu như bạn mong đợi. Nếu tôi chèn 'A', nó sẽ cung cấp một ký tự đặc biệt để đánh dấu kết thúc sớm của chuỗi sau ký tự đầu tiên, nhưng nó sẽ chiếm cùng một không gian.

Trường C được lưu dưới dạng nhị phân tương đương 256. Tại sao C mà không phải B? C là trường tĩnh tiếp theo có độ dài cố định và do đó, nó được nhóm lại với tất cả dữ liệu tĩnh khác trong hàng cơ sở dữ liệu.

Trường D là thông tin meta cho cơ sở dữ liệu chỉ ra rằng trong phần trường có độ dài biến sau, sẽ có chính xác 1 trường.

Trường E là một lần nữa thông tin meta cho cơ sở dữ liệu chỉ ra rằng đối với trường cụ thể này, nó có độ dài tối đa 1 ký tự. Thông tin này rất cần thiết vì nếu không cơ sở dữ liệu sẽ không biết trường B kết thúc ở đâu và trường có độ dài biến khác bắt đầu.

Tất cả điều này để chứng minh làm thế nào cơ sở dữ liệu xử lý lưu các trường có độ dài thay đổi. BLOB là rất nhiều trường có độ dài thay đổi cho hiệu ứng này. Cấu trúc cơ sở dữ liệu cho phép một hàng chứa cả giá trị nhỏ và lớn trong BLOB, tuy nhiên, có các yếu tố khác đang diễn ra ở đây. Cơ sở dữ liệu thường xử lý các khối thông tin vì các đĩa không quan tâm đến nội dung mà thay vào đó, nếu nó phù hợp với một khối.

Cơ sở dữ liệu sẽ cố gắng sắp xếp nhiều hàng thành một khối mà không phải tách một hàng thành hai phần, vì nếu không thì hiệu ứng cũng giống như có một tệp bị phân mảnh trên ổ cứng của bạn. Khi một đoạn được tải, nếu hàng tràn ra đoạn cụ thể đó, thì ổ cứng phải tìm kiếm phần còn lại của nó trong đoạn khác. Tệ hơn nữa, không có cách nào cơ sở dữ liệu có thể biết rằng một hàng chiếm nhiều hơn một đoạn mà không đọc đầy đủ nội dung của nó vì nó có độ dài thay đổi, vì vậy bạn không thể tối ưu hóa bằng cách tìm nạp cả hai khối cùng một lúc.

Theo dòng logic này, nếu bạn có thể tạo BLOB có độ dài tĩnh, bạn sẽ không gặp vấn đề tối ưu hóa này, vì cơ sở dữ liệu chỉ có thể đảm bảo rằng kích thước khối lớn hơn kích thước hàng tối thiểu do đó đảm bảo rằng hầu hết các hàng sẽ không phải được chia thành nhiều phần. Tất nhiên, cơ sở dữ liệu không làm điều này bởi vì nó có nghĩa là dành không gian quý giá khi bạn có thể sẽ không cần đến nó.

BLOBS vẫn ổn khi bạn xử lý số lượng tương đối nhỏ, nhưng đối với các tệp lớn như video và tương tự, cách khắc phục phổ biến chỉ đơn giản là lưu đường dẫn tệp trong cơ sở dữ liệu và để phần mềm xử lý tải tệp gần như luôn luôn hơn Có hiệu quả.

Hy vọng rằng giải thích nó. :)