Trả lời ngắn: MongoDB Compass hữu ích nhất ở chỗ ít người nghĩ tới — nó cho bạn thấy dữ liệu thật đang có hình dạng gì, điều rất quan trọng với cơ sở dữ liệu không ràng buộc cấu trúc.
Phạm vi: chỉ dùng cho một hệ duy nhất, không phải công cụ đa năng.
Vì sao cần nhìn thấy hình dạng dữ liệu?
Với cơ sở dữ liệu quan hệ truyền thống, mỗi bảng có cấu trúc cố định: bạn khai báo trước có những cột nào, kiểu gì, và hệ thống từ chối mọi dữ liệu không khớp.
Hệ phi quan hệ hoạt động khác. Mỗi bản ghi tự mang cấu trúc riêng, và bạn thêm trường mới bất cứ lúc nào mà không phải khai báo gì.
Đó là ưu điểm khi phát triển nhanh, nhưng sau một hai năm nó tạo ra một vấn đề thật: không ai còn biết chắc dữ liệu trong đó có hình dạng gì.
Có bản ghi cũ thiếu trường mới thêm, có bản ghi lưu ngày tháng dưới dạng chuỗi trong khi bản ghi khác lưu dạng thời gian, có trường bị viết sai chính tả từ một đợt cập nhật nào đó.
MongoDB Compass làm được gì?
| Việc | Mức độ | Ghi chú |
|---|---|---|
| Phân tích và hiển thị hình dạng dữ liệu thật | Tốt nhất | Tính năng giá trị nhất |
| Duyệt và sửa từng bản ghi trực quan | Rất tốt | Dễ hơn nhiều so với gõ lệnh |
| Phân tích câu truy vấn chạy chậm | Rất tốt | Chỉ ra chỗ thiếu chỉ mục |
| Dựng chuỗi xử lý dữ liệu nhiều bước bằng giao diện | Rất tốt | Xem kết quả từng bước |
| Quản lý chỉ mục | Tốt | Tạo và xoá thuận tiện |
| Miễn phí | Tốt | Không giới hạn tính năng chính |
| Chỉ dùng được cho một hệ duy nhất | Kém | Không thay được công cụ đa năng |
| Tiêu tốn tài nguyên | Khá | Khá nặng với một công cụ quản trị |
| Thao tác hàng loạt trên nhiều bản ghi | Khá | Vẫn nên dùng dòng lệnh |
Ai nên dùng MongoDB Compass?
- Đội đang dùng hệ cơ sở dữ liệu phi quan hệ này — công cụ chính thức nên hợp nhất.
- Người tiếp nhận một hệ thống có sẵn — nhìn hình dạng dữ liệu để hiểu nhanh.
- Ai cần tối ưu câu truy vấn chậm — công cụ phân tích chỉ rõ nguyên nhân.
- Người mới học hệ này — thấy được kết quả từng bước xử lý.
Không phù hợp nếu bạn làm việc với nhiều loại cơ sở dữ liệu — DBeaver gom tất cả vào một giao diện.
Tính năng phân tích hình dạng dữ liệu dùng vào việc gì?
Đây là thứ nên mở ra đầu tiên khi bạn tiếp xúc với một hệ thống lạ.
| Tình huống | Nó cho bạn biết gì |
|---|---|
| Nhận bàn giao hệ thống từ đội cũ | Cấu trúc thật, thường khác tài liệu |
| Nghi ngờ dữ liệu bị lẫn kiểu | Tỷ lệ bản ghi lưu chuỗi thay vì số hay ngày |
| Chuẩn bị đổi cấu trúc dữ liệu | Bao nhiêu bản ghi cũ sẽ bị ảnh hưởng |
| Tìm trường bị viết sai chính tả | Trường lạ chỉ xuất hiện ở vài phần trăm bản ghi |
| Ước lượng dung lượng theo từng trường | Trường nào đang chiếm nhiều chỗ nhất |
| Kiểm tra dữ liệu sau một đợt nhập lớn | Có bản ghi nào lệch khỏi khuôn mẫu không |
Quy trình tìm hiểu một hệ thống lạ
- Liệt kê các tập dữ liệu và ước lượng kích thước (30 phút) — Biết đâu là phần quan trọng.
- Chạy phân tích hình dạng cho từng tập lớn (2 giờ) — Đây là bước cho nhiều thông tin nhất.
- Ghi lại các trường lệch khuôn và tỷ lệ của chúng (1 giờ) — Danh sách nợ kỹ thuật.
- Xem danh sách chỉ mục hiện có (30 phút) — Suy ra được truy vấn nào hay chạy.
- Đối chiếu với tài liệu đội cũ để lại (2 giờ) — Khác biệt là điều đáng chú ý nhất.
- Viết lại tài liệu theo dữ liệu thật (1 ngày) — Bàn giao cho người sau.
Vì sao danh sách chỉ mục lại tiết lộ nhiều đến vậy?
Đây là mẹo đọc hệ thống mà người có kinh nghiệm hay dùng khi tiếp nhận dự án không có tài liệu.
Chỉ mục là cấu trúc phụ được tạo ra để một loại truy vấn cụ thể chạy nhanh. Không ai tạo chỉ mục cho vui, vì nó tốn dung lượng và làm chậm việc ghi dữ liệu.
Vì vậy mỗi chỉ mục là một dấu vết: nó nói cho bạn biết đội trước đã tối ưu cho truy vấn nào, tức là chức năng nào của hệ thống được dùng nhiều nhất.
Một chỉ mục trên trường ngày tạo kèm trạng thái gợi ý rằng có một màn hình lọc đơn hàng theo trạng thái và sắp xếp theo thời gian. Đọc danh sách chỉ mục trong ba mươi phút cho bạn bản đồ nghiệp vụ nhanh hơn nhiều so với đọc mã nguồn.
Hạn chế cần biết
Chỉ dùng được cho một hệ cơ sở dữ liệu
Không thay thế công cụ đa năng khi bạn làm nhiều hệ.
Khá nặng so với một công cụ quản trị
Mở nhiều kết nối cùng lúc sẽ thấy rõ.
Thao tác hàng loạt vẫn nên dùng dòng lệnh
Giao diện không phù hợp với việc sửa hàng nghìn bản ghi.
Phân tích hình dạng chậm với tập dữ liệu rất lớn
Nó phải quét mẫu nên cần thời gian.
Không có công cụ so sánh giữa hai môi trường
Phải tự đối chiếu bằng cách khác.
MongoDB Compass so với các cách khác
| Tiêu chí | MongoDB Compass | DBeaver | Dòng lệnh của hệ |
|---|---|---|---|
| Phân tích hình dạng dữ liệu | Tốt nhất | Kém | Kém |
| Số loại cơ sở dữ liệu hỗ trợ | Kém | Tốt nhất | Kém |
| Dựng chuỗi xử lý nhiều bước | Tốt nhất | Khá | Tốt |
| Thao tác hàng loạt | Khá | Tốt | Tốt nhất |
| Chi phí | Miễn phí | Miễn phí | Miễn phí |
| Dùng được trên máy chủ không có giao diện | Không | Không | Có |
Xem thêm đánh giá DBeaver, đánh giá Docker, đánh giá Postman, hoặc duyệt nhóm công cụ lập trình.
Kết luận
MongoDB Compass là công cụ nên có nếu đội bạn đang dùng hệ cơ sở dữ liệu này ở mức nghiêm túc.
Tính năng đáng tiền nhất lại là thứ ít được quảng bá: khả năng cho bạn thấy dữ liệu thật đang có hình dạng gì, chứ không phải hình dạng bạn tưởng nó có.
Hãy chạy phân tích đó trước mỗi lần định thay đổi cấu trúc dữ liệu. Nửa giờ xem trước rẻ hơn rất nhiều so với việc khắc phục hậu quả sau khi bản chuyển đổi đã chạy.
