- Infisical đã tăng trưởng nhanh thành một nền tảng xử lý hơn 50 triệu Secret mỗi ngày
- Khi mức sử dụng tăng lên, họ phải liên tục nâng cấp stack, và gần đây đã tiến hành di chuyển toàn bộ cơ sở dữ liệu từ MongoDB sang PostgreSQL
- Quá trình di chuyển này bao gồm nhiều bước phức tạp như áp dụng công nghệ mới, tạo schema cơ sở dữ liệu, tái cấu trúc logic, viết lại truy vấn, và chuyển hàng triệu (hoặc hàng tỷ) bản ghi dữ liệu sang PostgreSQL
Giai đoạn bắt đầu
- Khi mới xây dựng Infisical, nhóm đã chọn MongoDB + Mongoose ORM vì đây là stack mà họ quen thuộc nhất
- Ở giai đoạn đầu, họ tập trung nhiều hơn vào Infisical Cloud, dịch vụ SaaS được quản lý, và không kỳ vọng nhiều người dùng sẽ tự self-host sản phẩm
Vì sao không phải MongoDB?
- MongoDB hoạt động tốt ở thời gian đầu, nhưng khi các trường hợp sử dụng của sản phẩm vượt ra ngoài dịch vụ được quản lý, các nhược điểm bắt đầu bộc lộ
- Nhiều tổ chức thích tự self-host Infisical thay vì dùng Infisical Cloud, và một số cần đáp ứng các yêu cầu on-premise
- Do các giới hạn và vấn đề về tính dễ sử dụng của MongoDB, họ quyết định chuyển sang PostgreSQL
Vì sao chọn PostgreSQL?
- Khi tìm một cơ sở dữ liệu mới, các yếu tố quan trọng được cân nhắc gồm khả năng quản trị dễ dàng, hỗ trợ transaction và các tính năng quan hệ
- Họ đã cân nhắc giữa giải pháp lưu trữ nội bộ và giải pháp lưu trữ bên ngoài, nhưng cuối cùng chọn PostgreSQL
- PostgreSQL có cộng đồng năng động, tài liệu phong phú, nhiều giải pháp và phần mở rộng, đồng thời hầu hết các nhà cung cấp cloud đều có dịch vụ managed
Về ORM
- Sau khi chọn PostgreSQL, họ cần quyết định cách ứng dụng sẽ tương tác với cơ sở dữ liệu
- Họ tìm một công cụ mang lại trải nghiệm tương tự Mongoose ORM và quyết định dùng query builder Knex.js
- Knex.js cung cấp công cụ seeding và migration; kết hợp với phần tích hợp Zod tùy chỉnh để hỗ trợ TypeScript, họ đã đạt được mức độ hài lòng
Kế hoạch migration
- Khi việc viết lại mã gần hoàn tất, họ bắt đầu tính toán cách thực hiện migration để ánh xạ dữ liệu MongoDB sang PostgreSQL với mức gián đoạn tối thiểu
- Với Infisical, một hệ thống đóng vai trò trong hạ tầng quan trọng, downtime là điều không thể chấp nhận, nên họ thỏa hiệp bằng cách chặn thao tác ghi trong thời gian migration
Cuộc đại di chuyển
- Để chuẩn bị cho migration, họ lập checklist chi tiết và khung thời gian dự kiến
- Quá trình migration được thực hiện trong 6 giờ chỉ cho phép thao tác đọc, sau đó chuyển DNS sang instance mới sau khi việc di chuyển dữ liệu hoàn tất
Kết quả
- Migration diễn ra suôn sẻ, không mất dữ liệu, và một số lỗi tính năng có tác động tối thiểu đến khách hàng đã được sửa trong vòng 36 giờ
- Nền tảng ghi nhận hiệu năng cải thiện nhờ tối ưu truy vấn bằng join, đồng thời chi phí cơ sở dữ liệu cũng giảm 50%
- Việc áp dụng PostgreSQL giúp cải thiện kiểm tra tính hợp lệ của dữ liệu, và giờ đây việc self-host Infisical trở nên dễ dàng hơn nhiều
Kết luận
- Quyết định chuyển từ MongoDB sang PostgreSQL không hề dễ dàng; họ đã mất 3-4 tháng với nhiều kế hoạch và thảo luận cẩn trọng
- Họ khuyến nghị nên suy nghĩ thật sâu về trường hợp sử dụng và cách triển khai trước khi thử một dự án lớn như vậy
1 bình luận
Ý kiến Hacker News
Một người dùng có kinh nghiệm vận hành Postgres và MongoDB ở quy mô lớn cho biết họ thích cả hai cơ sở dữ liệu, nhưng không thể hiểu nổi việc Postgres thiếu hỗ trợ sẵn có cho tính sẵn sàng cao (HA) và mở rộng theo chiều ngang. Họ chỉ ra rằng mỗi lần triển khai Postgres đều mang tính đặc thù riêng và phải dùng nhiều tiện ích mở rộng cùng script để bù đắp. Họ nói thêm rằng những tiện ích mở rộng này thường nhiều lỗi và tài liệu kém. Họ cũng đề cập rằng việc thay đổi định dạng tệp giữa các phiên bản chính của Postgres khiến quá trình nâng cấp trở nên rất khó khăn. Họ ngạc nhiên khi MySQL vượt trội hơn Postgres rất nhiều ở HA/sharding.
Chia sẻ một bài blog mô tả quá trình di chuyển từ MongoDB sang PostgreSQL dưới góc độ kỹ thuật. Người này nói bài viết đó có ví dụ và biểu đồ, mang tính kỹ thuật nhiều hơn và ít thiên về khía cạnh kinh doanh hơn.
Một người dùng nói rằng PostgreSQL đang thống trị thế giới cơ sở dữ liệu, đồng thời chỉ ra rằng các tác giả ngay từ đầu đã chọn một kiến trúc không phù hợp với mô hình dữ liệu. Họ nhận xét rằng đưa dữ liệu quan hệ vào một kho lưu trữ phi quan hệ thì sớm muộn cũng gây ra vấn đề.
Chỉ ra mâu thuẫn giữa câu nói rằng việc chọn MongoDB và Mongoose ORM là quyết định tối ưu để tăng tốc phát triển tính năng, với câu dùng trích dẫn của Tony Hoare: "tối ưu hóa quá sớm là cội nguồn của mọi điều xấu" để biện minh cho lựa chọn đó.
Một người dùng cho rằng cơ sở dữ liệu tài liệu không phù hợp với các dự án mới, dự đoán chi phí giấy phép và chi phí lưu trữ của MongoDB sẽ tăng lên trong khi việc phát triển tính năng sẽ chững lại.
Một người từng chuyển sang Postgres vì các vấn đề do MongoDB gây ra cho biết họ rất hài lòng với quyết định đó. Họ nói thêm rằng việc MongoDB dùng JavaScript thay vì SQL là điều bất tiện.
Một người chỉ ra rằng bài viết đã bỏ sót việc thảo luận về những vấn đề phát sinh trong quá trình rewrite thực tế, và đặt câu hỏi liệu các truy vấn có được chuyển đổi tương đương hay không, sản phẩm đã được tổ chức như thế nào để có thể đọc và ghi trên cả hai cơ sở dữ liệu, có phát hiện lỗi nào trong lúc migration không, và liệu có thể chuyển các truy vấn theo kiểu 1:1 hay không.
Một người từng dùng MongoDB nói rằng cơ sở dữ liệu tài liệu phù hợp với một số trường hợp sử dụng, nhưng khi nhận ra cần phải dùng Mongoose thì nên cân nhắc chuyển sang cơ sở dữ liệu quan hệ. Họ khuyên rằng trong đa số trường hợp, Mongoose là thứ phải bổ sung cho một dự án có sẵn, còn nếu ngay từ đầu đã cần nó thì nên dùng cơ sở dữ liệu quan hệ.
Một người tiếp quản một dự án dùng MongoDB cho biết định dạng BSON không tốt, nhưng họ thích việc có thể dùng cùng một schema từ JSON API cho tới cơ sở dữ liệu. Họ nói thêm điều này phù hợp với lập trình hướng dữ liệu trong Go và Rust. Họ kết luận MongoDB chỉ thực sự phù hợp cho các tác vụ thiên về đọc, và với khối lượng ghi lớn thì MongoDB không giúp ích nhiều.
Một người nói rằng lý do chính để chuyển sang PostgreSQL là vấn đề giấy phép hơn là lý do kỹ thuật, đồng thời chia sẻ rằng họ đã thấy hiệu năng được cải thiện nhờ tối ưu hóa truy vấn bằng join. Họ cho biết dữ liệu không được mô hình hóa theo cách phù hợp với kho khóa-giá trị, nên việc chuyển sang đúng loại kho lưu trữ mới là lý do mang tính quyết định.