Bảng tối ưu hóa bộ nhớ - chúng thực sự có thể rất khó để duy trì?

Tôi đang nghiên cứu các lợi ích của việc nâng cấp từ MS SQL 2012 lên 2014. Một trong những điểm bán hàng lớn của SQL 2014 là các bảng được tối ưu hóa bộ nhớ, dường như thực hiện các truy vấn siêu nhanh.

Tôi đã thấy rằng có một vài hạn chế trên các bảng được tối ưu hóa bộ nhớ, chẳng hạn như:

• Không (max)có trường kích thước
• Tối đa ~ 1KB mỗi hàng
• Không có timestamptrường
• Không có cột tính toán
• Không UNIQUEràng buộc

Tất cả đều đủ điều kiện là phiền toái, nhưng nếu tôi thực sự muốn làm việc xung quanh chúng để đạt được lợi ích hiệu suất, tôi có thể lập một kế hoạch.

Các kicker thực sự là thực tế là bạn không thể chạy một ALTER TABLEtuyên bố, và bạn phải trải qua sự nghiêm khắc này mỗi khi bạn thêm một trường vào INCLUDEdanh sách chỉ mục. Hơn nữa, có vẻ như bạn phải tắt người dùng khỏi hệ thống để thực hiện bất kỳ thay đổi lược đồ nào đối với các bảng MO trên DB trực tiếp.

Tôi thấy điều này hoàn toàn thái quá, đến mức tôi thực sự không thể tin rằng Microsoft có thể đã đầu tư quá nhiều vốn phát triển vào tính năng này và để nó không thực tế để duy trì. Điều này dẫn tôi đến kết luận rằng tôi phải nhận được kết thúc sai của cây gậy; Tôi đã hiểu nhầm điều gì đó về các bảng được tối ưu hóa bộ nhớ khiến tôi tin rằng việc duy trì chúng khó khăn hơn nhiều so với thực tế.

Vì vậy, những gì tôi đã hiểu lầm? Bạn đã sử dụng bảng MO? Có một số loại chuyển đổi hoặc quy trình bí mật làm cho chúng thực tế để sử dụng và bảo trì?

Không, trong bộ nhớ thực sự là điều này chưa được đánh bóng. Nếu bạn quen thuộc với Agile, bạn sẽ biết khái niệm "sản phẩm có thể chuyển tối thiểu"; trong bộ nhớ là thế Tôi có cảm giác rằng MS cần một phản hồi cho Hana của SAP và ilk của nó. Đây là những gì họ có thể được gỡ lỗi trong khung thời gian cho phiên bản 2014.

Như với bất cứ điều gì khác trong bộ nhớ có chi phí và lợi ích liên quan đến nó. Lợi ích chính là thông lượng có thể đạt được. Một trong những chi phí là chi phí quản lý thay đổi, như bạn đã đề cập. Điều này không làm cho nó trở thành một sản phẩm vô dụng, theo tôi, nó chỉ làm giảm số lượng các trường hợp mà nó sẽ mang lại lợi ích ròng. Giống như các chỉ mục của cửa hàng hiện có thể cập nhật và các chỉ mục có thể được lọc, tôi không nghi ngờ rằng chức năng của bộ nhớ sẽ cải thiện trong các bản phát hành sắp tới.

SQL Server 2016 hiện có sẵn nói chung. Đúng như tôi nghĩ, OLTP trong bộ nhớ đã nhận được một số cải tiến. Hầu hết các thay đổi thực hiện chức năng mà các bảng truyền thống đã được hưởng một thời gian. Tôi đoán là các tính năng trong tương lai sẽ được phát hành cùng lúc cho cả bảng trong bộ nhớ và truyền thống. Bảng tạm thời là một trường hợp tại điểm. Mới trong phiên bản này, nó được hỗ trợ bởi cả hai bảng trong bộ nhớ và trên đĩa .

Một trong những vấn đề với công nghệ mới - đặc biệt là bản phát hành V1 đã được tiết lộ khá lớn là không đầy đủ tính năng - là mọi người đều nhảy vào bandwagon và cho rằng nó phù hợp hoàn hảo cho mọi khối lượng công việc. Không phải vậy. Điểm hay của Hekaton là khối lượng công việc OLTP dưới 256 GB với rất nhiều điểm tra cứu trên 2-4 ổ cắm. Điều này có phù hợp với khối lượng công việc của bạn?

Nhiều hạn chế phải thực hiện với các bảng trong bộ nhớ kết hợp với các thủ tục được biên dịch nguyên gốc. Tất nhiên, bạn có thể bỏ qua một số hạn chế này bằng cách sử dụng các bảng trong bộ nhớ nhưng không sử dụng các quy trình được biên dịch nguyên gốc hoặc ít nhất là không độc quyền.

Rõ ràng bạn cần kiểm tra xem hiệu suất đạt được có đáng kể trong môi trường của bạn hay không , và nếu có, liệu sự đánh đổi có xứng đáng hay không. Nếu bạn đang đạt được hiệu suất tuyệt vời từ các bảng trong bộ nhớ, tôi không chắc tại sao bạn lại lo lắng về việc bạn sẽ thực hiện bao nhiêu bảo trì trên các cột INCLUDE. Chỉ số trong bộ nhớ của bạn là theo định nghĩa bao gồm. Chúng chỉ thực sự hữu ích để tránh tra cứu trên phạm vi hoặc quét toàn bộ các chỉ mục không được phân cụm truyền thống và các thao tác này không thực sự xảy ra trong các bảng trong bộ nhớ (một lần nữa, bạn nên ghi lại khối lượng công việc của mình và xem hoạt động nào được cải thiện và không - tất cả không phải là thắng-thắng). Bạn có thường xuyên làm quen với các cột INCLUDE trên các chỉ mục của mình ngày hôm nay không?

Về cơ bản, nếu nó không xứng đáng với bạn ở dạng V1, thì đừng sử dụng nó. Đó không phải là một câu hỏi chúng tôi có thể trả lời cho bạn, ngoại trừ để cho bạn biết rằng rất nhiều khách hàng là sẵn sàng sống chung với những hạn chế, và đang sử dụng các tính năng đem lại lợi ích to lớn mặc dù trong số họ.

Máy chủ SQL 2016

Nếu bạn đang trên đường tới SQL Server 2016, tôi đã viết blog về các cải tiến bạn sẽ thấy trong OLTP trong bộ nhớ, cũng như loại bỏ một số hạn chế . Đáng chú ý nhất:

• Tăng kích thước bảng bền tối đa: 256 GB => 2 TB
• Các cột LOB / MAX, lập chỉ mục trên các cột không thể xóa, loại bỏ các yêu cầu đối chiếu BIN2
• Thay đổi và biên dịch lại các thủ tục
• Một số hỗ trợ cho ALTER TABLE - nó sẽ ngoại tuyến nhưng bạn sẽ có thể thay đổi và / hoặc thả / tạo lại các chỉ mục (tuy nhiên điều này dường như không được hỗ trợ trên các bản dựng CTP hiện tại, do đó, đừng coi đây là một sự đảm bảo)
• Kích hoạt DML, ràng buộc FK / kiểm tra, MARS
• HOẶC, KHÔNG, VÀO, EXISTS, DISTINCT, UNION, OUTER THAM GIA
• Song song

Bạn không thể nhấp chuột phải vào bảng được tối ưu hóa bộ nhớ, để mở trình thiết kế và thêm các cột mới theo ý muốn, từ trong Sql Server Management Studio. Bạn cũng không thể nhấp vào tên bảng như một phương tiện để đổi tên bảng. (SQL 2014 khi tôi viết bài này.)

Thay vào đó, bạn có thể nhấp chuột phải vào bảng và ra lệnh tạo lệnh cho cửa sổ truy vấn mới. Lệnh tạo này có thể được sửa đổi bằng cách thêm bất kỳ cột mới.

Vì vậy, để sửa đổi bảng, bạn có thể lưu trữ dữ liệu trong một bảng mới, bảng tạm thời hoặc biến bảng. Sau đó, bạn có thể thả và tạo lại bảng với lược đồ mới và cuối cùng sao chép lại trong dữ liệu thực tế . Trò chơi 3 vỏ container này chỉ kém một chút thuận tiện cho hầu hết các trường hợp sử dụng.

Nhưng, bạn không có lý do gì để bận tâm với các bảng Tối ưu hóa Bộ nhớ nếu không có vấn đề về hiệu suất mà bạn đang cố gắng giải quyết.

Sau đó, bạn sẽ phải cân nhắc nếu những hạn chế và công việc đáng giá cho trường hợp sử dụng của bạn. Bạn có một vấn đề hiệu suất? Bạn đã thử mọi thứ khác? Điều này sẽ cải thiện hiệu suất của bạn lên 10 - 100 lần? Sử dụng nó hoặc không sử dụng nó có thể sẽ trở thành một chút không có trí tuệ.

bạn có thể sử dụng OLTP trong bộ nhớ trong máy chủ hoạt động mà không gặp vấn đề gì lớn. chúng tôi đã sử dụng công nghệ này trong một công ty Ngân hàng và Thanh toán,

Nói chung, chúng ta có thể sử dụng các bảng được tối ưu hóa bộ nhớ khi khối lượng công việc quá cao. bằng cách sử dụng OLTP trong bộ nhớ, bạn có thể đạt hiệu suất tốt hơn tới 30 lần! Microsoft sửa hầu hết các hạn chế này trong SQL Server 2016 & 2017. các bảng được tối ưu hóa bộ nhớ có kiến ​​trúc hoàn toàn khác so với các bảng Dựa trên đĩa.

bảng tối ưu hóa bộ nhớ có hai loại. bảng bền và bảng không thể chữa được. Bảng bền và không bền duy trì dữ liệu bảng nằm trong bộ nhớ. Các bảng bền của Furthemore vẫn duy trì dữ liệu về Đĩa cho Dữ liệu khôi phục và Lược đồ. hầu hết các kịch bản hoạt động chúng ta nên sử dụng các bảng bền vì dữ liệu bị mất là rất quan trọng ở đây. trong một số trường hợp ví dụ tải ETL và bộ đệm, chúng ta có thể sử dụng các bảng không thể sử dụng được.

bạn có thể sử dụng sách điện tử này và tìm hiểu cách sử dụng công nghệ này:

Kalen Delaney: https://www.red-gate.com/l Library / sql-server-iternals-in-memory -oltp

Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718