Nhật ký công việc cho nhiệm vụ "Chuyển trang web sang nền tảng mới"
Cấu trúc CSDL legacy: giả thuyết "chỉ cần kết nối" bị xem xét lại
Sau khi chạy thử cục bộ, chúng tôi đã xem xét cấu trúc thực tế của cơ sở dữ liệu MySQL hiện có. Quy mô của legacy lớn hơn đáng kể so với những gì chỉ nhìn thấy qua Docker stack: 250 bảng, khoảng 198 nghìn dòng và ~82 MiB dữ liệu.
Trong tổng số 250 bảng, khoảng 150 bảng có tiền tố MODX cũ fSdf12_. Đây là lớp hệ thống lớn của chính MODX và các tiện ích mở rộng (Extras) được cài đặt qua nhiều năm: ACL/policies, contexts, manager/dashboard, media sources, package transport, lexicon, sessions, users/groups, các module billing/shop, society, SDK/importer, search, monitoring, GeoIP và các phân hệ khác. Phần lớn các bảng này trống hoặc chỉ chứa vài bản ghi, nhưng khi phân tích legacy, chúng vẫn trông giống như một phần có khả năng quan trọng của hệ thống.
Ngoài ra còn có một lớp mô hình lịch sử khác: hàng chục bảng quan hệ theo phong cách Prisma _...; nhiều bảng trong số đó hiện đang trống. Dấu vết của việc di chuyển/trùng lặp thực thể liên tiếp cũng hiển thị rõ: ví dụ như các biến thể cũ và mới của Place, Beer, User, Photo, các bình luận và bảng liên kết, các bảng sao lưu người dùng, views và các công cụ lưu trữ khác nhau (MyISAM + InnoDB). Đây không còn là một lược đồ miền đơn lẻ, mà là một vài thế hệ kiến trúc cùng tồn tại trong một cơ sở dữ liệu.
Đồng thời, lõi miền thực tế của pivkarta.ru nhỏ hơn nhiều. Dữ liệu cho thấy có vài nghìn địa điểm (Place ~3.8k), khoảng 1.6k loại/mục Beer, ~13k liên kết PlaceBeer, hình ảnh, người dùng và các liên kết của địa điểm với bia/tàu điện ngầm/người dùng; cộng với các thực thể nội dung như bình luận, chủ đề, tin tức/blog, v.v. Những thực thể nào thực sự cần thiết cho phiên bản sản phẩm hiện đại vẫn cần được xác định dựa trên các yêu cầu thực tế — số lượng bản ghi tự nó không chứng minh rằng tính năng đó cần được chuyển sang.
Điều này minh họa rõ ràng luận điểm từ bài viết «MODX trả một cái giá kiến trúc cố định khổng lồ cho các tính năng mà hầu hết các dự án gần như không bao giờ sử dụng»: ngay cả một bảng trống cũng không có nghĩa là chi phí kiến trúc bằng không. Nếu một phân hệ tồn tại, khi làm việc với legacy, chúng ta phải tìm hiểu mô hình, các mối quan hệ, ngữ nghĩa thời gian chạy (runtime semantics) của nó và hiểu xem liệu có thể loại bỏ nó một cách an toàn hay không. Trong cơ sở dữ liệu này, hiệu ứng có thể được nhìn thấy rõ ràng theo nghĩa đen: phần lớn lược đồ mô tả các khả năng của engine và các thử nghiệm lịch sử, chứ không phải mô hình miền hiện tại của pivkarta.ru.
Thay đổi hướng thử nghiệm
Trong worklog trước, lựa chọn đầu tiên là con đường ít xâm lấn nhất: giữ nguyên MySQL hiện có làm ranh giới bền vững (persistence boundary) và kết nối API mới thông qua Knex. Sau khi xem xét lược đồ, lựa chọn này không còn tỏ ra là tối ưu một cách hiển nhiên nữa.
Giờ đây, một giả thuyết có triển vọng hơn là — tạo một CSDL sạch mới với mô hình miền tối thiểu và chỉ di chuyển sang đó dữ liệu thực sự cần thiết đã được chứng minh. Sử dụng CSDL cũ làm nguồn dữ liệu và khảo cổ học yêu cầu, nhưng không coi nó làm nền tảng vĩnh viễn cho kiến trúc mới.
Điều này làm tăng công việc ở hiện tại: tác nhân (agent) sẽ phải tìm hiểu xem trong số 250 bảng, bảng nào thực sự tham gia vào sản phẩm, bảng nào là bảng kỹ thuật của MODX/Prisma/Extras, bảng nào đại diện cho các phiên bản cũ của cùng một dữ liệu, và tính năng nào thậm chí không còn cần thiết nữa. Nhưng chính điều này lại là một bài kiểm tra brownfield tốt cho HAIH: không mang theo độ phức tạp tích lũy chỉ vì nó đã tồn tại; khôi phục các yêu cầu thực tế và xây dựng một mô hình mới tối thiểu cho chúng.
Bước hợp lý tiếp theo là xây dựng bản đồ legacy tables → các khả năng thực tế (capabilities) → cần thiết/không cần thiết → mô hình mới → di chuyển/xác minh (migration/verification), sau đó chọn kịch bản theo chiều dọc (vertical scenario) đầu tiên và chuyển nó cùng với dữ liệu theo hình thức end-to-end.
Thử nghiệm liên quan: haih.site và nhiệm vụ /tasks/cmujk0ehv0m20qw0rs14y30bw. Nhiệm vụ hiện tại: /tasks/cmqqxckd3003zp50up0dmzbld.