Postgres vs MongoDB cho ứng dụng giao dịch B2B ở quy mô 1M+ bản ghi
Sản phẩm B2B của bạn đã đạt product-market fit từ năm ngoái. Hôm nay bạn có 1.2 triệu bản ghi trong cơ sở dữ liệu chính, thời gian phản hồi đang bò qua mức 400ms vào giờ cao điểm, và hóa đơn hạ tầng của bạn vừa tăng gấp đôi. Trước khi bạn dành thêm một quý nữa để tinh chỉnh sai engine, đáng để tự hỏi liệu ngay từ đầu bạn đã chọn đúng cơ sở dữ liệu chưa, hay việc chuyển đổi bây giờ rẻ hơn thêm một năm nữa dùng các giải pháp chắp vá.
Chỗ mà "cứ chọn đại một cái" âm thầm đổ vỡ
Cuộc tranh luận Postgres và MongoDB đã cũ, nhưng phần lớn đội ngũ vẫn ra quyết định dựa trên cảm tính. Ai đó trong đội biết Postgres, hoặc tutorial dùng MongoDB, thế là nó trở thành mặc định. Lựa chọn đó vô hình trong vài trăm nghìn bản ghi đầu tiên. Vượt qua một triệu dòng và vài nghìn người dùng đồng thời, cái giá của lựa chọn sai bắt đầu lộ diện dưới dạng dashboard chậm, những cuối tuần chữa cháy, và các đề xuất tái kiến trúc đắt đỏ từ trưởng nhóm kỹ thuật của bạn.
Cả hai engine đều xuất sắc. Cả hai đều vận hành các workload production khổng lồ. Nhưng chúng tối ưu cho các dạng dữ liệu khác nhau và các bảo đảm khác nhau, và ứng dụng giao dịch B2B đè áp lực đúng vào những trục mà hai bên phân kỳ. Bốn đánh đổi quan trọng nhất cho lớp ứng dụng này là: tính nhất quán, độ trễ truy vấn ở quy mô lớn, chi phí sở hữu, và chi phí thay đổi.
Tính nhất quán là rủi ro kinh doanh, không phải sở thích
Đối với một hệ thống giao dịch B2B (hóa đơn, đơn hàng, hợp đồng, tồn kho, bảng lương) mô hình nhất quán mặc định của cơ sở dữ liệu không phải là câu hỏi về khẩu vị. Đó là rủi ro kinh doanh sẽ xuất hiện trên P&L của bạn khi nó thất bại.
Postgres là một engine quan hệ trưởng thành với bảo đảm ACID mạnh, khóa ngoại thực sự, và mức cô lập serializable có sẵn ngay từ đầu. Khi service tính hóa đơn của bạn commit một hóa đơn, bạn có thể bảo đảm rằng các dòng chi tiết tương ứng tồn tại, rằng khoản tín dụng của khách hàng đã được trừ một cách nguyên tử, và rằng một lượt đọc đồng thời không thể thấy một lượt ghi dang dở. Đối với các quy trình liên quan đến tài chính, sự đúng đắn này đáng để trả tiền.
MongoDB đã thu hẹp phần lớn khoảng cách đó. Giao dịch ACID đa tài liệu đã sẵn sàng cho production kể từ 4.0, và các lượt ghi đơn tài liệu luôn nguyên tử. Nhưng mặc định vẫn nghiêng về tính sẵn sàng và schema linh hoạt hơn là tính đúng đắn nghiêm ngặt. Giao dịch đa tài liệu mang một chi phí hiệu năng đo được, index phải được duy trì có chủ đích, và schema drift có thể ẩn mình cho đến khi một báo cáo sai lộ ra trước mặt khách hàng.
Đánh đổi kỹ thuật ánh xạ trực tiếp sang rủi ro kinh doanh. Nếu một con số sai trong báo cáo hướng tới khách hàng có thể khiến bạn mất một khách, hãy ưu tiên cơ sở dữ liệu ép buộc tính đúng đắn theo mặc định. Nếu workload của bạn chủ yếu là telemetry chỉ ghi thêm hoặc nội dung do người dùng tạo mà nhất quán cuối cùng là chấp nhận được, ràng buộc này ít quan trọng hơn.
Độ trễ ở mức 1M+ bản ghi
Cả hai engine đều mở rộng vượt xa một triệu bản ghi. Khác biệt thực sự là bạn phải làm bao nhiêu công việc để giữ chúng nhanh.
Postgres thắng ở mẫu đọc "nhàm chán": tập kết quả có giới hạn, join có index, các truy vấn định dạng tốt với bộ lọc dự đoán được. Một bảng Postgres được index đúng cách phục vụ point lookup ở đơn vị mili-giây một chữ số cho đến hàng trăm triệu dòng, và query planner thường có thể phục hồi từ một truy vấn viết kém. Nơi Postgres vật lộn là đọc tài liệu không có giới hạn, các cấu trúc lồng nhau bị phi chuẩn hóa sâu, và workload với schema thay đổi thất thường.
MongoDB thắng khi mẫu truy cập của bạn thực sự có hình dạng tài liệu: một truy vấn trả về một đối tượng lồng nhau ánh xạ gọn gàng sang phản hồi API, không có join trong đường dẫn nóng. Điều đó loại bỏ các vòng đi mạng và chi phí tuần tự hóa. Điều oái oăm là điều này chỉ đúng nếu bạn thiết kế đúng ranh giới tài liệu ngay từ ngày đầu. Khi các ranh giới đó sai (và chúng thường sai, vì các quyết định sản phẩm sớm chỉ là phỏng đoán) bạn kết thúc với các lượt lookup chéo collection mà MongoDB chưa bao giờ được tối ưu cho, và độ trễ suy giảm nhanh hơn so với một join Postgres tương đương.
Đối với một ứng dụng B2B có dashboard, danh sách lọc được, và báo cáo phân tích chồng lên trên dữ liệu giao dịch, Postgres gần như luôn thắng cuộc đấu về độ trễ trung vị ở mức 1M+ bản ghi.
Bức tranh chi phí thực sự
Các trang giá của cloud khiến Postgres và MongoDB trông giống nhau. Chi phí sở hữu thực tế thì không.
Postgres là một mặt hàng phổ thông. Mọi cloud lớn đều cung cấp dịch vụ được quản lý, rất nhiều kỹ sư biết cách tinh chỉnh nó, và Postgres mã nguồn mở chạy trong production giống hệt như trên laptop. Khi có sự cố lúc 2 giờ sáng, bạn có thể tìm ra câu trả lời.
MongoDB được quản lý thì tiện lợi nhưng có giá cao khi bạn bước vào các cluster chuyên dụng có backup, VPC peering, và ghi log kiểm toán. Tự host MongoDB là khả thi nhưng đòi hỏi kỹ năng vận hành hiếm hơn và đắt hơn so với kỹ năng vận hành Postgres trong thị trường hiện tại.
Chi phí lớn hơn là chi phí bậc hai: bao nhiêu giờ kỹ sư mỗi năm đổ vào di trú schema, tinh chỉnh index, và chữa cháy? Các đội chúng tôi làm việc cùng thường xuyên đánh giá thấp con số này từ ba đến năm lần. Một cơ sở dữ liệu tiết kiệm cho đội của bạn hai tuần công kỹ sư mỗi quý sẽ tự trả lại nhiều lần giá trị của nó, bất kể mức giá niêm yết trên hóa đơn.
Khi nào mỗi engine thực sự thắng
Chọn Postgres khi dữ liệu của bạn tự nhiên là dạng quan hệ (khách hàng, đơn hàng, hóa đơn, dòng chi tiết), khi bạn cần nhất quán mạnh và toàn vẹn tham chiếu thực sự, khi đội của bạn nhỏ và không đủ sức nuôi một chuyên gia cơ sở dữ liệu, hoặc khi các lượt đọc phân tích và dashboard sống cùng hệ thống với các lượt ghi.
Chọn MongoDB khi tài liệu của bạn thực sự lồng nhau và ít khi được join (catalog sản phẩm, nội dung CMS, payload sự kiện khối lượng lớn), khi bạn cần mở rộng ghi theo chiều ngang xuyên nhiều vùng và chấp nhận được nhất quán cuối cùng, khi schema của bạn tiến hóa nhanh và bạn coi trọng linh hoạt hơn là ép buộc, hoặc khi bạn đã có sẵn chuyên môn vận hành để chạy nó tốt.
Đối với hầu hết ứng dụng giao dịch B2B, một sự tự đánh giá trung thực sẽ đáp xuống Postgres. Điều đó không có nghĩa MongoDB sai. Nó có nghĩa mặc định phải được kiếm được bằng hình dạng của workload, không phải bằng sự quen thuộc của đội.
Một lộ trình thực dụng nếu bạn đã ở production
Nếu bạn đã ở production trên engine sai, đừng di trú trong hoảng loạn. Viết lại là cách đắt nhất để giải quyết một vấn đề cơ sở dữ liệu. Hãy bắt đầu bằng cách đo lường: profile mười truy vấn chậm nhất của bạn, tính toán chi phí hàng năm của các gánh nặng vận hành bạn đang gánh chịu, và định giá một cuộc di trú có mục tiêu cho hai hoặc ba workload nóng nhất so với chi phí giữ nguyên hiện trạng.
Đôi khi câu trả lời đúng là kết hợp. Giữ hệ thống hiện tại cho những gì nó làm tốt, và chỉ giới thiệu Postgres hoặc MongoDB song song với nó cho các workload mà engine kia thực sự phù hợp hơn. Đó là một canh bạc nhỏ hơn, kiểm nghiệm được so với viết lại toàn bộ, và nó cho phép bạn xác thực giả định trước khi cam kết toàn bộ sản phẩm cho nó.
Cơ sở dữ liệu bạn chọn ở mức 10,000 bản ghi hiếm khi là cơ sở dữ liệu đúng ở mức 10 triệu. Các đội tránh được những cuộc chuyển nền tảng đau đớn là những đội xem xét lại lựa chọn theo lịch trình chứ không phải khi có hỏa hoạn. Nếu sản phẩm của bạn đang tiến gần đến quy mô đó và bạn muốn một ý kiến thứ hai có kinh nghiệm về kiến trúc, đội kỹ sư MerkTechs sẵn lòng ngồi xuống với CTO của bạn và đi qua các đánh đổi dựa trên workload thực tế của bạn trước khi hóa đơn scaling tiếp theo đáp xuống.