- Postgres, MySQL, MSSQL là SQL. Còn MongoDB, Cassandra là NoSQL...
- NoSQL nhanh hơn SQL đấy, sao không dùng? MySQL lỗi thời rồi, chuyển sang MongoDB đi.
- Khi nào thì nên dùng NoSQL nhỉ, nếu SQL lỗi thời rồi thì sao vẫn còn được dùng ở rất rất nhiều các project?
Và vô vàn các câu hỏi hay lập luận, khẳng định đanh thép từ giới chuyên gia về vấn đề gây tranh cãi này. Còn mình thì nghĩ rằng.. thực ra chẳng có gì để phải tranh cãi nếu chúng ta hiểu đúng về SQL và NoSQL.
Nếu bạn chưa hiểu rõ về SQL và NoSQL thì hãy tiếp tục. Còn nếu bạn đã nắm chắc như lòng bàn tay thì.. cũng hãy đọc tiếp để góp ý, bổ sung cho mình nhé.
Sau khi tìm hiểu về SQL và NoSQL là gì thì cuối cùng là so sánh giữa SQL và NoSQL để... hiểu điểm mạnh, điểm yếu của từng loại mà áp dụng cho phù hợp. Trên thực tế với những super big application / business đều áp dụng cả 2 loại SQL và NoSQL cho những data khác nhau với mục đích khác nhau.
Đừng so sánh để dìm hàng mà hãy so sánh để biết cách phát huy ưu điểm và hạn chế nhược điểm. Không chỉ trong lĩnh vực này mà còn thực tế ngoài đời sống nữa nhé các tài năng trẻ.
1. Data schema
Đầu tiên là về data schema, không cần bàn luận nhiều nữa vì 2 phần trên nói hết cả rồi.
Với SQL, cấu trúc của table, column sẽ được define trước và phụ thuộc vào schema. Ưu điểm là chúng ta biết trước được data format, đồng thời nhược điểm là data không flexible.
Khó để flexible thôi chứ không phải không thể. Bằng cách áp dụng EAV model chúng ta có thể dễ dàng biến Relational database strict schema sang dynamic & flexible data struct và cái giá phải trả đó là tốc độ query và sự tường minh trong design.
Ngược lại, nhược điểm và ưu điểm với data schema của SQL chính là ưu điểm và nhược điểm của NoSQL. NoSQL là schema-less, không tuân thủ theo một chuẩn data nào nên nó rất linh động trong việc mở rộng các record.
2. Relation and data structure
Tiếp theo, relation là một ưu điểm rất mạnh của relational database vì nó sinh ra với mục đích đó. Data trước khi lưu trữ sẽ được chuẩn hoá (normalize) và chia vào nhiều table khác nhau. Các data relation đến nhau thông qua FK. Việc update data chỉ cần diễn ra ở một table và các table còn lại không cần thay đổi gì cả.
Với NoSQL và non-relational database, relation là thứ vô cùng xa xỉ, gần như không có hoặc nếu có thì là rất rất ít. Do đó, sử dụng NoSQL phải chấp nhận duplicate data và khi update data có thể phải thực hiện ở nhiều collections nhưng đổi lại là tốc độ read data nhanh hơn so với relational database vì không có join.
3. Scaling
Để nói về scaling và replicate data chắc phải dành riêng một bài khác mới đủ, mình sẽ trình bày ngắn gọn nhất để chúng ta nắm được mấu chốt phần này.
Có 2 loại scaling là vertical scaling (scale theo chiều dọc) và horizontal scaling (scale theo chiều ngang).
Ví dụ thế này, gia đình A có 3 nhân khẩu, ở căn biệt thự 300m2 cũng gọi là rộng rãi vch rồi. Thế rồi thời gian thấm thoát thôi qua, gia đình A tăng số lượng người từ 3 lên 5, lên 10, lên 20, lên 50 rồi đến cả trăm người. Thế là một căn biệt thự không đủ. Bây giờ có 2 phương án thế này:
- Một là xây thêm tầng: nhưng xây bao nhiêu cho đủ. Mà xây thêm thì cũng chỉ có giới hạn, cùng lắm như toà Landmark 81 là kinh lắm rồi.
Đây là ví dụ của vertical scaling. Với software, điều này tương tự với việc vẫn là con server đó nhưng ta cải thiện sức mạnh bằng cách tăng RAM, tăng CPU, chuyển từ HDD sang SSD. - Hai là mua thêm nhà: trên lí thuyết đất đai có giới hạn, nhưng chỉ sợ thiếu tiền thôi chứ không sợ thiếu đất. Nếu không lo về tài chính thì cách này có vẻ ổn hơn cách đầu, gần như không giới hạn.
Và đây là ví dụ của horizontal scaling: phân tán dữ liệu trên nhiều server khác nhau thay vì chỉ dùng một server.
Vậy thì nó có liên quan gì đến SQL và NoSQL?
Ta cần hiểu rõ hơn về tính chất đặc thù của từng loại. Kim chỉ nam của relational database là relation, nhờ đó mới có thể sử dụng SQL để query data. Như vậy, nếu data được phân tán trên nhiều server khác nhau thì việc join data gần như bất khả thi hoặc cần những kĩ thuật phức tạp mới có thể làm được. Vậy nên SQL và relational database chỉ phù hợp với vertical scaling.
Với NoSQL và non-relational database thì việc horizontal scaling trở nên dễ dàng hơn vì nó đã loại bỏ relation. Mỗi record trong NoSQL đã có đủ thông tin cho chính nó và không cần join nên việc phân tán data (documents) ra nhiều server không gặp bất lợi gì. Ngoài ra hoàn toàn có thể phân tán cả các records thuộc cùng một document ra nhiều nơi khác nhau (partition/sharding). Vì vậy NoSQL scale đơn giản hơn rất nhiều cả vertical scale và horizontal scale.
Tạm thời ta chỉ cần hiểu rằng việc horizontal scale với NoSQL đơn giản hơn SQL nhiều.
4. Query speed
Phần mà ai cũng quan tâm đó là tốc độ query data.
Rất khó để nói rằng SQL hay NoSQL query nhanh hơn. Phải phụ thuộc vào từng hoàn cảnh và lượng data cũng như data structure ta mới có thể trả lời rõ ràng được.
Nếu fetch data phức tạp với nhiều relation và có hàng nghìn queries 1 lúc thì SQL có tốc độ không tốt bằng NoSQL.
Nhưng nếu data được update thường xuyên và write > read thì việc sử dụng NoSQL chưa chắc đã cho tốc độ tốt hơn so với SQL.
Cuối cùng, theo mình nghĩ việc quyết định lựa chọn SQL hay NoSQL hay cả 2 sẽ phụ thuộc vào 3 yếu tố sau:
- Business của dự án.
- Dung lượng dữ liệu.
- Kỹ năng của team.
Còn rất rất nhiều yếu tố khác và đã có vô vàn các bài viết về nó rồi nên mình không đề cập ở đây. Chốt lại, SQL cũng được mà NoSQL cũng được, điều quan trọng là bạn cần nắm rõ, hiểu kỹ và có thể xử lý mọi vấn đề liên quan đến nó là ok.
After credit
Tên MongoDB bắt nguồn từ humongous nghĩa là to lớn, khổng lồ với ý nghĩa nó có thể chứa được một lượng rất rất lớn data.
Cho những ai chưa biết ngoài SQL, NoSQL còn có một loại khác là NewSQL. Và nó cũng đã xuất hiện cách đây 7-8 năm về trước rồi. Cụ thể nó có khác gì so với SQL và NoSQL thì hẹn gặp trong bài viết khác nhé.
Sưu tầm
Japan IT Works
