2.1 Sự xuất hiện của thuật ngữ NoSQL
Gần đây, thuật ngữ "NoSQL" đã trở nên rất thời thượng và phổ biến, tất cả các loại giải pháp phần mềm đang được phát triển và quảng bá tích cực dưới dấu hiệu này. NoSQL đồng nghĩa với lượng dữ liệu khổng lồ, khả năng mở rộng tuyến tính, cụm, khả năng chịu lỗi, tính phi quan hệ. Tuy nhiên, ít người hiểu rõ về NoSQL storage là gì, thuật ngữ này xuất hiện như thế nào và chúng có đặc điểm chung gì. Hãy cố gắng lấp đầy khoảng trống này.
Điều thú vị nhất về thuật ngữ này là mặc dù thực tế là nó được sử dụng lần đầu tiên vào cuối những năm 90, nhưng nó chỉ có được ý nghĩa thực sự ở dạng mà nó được sử dụng hiện nay vào giữa năm 2009. Ban đầu, đây là tên của một -cơ sở dữ liệu nguồn được tạo bởi Carlo Strozzi, lưu trữ tất cả dữ liệu dưới dạng tệp ASCII và sử dụng các tập lệnh shell thay vì SQL để truy cập dữ liệu. Nó không liên quan gì đến "NoSQL" ở dạng hiện tại.
Vào tháng 6 năm 2009, Johan Oskarsson đã tổ chức một cuộc họp tại San Francisco để thảo luận về các xu hướng mới trong thị trường xử lý và lưu trữ CNTT. Động lực chính cho cuộc họp là các sản phẩm mã nguồn mở mới như BigTable và Dynamo. Để có một dấu hiệu sáng sủa cho một cuộc họp, cần phải tìm một thuật ngữ ngắn gọn và súc tích, hoàn toàn phù hợp với thẻ bắt đầu bằng # Twitter. Một trong những thuật ngữ này được đề xuất bởi Eric Evans từ RackSpace - "NoSQL". Thuật ngữ này chỉ được lên kế hoạch cho một cuộc họp và không có tải trọng ngữ nghĩa sâu sắc, nhưng nó đã tình cờ lan truyền khắp mạng toàn cầu như một quảng cáo lan truyền và trở thành tên thực tế của cả một hướng trong ngành CNTT. Nhân tiện, Voldemort (bản sao của Amazon Dynamo), Cassandra, Hbase (tương tự của Google BigTable), Hypertable, CouchDB, MongoDB đã phát biểu tại hội nghị.
Điều đáng nhấn mạnh một lần nữa là thuật ngữ "NoSQL" có nguồn gốc hoàn toàn tự phát và không có một định nghĩa hoặc tổ chức khoa học được chấp nhận chung đằng sau nó. Tên này đúng hơn là đặc trưng cho vectơ phát triển CNTT ngoài cơ sở dữ liệu quan hệ. Nó là viết tắt của Not Only SQL, mặc dù có những người ủng hộ định nghĩa trực tiếp về No SQL. Pramod Sadalaj và Martin Fowler đã cố gắng nhóm lại và hệ thống hóa kiến thức về thế giới NoSQL trong cuốn sách gần đây của họ "NoSQL Distilled".
2.2 Đặc điểm cơ bản của cơ sở dữ liệu NoSQL
Có một vài đặc điểm chung cho tất cả NoSQL, vì nhiều hệ thống không đồng nhất hiện được ẩn dưới nhãn NoSQL (có lẽ danh sách đầy đủ nhất có thể được tìm thấy tại http://nosql-database.org/). Nhiều đặc điểm chỉ dành riêng cho một số cơ sở dữ liệu NoSQL nhất định, tôi chắc chắn sẽ đề cập đến điều này khi liệt kê.
1. Không sử dụng SQL
Ý tôi là ANSI SQL DML, vì nhiều cơ sở dữ liệu cố gắng sử dụng các ngôn ngữ truy vấn tương tự như cú pháp yêu thích nổi tiếng, nhưng không ai quản lý để triển khai đầy đủ nó và khó có thể thành công. Mặc dù có tin đồn rằng các công ty khởi nghiệp đang cố triển khai SQL, chẳng hạn như trong hadup ( http://www.drawntoscalehq.com/ và http://www.hadapt.com/ ).
2. Không cấu trúc (schemaless)
Ý nghĩa là trong cơ sở dữ liệu NoQuery, không giống như cơ sở dữ liệu quan hệ, cấu trúc dữ liệu không được quy định (hoặc được nhập yếu, nếu chúng ta vẽ tương tự với ngôn ngữ lập trình) - bạn có thể thêm một trường tùy ý vào một dòng hoặc tài liệu riêng biệt mà không cần thay đổi cấu trúc trước tiên của toàn bộ bảng. Vì vậy, nếu có nhu cầu thay đổi mô hình dữ liệu, thì hành động đủ duy nhất là phản ánh sự thay đổi trong mã ứng dụng.
Ví dụ: khi đổi tên một trường trong MongoDB:
BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"Nếu chúng tôi thay đổi logic ứng dụng, thì chúng tôi cũng mong đợi một trường mới khi đọc. Nhưng do thiếu lược đồ dữ liệu, trường tổng cộng bị thiếu trong các đối tượng Đơn hàng đã tồn tại khác. Trong tình huống này, có hai lựa chọn cho hành động tiếp theo.
Đầu tiên là thu thập dữ liệu tất cả các tài liệu và cập nhật trường này trong tất cả các tài liệu hiện có. Do khối lượng dữ liệu, quá trình này xảy ra mà không có bất kỳ khóa nào (có thể so sánh với lệnh thay đổi tên cột đổi tên bảng), vì vậy trong quá trình cập nhật, dữ liệu hiện có có thể được đọc bởi các quy trình khác. Do đó, tùy chọn thứ hai - kiểm tra mã ứng dụng - là không thể tránh khỏi:
BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum == null)
totalSum = order.getDouble("totalSum"); // This is the updated modelVà khi chúng tôi ghi lại, chúng tôi sẽ ghi trường này vào cơ sở dữ liệu ở định dạng mới.
Một hệ quả thú vị của việc không có lược đồ là hiệu quả làm việc với dữ liệu thưa thớt. Nếu một tài liệu có trường date_published còn tài liệu thứ hai thì không, thì sẽ không có trường date_published trống nào được tạo cho tài liệu thứ hai. Về nguyên tắc, điều này là hợp lý, nhưng một ví dụ ít rõ ràng hơn là cơ sở dữ liệu NoSQL theo họ cột, sử dụng các khái niệm quen thuộc về bảng/cột. Tuy nhiên, do thiếu lược đồ, các cột không được khai báo và có thể được thay đổi/thêm vào trong phiên cơ sở dữ liệu của người dùng. Đặc biệt, điều này cho phép sử dụng các cột động để triển khai danh sách.
Lược đồ phi cấu trúc có nhược điểm của nó - ngoài chi phí đã đề cập ở trên trong mã ứng dụng khi thay đổi mô hình dữ liệu - không có tất cả các loại hạn chế từ cơ sở (không rỗng, duy nhất, ràng buộc kiểm tra, v.v.), cộng với đó là những khó khăn khác trong việc hiểu và kiểm soát dữ liệu cấu trúc khi làm việc song song với cơ sở dữ liệu của các dự án khác nhau (không có từ điển bên cạnh cơ sở dữ liệu). Tuy nhiên, trong một thế giới hiện đại đang thay đổi nhanh chóng, sự linh hoạt như vậy vẫn là một lợi thế. Một ví dụ là Twitter, cách đây 5 năm, cùng với dòng tweet, chỉ lưu trữ một ít thông tin bổ sung (thời gian, cách xử lý Twitter và một vài byte thông tin meta khác), nhưng bây giờ, ngoài bản thân tin nhắn, còn một số thông tin khác kilobyte siêu dữ liệu được lưu trữ trong cơ sở dữ liệu.
(Sau đây, chúng ta chủ yếu nói về cơ sở dữ liệu khóa-giá trị, tài liệu và họ cột, cơ sở dữ liệu đồ thị có thể không có các thuộc tính này)
2.3. Biểu diễn dữ liệu dưới dạng tập hợp (aggregate)
Không giống như mô hình quan hệ lưu trữ thực thể nghiệp vụ logic của ứng dụng vào các bảng vật lý khác nhau cho mục đích chuẩn hóa, các cửa hàng NoSQL hoạt động trên các thực thể này dưới dạng các đối tượng tổng thể:
Ví dụ này thể hiện các tập hợp cho một mô hình quan hệ khái niệm thương mại điện tử tiêu chuẩn "Đặt hàng - Mục đặt hàng - Thanh toán - Sản phẩm". Trong cả hai trường hợp, thứ tự được kết hợp với các vị trí thành một đối tượng logic, trong khi mỗi vị trí lưu trữ một liên kết đến sản phẩm và một số thuộc tính của nó, chẳng hạn như tên (việc không chuẩn hóa như vậy là cần thiết để không yêu cầu đối tượng sản phẩm khi truy xuất một trật tự - quy tắc chính của các hệ thống phân tán là "liên kết" giữa các đối tượng). Trong một tập hợp, các khoản thanh toán được kết hợp với đơn đặt hàng và là một phần không thể thiếu của đối tượng, trong một tập hợp khác, chúng được đặt trong một đối tượng riêng biệt. Điều này thể hiện quy tắc chính để thiết kế cấu trúc dữ liệu trong cơ sở dữ liệu NoSQL - nó phải tuân theo các yêu cầu của ứng dụng và được tối ưu hóa nhiều nhất có thể cho các truy vấn thường xuyên nhất.
Nhiều người sẽ phản đối, lưu ý rằng làm việc với các đối tượng lớn, thường không chuẩn hóa, có nhiều vấn đề khi thử các truy vấn tùy ý trên dữ liệu khi các truy vấn không phù hợp với cấu trúc của các tập hợp. Điều gì sẽ xảy ra nếu chúng tôi sử dụng đơn đặt hàng cùng với mục hàng đặt hàng và thanh toán (đây là cách ứng dụng hoạt động), nhưng doanh nghiệp yêu cầu chúng tôi đếm xem có bao nhiêu đơn vị sản phẩm cụ thể đã được bán vào tháng trước? Trong trường hợp này, thay vì quét bảng OrderItem (trong trường hợp là mô hình quan hệ), chúng tôi sẽ phải truy xuất toàn bộ đơn hàng trong bộ lưu trữ NoSQL, mặc dù chúng tôi sẽ không cần nhiều thông tin này. Thật không may, đây là một thỏa hiệp phải được thực hiện trong một hệ thống phân tán: chúng tôi không thể chuẩn hóa dữ liệu như trong hệ thống một máy chủ thông thường,
Tôi đã cố gắng nhóm các ưu và nhược điểm của cả hai cách tiếp cận trong một bảng:
