Trong vài năm qua chúng ta đã thấy sự gia tăng của một loại cơ sở dữ liệu mới, đó là cơ sở dữ liệu NoSQL - mà đang thách thức sự thống trị của cơ sở dữ liệu quan hệ. Cơ sở dữ liệu quan hệ đã thống trị ngành công nghiệp phần mềm trong một thời gian dài khi đã cung cấp cơ chế để lưu trữ dữ liệu liên tục, đồng thời kiểm soát, giao dịch, giao diện được chuẩn hóa và được tích hợp vào các hệ thống dữ liệu ứng dụng, báo cáo. Tuy nhiên, ưu thế đó đã không còn tồn tại cho cơ sở dữ liệu quan hệ nữa.
NoSQL nghĩa là gì?
NoSQL có nghĩa là gì và làm thế nào để phân loại các cơ sở dữ liệu? NoSQL có nghĩa là Không Chỉ SQL, ngụ ý rằng khi thiết kế một giải pháp phần mềm hoặc sản phẩm, có nhiều hơn một cơ chế lưu trữ có thể được sử dụng dựa trên các nhu cầu. NoSQL không có một định nghĩa rõ ràng mà chúng ta có thể hiểu là mô hình cơ sở dữ liệu mới có các đặc điểm như sau:
- Không sử dụng các mô hình quan hệ
- Chạy tốt trên các cụm(server)
- Chủ yếu là mã nguồn mở
- Xây dựng cho web thế kỷ 21
- Tối thiểu hóa lược đồ
Tại sao lại là NoSQL?
Chúng ta sẽ gặp vấn đề khó khăn khi có sự không tương ứng giữa cấu trúc dữ liệu quan hệ và cấu trúc dữ liệu được lưu trong bộ nhớ hệ thống. Tuy nhiên, sử dụng NoSQL cho phép chúng ta tiếp tục phát triển mà không cần chuyển đổi cấu trúc lưu trong bộ nhớ với cấu trúc dữ liệu quan hệ.
Sự gia tăng của các trang web cũng tạo ra một sự thay đổi quan trọng trong việc lưu trữ dữ liệu như sự cần thiết để hỗ trợ khối lượng dữ liệu lớn bằng cách chạy trên các cụm. Tuy nhiên, cơ sở dữ liệu quan hệ không được thiết kế để hoạt động hiệu quả trên các cụm. Ví dụ, các nhu cầu lưu trữ dữ liệu của một ứng dụng ERP là rất nhiều khác biệt so với nhu cầu lưu trữ dữ liệu của một Facebook hoặc một Etsy.
Mô hình dữ liệu tổng hợp
Mô hình cơ sở dữ liệu quan hệ là rất khác nhau so với các loại cấu trúc dữ liệu mà các nhà phát triển ứng dụng sử dụng. Sử dụng các cấu trúc dữ liệu đã được mô hình hóa bởi các nhà phát triển để giải quyết vấn đề, lĩnh vực khác nhau đã làm tăng chuyển động đi từ mô hình quan hệ và hướng tới mô hình tổng hợp (hầu hết trong số này được đề cập đến trong cuốn sách Domain Driven Design của Eric Evans). Một số mô hình là tổng hợp của các đơn vị dữ liệu mà chúng ta tương tác với từng phần trong đó. Các đơn vị dữ liệu với cơ sở dữ liệu như là key-value, 'document', và 'column-family'.
Tổng hợp làm cho chúng ta dễ dàng hơn trong việc quản lý dữ liệu lưu trữ trên các cụm. Và các đơn vị dữ liệu bây giờ có thể lư trữ trên bất kỳ máy tính nào và khi lấy ra từ cơ sở dữ liệu chúng ta sẽ được tất cả các dữ liệu có liên quan cùng với nó. Cơ sở dữ liệu tổng hợp làm việc tốt nhất khi hầu hết các dữ liệu được thực hiện trên cùng một tổng hợp, ví dụ như khi cần có được một đơn đặt hàng và tất cả các chi tiết của nó, nó sẽ tốt hơn khi lưu trữ thông tin theo một đối tượng tổng hợp.
Mô hình phân tán:
Cơ sở dữ liệu theo định hướng tổng hợp thực hiện phân phối các dữ liệu dễ dàng hơn, vì các cơ chế phân phối có để di chuyển tổng hợp và không phải lo lắng về dữ liệu có liên quan, như tất cả các dữ liệu liên quan được chứa trong tổng hợp. Có hai kiểu phân phối dữ liệu:
Sharding: sharding phân phối dữ liệu khác nhau trên nhiều máy chủ, do đó mỗi máy chủ đóng vai trò như là nguồn duy nhất cho một tập hợp con của dữ liệu. Replication: replication sao chép dữ liệu trên nhiều máy chủ, vì vậy mỗi bit dữ liệu có thể được tìm thấy ở nhiều nơi. Replication có hai hình thứ
- Master-slave: làm cho một nút có quyền hạn như là bản sao để xử lý ghi trong khi slave đồng bộ với master và có thể xử lý đọc.
- Peer-to-peer: cho phép ghi vào bất kỳ nút nào mà các nút phối hợp đồng bộ các bản sao của dữ liệu
Master-slave làm giảm sự xung đột khi có thực hiện cập nhật còn peer-to-peer tránh tải tất cả viết lên một máy chủ duy nhất nên khi có lỗi chỉ xảy ra tại một điểm duy nhất. Một hệ thống có thể sử dụng một trong hai hoặc cả hai kỹ thuật trên.
Phân loại cơ sở dữ liệu NoSQL
NoSQL được chia làm 4 loại sau:
1. Loại key-value:
Lưu trữ kiểu key-value là kiểu lưu trữ dữ liệu NoSQL đơn giản nhất sử dụng từ một API. Chúng ta có thể nhận được giá trị cho khóa, đặt một giá trị cho một khóa, hoặc xóa một khóa từ dữ liệu. Ví dụ, giá trị là ‘blob’ được lưu trữ thì chúng ta không cần quan tâm hoặc biết những gì ở bên trong. Từ các cặp giá trị được lưu trữ luôn luôn sử dụng truy cập thông qua khóa chính và thường có hiệu năng truy cập tốt và có thể dễ dàng thu nhỏ lại.
Một vài cơ sở dữ liệu key-value phổ biến là Riak, Redis(thường dùng phía server), memcached, Berkeley DB, HamsterDB, Amazon DynamoDB(mã nguồn đóng), Project Voldemort và Couchbase.
Tất cả các cơ sở dữ liệu kiểu key-value đều không giống nhau, có rất nhiều điểm khác nhau giữa các sản phẩm. Ví dụ, dữ liệu của memcached không được nhất quán trong khi ngược lại với Riak. Đấy là những điểm nổi bật quan trọng khi chọn giải pháp phù hợp để sử dụng. Cụ thể hơn là khi chúng ta cần cài đặt caching cho nội dung yêu thích của người dùng, cài đặt sử dụng memcached có nghĩa là khi các nút hỏng hết dẫn tới dữ liệu bị mất và cần phải làm mới lại từ hệ thống nguồn. Tuy nhiên, nếu chúng ta lưu trữ cùng dữ liệu đó trong Riak, chúng ta không cần lo lắng về việc mất dữ liệu nhưng cần phải xem xét việc cập nhật trạng thái của dữ liệu như thế nào. Điều này là quan trọng không chỉ cho chọn cơ sở dữ liệu key-value cho hệ thống và còn quan trọng cho việc chọn cơ sở dữ liệu key-value nào.
2. Cơ sở dữ liệu tài liệu (Document databases)
Tài liệu là nguyên lý chính của cơ sở dữ liệu kiểu dữ liệu. Dữ liệu lưu trữ và lấy ra là các tài liệu với định dạng XML, JSON, BSON,… Tài liệu miêu tả chính nó, kế thừa từ cấu trúc dữ liệu cây. Có thể nói cơ sở dữ liệu tài liệu là 1 phần của key-value. Cơ sở dữ liệu kiểu tài liệu như MongoDB cung cấp ngôn ngữ truy vấn đa dạng và cúc trúc như là cơ sở dữ liệu như đánh index,…
Một số cơ sở dữ liệu tài liệu phổ biến mà chúng ta hay gặp là MongoDB, CouchDB, Terastore, OrientDB, RavenDB.
3. Cơ sở dữ liệu ‘column family’
Cơ sở dữ liệu column-family lưu trữ dữ liệu trong nhiều cột trong mỗi dòng với key cho từng dòng. Column families là một nhóm các dữ liệu liên quan được truy cập cùng với nhau. Ví dụ, với khách hàng, chúng ta thường xuyên sử dụng thông tin cá nhân trong cùng một lúc chứ không phải hóa đơn của họ.
Cassandra là một trong số cơ sở dữ liệu column-family phổ biến. Ngoài ra còn có một số cơ sở dữ liệu khác như HBase, Hypertable và Amazon DynamoDB. Cassandra có thể được miêu tả nhanh và khả năng mở rộng dễ dàng với các thao tác viết thông qua các cụm. Các cụm không có node master, vì thế bất kỳ việc đọc và ghi nào đểu có thể được xử lý bởi bất kỳ node nào trong cụm.
4. Cơ sở dữ liệu đồ thị
Kiểu đồ thị này cho phép bạn lưu trữ các thực thể và quan hệ giữa các thực thể. Các đối tượng này còn được gọi là các nút, trong đó có các thuộc tính. Mỗi nút là một thể hiện của một đối tượng trong ứng dụng. Quan hệ được gọi là các cạnh, có thể có các thuộc tính. Cạnh có ý nghĩa định hướng; các nút được tổ chức bởi các mối quan hệ. Các tổ chức của đồ thị cho phép các dữ liệu được lưu trữ một lần và được giải thích theo nhiều cách khác nhau dựa trên các mối quan hệ.
Thông thường, khi chúng ta lưu trữ một cấu trúc đồ thị giống như trong RDBMS, nó là một loại duy nhất của mối quan hệ. Việc tăng thêm một mối quan hệ có nghĩa là rất nhiều thay đổi sơ đồ và di chuyển dữ liệu, mà không phải là trường hợp khó khi chúng ta đang sử dụng cơ sở dữ liệu đồ thị. Trong cơ sở dữ liệu đồ thị, băng qua các thành phần tham gia hoặc các mối quan hệ là rất nhanh. Các mối quan hệ giữa các node không được tính vào thời gian truy vấn nhưng thực sự tồn tại như là một mối quan hệ. Đi qua các mối quan hệ là nhanh hơn so với tính toán cho mỗi truy vấn.
Có rất nhiều cơ sở dữ liệu đồ thị có sẵn, chẳng hạn như Neo4J, Infinite Graph, OrientDB, hoặc FlockDB (đó là một trường hợp đặc biệt: một cơ sở dữ liệu đồ thị mà chỉ hỗ trợ các mối quan hệ duy nhất chuyên sâu hoặc danh sách kề, nơi mà bạn không thể đi qua nhiều hơn một mức độ sâu sắc đối với các mối quan hệ ).
Tại sao lựa chọn cơ sở dữ liệu NoSQL
Chúng ta đã đề cập đến rất nhiều trong những vấn đề chung, bạn cần phải nhận thức được để đưa ra quyết định trong thế giới mới của cơ sở dữ liệu NoSQL. Bây giờ là lúc để nói về lý do tại sao chúng ta sẽ chọn cơ sở dữ liệu NoSQL. Dưới đây là một số lý do để xem xét việc sử dụng các cơ sở dữ liệu NoSQL.
- Để cải thiện năng suất lập trình bằng cách sử dụng một cơ sở dữ liệu phù hợp hơn với nhu cầu của ứng dụng.
- Để cải thiện hiệu suất truy cập dữ liệu thông qua một số sự kết hợp xử lý khối lượng dữ liệu lớn hơn, giảm độ trễ, và cải thiện thông.
Hầu hết các cơ sở dữ liệu NoSQL là mã nguồn mở, thử nghiệm chúng là một vấn đề đơn giản. Hãy tải về và trải nghiệm. Thậm chí nếu NoSQL không thể được sử dụng như hiện nay, việc thiết kế các hệ thống sử dụng dịch vụ đóng gói hỗ trợ thay đổi công nghệ lưu trữ dữ liệu nhanh như hiện nay như là nhu cầu tất yếu.
Chọn cơ sở dữ liệu NoSQL
Với quá nhiều sự lựa chọn, làm thế nào để chúng ta chọn cơ sở dữ liệu NoSQL? Như đã mô tả sẽ phụ thuộc nhiều vào yêu cầu hệ thống, ngoài ra:
- Cơ sở dữ liệu key-value nói chung là hữu ích để lưu trữ thông tin phiên làm việc(sessions), hồ sơ người dùng, sở thích, dữ liệu giỏ hàng. Chúng tôi sẽ tránh sử dụng cơ sở dữ liệu key-value khi chúng ta cần phải truy vấn dữ liệu, có các mối quan hệ giữa các dữ liệu được lưu trữ hoặc chúng ta cần để hoạt động trên nhiều phím cùng lúc.
- Cơ sở dữ liệu tài liệu nói chung là hữu ích cho hệ thống quản lý nội dung như blog, phân tích web, ứng dụng phân tích thời gian thực và thương mại điện tử. Chúng tôi sẽ tránh sử dụng cơ sở dữ liệu tài liệu cho hệ thống mà cần giao dịch phức tạp kéo dài nhiều hoạt động hoặc tổng hợp các truy vấn đối với các cấu trúc khác nhau.
- Cơ sở dữ liệu column-family thường hữu ích cho hệ thống quản lý nội dung như blog, bảo trì, hết hạn sử dụng, khối lượng ghi nặng như log tập hợp. Chúng ta sẽ tránh sử dụng cơ sở dữ liệu column-family trong hệ thống đang được phát triển sớm hoặc đang thay đổi mẫu truy vấn.
- Cơ sở dữ liệu đồ thị là phù hợp rất tốt với các không gian vấn đề mà chúng ta đã kết nối dữ liệu, chẳng hạn như các mạng xã hội, dữ liệu không gian, thông tin định tuyến cho hàng hóa và tiền bạc.
Tham khảo:
http://www.thoughtworks.com/insights/blog/nosql-databases-overview
http://newtech.about.com/od/databasemanagement/a/Nosql.htm