Vấn đề phân tách đọc ghi trong mô hình CQRS - ES
White

Nghia Minh Le viết ngày 26/09/2016

Trưa có buổi nói chuyện với anh Thanh VNG, anh có đưa ra một vấn đề là khi đồng bộ dữ liệu từ write side sang read side, thì tại chính read side vẫn có thể gây ra bottle neck. Do bản chất tại đó vẫn phải ghi và update dữ liệu. Đây cũng là một vấn đề mình có nghĩ tới trước đó, nhưng hôm nay trao đổi thì mình mới cần nghĩ sâu hơn xem thực sự mô hình đang làm có khả thi hay không.
Quả thật, việc đồng bộ dữ liệu giữa write side và read side dù được thực hiện qua một message queue, thì khi lượng message tăng cao thì việc ghi tại read side vẫn gây ra tranh chấp với read data. Vì bản chất read và write luôn tranh chấp, cái này lock cái kia theo mô hình của dữ liệu quan hệ truyền thống. Nếu không giải quyết vấn đề này, thì phân tách write side và read site chẳng có ý nghĩa gì cả. Dù cho write side có tối ưu cho việc ghi thông qua việc áp dụng appending model (chỉ insert), thì rồi read side vẫn có thể gây ra tranh chấp và làm giảm hiệu năng.

Sau khi đi về thì có suy nghĩ thêm thì nhận thấy mình chưa hiểu rõ mô hình. Cụ thể có mấy vấn đề sau cần lưu ý:

  • Vấn đề lock và consistency: Khi đã phân tách giữa read side và write side, thì đồng nghĩa phải hiểu rằng read side chỉ là eventually consistency với write side. Dữ liệu của read side luôn cập nhật chậm sau một khoảng thời gian t so với write side. Khác với wride side luôn đòi hỏi phải strong consistency. Điều đó dẫn tới việc thiết kế DB cho read side sẽ khác. Do không đòi hỏi phải consistency, thì nên việc sử dụng công nghệ lưu trữ sẽ rất đa dạng, có thể sử dụng các giải pháp caching, hoặc sử dụng các dạng database không có lock: no sql, sql database với chế độ transaction ở mức read uncommited, hoặc các database index như Solr, Elastic... Vì việc sử dụng các chế lock ở DB cho Read Side không có nhiều giá trị. Do nó đã không consistency với write side ở mức thấp nhất rồi - eventually consistency.

  • Sử dụng optimistic lock: Dữ liệu giữa read side có thể cũ hơn dữ liệu ở write side. Nhưng việc đó không được phép để gây ra sai lệch khi giao dịch ghi. Điều đó có thể giải quyết bằng cơ chế optimistic lock. Áp dụng cơ chế đánh version dữ liệu.

  • Material View Pattern: Khác với cấu trúc dữ liệu truyền thống, với một khối dữ liệu. Việc áp dụng CQRS - ES cho phép triển khai pattern Material View, theo đó xây dựng một cấu trúc lưu trữ tối ưu cho từng view riêng rẽ. Tại đó dữ liệu sẽ được cấu trúc, tính toán trước, tổ chức index, denormailize data để sao tối ưu nhất cho việc select ra.

  • Triển khai nhiều loại database khác nhau: Cùng dữ liệu write side, sẽ dựa trên các log data để build nhiều dạng database khác nhau, phục vụ cho nhiều mục đích đọc và phân tích dữ liệu khác nhau.
    Trên đây là một vài thứ mình rút ra trong việc xây dựng và triển khai mô hình CQRS - ES. Nếu không hiểu được vấn đề này, sẽ dẫn tới việc build read side như cách thông thường, và rút cục không khai thác được hiệu quả của mô hình.
    Quả thật đi trao đổi với expert luôn là cơ hội tốt để tự phản biện, giúp hiểu hơn về những gì mình làm.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Nghia Minh Le

10 bài viết.
115 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
29 0
1. Nguyên lý consistency của relational database – SQL Server. SQL Server nói riêng và các database quan hệ nói chung là dạng database có độ nhất...
Nghia Minh Le viết gần 2 năm trước
29 0
White
19 0
Nhân đọc cuốn The Pragmatic Programmer Lập trình viên thực dụng, note lại mấy dòng về tính thực dụng trong thiết kế. Có một câu chuyện vui: có căn...
Nghia Minh Le viết hơn 1 năm trước
19 0
White
16 2
Mô hình Event Sourcing là một mô hình thiết kế hệ thống mà theo đó sẽ lưu giữ trạng thái thay đổi của một đối tượng là một chuỗi các thay đổi đã xả...
Nghia Minh Le viết gần 2 năm trước
16 2
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
10 bài viết.
115 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!