Hiểu về cơ sở dữ liệu SQL so với NoSQL

Cơ sở dữ liệu thực chất là gì?

Nơi để lưu trữ và truy xuất dữ liệu. Chỉ vậy thôi.

Ứng dụng của bạn có người dùng. Những người dùng đó đã đặt hàng. Những đơn hàng đó có sản phẩm.Tất cả thông tin đó cần được lưu trữ ở đâu đó và cần được trả về nhanh chóng khi bạn yêu cầu.

Nơi đó chính là một cơ sở dữ liệu.

Và đây mới là điểm thú vị. Bởi vì cơ sở dữ liệu không chỉ có một loại duy nhất.Có nhiềuloạikhác nhau được xây dựng cho các vấn đề khác nhau.Và việc chọn sai loại cơ sở dữ liệu cho dự án của bạn là loại sai lầm sẽ khiến bạn gặp rắc rối sáu tháng sau đó.

Vậy chúng ta hãy cùng xem xét từng cái một.

Loại 1: Cơ sở dữ liệu quan hệ (SQL)

Đây là phiên bản kinh điển. Phiên bản đã tồn tại từ những năm 1970 và vẫn đang vận hành hầu hết internet.

Hãy tưởng tượng một bảng tính. Có các hàng và cột. Mỗi hàng là một bản ghi, ví dụ như một người dùng, một đơn đặt hàng, một sản phẩm. Mỗi cột chứa một thông tin về bản ghi đó, chẳng hạn như tên, giá cả, ngày tháng.

Hãy tưởng tượng nhiều bảng tính có thể giao tiếp với nhau.Đó chính là cơ sở dữ liệu quan hệ.

Bạn viết một đoạn mã gọi là SQL (viết tắt của Structured Query Language) để đặt câu hỏi cho hệ thống. Ví dụ:“Hãy cho tôi tất cả các đơn đặt hàng được thực hiện trong 7 ngày qua bởi người dùng ở Mumbai.”Và hệ thống sẽ thực hiện chính xác điều đó.

Ví dụ: MySQL, PostgreSQL, SQLite

Phù hợp nhất cho:Dữ liệu có cấu trúc, ít thay đổi về hình dạng. Được sử dụng trong ngân hàng, thương mại điện tử. Bất cứ lĩnh vực nào mà dữ liệu có quy tắc và mối quan hệ rõ ràng.

Điểm mạnh của SQL là tínhnghiêm ngặt. Mỗi hàng đều tuân theo cùng một cấu trúc.Tính nghiêm ngặt đó giúp dữ liệu luôn sạch sẽ và nhất quán.

Điểm yếu là gì? Chính là sự cứng nhắc đó.Nếu dữ liệu của bạn liên tục thay đổi về hình dạng, các trường mới, cấu trúc mới, thì SQL sẽ không còn linh hoạt nữa.

Loại 2: Cơ sở dữ liệu tài liệu (NoSQL)

Giờ chúng ta đi theo hướng ngược lại.

Thay vì cấu trúc theo hàng và cột, cơ sở dữ liệu tài liệu lưu trữ dữ liệu dưới dạng tài liệu.Hãy nghĩ đến JSON. Mỗi tài liệu có thể trông hoàn toàn khác nhau. Một bản ghi người dùng có thể có 3 trường. Một bản ghi khác có thể có 15 trường. Điều đó không quan trọng.

Điều này cực kỳ hữu ích khi dữ liệu của bạn lộn xộn, thay đổi liên tục hoặc phát triển nhanh chóng. Bạn đang xây dựng một sản phẩm và mọi thứ liên tục thay đổi?Bạn không muốn phải tái cấu trúc toàn bộ cơ sở dữ liệu mỗi khi thêm một tính năng mới.

Ví dụ: MongoDB

Phù hợp nhất cho:Các ứng dụng có cấu trúc dữ liệu không cố định. Nền tảng nội dung, danh mục sản phẩm. Được sử dụng trong các công ty khởi nghiệp năng động, nơi các yêu cầu thay đổi hàng tuần.

Sự đánh đổi nằm ở tính nhất quán.Bạn có được sự linh hoạt, nhưng lại mất đi những đảm bảo chặt chẽ mà SQL mang lại. Đối với một số ứng dụng, điều đó hoàn toàn ổn. Nhưng đối với những ứng dụng khác liên quan đến tiền bạc, đó lại là một vấn đề.

Loại 3: Cơ sở dữ liệu cặp khóa-giá trị

Đây là cách đơn giản nhất.

Bạn có một khóa. Bạn có một giá trị. Bạn yêu cầu khóa, bạn nhận lại giá trị. Xong.

Hãy tưởng tượng nó giống như một cuốn từ điển hoặc phòng thay đồ. Bạn đưa số của mình cho nhân viên, họ đưa túi cho bạn.

Không có truy vấn hay cấu trúc phức tạp nào cả.Chỉ đơn giản là: hãy cho tôi thứ được gắn với khóa này.

Ví dụ: Redis

Phù hợp nhất cho:Tốc độ, bộ nhớ đệm, phiên làm việc. Những thứ bạn cần truy xuất nhanh chóng, lặp đi lặp lại.

Khi người dùng đăng nhập và bạn cần ghi nhớ thông tin của họ trên nhiều trang,phiên đăng nhập đó sẽ được lưu trữ trong Redis.Khi một trang tải rất chậm do thao tác truy cập cơ sở dữ liệu chậm,bạn sẽ lưu kết quả vào bộ nhớ cache của Redis để yêu cầu tiếp theo nhận được kết quả chỉ trong vài mili giây.

Nó không dùng để lưu trữ dữ liệu chính của bạn.Nó chỉ dùng để lưu trữ những thứ bạn cầnnhanh chóng.

Loại 4: Cơ sở dữ liệu đồ thị

Hầu hết các cơ sở dữ liệu lưu trữ dữ liệu.Cơ sở dữ liệu đồ thị lưu trữmối quan hệ giữa các dữ liệu.

Thực ra đó là một cách suy nghĩ hoàn toàn khác.

Hãy tưởng tượng một mạng xã hội. Bạn có những người dùng. Nhưng điều quan trọng không chỉ là người dùng đó là ai, mà còn là ai theo dõi ai, ai quen biết ai, ai kết nối với ai. Cácmối quan hệ mớilà điểm mấu chốt.

Trong cơ sở dữ liệu thông thường, việc tìm ra điều đó đòi hỏi các phép nối và truy vấn phức tạp, và tốc độ sẽ chậm hơn khi càng đi sâu vào chi tiết. Trong cơ sở dữ liệu đồ thị, các mối quan hệ là yếu tố chính. Việc duyệt qua các mối quan hệ đó chính là mục đích của toàn bộ hệ thống.

Ví dụ: Neo4j

Phù hợp nhất cho:Mạng xã hội, công cụ đề xuất, phát hiện gian lận. Bất cứ lĩnh vực nào mà câu hỏi đặt ra là“những thứ này được kết nối với nhau như thế nào?”

Nếu bạn đang xây dựng một thứ gì đó mà câu hỏi đặt ra là “ai đang ở cách người này 3 bước chân?”, thì đó chính là dấu hiệu dành cho bạn.

Loại 5: Cơ sở dữ liệu chuỗi thời gian

Được rồi, cái này hơi đặc biệt một chút nhưng cũng đủ thú vị để nhắc đến.

Cơ sở dữ liệu chuỗi thời gian được xây dựng đặc biệt cho dữ liệu gắn liền với thời gian.Không chỉ là dữ liệucódấu thời gian mà là dữ liệu mà thời gian là yếu tố quan trọng nhất.

Mức sử dụng CPU máy chủ mỗi giây. Nhiệt độ mỗi 5 phút. Giá cổ phiếu mỗi mili giây. Lưu lượng truy cập trang web mỗi giờ.

Về mặt kỹ thuật, các cơ sở dữ liệu thông thường có thể lưu trữ loại dữ liệu này, nhưng chúng sẽ hoạt động chậm dần sau một thời gian.Cơ sở dữ liệu chuỗi thời gian được xây dựng để ghi và đọc loại dữ liệu này với tốc độ cao.

Ví dụ: InfluxDB

Phù hợp nhất cho:Giám sát, số liệu, cảm biến IoT. Bất cứ thứ gì mà bạn muốn hỏi“điều gì đã xảy ra theo thời gian và nó đã thay đổi như thế nào?”

Đa số người mới bắt đầu sẽ không cần đến thứ này ngay lập tức. Nhưng khi cần, bạn sẽ rất vui vì biết nó tồn tại.

Hãy đơn giản hóa vấn đề này.

Tôi biết đó là rất nhiều loại.Vì vậy, đây là phiên bản tóm tắt. Hãy ghi nhớ điều này:

SQL— Dữ liệu của bạn có cấu trúc rõ ràng, cố định. Bạn cần tính nhất quán. Hãy bắt đầu từ đây trước.

MongoDB (Tài liệu)— Dữ liệu của bạn thường xuyên thay đổi hình dạng. Bạn đang làm việc nhanh chóng. Bạn cần sự linh hoạt.

Redis (Cặp khóa-giá trị)— Bạn cần nhận lại dữ liệungay lập tức. Hãy lưu vào bộ nhớ cache. Tốc độ là ưu tiên hàng đầu.

Đồ thị (Neo4j)— Mối quan hệ giữa các dữ liệu quan trọng hơn chính bản thân dữ liệu.

Dữ liệu chuỗi thời gian (InfluxDB)— Bạn đang theo dõi một thứ gì đó thay đổi liên tục theo thời gian.

Đó là tất cả những gì bạn cần hiểu. Năm loại. Năm công việc khác nhau. Mỗi công việc đều có lý do riêng.

Sai lầm mà ai cũng mắc phải

Khi nghe cụm từ “SQL vs NoSQL”, họ nghĩ đó là một cuộc cạnh tranh, một bên thắng và một bên thua.

Không phải vậy.

Các cơ sở dữ liệu này không cạnh tranh với nhau. Chúng thực hiện các chức năng khác nhau.Hầu hết các ứng dụng thực tế đều sử dụng nhiều hơn một cơ sở dữ liệu.Dữ liệu chính của bạn nằm trong PostgreSQL. Phiên làm việc của bạn nằm trong Redis. Nguồn cấp dữ liệu hoạt động của người dùng nằm trong MongoDB.

Kỹ năng nằm ở chỗ biết phương pháp nào phù hợp với vấn đề bạn đang giải quyết.

Bạn không cần phải thành thạo tất cả chúng.

Nói thật đấy. Bạn không nên làm thế.

Hãy bắt đầu với SQL. Nó có mặt ở khắp mọi nơi. Nó dạy bạn cách tư duy về dữ liệu. Hầu như mọi công ty đều sử dụng nó ở đâu đó. Hãy làm quen với nó.

Rồi khi bạn xây dựng nhiều hơn, khi các dự án của bạn trở nên phức tạp hơn, bạn sẽ tự nhiên gặp phải những lúc mà SQL không còn đáp ứng được nhu cầu. Và khi điều đó xảy ra, bạn sẽ biết mình cần tìm đến giải pháp nào. Bởi vì giờ đây bạn đã biết rằng có những lựa chọn khác.

Đó mới là toàn bộ vấn đề. Không cần phải thành thạo mọi thứ. Chỉ cần biết những gì đang tồn tại và lý do tại sao nó được tạo ra.

Lần tới khi ai đó nói “chúng tôi đang sử dụng Mongo cho việc này” hoặc “chúng tôi lưu trữ dữ liệu đó trong Redis”, bạn đã biết lý do rồi.

Nguồn