Đặt Nhật ký giao dịch trên khối lượng riêng [trạng thái rắn]?


12

Nhật ký giao dịch thường bị cô lập trên một khối lượng riêng. Lý do cho cách làm này, theo tôi hiểu, là dữ liệu của nhật ký giao dịch được ghi tuần tự - và các ổ cứng có thể thực hiện các thao tác ghi với tốc độ lớn hơn nhiều so với ngẫu nhiên. Điều này là do kim nhỏ bên trong ổ đĩa phải di chuyển một khoảng cách ngắn hơn nhiều khi ghi các khối dữ liệu liên tiếp, trái ngược với ghi ngẫu nhiên.

(Xin lỗi vì cách giải thích ngây thơ. Chỉ cố gắng hiểu ý nghĩa của những gì tôi đã đọc.)

Với suy nghĩ này, điều này xảy ra với tôi rằng các ổ đĩa trạng thái rắn không có ít kim và đĩa và các thứ di chuyển xung quanh chúng. Nếu cả cơ sở dữ liệu và nhật ký giao dịch của tôi đều nằm trên một RAID 5 trong số tám ổ đĩa trạng thái rắn, thì có thực sự có bất kỳ sự thay đổi nào trong việc chuyển nhật ký giao dịch lên khối lượng riêng của nó không? Nếu việc tăng hiệu quả được cho là dựa trên tiền đề của việc ghi tuần tự làm giảm khoảng cách mà kim di chuyển và vặn xoắn, và một ổ đĩa trạng thái rắn không có bộ phận chuyển động nào, tôi sẽ đạt được gì khi cô lập nhật ký?


Bạn vẫn còn có các bus và bộ đệm để xem xét. Tôi sẽ tách chúng ra do khác biệt mẫu I / O. Nếu ứng dụng của bạn không giao dịch nhiều, bạn có thể không biết sự khác biệt, nếu chi phí là một vấn đề.
Eric Higgins

Khi bạn sử dụng thuật ngữ "xe buýt" ... bạn có đang đề cập đến đường dẫn dữ liệu đi từ bo mạch chủ đến thẻ RAID không?
Chad Decker

2
"có thực sự có bất kỳ sự thay đổi nào trong việc chuyển nhật ký giao dịch lên khối lượng riêng của nó không?" gần như chắc chắn là không, nhưng thực sự có một tốc độ tăng tốc khi chuyển toàn bộ mảng sang RAID10 và độ tin cậy tăng lên khi cung cấp quá mức (tức là phân vùng dưới) SSD
Jack nói hãy thử topanswers.xyz

Câu trả lời:


10

Câu trả lời ngắn, sử dụng một mảng duy nhất, không có khả năng đạt được hiệu suất nào từ việc tách nhật ký khỏi dữ liệu trên 8 ổ SSD. Xem SQL trên SSD: Hot and Crazy Love để biết bình luận chi tiết hơn (và giải trí) về SSD. Đặc biệt chú ý đến các lưu ý về lỗi tương quan của SSD.

Tách nhật ký khỏi dữ liệu trên SSD là một RPO (mục tiêu điểm khôi phục) hơn là vấn đề hiệu suất. Quan niệm là bạn có thể giảm RPO của mình bằng cách tách các nhật ký khỏi dữ liệu sao cho trong trường hợp mảng dữ liệu bị lỗi, mảng nhật ký của bạn sẽ / có thể truy cập được. Thận trọng sẽ xem xét một kiểu / mô hình ổ đĩa khác nhau trong mỗi hai mảng để giảm thiểu vấn đề lỗi tương quan nếu RPO là nghiêm trọng.

Các ý kiến ​​liên quan đến băng thông xe buýt là không liên quan. Nếu bạn cần thay đổi nhiều IO, bạn sẽ có vấn đề lớn hơn.


-4

Có một nhóm đồng ý rằng trên một ổ cứng sẽ có lợi khi tách ra, họ vẫn cho rằng đối với các ổ SSD thì điều này không còn cần thiết nữa.

Vì vậy, đối với họ tôi muốn hỏi "nếu không có vấn đề tranh chấp thì tại sao lại là RAID 10? Không cần phải tước nữa! Vì vậy, việc sử dụng một mình là đủ, và dĩ nhiên không cần 8 ổ đĩa, gấp đôi cơ sở dữ liệu kích thước nên đủ! ".

Tuy nhiên, thực tế là nếu thứ gì đó cần RAID 10 thì đó là tệp nhật ký!

Điều này không chỉ vì vấn đề tuần tự và ngẫu nhiên (xem tài nguyên bên dưới), mà nó thực sự rất quan trọng một khi bạn hiểu cách hoạt động của ổ SSD.

Để thực hiện một câu chuyện dài ngắn (đối với một mô tả còn thấy http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), một ổ SSD rất hiệu quả trong việc đọc và viết ra các số không, tuy nhiên để viết ra các ổ đó thì không hiệu quả lắm vì nó phải xóa toàn bộ phần để viết dù chỉ một lần!

Mặc dù đây không phải là vấn đề đối với ghi chung, vì dù sao chúng cũng được lưu vào bộ nhớ và được ghi trong ranh giới trang, đây là một vấn đề lớn đối với tệp nhật ký, vì tệp nhật ký bỏ qua bất kỳ bộ đệm nào và thay vào đó là khối máy chủ SQL cho đến khi Nhật ký được ghi vào đĩa!, điều đó có nghĩa là đối với mỗi lần ghi có thể sẽ có một phần xóa hoàn toàn.

Vì vậy, để tối ưu hóa nó, tôi khuyên bạn nên dành mọi đĩa bổ sung (ngoài gấp đôi kích thước cơ sở dữ liệu, không cần tước!) Cho tệp nhật ký, bằng cách này, nó sẽ có thể xử lý nhiều nhất có thể trong khung thời gian ngắn hơn.

TRẢ LỜI

Câu trả lời là có, vì ba lý do. 1) Ngẫu nhiên so với tuần tự - Mặc dù rõ ràng SSD tăng hiệu năng đáng kể khi ghi ngẫu nhiên, vẫn còn vấn đề ngẫu nhiên so với tuần tự, như có thể thấy từ các liên kết và liên kết sau:

2) Độ tin cậy - Có nhiều khả năng tất cả các ổ SSD sẽ bị lỗi đồng thời, trong trường hợp RAID không được bảo vệ, tuy nhiên do ổ SSD chỉ được sử dụng cho tuần tự có tuổi thọ khác nhau nên đây có thể là cứu cánh của bạn

3) Ghi chú - Lý do đặt nhật ký vào trục chính của nó không chỉ vì ngẫu nhiên so với tuần tự mà còn vì tranh chấp ghi, vì người ta cũng có thể thấy tempdb trên một khối riêng biệt cho biết vấn đề ở đây cũng là về sự tranh chấp.

Và điều này sẽ áp dụng nhiều hơn cho tệp nhật ký, vì ghi vào các bản ghi khối giao dịch khỏi bị coi là cam kết cho đến khi nó được ghi vào bề mặt đĩa.

Trên thực tế đối với nhật ký, bạn có thể sử dụng ổ đĩa cứng thông thường như một tờ giấy trắng của Dell tại địa chỉ http://www.dell.com/doads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf

BIÊN TẬP

Việc đưa tempdb vào mảng riêng cho đĩa quay được Microsoft khuyên dùng, xem

và nhiều thứ khác và đó là khái niệm được chấp nhận chung trong Sql Server, trong khi không ai bày tỏ vấn đề với việc chia mảng.

Hơn nữa, nhóm SQL Server đã tạo ra các khái niệm phân vùng Filegroup và Partioining, với mục đích duy nhất là có thể di chuyển chúng trên một mảng riêng biệt.

Và trên thực tế, MSDN tại http://msdn.microsoft.com/en-us/l Library / ms187087 (v ​​= sql.105 ) khuyến nghị rằng có thể có một lợi ích hiệu suất từ ​​việc tách chỉ mục không tách rời trên mảng của chính nó, (mặc dù điều này không nên được coi là một lời khuyên chung cho mọi tình huống, chỉ đối với khối lượng công việc cụ thể, xem thêm thông tin tại http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).

Vì vậy, đây chỉ là một phần mở rộng hợp lý để nói lý do phân tách trên đĩa quay không chỉ liên quan đến vấn đề đọc liên tiếp và đọc ngẫu nhiên, mà còn là sự tranh chấp viết chung, một điều gì đó cũng áp dụng cho SSD.

Mặc dù có thể một số người không đồng ý với lời khuyên đó và cho rằng không có lợi ích gì khi đặt tempdb và khối lượng riêng của nó (như Jack Douglas), và bạn thậm chí có thể cho rằng không có lợi ích gì khi tách các tệp nhật ký (như Mark Storey -Smith), và thay vào đó tuyên bố rằng việc chia mảng tồi tệ hơn nhiều, vẫn không quên rằng đây là một cách tiếp cận mới đi ngược lại với cách tiếp cận được chấp nhận chung do Microsoft và cộng đồng đề xuất, và cho đến nay không ai cung cấp liên kết đến bất kỳ kiểm tra điểm chuẩn để hỗ trợ nó.

Vì vậy, lời tôi nói với tất cả những người downvoters là, tôi thấy rất thiếu đạo đức đối với một bài viết chỉ vì nó có ý kiến ​​khác với bạn, đặc biệt là khi 1) ý kiến ​​của bạn đi ngược lại lý thuyết được chấp nhận chung 2) và nó chống lại các nhà cung cấp (Microsoft ) tài liệu riêng 3) và bạn chưa cung cấp bất kỳ bằng chứng nào chỉ là ý kiến.

Nhưng trong trường hợp này thậm chí còn kỳ cục hơn, vì bài đăng của tôi không gì khác hơn là phần mở rộng hợp lý cho lý thuyết này, vì vậy một bài viết coi bài đăng này là lời khuyên trên giường tất nhiên phải quay lại tất cả các bài viết tư vấn lý thuyết này và đánh giá thấp chúng .

Nói rằng ai đó quyết định rằng RAID là lý thuyết trường học cũ và đánh giá thấp tất cả các bài viết giới thiệu nó, làm thế nào điều này có ý nghĩa?


Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .
Paul White 9
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.