Hiện nay, các loại database NoSQL, thường được gọi bằng cái tên cơ sơ dữ liệu phi quan hệ, xuất hiện nhiều và được nhiều developer ưa chuộng. Tuy nhiên, vẫn có nhiều trường hợp NoSQL không được sử dụng đúng mục đích và vô tình tạo ra gánh nặng kỹ thuật không cần thiết.
Dùng NoSQL cho mục đích lưu trữ các transaction mà bản chất là RDBMS
Một sai lầm phổ biến là đem NoSQL dùng cho các bài toán vốn dĩ thuộc về quan hệ, ví dụ như lưu trữ các giao dịch (transaction), đơn hàng, hay thông tin kế toán.
Những dữ liệu này thường đòi hỏi tính toàn vẹn, nhất quán, và khả năng truy xuất bằng quan hệ giữa nhiều bảng (JOIN). Việc cố gắng mô phỏng lại các quan hệ này bằng NoSQL hoàn toàn khả thi, nhưng vừa tốn công hơn, tốn thời gian hơn, vừa khó kiểm soát về mặt logic.
NoSQL có thể linh hoạt hơn trong việc lưu trữ các cấu trúc dữ liệu dạng lồng ghép (nested) và công nhận là nó tiện thật, nhưng đổi lại bạn phải chấp nhận tự xử lý các vấn đề về quan hệ và đồng nhất dữ liệu mà trước giờ RDBMS đã làm giúp bạn. Nếu team không có đủ kinh nghiệm hoặc discipline, việc dữ liệu trở nên rối loạn, trùng lặp và khó truy vấn là chuyện sớm muộn. Một ví dụ rất đơn giản, cùng 1 field “price” nhưng nếu bạn lưu giá trị trong 1 document là 1.0, một document khác bạn lại lưu “1.0” (có thể vì bug của developer chẳng hạn) thì mọi chuyện đã phức tạp hơn rồi.
Cẩn thận với các normal form
Khi học về các loại normal form để đảm bảo tính đồng nhất của dữ liệu, bạn thường được dạy rằng chỉ nên lưu một dữ liệu tại một nơi. Ví dụ, tên sản phẩm chỉ nên có ở một bảng, để khi cần chỉnh sửa thì chỉ sửa một chỗ duy nhất.
Nói cho ngay thì các hệ thống NoSQL vẫn có thể làm tốt chuyện này, tuy nhiên trong thực tế, nếu developer không quản lý cẩn thận hoặc “code ẩu”, thì rất dễ xảy ra tình trạng lưu thông tin lặp lại ở nhiều nơi — chỉ vì nó tiện, hoặc vì “lưu thẳng object vào NoSQL cho nhanh”.
Không phải lúc nào cũng cần normalize, ví dụ khi bạn cần denormalize có chủ đích để tăng tốc độ truy xuất, nhưng điều quan trọng là phải hiểu rõ trade-off: bạn đang đánh đổi hiệu năng lấy tính toàn vẹn. Nếu không có quy trình cập nhật đồng bộ, dữ liệu sẽ sớm mất nhất quán.
Khó JOIN khi cần phức tạp
Hầu hết các giải pháp NoSQL hiện nay đều đã hỗ trợ các thao tác tương tự JOIN, thông qua lookup hoặc aggregation pipeline. Tuy nhiên, tính tiện lợi và linh hoạt vẫn chưa thể so với SQL truyền thống, đặc biệt là khi SQL ngày nay không chỉ được sử dụng bởi lập trình viên mà còn bởi các phòng ban khác, ví dụ phòng phân tích dữ liệu, phòng tài chính, phòng marketing... Nếu ở quy mô nhỏ, đôi khi việc không hỗ trợ sẵn SQL làm cho mọi thứ mất thời gian, còn nếu đúng chuẩn thì kéo hết về data warehouse rồi phân tích bên đó, nhưng thực tế không phải công ty nào cũng đủ nguồn lực, hoặc biết cách để xử lý vấn đề này. Nếu quy mô rất nhỏ hoặc vừa vừa, một câu SQL để lấy data thẳng ra làm báo cáo từ một database slave có khi đã đáp ứng được yêu cầu của bên kinh doanh rồi mà.
RDBMS được sinh ra để làm việc với dữ liệu quan hệ, nên các phép JOIN phức tạp, truy vấn nhiều tầng, hoặc phân tích dữ liệu tổng hợp thường dễ dàng và hiệu quả hơn.
Còn với NoSQL, càng nhiều quan hệ thì schema của bạn càng trở nên khó bảo trì, và hiệu năng có thể giảm nhanh chóng nếu không tối ưu cẩn thận.
Tóm lại, công cụ nào phù hợp với việc nào thì nên dùng đúng chỗ, đừng cố ép NoSQL vào những bài toán không dành cho nó.
Không phải công cụ phân tích nào cũng hỗ trợ tốt cho NoSQL
Một điểm thường bị bỏ qua là hệ sinh thái xung quanh NoSQL chưa phong phú bằng các hệ RDBMS lâu đời khi nói về công cụ để phân tích, khai phá dữ liệu.
Nhiều công cụ báo cáo, phân tích, ETL, hoặc BI vẫn tối ưu cho SQL hơn là NoSQL. Việc tích hợp, migrate, hoặc phân quyền phức tạp đôi khi trở thành một rào cản lớn khi bạn muốn mở rộng hệ thống.
Nếu bạn chọn NoSQL chỉ vì “nghe nói scale tốt” mà không có nhu cầu thật sự về scale, hoặc không có đủ hạ tầng để tận dụng lợi thế đó hoặc không có nhân sự để thực hiện một cách bài bản, thì có thể bạn đang tự thêm rào cản kỹ thuật mà không cần thiết.
Vài dòng kết bài
Hãy chọn database dựa trên mô hình dữ liệu và nhu cầu kinh doanh thực tế, chứ không phải theo xu hướng. NoSQL, RDBMS, hay thậm chí graph database — mỗi loại đều có thế mạnh riêng. Việc của bạn là hiểu rõ bản chất bài toán và chọn công cụ giúp bạn giải quyết nó gọn gàng nhất, thay vì chọn thứ đang “hot” nhất.