1. NoSQL là gì ?

Bạn Đang Xem: TÌM HIỂU VỀ NOSQL

• NoSQL còn tồn tại tức thị Non-Relational (NoRel) – không ràng buộc. Tuy nhiên, thuật ngữ đó ít phổ dụng hơn và ngày này người ta thường dịch NoSQL thành Not Only SQL – Không chỉ SQL. NoSQL ám chỉ đến những cơ sở tài liệu không dùng mô hình tài liệu quan hệ để quản lý tài liệu trong ngành nghề phần mềm.

• Thuật ngữ NoSQL được giới thiệu lần nguồn vào năm 1998 sử dụng làm tên gọi chung cho những lightweight open source relational database (cơ sở tài liệu quan hệ nguồn mở nhỏ) nhưng không sử dụng SQL cho truy vấn.

• Vào năm 2009, Eric Evans, viên chức của Rackspace giới thiệu lại thuật ngữ NoSQL trong một hội thảo chiến lược về cơ sở tài liệu nguồn mở phân tán. Thuật ngữ NoSQL lưu lại bước phát triển của thế hệ database mới: distributed (phân tán) + non-relational (không ràng buộc).

• Một số đặc điểm nhận dạng cho thế hệ database mới này gồm có:

Schema-free Tương trợ mở rộng dễ dàng API đơn giản Eventual consistency (nhất quán cuối) và/hoặc transactions hạn chế trên các thành phần tài liệu đơn lẻ Không giới hạn không gian tài liệu

2. Một số thuật ngữ liên quan

• Non-relational: relational – ràng buộc – thuật ngữ sử dụng đến những quan hệ giữa các bảng trong cơ sở tài liệu quan hệ (RDBMs) sử dụng mô hình khóa gồm 2 loại khóa: khóa chính và khóa phụ (primary key + foreign key) để ràng buộc tài liệu nhằm thể hiện tính nhất quán tài liệu từ các bảng khác nhau. Non-relational là khái niệm không sử dụng các ràng buộc tài liệu cho nhất quán tài liệu ở NoSQL database.

• Distributed storage: mô hình lưu trữ phân tán các file hoặc tài liệu ra nhiều máy tính khác nhau trong mạng LAN hoặc Internet dưới sự kiểm soát của phần mềm.

• Eventual consistency (nhất quán cuối): tính nhất quán của tài liệu không nhất thiết phải đảm bảo ngay tức khắc sau mỗi phép write. Một mạng lưới hệ thống phân tán đồng ý những ảnh hưởng tác động theo phương thức Viral và sau một khoảng tầm thời kì (không phải ngay tức khắc), thay đổi sẽ đi đến mọi điểm trong mạng lưới hệ thống, tức là cuối cùng (eventually) tài liệu trên mạng lưới hệ thống sẽ trở lại trạng thái nhất quán.

• Vertical scalable (khả năng mở rộng chiều dọc): Khi tài liệu lớn về lượng, phương pháp tăng cường khả năng lưu trữ và xử lý bằng việc cải tiến phần mềm và cải thiện phần cứng trên một máy tính đơn lẻ được gọi là khả năng mở rộng chiều dọc. Ví dụ việc tăng cường CPUs, cải thiện đĩa cứng, bộ nhớ trong một máy tính,… cho DBMs nằm trong phạm trù này. Khả năng mở rộng chiều dọc còn tồn tại một thuật ngữ khác scale up.

• Horizontal scalable (khả năng mở rộng chiều ngang): Khi tài liệu lớn về lượng, phương pháp tăng cường khả năng lưu trữ và xử lý là dùng nhiều máy tính phân tán. Phân tán tài liệu được tương trợ bởi phần mềm tức cơ sở tài liệu.

• Xem Thêm : Thưởng thức xôi xéo Đà Nẵng, Sài Gòn – hương vị quen mà lạ

  Trong những khi giá thành phần cứng ngày càng giảm, tốc độ xử lý, bộ nhớ ngày càng tăng thì horizontal scalable là một lựa chọn đúng đắn. Hàng trăm máy tính nhỏ được chập lại tạo thành một mạng lưới hệ thống tính toán mạnh hơn nhiều so với vi xử lý RISC truyền thống đơn lẻ. Mô hình này tiếp tục được tương trợ bởi các công nghệ kết nối Myrinet và InfiniBand. Từ đó tất cả chúng ta có thể quản lý, bảo trì từ xa, xây dựng batch procession (xử lý nhất tề tập lệnh) tốt hơn. Do những yên cầu về tốc độ xử lý I/O cao, lượng cực lớn tài liệu,… scale horizontally sẽ xúc tiến các công nghệ lưu trữ mới phát triển giống như object storage devices (OSD).

3. Một số khái niệm mới trong NoSQL

• Fields – tương đương với khái niệm Columns trong SQL

• Document – thay thế khái niệm row trong SQL. Này cũng đây chính là khái niệm tạo nên sự sự khác biệt giữa NoSQL và SQL, 1 document chứa số cột (fields) không nhất quyết trong khi một row thì số cột(columns) là định sẵn trước.

• Collection – tương đương với khái niệm table trong SQL. Một collection là tập hợp các document. Điều nhất là một collection có thể chứa các document hoàn toàn khác nhau.

• Key-value – cặp từ khóa – giá trị được dùng để làm lưu trữ tài liệu trong NoSQL

• Cursor – tạm dịch là con trỏ. Tất cả chúng ta sẽ sử dụng cursor để lấy tài liệu từ database.

• Indexes ~ counterparts: Trong các hệ cơ sở tài liệu quan hệ, các cột được khái niệm theo bảng còn với hệ cơ sở tài liệu không ràng buộc, các cột được khái niệm ở mỗi document. Chính vì vậy, các document quản lí gần như tất cả, các collection không cần quản lí chặt chẽ những gì đang xẩy ra trong nó nữa .

4. Ưu điểm của NoSQL

• Các RDBMs ngày nay đã bộc lộ những yếu kém như việc đánh chỉ mục một lượng lớn tài liệu, phân trang, hoặc phân phối luồng tài liệu tiếp thị quảng cáo (phim, ảnh, nhạc, …). Cơ sở tài liệu quan hệ được thiết kế cho những mô hình tài liệu nhỏ thường xuyên đọc viết trong lúc các Social Network Services lại sở hữu một lượng tài liệu cực lớn và update liên tục do số lượng người dùng quá nhiều ở một thời khắc. Thiết kế trên Distributed NoSQL giảm thiểu tối đa các phép tính toán, I/O liên quan kết phù hợp với batch processing đủ đảm bảo được yêu cầu xử lý tài liệu của khá nhiều mạng dịch vụ tài liệu cộng đồng này. Facebook, Amazon là những ví dụ điểm hình.

• Về cơ bản, các thiết kế của NoSQL lựa chọn mô hình lưu trữ tập tài liệu theo cặp giá trị key-value. Khái niệm node được sử dụng trong quản lý tài liệu phân tán. Với những mạng lưới hệ thống phân tán, việc lưu trữ có đồng ý trùng lặp tài liệu. Một request truy vấn tới data có thể gửi tới nhiều máy cùng lúc, khi một máy nào nó bị chết cũng không ảnh hưởng tác động nhiều tới toàn bộ mạng lưới hệ thống. Để đảm bảo tính real time trong các mạng lưới hệ thống xử lý lượng lớn, thông thường người ta sẽ tách biệt database ra làm 2 hoặc nhiều database. Một database nhỏ đảm bảo vào ra liên tục, khi đạt tới ngưỡng thời kì hoặc dung tích, database nhỏ sẽ tiến hành gộp (merge) vào database lớn có thiết kế tối ưu được chấp nhận đọc (read operation). Mô hình đó được chấp nhận tăng cường hiệu suất I/O – một trong những nguyên nhân chính khiến performance trở thành kém.

NoSQL có những đặc điểm sau:

• High Scalability: Gần như không có một giới hạn cho tài liệu và người dùng trên mạng lưới hệ thống.
• High Availability: Do đồng ý sự trùng lặp trong lưu trữ nên nếu một node (commodity machine) nào đó bị chết cũng không ảnh hưởng tác động tới toàn bộ mạng lưới hệ thống.
• Atomicity: Độc lập data state trong các operation.
• Consistency: đồng ý tính nhất quán yếu, update mới không đảm nói rằng các truy xuất sau đó thấy ngay được sự thay đổi. Sau một khoảng tầm thời kì Viral thì tính nhất quán cuối cùng của tài liệu mới được đảm bảo.
• Durability: tài liệu có thể tồn tại trong bộ nhớ máy tính nhưng song song cũng được lưu trữ lại đĩa cứng.
• Deployment Flexibility: việc bổ sung thêm/loại bỏ các node, mạng lưới hệ thống sẽ tự động hóa nhận diện để lưu trữ mà không nhất thiết phải can thiệp bằng tay. Mạng lưới hệ thống cũng không yên cầu cấu hình phần cứng mạnh, đồng nhất.
• Modeling flexibility: Key-Value pairs, Hierarchical data (tài liệu cấu trúc), Graphs.
• Query Flexibility: Multi-Gets, Range queries (load một tập giá trị dựa vào một trong những dãy các khóa).

5. Ví dụ về mô hình Wide Column Store / Column Families

• Column family databases được nghe biết nhiều nhất qua sự triển khai BigTable của Google. Nhìn bên phía ngoài vào nó giống với cơ sỡ tài liệu quan hệ nhưng thực sự thì có sự khác biệt rất lớn từ bên trong. Một trong những khác biệt đó đây chính là việc lưu trữ tài liệu theo dòng (trong cơ sở tài liệu quan hệ) so với việc lưu trữ tài liệu theo cột (trong column family databases). Nhưng sự khác biệt lớn là ở chính khái niệm của nó. Tất cả chúng ta không thể ứng dụng cùng một giải pháp mà tất cả chúng ta sử dụng trong cơ sở tài liệu quan hệ vào trong cơ sở tài liệu column family. Đó là bởi vì cơ sở tài liệu cột (column family database) phi quan hệ. Các khái niệm sau đây rất quan trọng để hiểu được column family database thao tác làm việc thế nào: o Column family o Super column o Column
• Column và super column trong column family database dùng thay thế nhau, có tức thị chúng sẽ là 0 byte nếu chúng không có chứa tài liệu. Không phải như một bảng, thứ duy nhất tất cả chúng ta cần xác định trong column family database tên cột và các tùy chọn chính (không có sơ đồ nhất quyết).
• Ý tưởng cơ bản: o Column families: Một column family là phương pháp tài liệu được lưu trữ trên đĩa. Tất cả tài liệu trong một cột sẽ tiến hành lưu trên cùng một file. Một column family có thể chứa super column hoặc column. o Super column: Một super column có thể được sử dụng như một dictionary(kiểu từ vựng). Nó là một column có thể chứa những column khác (mà không phải là super column). o Column: Một column là một bộ gồm tên, giá trị và dấu thời kì (thông thường chỉ quan tâm tới key-value).
• Hiểu được sơ đồ đượcc thiết kế thế nào rất quan trọng. Nếu tất cả chúng ta thiết kế sơ đồ không đúng, tất cả chúng ta không thể lấy được tài liệu. Column family database cung cấp một trong hai cách truy vấn: key hoặc là key range. Điều này còn có tức thị, vì CFDB có thể phân tán nên khóa xác định vị trí vật lý thực sự mà tài liệu được lưu trữ. Tài liệu được lưu trữ dựa trên sự sắp xếp của column family và tất cả chúng ta không có cách nào để thay đổi sự sắp xếp này (ngoại trừ việc sắp xếp tăng dần hay giảm dần).
• Không phải như trong cơ sở tài liệu quan hệ, trật tự sắp xếp không bị ảnh hưởng tác động bởi giá trị cột, nhưng lại bị ảnh hưởng tác động bởi tên cột.
• Giả sử trong column family Users, một dòng với khóa đây chính là ”@ayende”, một cột name với giá trị “Ayende Rahien” và một cột location với giá trị “Israel”. CFDB sẽ sắp xếp vật lý trong User column family file như sau:

@ayende/location = “Israel” @ayende/name = “Ayende Rahien”

• Bởi vì location đứng trước name nên cột location sẽ tiến hành lưu trước cột name. Tương tự cho super column, ví dụ cột Friends, “@ayende” có 2 friend thì trong file Friends column family được lưu trữ vật lý như sau:

Xem Thêm : Hiểu đúng về ý nghĩa số 94] Ý nghĩa số điện thoại đuôi 94

@ayende/friends/arava= 945 @ayende/friends/rose = 14

• Điều này rất quan trọng để hiểu được cách thao tác làm việc của CFDB. Giả sử tất cả chúng ta có mô hình twitter cần lưu trữ: users và tweets. Tất cả chúng ta khái niệm 3 cột: o User: sắp xếp theo UTF8 o Tweets: sắp xếp theo Sequential Guid o UsersTweets: super column, sắp xếp theo Sequential Guid
• Giả sử tất cả chúng ta muốn tạo một User:

cfdb.Users.Insert(key: “@ayende”, name: “Ayende Rahien”, location: “Israel”, profession: “Wizard”);

Hình ảnh nội tuyến 1

• Giờ tất cả chúng ta sẽ tạo một tweet:

var firstTweetKey = “Tweets/” + SequentialGuid.Create(); cfdb.Tweets.Insert(key: firstTweetKey, application: “TweekDeck”, text: “Err, is this on?”, private: true; var secondTweetKey = “Tweets/” + SequentialGuid.Create(); cfdb.Tweets.Insert(key: secondTweetKey, app: “Twhirl”, version: “1.2”, text: “Well, I guess this is my mandatory hello world”, public: true, version: 1.2);

Hình ảnh nội tuyến 2

• Một vài lưu ý là: o Thực sự giá trị của khóa không quan trọng, nhưng nó là những chuỗi liên tục được chấp nhận tất cả chúng ta sắp xếp sau này, o Cả hai dòng chứa tài liệu khác nhau bởi vì tất cả chúng ta không có sơ đồ nhất quyết. o Tất cả chúng ta không có cách nào liên kết giữa một user và tweet
• Trong cơ sở tài liệu quan hệ, tất cả chúng ta sẽ khái niệm một cột là UserId trong Tweet được chấp nhận tất cả chúng ta liên kết với bảng User. Hơn nữa, cơ sở tài liệu quan hệ còn được chấp nhận tất cả chúng ta truy vấn tweets theo UserId. CFDB không làm được điều này, tất cả chúng ta không thể truy vấn theo tài liệu cột. Thay vì thế, điều duy nhất CFDB được chấp nhận tất cả chúng ta là truy vấn theo khóa. Tất cả chúng ta khái niệm một index thứ hai, nơi mà cột UsersTweets xuất hiện:

cfdb.UsersTweets.Insert(key: “@ayende”, timeline: { SequentialGuid.Create(): firstTweetKey } ); cfdb.UsersTweets.Insert(key: “@ayende”, timeline: { SequentialGuid.Create(): secondTweetKey } );

• Tất cả chúng ta thêm tài liệu vào cột UsersTweets một dòng với khóa là “@ayende”, super column timeline với 2 cột – tên mỗi cột là sequential guid được chấp nhận sắp xếp.

Hình ảnh nội tuyến 3

• Lưu ý: Vướng mắc nêu ra là tất cả chúng ta có thể tạo ra super column trong cột User để lưu giữ quan hệ. Lời giải đáp là: tất cả chúng ta có thể làm điều đó, ngoại trừ một column family có thể chứa hoặc column hoặc super column, không thể chứa cả hai.
• Để lấy những tweets của một user, tất cả chúng ta cần thực thi:

var tweetIds =cfdb.UsersTweets.Get(“@ayende”) .FetchSuperColumnValues(“timeline”) .Take(25) .OrderByDescending() .Select(x=>x.Value); var tweets = cfdb.Tweets.Get(tweetIds);

• Về cơ bản tất cả chúng ta thực hiện 2 truy vấn: o Truy vấn thứ nhất vào cột UsersTweets, yêu cầu cột và giá trị trong timeline super column với khóa là “@ayende” o Truy vấn thứ hai là truy vấn vào cột Tweets để lấy giá trị thực sự của Tweet.
• Kiểu này tất cả chúng ta thường thấy trong NoSQL. Nó được gọi là ”secondary index”, một cách truy cập tài liệu nhanh chóng theo khóa dựa trên một giá trị khác entity/row/document. Đây là một ví dụ về truy vấn Tweeys theo User trên tài liệu tất cả chúng ta có. Nếu không tạo ra secondary index thì tất cả chúng ta không có cách nào trả lời cho vướng mắc: “cho xem 25 tweets tiên tiến nhất của ayende?”
• Bởi vì tài liệu được sắp xếp theo tên cột và giảm dần, tất cả chúng ta có thể lấy được 25 tweets tiên tiến nhất của ayende. Và sẽ thế nào nếu ta muốn truy vấn 25 tweets tiên tiến nhất (không theo một user nào)? Rất đơn giản, chỉ có truy vấn vào cột Tweets sắp xếp theo khóa giảm dần.

6. Những điểm hạn chế ?

CFDB viết tắt cho (mô hình Wide Column Store / Column Families).

• CFDB khó khăn trong việc nghiên cứu lúc đầu ví nó nhìn bên phía ngoài thì giống cơ sở tài liệu quan hệ mà lại bị hạn chế rất nhiều. Không có “join”, không có khả năng truy vấn thực sự(ngoại trừ truy vấn theo khóa chính), không có sự phong phú sự tương trợ như cơ sở tài liệu quan hệ làm được. SQLite hay Access đem lại nhiều lợi ích hơn CFDB. Vì sao CFDB lại hạn chế như vậy?

• Lời giải đáp khá đơn giản. CFDB được thiết kế đê chạy trên một số lượng lớn các máy, và lưu trữ một lượng tài liệu cực lớn. Tất cả chúng ta không thể lưu trữ một lượng lớn tài liệu trong cơ sở tài liệu quan hệthậm chí là nhiều máy như Oracle RAC sẽ nhanh chóng bị sụp đổ hoặc là chết rất nhanh về kích thước của tài liệu và những truy vấn này được CFDB xử lý một cách dễ dàng. Nhớ rằng CFDB loại bỏ các khái niệm trừu tượng, những thứ làm cho nó cứng nhắt khi chạy trên một cụm máy.

• Lý do mà CFDB không tương trợ join là join yêu cầu tất cả chúng ta quét toàn bộ tập hợp tài liệu. Điều đó yêu cầu phải có một nơi có cái nhìn tổng quát về toàn bộ cơ sở tài liệu(kết quả trong nút cổ chai và điểm duy nhất bị thất bại) hoặc thực hiện một truy vấn thực sự trên tất cả những máy có trong cụm. CFDB không cung cấp phương pháp để truy vấn theo cột hay giá trị bởi vì nó sẽ yêu cầu một index trên toàn bộ tập hợp tài liệu (hay chỉ là một cột duy nhất). Và một lần nữa không thực tế, không thể chạy truy vấn trên tất cả những máy. Bằng phương pháp giới hạn truy vấn theo khóa, CFDB đảm nói rằng nó biết chuẩn xác về node mà truy vấn có thể thực hiện trên đó. Có tức thị mỗi truy vấn được chạy trên một tập nhỏ tài liệu là cho rẻ hơn nhiều.

• Nhiều hạn chế, khó sử dụng nhưng CFDB lại sở hữu khả năng mở rộng cao. Đây là điều tất cả chúng ta cần quan tâm tới.