NoSQL còn có nghĩa là NonRelational (NoRel) không ràng buộc. Tuy nhiên, thuật ngữ đó ít phổ dụng hơn và ngày nay 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ở dữ liệu không dùng mô hình dữ liệu quan hệ để quản lý dữ liệu trong lĩnh vực phần mềm.
NoSQL Giới thiệu NoSQL 1.1 Thuật ngữ NoSQL NoSQL có nghĩa Non-Relational (NoRel) - không ràng buộc Tuy nhiên, thuật ngữ phổ dụng ngày người ta thường dịch NoSQL thành Not Only SQL - Không SQL NoSQL ám đến sở liệu không dùng mô hình liệu quan hệ để quản lý liệu lĩnh vực phần mềm 1.2 Lịch sử - - - Thuật ngữ NoSQL giới thiệu lần đầu vào năm 1998 sử dụng làm tên gọi chung cho lightweight open source relational database (cơ sở liệu quan hệ nguồn mở nhỏ) không sử dụng SQL cho truy vấn Vào năm 2009, Eric Evans, nhân viên Rackspace giới thiệu lại thuật ngữ NoSQL hội thảo sở liệu nguồn mở phân tán Thuật ngữ NoSQL đánh dấu bước phát triển hệ database mới: distributed (phân tán) + non-relational (không ràng buộc) Ghi chú: Một mệnh đề thú vị non-relational data store: "select fun, profit from real_world where relational=false;" 1.3 Định nghĩa - - Thế hệ database hệ sở liệu non-relational (không ràng buộc), distributed (phân tán), open source, horizontal scalable (khả mở rộng theo chiều ngang) lưu trữ, xử lý từ lượng nhỏ hàng petabytes liệu hệ thống có độ chịu tải, lỗi cao với đòi hỏi tài nguyên phần cứng thấp Một số đặc điểm nhận dạng cho hệ database bao gồm: • • • • - Schema-free Hỗ 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ế thành phần liệu đơn lẻ • Không giới hạn không gian liệu • NoSQL storage đặc biệt phổ dụng thời kỳ Web 2.0 bùng nổ, nơi mạng dịch vụ liệu cộng đồng cho phép người dùng tạo hàng tỷ nội dung web Do đó, liệu lớn nhanh vượt qua giới hạn phần cứng cần phải giải toán phân tán Nửa đầu năm 2009, người ta manh nha thuật ngữ NoSQL đánh dấu trưởng thành hệ database sản phẩm phần mềm phát triển từ trước lâu 1.4 Một số thuật ngữ liên quan - - - - - Non-relational: relational - ràng buộc - thuật ngữ sử dụng đến mối quan hệ bảng sở liệu quan hệ (RDBMs) sử dụng mô hình khóa gồm loại khóa: khóa khóa phụ (primary key + foreign key) để ràng buộc liệu nhằm thể tính quán liệu từ bảng khác Non-relational khái niệm không sử dụng ràng buộc liệu cho quán liệu NoSQL database Distributed storage: mô hình lưu trữ phân tán file liệu nhiều máy tính khác mạng LAN Internet kiểm soát phần mềm Eventual consistency (nhất quán cuối): tính quán liệu không cần phải đảm bảo tức khắc sau phép write Một hệ thống phân tán chấp nhận ảnh hưởng theo phương thức lan truyền sau khoảng thời gian (không phải tức khắc), thay đổi đến điểm hệ thống, tức cuối (eventually) liệu hệ thống trở lại trạng thái quán Vertical scalable (khả mở rộng chiều dọc): Khi liệu lớn lượng, phương pháp tăng cường khả lưu trữ xử lý việc cải tiến phần mềm cải thiện phần cứng máy tính đơn lẻ gọi khả mở rộng chiều dọc Ví dụ việc tăng cường CPUs, cải thiện đĩa cứng, nhớ máy tính, cho DBMs nằm phạm trù Khả mở rộng chiều dọc có thuật ngữ khác scale up Horizontal scalable (khả mở rộng chiều ngang): Khi liệu lớn lượng, phương pháp tăng cường khả lưu trữ xử lý dùng nhiều máy tính phân tán Phân tán liệu hỗ trợ phần mềm tức sở liệu Trong giá thành phần cứng ngày giảm, tốc độ xử lý, nhớ ngày tăng horizontal scalable lựa chọn đắn Hàng trăm máy tính nhỏ chập lại tạo thành hệ thống tính toán mạnh nhiều so với vi xử lý RISC truyền thống đơn lẻ Mô hình tiếp tục hỗ trợ công nghệ kết nối Myrinet InfiniBand Từ quản lý, bảo trì từ xa, xây dựng batch procession (xử lý đồng loạt tập lệnh) tốt Do đòi hỏi tốc độ xử lý I/O cao, lượng cực lớn liệu, scale horizontally thúc đẩy công nghệ lưu trữ phát triển giống object storage devices (OSD) 1.5 Một số khái niệm NoSQL - - - Fields – tương đương với khái niệm Columns SQL Document – thay khái niệm row SQL Đây khái niệm làm nên khác biệt NoSQL SQL, document chứa số cột (fields) không cố định row số cột(columns) định sẵn trước Collection – tương đương với khái niệm table SQL Một collection tập hợp document Điều đặc biệt collection chứa document hoàn toàn khác Key-value – cặp từ khóa – giá trị dùng để lưu trữ liệu NoSQL Cursor – tạm dịch trỏ Chúng ta sử dụng cursor để lấy liệu từ database Indexes ~ counterparts: Trong hệ sở liệu quan hệ, cột định nghĩa theo bảng với hệ sở liệu không ràng buộc, cột định nghĩa document Bởi thế, document quản lí gần tất cả, collection không cần quản lí chặt chẽ xảy Kiến trúc 2.1 Sơ lược - - Các RDBMs bộc lộ yếu việc đánh mục lượng lớn liệu, phân trang, phân phối luồng liệu media (phim, ảnh, nhạc, ) Cơ sở liệu quan hệ thiết kế cho mô hình liệu nhỏ thường xuyên đọc viết Social Network Services lại có lượng liệu cực lớn cập nhật liên tục số lượng người dùng nhiều thời điểm Thiết kế Distributed NoSQL giảm thiểu tối đa phép tính toán, I/O liên quan kết hợp với batch processing đủ đảm bảo yêu cầu xử lý liệu mạng dịch vụ liệu cộng đồng Facebook, Amazon ví dụ điểm hình Về bản, thiết kế NoSQL lựa chọn mô hình lưu trữ tập liệu theo cặp giá trị key-value Khái niệm node sử dụng quản lý liệu phân tán Với hệ thống phân tán, việc lưu trữ có chấp nhận trùng lặp liệu Một request truy vấn tới data gửi tới nhiều máy lúc, máy bị chết không ảnh hưởng nhiều tới toàn hệ thống Để đảm bảo tính real time hệ thống xử lý lượng lớn, thông thường người ta tách biệt database làm nhiều database Một database nhỏ đảm bảo vào liên tục, đạt tới ngưỡng thời gian dung lượng, database nhỏ gộp (merge) vào database lớn có thiết kế tối ưu cho phép đọc (read operation) Mô hình cho phép tăng cường hiệu suất I/O - nguyên nhân khiến performance trở nên 2.2 Một số đặc điểm - - - High Scalability: Gần giới hạn cho liệu người dùng hệ thống High Availability: Do chấp nhận trùng lặp lưu trữ nên node (commodity machine) bị chết không ảnh hưởng tới toàn hệ thống Atomicity: Độc lập data state operation Consistency: chấp nhận tính quán yếu, cập nhật không đảm bảo truy xuất sau thấy thay đổi Sau khoảng thời gian lan truyền tính quán cuối liệu đảm bảo Durability: liệu tồn nhớ máy tính đồng thời lưu trữ lại đĩa cứng Deployment Flexibility: việc bổ sung thêm/loại bỏ node, hệ thống tự động nhận biết để lưu trữ mà không cần phải can thiệp tay Hệ thống không đòi hỏi cấu hình phần cứng mạnh, đồng Modeling flexibility: Key-Value pairs, Hierarchical data (dữ liệu cấu trúc), Graphs Query Flexibility: Multi-Gets, Range queries (load tập giá trị dựa vào dãy khóa) 2.3 What is NoSQL (technically speaking)? - - - - - - Đừng gọi chúng database CTO Amazon, Werner Vogels đề cập đến hệ thống Dynamo họ gọi "highly available key-value store" Google gọi BigTable để nhấn mạnh "distributed storage system for managing structured data" (hệ thống lưu trữ quản lý liệu cấu trúc có phân tán) Có thể thổi bay lượng liệu cực lớn Hypertable, open source column-based database mô hình BigTable sử dụng cho local search engine Zvents Inc ghi tới tỷ cell liệu ngày (theo Doug Judd kỹ sư Zvents) Trong BigTable kết hợp với MapReduce xử lý tới 20 petabytes liệu ngày Đánh bại performance bottlenecks Bằng việc bỏ qua thông dịch SQL với truy vấn rườm rà, NoSQL cho ta kiến trúc tối ưu tốc độ thực thi (ghi truy vấn liệu) Việc sử dụng ràng buộc quan hệ truy vấn SQL thân thiện thích hợp với phần đông liệu Tuy nhiên, liệu đơn giản, thủ tục SQL không cần thiết (theo Curt Monash - nhà phân tích sở liệu, blogger) Raffaele Sena, senior computer scientist Adobe Systems Inc nói ConnectNow Web collaboration service họ sử dụng Java clustering software từ Terracotta thay cho sở liệu quan hệ khiến "hệ thống họ trở nên mạnh hơn, phức tạp so với việc sử dụng sở liệu quan hệ" Các thiết kế database có tính đặc thù (như document-oriented database) lược bỏ tầng chuyển đổi sang mô hình lưu trữ quan hệ từ interface đồng thời khiến giao tiếp tương tác trở nên tự nhiên MongoDB vs SQL Server 2008 Performance Showdown - Không cần thiết Đồng ý RDBMs cung cấp mô hình tuyệt vời để đảm bảo tính toàn vẹn liệu Tuy nhiên, nhiều người lựa chọn NoSQL nói chúng không cần thiết cho nhu cầu họ Như dự án ConnectNow Adobe, liệu người dùng session không cần thiết phải lưu lại, chúng bị xóa người dùng logoff Vì vậy, key-value memory storage đủ dùng Phân loại 3.1 Core NoSQL Systems 3.1.1 - - Wide Column Store / Column Families Column family databases biết đến nhiều qua triển khai BigTable Google Nhìn bên vào giống với sỡ liệu quan hệ thực có khác biệt lớn từ bên Một khác biệt việc lưu trữ liệu theo dòng (trong sở liệu quan hệ) so với việc lưu trữ liệu theo cột (trong column family databases) Nhưng khác biệt lớn khái niệm Chúng ta áp dụng giải pháp mà sử dụng sở liệu quan hệ vào sở liệu column family Đó sở liệu cột (column family database) phi quan hệ Các khái niệm sau quan trọng để hiểu column family database làm việc nào: o Column family o Super column o Column Column super column column family database dùng thay nhau, có nghĩa chúng byte chúng chứa liệu Không giống bảng, thứ - - - cần xác định column family database tên cột tùy chọn (không có lược đồ cố định) Ý tưởng bản: o Column families: Một column family cách thức liệu lưu trữ đĩa Tất liệu cột lưu file Một column family chứa super column column o Super column: Một super column dùng dictionary(kiểu từ điển) Nó column chứa column khác (mà super column) o Column: Một column gồm tên, giá trị dấu thời gian (thông thường quan tâm tới key-value) Hiểu lược đồ đượcc thiết kế quan trọng Nếu thiết kế lược đồ không đúng, lấy liệu Column family database cung cấp hai cách truy vấn: key key range Điều có nghĩa là, CFDB phân tán nên khóa xác định vị trí vật lý thực mà liệu lưu trữ Dữ liệu lưu trữ dựa xếp column family cách để thay đổi xếp (ngoại trừ việc xếp tăng dần hay giảm dần) Không giống sở liệu quan hệ, thứ tự xếp không bị ảnh hưởng giá trị cột, lại bị ảnh hưởng tên cột Giả sử column family Users, dòng với khóa ”@ayende”, cột name với giá trị “Ayende Rahien” cột location với giá trị “Israel” CFDB xếp vật lý User column family file sau: @ayende/location = "Israel" @ayende/name = "Ayende Rahien" - Bởi location đứng trước name nên cột location lưu trước cột name Tương tự cho super column, ví dụ cột Friends, “@ayende” có friend file Friends column family lưu trữ vật lý sau: @ayende/friends/arava= 945 @ayende/friends/rose = 14 - - Điều quan trọng để hiểu cách làm việc CFDB Giả sử có mô hình twitter cần lưu trữ: users tweets Chúng ta định nghĩa cột: o User: xếp theo UTF8 o Tweets: xếp theo Sequential Guid o UsersTweets: super column, xếp theo Sequential Guid Giả sử muốn tạo User: cfdb.Users.Insert(key: "@ayende", name: "Ayende Rahien", location: "Israel", profession: "Wizard"); - Chúng ta xem hình bên để biết dòng trông nào, không giống với dòng sở liệu quan hệ: - Biểu diễn dòng Column family database Giờ tạo 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 1.3: Biểu diễn tweet Column family database - - Giá trị hiển thị hình 1.3 Một vài lưu ý là: o Thực giá trị khóa không quan trọng, chuỗi liên tiếp cho phép xếp sau này, o Cả hai dòng chứa liệu khác lược đồ cố định o Chúng ta cách liên kết user tweet Trong sở liệu quan hệ, định nghĩa cột UserId Tweet cho phép liên kết với bảng User Hơn nữa, sở liệu quan hệ cho phép truy vấn tweets theo UserId CFDB không làm điều này, truy vấn theo liệu cột Thay thế, điều CFDB cho phép truy vấn theo khóa Chúng ta định nghĩa 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 } ); - Hình 1.4 cho thấy liệu database Chúng ta thêm liệu vào cột UsersTweets dòng với khóa “@ayende”, super column timeline với cột – tên cột sequential guid cho phép xếp Hình 1.4: biểu diễn index thứ hai, liên kết users tweets Column Family database - - Lưu ý: Câu hỏi đặt tạo super column cột User để lưu giữ quan hệ Câu trả lời là: làm điều đó, ngoại trừ column family chứa column super column, chứa hai Để lấy tweets user, 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); - - - Lưu ý: truy vấn API cho NET, ví dụ cho dễ hiểu API thực Về thực truy vấn: o Truy vấn thứ vào cột UsersTweets, yêu cầu cột giá trị timeline super column với khóa “@ayende” o Truy vấn thứ hai truy vấn vào cột Tweets để lấy giá trị thực Tweet Kiểu thường thấy NoSQL Nó gọi ”secondary index”, cách truy cập liệu nhanh chóng theo khóa dựa giá trị khác entity/row/document Đây ví dụ truy vấn Tweeys theo User liệu có Nếu không tạo secondary index cách trả lời cho câu hỏi: “cho xem 25 tweets ayende?” Bởi liệu xếp theo tên cột giảm dần, lấy 25 tweets ayende Và ta muốn truy vấn 25 tweets (không theo user nào)? Rất đơn giản, cần truy vấn vào cột Tweets xếp theo khóa giảm dần Tại column family database lại bị giới hạn? - CFDB khó khăn việc nghiên cứu lúc đầu ví nhìn bên giống sở liệu quan hệ mà lại bị hạn chế nhiều Không có “join”, khả truy vấn thực sự(ngoại trừ - - - 3.1.2 - truy vấn theo khóa chính), phong phú hỗ trợ sở liệu quan hệ làm SQLite hay Access đem lại nhiều lợi ích CFDB Tại CFDB lại hạn chế vậy? Câu trả lời đơn giản CFDB thiết kế đê chạy số lượng lớn máy, lưu trữ lượng liệu cực lớn Chúng ta lưu trữ lượng lớn liệu sở liệu quan hệ chí nhiều máy Oracle RAC nhanh chóng bị sụp đổ chết nhanh kích thước liệu truy vấn CFDB xử lý cách dễ dàng Nhớ CFDB loại bỏ khái niệm trừu tượng, thứ làm cho cứng nhắt chạy cụm máy Lý mà CFDB không hỗ trợ join join yêu cầu quét toàn tập hợp liệu Điều yêu cầu phải có nơi có nhìn tổng quát toàn sở liệu(kết nút cổ chai điểm bị thất bại) thực truy vấn thực tất máy có cụm CFDB không cung cấp cách thức để truy vấn theo cột hay giá trị yêu cầu index toàn tập hợp liệu (hay cột nhất) Và lần không thực tế, chạy truy vấn tất máy Bằng cách giới hạn truy vấn theo khóa, CFDB đảm bảo biết xác node mà truy vấn thực Có nghĩa truy vấn chạy tập nhỏ liệu cho chi phí rẻ nhiều Nhiều hạn chế, khó sử dụng CFDB lại có khả mở rộng cao Đây điều cần quan tâm tới Key-Value Store/Tuple store Cơ sở liệu NoSQL đơn giản Key/Value stores Nó đơn giản API đơn giản, triển khai thực tế NoSQL thường phức tạp Hầu hết Key/Value stores thường có API sau: void Put(string key, byte[] data); byte[] Get(string key); void Remove(string key); - 3.1.3 Có nhiều biến thể Key/Value store sở cho tất biến thể Một Key/Value store cho phép lưu trữ giá trị khóa (key-value) Giá trị lưu dạng BLOB (Binary large object) Đơn giản lưu trữ liệu mà không quan tâm đến nội dung lưu trữ Nói cách khác, lưu trữ liệu mà không cần xác định lược đồ, phía client có định nghĩa mang tính tham khảo để biết liệu thực Lợi ích phương pháp đơn giản để xây dựng key/value store dễ dàng mở rộng Một key/value store có hiệu suất tốt mô hình truy cập liệu key/value store trọng nhiều vào việc tối ưu hóa Nói chúng, hầu hết thao tác key/value thực sử dụng O(1) có máy dùng để lưu trữ liệu liệu có độ lớn Document Store 3.1.3.1 Giới thiệu - Document store thực chất document-oriented database (cơ sở liệu hướng tài liệu) – thiết kế riêng biệt cho việc lưu trữ document - Nó chương trình máy tính thiết kế dùng để lưu trữ, truy lại quản lý hướng tài liệu, liệu bán cấu trúc ,hoặc thông tin Document-oriented databases loại sở liệu NoSQL biết đến với thuật ngữ “document-oriented document” (hay “document store”) Trái ngược lại với sở liệu quan hệ truyền thống-quan niệm “Relations” (hay “Tables”), hệ thống thiết kế xung quanh khái niệm trừu tượng gọi “document” 3.1.3.2 Document (tài liệu) - Khái niệm trung tâm document-oriented database khái niệm “document” Trong - loại document-oriented database triển khai không giống phần chi tiết so với định nghĩa nói chung tất giả định tài liệu đóng gói mã hóa liệu (thông tin) số định dạng tiêu chuẩn mã hóa Một số kiểu mã hóa sử dụng bao gồm XML, YAML, JSON, BSON, hình thức nhị phân PDF tài liệu Microsoft Office (MS Word, Excel …) Các document (tài liệu) bên document-oriented database tương tự nhau,nó gần giống với khái niệm “records” hay “row” sở liệu quan hệ truyền thống cứng nhắc Documents không bắt buộc phải tuân theo lược đồ tiêu chuẩn không cần phải có tất phần, chìa khóa, tương tự Ví dụ document: • FirstName:"Bob", Address:"5 Oak St.", Hobby:"sailing" Một document khác là: • - FirstName:"Jonathan", Address:"15 Wanamassa Point Road", Children: [{Name:"Michael",Age:10}, {Name:"Jennifer", Age:8}, {Name:"Samantha", Age:5}, {Name:"Elena", Age:2}] Cả hai document có số thông tin tương tự số thông tin khác Không giống sở liệu quan hệ truyền thống, nơi record(row) có tập hợp trường liệu (fields hay columns) trường liệu không sử dụng lưu trữ trống, document-oriented database trường liệu trống document Hệ thống cho phép thông tin thêm vào không đòi hỏi phải khai báo rõ ràng khác mẩu thông tin lại 3.1.3.3 Keys (Khóa) - Các document đề cập document-oriented database thông qua khóa đại diện cho documnet Thông thường, khóa chuỗi đơn giản Trong số trường hợp, chuỗi URI đường dẫn (path) Bạn sử dụng khóa để lấy document (tài liệu)từ sở liệu Thông thường, sở liệu lưu lại số (index)trong khóa document để document tìm kiếm nhanh chóng 3.1.3.4 Retrieval (truy lại hay tìm kiếm thông tin) - Một đặc điểm khác biệt document-oriented database việc sử dụng key-document (hoặc key-value) để lấy tài liệu, sở liệu cung cấp API ngôn ngữ truy vấn cho phép bạn lấy tài liệu dựa nội dung Ví dụ, bạn muốn truy vấn lấy toàn document mà document có tập hợp trường liệu định với giá trị định Tập hợp API truy vấn ngôn ngữ truy vấn tính có sẵn, hiệu mong đợi truy vấn, thay đổi đáng kể từ việc triển khai 3.1.3.5 Organization (Tổ chức) - Các triển khai cung cấp loạt cách xếp tài liệu, bao gồm khái niệm về: • • • • Collections Tags Non-visible Metadata Directory hierarchies 3.1.3.6 Implementations Name eXist Publisher eXist, [2] MUMPSDatabas e[7] License GPL Language Notes XQuery, Java XML over REST/HTTP, WebDAV, Lucene Fulltext search, validation, versioning, clustering, Yes [4] triggers, URL rewriting, collections, ACLS, XQuery Update Proprietary and MUMPS GNU Affero GPL[8] Lotus Notes IBM Proprietary LotusScript,Java, Lotus @Formula BaseX BaseX Team BSD License Java, XQuery RESTfulAPI Commonly used in health (unknown) applications (unknown) Support for XML, JSON Yes and binary formats; client-/server based architecture; concurrent structural and full-text Name Publisher License Language Notes searches and REST APIs OrientDB Orient Technologies Terrastore Jackrabbit Apache Software Foundation RESTfulAPI updates; Apache License Java JSON over HTTP Yes Apache License Java JSON/HTTP (unknown) Apache License Java (unknown) CouchDB Couchbase,Apac he Software Apache License Foundation Erlang JSON over REST/HTTP with Multi-Version Concurrency Control and Yes [3] limited ACID properties Usesmap and reduce for views and queries.[2] FleetDB FleetDB Clojure A JSON-based schemafree database optimized (unknown) for agile development MarkLogic ThruDB MarkLogic Corporation MIT License Free Express C++, XQuer license orCommerc y,XSLT ial BSD License C++, Java Fast, scalable, distributed, enterprise-grade document-oriented database with MultiVersion Concurrency Yes Control, integrated Full text search and ACIDcompliant transaction semantics Built on top of Apache (unknown) Thrift framework that Name Publisher License Language Notes RESTfulAPI provides indexing and document storage services for building and scaling websites Alternate implementation is being developed in Java Alpha software Clusterpoint MongoDB RavenDB Redis Free community Clusterpoint Ltd license C++ [1] /Commercial 10gen, Inc Hibernating Rhinos GNU AGPL v3.0 [5] C++ Scalable, highperformance, schema-free, document-oriented databas e management systemplatform with server based data storage, Yes fast full text search engine functionality, informationranking for search relevance and clustering Fast, document-oriented database optimized for Optional [6] highly transient data AGPL Free orCommercial JSON over REST/HTTP with a rich Net client API ACID compliant Uses Lucene.net to C#, F#,VB.NET provide indexes using Yes [9] a LINQ interface, optionally with MapReduce function ality BSD License ANSI C Key-value store (unknown) supporting lists and sets with fast, simple and Name Publisher License Language Notes RESTfulAPI binary-safe protocol Rocket U2 3.1.4 - Rocket Software Proprietary UniData, UniVerse Yes (Beta) Graph Database Graph database dạng sở liệu thiết kế riêng cho việc lưu trữ thông tin đồ họa cạnh, nút, properties Một số sản phẩm tiêu biểu: Neo4J, Sones, AllegroGraph, Core Data, DEX, FlockDB, InfoGrid, OpenLink Virtuoso, Name Language Notes AllegroGraph SPARQL RDF GraphStore DEX Java, C++ High-performance Graph Database FlockDB Scala InfiniteGraph Java Neo4j Java OpenLink Virtuoso C++, C#, Java, SPARQL OrientDB Java Pregel Sones GraphDB C# High-performance, scalable, distributed Graph Database middleware and database engine hybrid Name Language Notes OWLIM Java, SPARQL 1.1 RDF graph store with reasoning [...]... truy lại và quản lý hướng tài liệu, hoặc dữ liệu bán cấu trúc ,hoặc thông tin Document-oriented databases là một trong những loại chính của cơ sở dữ liệu NoSQL được biết đến với thuật ngữ “document-oriented document” (hay là “document store”) Trái ngược lại với cơ sở dữ liệu quan hệ truyền thống -quan niệm về “Relations” (hay “Tables”), những hệ thống này được thiết kế xung quanh một khái niệm trừu tượng... số thông tin khác nhau Không giống như một cơ sở dữ liệu quan hệ truyền thống, nơi mỗi record(row) có cùng một tập hợp trường dữ liệu (fields hay columns) và các trường dữ liệu này nếu không được sử dụng thì có thể được lưu trữ trống, còn trong một document-oriented database thì không có trường dữ liệu trống trong document Hệ thống này cho phép thông tin mới được thêm vào và nó không đòi hỏi phải khai... khóa này để lấy document (tài liệu) từ cơ sở dữ liệu Thông thường, cơ sở dữ liệu vẫn lưu lại một chỉ số (index)trong khóa của document để document có thể được tìm kiếm nhanh chóng 3.1.3.4 Retrieval (truy lại hay tìm kiếm thông tin) - Một trong các đặc điểm khác biệt của một document-oriented database là việc sử dụng key-document (hoặc key-value) để lấy một tài liệu, cơ sở dữ liệu sẽ cung cấp một API hoặc... cũng như các hình thức nhị phân như PDF và các tài liệu Microsoft Office (MS Word, Excel …) Các document (tài liệu) bên trong một document-oriented database thì tương tự nhau,nó gần giống với khái niệm “records” hay “row” trong cơ sở dữ liệu quan hệ truyền thống nhưng nó ít cứng nhắc hơn Documents không bắt buộc phải tuân theo một lược đồ tiêu chuẩn cũng không cần phải có tất cả các phần, chìa khóa, tương... optionally with MapReduce function ality BSD License ANSI C Key-value store (unknown) supporting lists and sets with fast, simple and Name Publisher License Language Notes RESTfulAPI binary-safe protocol Rocket U2 3.1.4 - Rocket Software Proprietary UniData, UniVerse Yes (Beta) Graph Database Graph database là một dạng cơ sở dữ liệu được thiết kế riêng cho việc lưu trữ thông tin đồ họa như cạnh, nút, properties... Affero GPL[8] Lotus Notes IBM Proprietary LotusScript,Java, Lotus @Formula BaseX BaseX Team BSD License Java, XQuery RESTfulAPI Commonly used in health (unknown) applications (unknown) Support for XML, JSON Yes and binary formats; client-/server based architecture; concurrent structural and full-text Name Publisher License Language Notes searches and REST APIs OrientDB Orient Technologies Terrastore... quanh một khái niệm trừu tượng gọi là “document” 3.1.3.2 Document (tài liệu) - Khái niệm trung tâm của document-oriented database là khái niệm “document” Trong - khi mỗi loại document-oriented database được triển khai không giống nhau ở phần chi tiết so với định nghĩa thì nói chung tất cả đều giả định các tài liệu đóng gói và mã hóa dữ liệu (thông tin) trong một số định dạng tiêu chuẩn hoặc mã hóa Một... việc sử dụng key-document (hoặc key-value) để lấy một tài liệu, cơ sở dữ liệu sẽ cung cấp một API hoặc ngôn ngữ truy vấn cho phép bạn lấy các tài liệu dựa trên nội dung Ví dụ, bạn muốn truy vấn lấy toàn bộ document mà những document đó có tập hợp trường dữ liệu nhất định với những giá trị nhất định Tập hợp các API truy vấn hoặc ngôn ngữ truy vấn là tính năng có sẵn, cũng như hiệu năng mong đợi của các... HTTP Yes Apache License Java JSON/HTTP (unknown) Apache License Java (unknown) CouchDB Couchbase,Apac he Software Apache License Foundation Erlang JSON over REST/HTTP with Multi-Version Concurrency Control and Yes [3] limited ACID properties Usesmap and reduce for views and queries.[2] FleetDB FleetDB Clojure A JSON-based schemafree database optimized (unknown) for agile development MarkLogic ThruDB... Built on top of Apache (unknown) Thrift framework that Name Publisher License Language Notes RESTfulAPI provides indexing and document storage services for building and scaling websites Alternate implementation is being developed in Java Alpha software Clusterpoint MongoDB RavenDB Redis Free community Clusterpoint Ltd license C++ [1] /Commercial 10gen, Inc Hibernating Rhinos GNU AGPL v3.0 [5] C++ Scalable, ... devices (OSD) 1.5 Một số khái niệm NoSQL - - - Fields – tương đương với khái niệm Columns SQL Document – thay khái niệm row SQL Đây khái niệm làm nên khác biệt NoSQL SQL, document chứa số cột (fields)... điều cần quan tâm tới Key-Value Store/Tuple store Cơ sở liệu NoSQL đơn giản Key/Value stores Nó đơn giản API đơn giản, triển khai thực tế NoSQL thường phức tạp Hầu hết Key/Value stores thường có... tính quán liệu từ bảng khác Non-relational khái niệm không sử dụng ràng buộc liệu cho quán liệu NoSQL database Distributed storage: mô hình lưu trữ phân tán file liệu nhiều máy tính khác mạng