Cách hiệu quả nhất về mặt thời gian để tuần tự hóa / giải mã hóa một DataTable đến / từ Redis là gì?

Thật không may khi làm việc với các tập dữ liệu lớn, sẽ luôn mất thời gian để tuần tự hóa và giải mã hóa cấu trúc. DataTable đặc biệt là các đối tượng khá phức tạp, vì chúng có các hàng và cột thường có nhiều dữ liệu meta được đính kèm - ngay cả khi nó có vẻ là một bảng cơ bản.

`DataTable` so với `List<POCO>` :

Cân nhắc xem bạn có thực sự cần đăng ký dưới dạng DataTable hay không . Bạn có thể tạo một POCO đơn giản hơn và tuần tự hóa một List<YourRecord> không ? Nói cách khác, nếu bạn không cần các thuộc tính bổ sung trên các trường và cột và bạn có thể tuần tự hóa sang một định dạng đơn giản hơn, nó có thể nhanh hơn và tiết kiệm không gian hơn trong bộ nhớ cache; và sau đó khôi phục về DataTable nếu cần.

Một tùy chọn khác là tách DataTable thành các bộ nhỏ hơn, mà bạn tuần tự hóa và lưu trữ trong các phần nhỏ hơn. Bạn có thể thấy điều này hiệu quả hơn. Bạn sẽ có thể đánh giá tiêu chuẩn này.

Điểm chuẩn:

Cuối cùng thì bộ nhớ cache Redis của bạn phải là một cải tiến so với thời gian thực hiện để truy vấn lại nguồn dữ liệu. Bạn sử dụng thuật ngữ takes too much time , nhưng nếu mất 2 giây để lấy từ bộ nhớ cache so với 8 giây để truy vấn nguồn dữ liệu thì đó là một sự thúc đẩy đáng kể. Nhưng cách duy nhất để chắc chắn là làm điểm chuẩn.

Thiết lập môi trường của bạn để bạn chỉ chạy các công cụ cần thiết. Không thực hiện các tác vụ khác trong khi chạy điểm chuẩn, vì vậy bạn không tạo ra bất kỳ sự thiên vị nào.
Ghi lại thời gian cần thiết để tuần tự hóa một DataTable . Thực hiện động tác này nhiều lần và trung bình.
```
var start = DateTime.Now;
// Serialize
var duration = DateTime.Now - start;
```
Thử nghiệm với các kích thước khác nhau của DataTable s và xem bạn có tìm thấy thời gian có thể chấp nhận được không.
Hãy thử một thư viện tuần tự hóa khác, chẳng hạn như JSON.NET. Mặc dù thật tuyệt khi giữ tất cả ServiceStack, điều này có thể giúp bạn xác định xem đó là thiếu sót của ServiceStack.Text hay chỉ là sự cố với tập dữ liệu lớn.
Lặp lại quy trình giải mã trên không.

Bộ nhớ:

Nếu bạn đang làm việc với các tập dữ liệu lớn, liệu cả ứng dụng của bạn và bộ đệm có đủ bộ nhớ không? Bộ nhớ trong ứng dụng của bạn có thể là một nút cổ chai; Bạn nên xem trình giám sát hoạt động của hệ thống trong khi thực hiện các hoạt động và đảm bảo rằng bạn không hết bộ nhớ và hệ thống của bạn thực hiện phân trang. Nếu bạn thấy điều này xảy ra, hãy xem xét việc tăng RAM hoặc chia DataTable thành các tập dữ liệu nhỏ hơn như đã đề cập trước đây.

Độ trễ:

Nếu bạn đang kết nối với máy chủ Redis qua mạng và không trên cùng một máy, bạn đã kiểm tra độ trễ của mạng chưa? Bạn có thể muốn ping giữa máy chủ ứng dụng của mình và máy chủ bộ đệm và đảm bảo rằng bạn thực sự có ping thấp. Đặc biệt nếu bạn thấy bộ nhớ đệm các đối tượng đơn giản chậm.

Làm lại?

Nếu bạn không tìm thấy cách nào để cải thiện thời gian lưu vào bộ nhớ cache và khôi phục, thì có lẽ việc sử dụng Redis không phù hợp. Có lẽ đang sử dụng static DataTable trong bộ nhớ ứng dụng sẽ phù hợp hơn. Nói cách khác, bằng cách giữ bộ nhớ cache trong bộ nhớ ứng dụng và sau đó không cần lo lắng về tuần tự hóa và giải mã hóa. Tất nhiên, bạn có thể cần phải cẩn thận về việc đảm bảo bạn có đủ bộ nhớ cho ứng dụng của mình để thực hiện việc này. Tuy nhiên, tôi sẽ rất ngạc nhiên nếu bạn phải chọn tùy chọn này .

Tóm tắt:

Nếu không nhìn thấy tập dữ liệu của bạn hoặc kiến thức về dịch vụ bạn đang xây dựng, cuối cùng nó chỉ đưa ra lời khuyên chung chung về cách thu hẹp tốt nhất nguyên nhân gây ra vấn đề của bạn. Lời khuyên chính là không sử dụng DataTable nếu một cấu trúc đơn giản hơn sẽ làm được, và chuẩn từng hoạt động để xác định bất kỳ điểm nghẽn nào.

Tôi hy vọng điều này sẽ hữu ích.