So sánh data sql với mongodb

Cơ sở dữ liệu NoSQL đang ngày càng trở nên phổ biến và được sử dụng nhiều hơn bao giờ hết, một ví dụ điển hình là MongoDB. Tuy nhiên, trong một vài trường hợp chúng ta sẽ vẫn cần đến sức mạnh đến từ cơ sở dữ liệu SQL. Điểm khác biệt chính giữa hai cơ sở dữ liệu này là gì? Làm sao để chọn được sơ sở dữ liệu phù hợp cho ứng dụng mà bạn sắp bắt tay vào xây dựng? Cùng tham khảo bài viết dưới đây nhé!

Sự khác biệt giữa SQL và NoSQL

Trong cơ sở dữ liệu MongoDB (một loại NoSQL), dữ liệu của chúng ta được lưu dưới dạng JSON, trong khi đó các cơ sở dữ liệu SQL được lưu dựa trên cấu trúc bảng và mối quan hệ giữa chúng.

NoSQL có gì nổi bật?

Việc thêm và truy xuất dữ liệu đơn giản hơn

Cơ sở dữ liệu SQL khi thêm vào một đối tượng dữ liệu mới bạn cần quan tấm đến mối quan hệ giữa dữ liệu đó với dữ liệu ở các bảng khác có liên quan (có thể là ghi thêm/sử đổi dữ liệu trên một bảng khác nếu cần). Còn đối với NoSQL các thông tin liên quan được lưu trữ trong cùng một block làm cho việc chèn thêm được dễ dàng hơn.

Lược đồ linh hoạt

Đảm bảo tính nhất quán dữ liệu trong SQL là một công việc hết sức khó khăn. Khi chúng ta thêm một thuộc tính mới vào một bảng nào đó trên lược đồ dã xây dựng trước, ta phải thực hiện thêm thuộc tính mới đó vào toàn bộ các dòng của bảng dữ liệu, kể cả các dữ liệu cũ. Còn với NoSQL bạn hoàn toàn có thể quyết định việc thuộc tính mới đó chỉ áp dụng cho các dữ liệu mới vừa tạo.

Khả năng mở rộng

Với SQL database chúng ta cần sử dụng kỹ thuật sharding để cải thiện tốc độ truy vấn cũng như khả năng mở rộng. Sharding là một kỹ thuật chia nhỏ lượng dữ liệu lưu trữ thành từng nhóm nhỏ dựa trên các thuộc tính. Còn NoSQL các kỹ thuật chia dữ liệu này được xây dựng sẵn cho việc mở rộng dữ liệu lưu trữ - "build for scale".

Khả năng phân tích

Các cơ dở dữ liệu NoSQL cung cấp một khả năng tìm các số liệu dễ dàng hơn.

Còn SQL thì sao?

Cập nhật nhanh chóng

Nếu như dữ liệu của bạn thường xuyên được cập nhật thì NoSQL không hẳn là một sự lựa chọn tốt. Bởi, cơ sở dữ liệu NoSQL cần xem qua toàn bộ block trước khi tìm đến đúng thuộc tính mà chúng ta muốn chỉnh sửa, trong khi đó với SQL chúng ta có thể duyệt đến trực tiếp thông qua cột của các bảng.

Tính nhất quán

Dữ liệu lưu trong NoSQL có thể trùng lắp, có cùng cả key-value nhưng SQL có cơ chế khóa chính giúp đảm bảo dữ liệu là duy nhất cho mỗi dòng. Nhất quán dữ liệu cũng là một vấn đề của NoSQL, các tính chất đặc trưng của SQL là ACID (Atomicity, Consistency, Isolation, Durability) cũng khó để áp dụng hoàn hảo trong NoSQL. Vì thế, NoSQL thường không được sử dụng trong các hệ thống tài chính.

Tốc độ đọc ổn định

Đối với cơ sở dữ liệu hướng tài liệu như MongoDB thì việc đọc một thuộc tính cần có giai đoạn duyệt qua cả Block để tìm. Còn SQL có thể duyệt đến trực tiếp thông qua cột dữ liệu.

Quan hệ giữa các bảng dữ liệu

Với cơ sở dữ liệu quan hệ như MySQL chúng ta biết được các bảng khác nhau có mối quan hệ như thế nào thông qua các ràng buộc toàn vẹn tương ứng đối với dữ liệu trong một bảng hoặc giữa các bảng.

Không có gì là hoàn hảo cho mọi trường hợp cả, thể nên chúng ta cần quyết định dựa trên thực tế rằng ứng dụng của bạn đang cần điều gì? Nếu là một ứng dụng cần đến khả năng mở rộng đề chứa được nhiều dữ liệu mà việc cập nhật dữ liệu đó là rất ít so với ghi thêm thì NoSQL là một sự lựa chọn tốt. Nếu dữ liệu của bạn cần phải cập nhật thường xuyên và phải tuân theo một ràng buộc về quan hệ nào đó thì SQL chính là thứ mà bạn nên cân nhắc. Hãy phân tích những điều mà ứng dụng của bạn đang cần, so sánh với các ưu điểm của từng loại cơ sở dữ liệu để có thể đưa ra lựa chọn hợp lý nhé!

Kể từ khi máy tính chào đời, chúng ta đã chứng kiến sự phát triển về khối lượng data, đòi hỏi công nghệ lưu trữ data, xử lí và phân tích cũng phải được nâng tầm theo. Trong thập kỉ vừa qua, software developer xem SQL như là một di tích khi không thể theo kịp tốc độ phát triển của data volume, dẫn đến sự nổi lên của NoSQL: MapReduce và Bigtable, Cassandra, MongoDB, và nhiều nữa.

Thế nhưng SQL đã bắt đầu sống dậy. Tất cả các bên cung cấp dịch vụ cloud giờ còn có cả dịch vụ managed relational database như: Amazon RDS, Google Cloud SQL, Azure Database cho PostgreSQL. Theo Amazon, PostgreSQL- và MySQL-compatible database Aurora database của hãng là dịch vụ có tốc độ phát triển nhanh nhất trong lịch sử của AWS. SQL interfaces của Hadoop và Spark liên tục được cải thiện. Tháng vừa rồi thì Kafka launched SQL support.

Trong bài viết này chúng ta sẽ tìm hiểu nguyên nhân cho sự hồi sinh của SQL, cũng như ý nghĩa của nó đối với tương lai của data engineering và analysis.

• Tối ưu hoá MySQL sử dụng việc gộp các index
• MySQL ngoại truyện
• Sử dụng trigger trong SQL qua ví dụ cơ bản.
• Khác biệt giữa khóa chính và khóa ngoại trong SQL

Part 1: A New Hope – Một hi vọng mới

Để hiểu được vì sao SQL trở lại ta phải quay về cội nguồn xuất phát của nó.

Câu chuyện của chúng ta bắt đầu với ngiên cứu của IBM trong những năm đầu của thập niên 70s. Khi đó, các ngôn ngữ query vẫn còn dựa rất nhiều vào thuật toán phức tạp. Donald Chamberlin và Raymond Boyce, hai chàng trai còn “non” trong thế giới lập trình, đã vô cùng ấn tượng với relational data model nhưng họ nhận ra các ngôn ngữ query sẽ chỉ làm “nghẽn lỗ chai”. Do đó cả hai quyết tâm tạo ra một ngôn ngữ query mới, dễ hiểu cho ngay cả user không giỏi toán học và computer programming.

Đây là thời điểm trước cả internet, máy tính cá nhân, khi mà C chỉ vừa mới được giới thiệu với toàn thế giới, đã có 2 nhà khoa học máy tính trẻ nhận ra rằng sự thành công của ngành công nghệ đa phần đến từ việc phát triển một nhóm người dùng thay vì bỏ công đào tạo các chuyên gia lập trình. Họ muốn một ngôn ngữ query dễ đọc như tiếng anh.

Kết quả là thế giới biết tới SQL vào năm 1974. và trong vài thập kỉ tiếp theo, SQL sẽ trở nên vô cùng nổi tiếng. Các database như System R, Ingres, DB2, Oracle, SQL Server, PostgreSQL, MySQL cũng nhanh chóng đô hộ cả ngành công nghệ software. SQL được xem như cầu nối tới database cũng như là lingua franca giúp tăng sự đa dạng cho ecosystem.

Trong một khoảng thời gian, SQL gần như là một ông hoàn cho đến khi Internet xuất hiện.

Part 2: NoSQL Strikes Back – NoSQL tấn công

Trong khi Chamberlin và Boyce đang phát triển SQL, cả hai đều không hay biết việc một nhóm engineer tại California đang thực hiện một project mà sau này đe dọa tới sự tồn tại của SQL. Nó có tên gọi là ARPANET, chào đời vào ngày 29 tháng 10 năm 1969.

Thế nhưng SQL vẫn sống khỏe cho đến khi một engineer khác xuất hiện và sáng tạo ra World Wide Web vào 1989.

Như cỏ dại sau mưa, Internet và Web phát triển mạnh mẽ, ảnh hưởng đến thế giới của chúng ta tại nhiều phương diện khác nhau, nhưng với cộng đồng data thì một vấn đề mới đã xuất hiện: các nguồn mới generate data với volume và vận tốc ngày càng cao.

Và khi Internet ngày càng to lớn thì cộng đồng cũng phát hiện rằng relational databases tại thời điểm đó không đủ khả năng để load khối lượng data như vậy dẫn đến hiện trạng overload của rất nhiều database khác nhau.

Ngay lúc đó 2 ông lớn Internet đã đột phá khi phát triển ra các distributed non-relational systems mới để cứu vãn tình hình: MapReduce (2004) và Bigtable (2006) bởi Google, Dynamo (2007) bởi Amazon. Chúng còn dẫn tới sự ra đời của các non-relational databases, bao gồm Hadoop, Cassandra và MongoDB. Do các systems này được tạo ra từ con số không, chúng cũng xung đột với SQL, dẫn tới sự bùng nổ của NoSQL.

Không có gì ngạc nhiên khi cộng đồng software developer chào đón NoSQL vô cùng nồng nhiệt. Sao mà không phấn khích khi NoSQL vừa mới vừa đẹp, chứa đựng sức mạnh và qui mô lớn, cứ như rằng nó chính là con đường thành công dành cho engineer. Thế rồi vấn đề mới lại xuất hiện.

Developer nhanh chóng nhận ra việc thiếu vắng SQL hóa ra lại khiến mọi thứ khá giới hạn. Do mỗi NoSQL database đều có một ngôn ngữ query riêng cũng như qui luật riêng, kèm theo đó hệ ecosystem nghèo nàn khiến cho không chỉ việc học chúng đã khó mà kết nối các database tới app cũng trở nên phức tạp. Đó là chưa kể các công ty còn phải tự phát triển tool phù hợp cho riêng mình.

Những ngôn ngữ NoSQL này do còn mới nên chúng cũng chưa thật sự trưởng thành, trong khi với SQL thì đã có nhiều năm phát triển relational databases giúp các tính năng của nó đã được cải thiện. Do đó, sự non nớt của NoSQL khiến tăng mức độ phức tạp khi làm app. Sự thiếu vắng của JOINs cũng gây ra các vấn đề đối với data.

Một vài NoSQL databases đã thử phát triển những ngôn ngữ Query tương tự như “SQL” (Cassandra’s CQL) nhưng nó lại khiến mọi thứ tệ hơn với việc các engineers bị nhầm lẫn khi sử dụng nó.