Vì sao cơ sở dữ liệu và sự phức tạp của chúng giờ đây không còn cần thiết

Những vấn đề của cơ sở dữ liệu và vì sao sự phức tạp của chúng là không cần thiết

• Cơ sở dữ liệu là trạng thái khả biến toàn cục, khiến mã nguồn trở nên phức tạp và khó hiểu.
• Mô hình dữ liệu bị giới hạn và không thể hỗ trợ mọi trường hợp sử dụng, nên cần phải dùng nhiều cơ sở dữ liệu.
• Vấn đề chuẩn hóa so với phi chuẩn hóa tạo ra sự căng thẳng giữa tính nhất quán dữ liệu và hiệu năng.
• Lược đồ bị giới hạn gây ra sự phức tạp khi phải điều chỉnh cách biểu diễn miền để phù hợp với cơ sở dữ liệu.
• Việc triển khai phức tạp làm tăng chi phí và độ phức tạp do phải kết hợp và tích hợp nhiều công cụ khác nhau.

Mô hình nhất quán để xây dựng backend ứng dụng

• Chức năng cơ bản của backend là nhận dữ liệu mới và trả lời các câu hỏi về dữ liệu đó.
• Thiết kế backend lý tưởng nên càng gần với lý tưởng càng tốt, đồng thời vẫn đáp ứng các ràng buộc thực tế.

Rama

• Rama là một nền tảng phát triển backend, tái triển khai Mastodon để cung cấp dịch vụ ở quy mô Twitter.
• Rama triển khai mọi thành phần của backend như dữ liệu, chỉ mục, ETL và truy vấn theo một cách thức tổng quát.
• Rama đơn giản hóa việc triển khai phức tạp và tích hợp giám sát, qua đó cắt giảm đáng kể chi phí phát triển và bảo trì.

Ý kiến của GN⁺

• Vấn đề trạng thái khả biến toàn cục của cơ sở dữ liệu làm tăng độ phức tạp của mã nguồn và khả năng phát sinh lỗi, đây là vấn đề mà các nhà phát triển thường xuyên đối mặt.
• Rama đưa ra một cách tiếp cận mới để vượt qua các giới hạn của cơ sở dữ liệu hiện có và giảm bớt độ phức tạp của phát triển backend.
• Bài viết này mang đến thông tin thú vị và hữu ích cho các nhà phát triển muốn giảm độ phức tạp của cơ sở dữ liệu và hệ thống backend.

[GN⁺]

Ý kiến trên Hacker News

• Cần sử dụng một subsystem biểu diễn nguồn chân lý duy nhất và một subsystem khác triển khai nhiều kho lưu trữ chỉ mục được dẫn xuất từ nguồn đó. Đây là sự kết hợp giữa event sourcing và materialized views.

  • Event sourcing và materialized views: Giải pháp là tách riêng hệ thống biểu diễn nguồn chân lý và các kho lưu trữ chỉ mục dựa trên nó để quản lý.

• Chúng tôi tách riêng read model và write model: write model ("nguồn chân lý") được cấu thành từ mô hình miền quan hệ truyền thống, và gần như mọi command đều tạo ra các event được đăng vào hàng đợi domain event dùng chung. Read model được cấu thành bởi các worker tiêu thụ event và xây dựng view.

  • Tách read/write model: Write model được cấu thành từ mô hình miền quan hệ, còn các command tạo ra event rồi đăng vào hàng đợi domain event. Read model tiêu thụ event để xây dựng view.

• Khi dữ liệu thay đổi, materializing có thể mang lại lợi ích khi sản phẩm cần thực hiện rất nhanh một tác vụ duy nhất. Nhưng vấn đề xuất hiện khi bạn muốn thêm tính năng mới đòi hỏi transaction phức tạp hoặc cần dữ liệu được tổ chức theo cách khác.

  • Giới hạn của materializing dữ liệu: Hữu ích khi tối ưu cho một tác vụ đơn lẻ, nhưng có thể phát sinh vấn đề khi thêm tính năng cần transaction phức tạp hoặc cấu trúc dữ liệu mới.

• Việc khẳng định rằng điều này đã được chứng minh ở quy mô của một "client Mastodon ở quy mô Twitter" là điều bất khả, trừ khi bạn thực sự đang vận hành một website có 40 triệu người dùng mỗi ngày.

  • Tầm quan trọng của quy mô: Không thể mô phỏng một môi trường người dùng thực sự ở quy mô lớn, nên rất khó để đưa ra tuyên bố như vậy.

• Cách tiếp cận tốt hơn là sự kết hợp giữa event sourcing và materialized views.

  • Kết hợp event sourcing và materialized views: Được đưa ra như một cách tiếp cận tốt hơn, dù đi kèm với mức độ phức tạp cao hơn.

• Không có một mô hình dữ liệu đơn lẻ nào có thể hỗ trợ mọi use case.

  • Sự đa dạng của mô hình dữ liệu: Không thể dùng một mô hình dữ liệu duy nhất để hỗ trợ mọi use case.

• Tôi không có gì phàn nàn về database.

  • Tính hữu dụng của database: Không có phàn nàn gì về database; đây vẫn là một công cụ hợp lệ.

• Có phải các khái niệm như concurrency, isolation, constraint, v.v. đã bị bỏ sót? "Query topology" thực sự vượt trội hơn đối với môi trường phát triển sao?

  • Hoài nghi về query topology: Các khái niệm quan trọng như concurrency, isolation và constraint đã bị bỏ sót, đồng thời đặt câu hỏi về tuyên bố rằng query topology vượt trội hơn cho môi trường phát triển.

• Tôi cần một bản ELI5 về Rama. Tài liệu quá khó hiểu, và xin đừng dùng những buzzword như "paradigm shift" hay "platform".

  • Yêu cầu giải thích đơn giản về Rama: Mong muốn có một lời giải thích dễ hiểu về Rama và tránh dùng các buzzword.

• Event sourcing (+ materialized views và index) không có nghĩa là vứt bỏ RDBMS. Có thể dùng cả hai cùng nhau.

  • Sự cùng tồn tại của event sourcing và RDBMS: Event sourcing và materialized views có thể được sử dụng cùng với RDBMS; chúng không loại trừ lẫn nhau.

Kiến thức nền:

• Event Sourcing: Mẫu thiết kế ghi lại các thay đổi trạng thái của hệ thống dưới dạng event, từ đó có thể phát lại để tái dựng trạng thái hệ thống.
• Materialized Views: Kỹ thuật lưu trữ vật lý kết quả truy vấn của database nhằm cải thiện hiệu năng đọc dữ liệu.
• RDBMS (Relational Database Management System): Hệ thống quản lý cơ sở dữ liệu quan hệ.