Việc sử dụng Cơ sở dữ liệu NoQuery có thực tế đối với các bộ dữ liệu lớn mà bạn cần tìm kiếm theo nội dung không?

Tôi đã tìm hiểu về Cơ sở dữ liệu NoQuery một tuần nay.

Tôi thực sự hiểu những lợi thế của Cơ sở dữ liệu NoQuery và nhiều trường hợp sử dụng mà chúng rất phù hợp.

Nhưng mọi người thường viết các bài báo của họ như thể NoQuery có thể thay thế Cơ sở dữ liệu quan hệ. Và có một điểm tôi không thể hiểu được:

Cơ sở dữ liệu NoQuery là (thường) lưu trữ khóa-giá trị.

Tất nhiên có thể lưu trữ mọi thứ vào kho lưu trữ khóa-giá trị (bằng cách mã hóa dữ liệu bằng JSON, XML, bất cứ điều gì), nhưng vấn đề tôi thấy là bạn cần lấy một lượng dữ liệu phù hợp với một tiêu chí cụ thể, trong nhiều trường hợp sử dụng. Trong cơ sở dữ liệu NoQuery, bạn chỉ có một tiêu chí bạn có thể tìm kiếm một cách hiệu quả - khóa. Cơ sở dữ liệu quan hệ được tối ưu hóa để tìm kiếm bất kỳ giá trị nào trong hàng dữ liệu một cách hiệu quả.

Vì vậy, Cơ sở dữ liệu NoQuery không thực sự là một lựa chọn cho việc lưu giữ dữ liệu cần tìm kiếm theo nội dung của chúng. Hay tôi đã hiểu lầm điều gì?

Một ví dụ:

Bạn cần lưu trữ dữ liệu người dùng cho một webshop.

Trong cơ sở dữ liệu quan hệ, bạn lưu trữ mọi người dùng dưới dạng một hàng trong usersbảng, với ID, tên, quốc gia của anh ấy, v.v.

Trong Cơ sở dữ liệu NoQuery, bạn sẽ lưu trữ mỗi người dùng với ID của mình làm khóa và tất cả dữ liệu của anh ấy (được mã hóa bằng JSON, v.v.) làm giá trị.

Vì vậy, nếu bạn cần đưa tất cả người dùng từ một quốc gia cụ thể (vì một số lý do mà các nhân viên tiếp thị cần biết điều gì đó về họ), thì việc đó dễ dàng thực hiện trong Cơ sở dữ liệu quan hệ, nhưng không hiệu quả lắm trong Cơ sở dữ liệu NoQuery, bởi vì bạn phải nhận mọi người dùng, phân tích tất cả dữ liệu và bộ lọc.

Tôi không nói điều đó là không thể , nhưng nó phức tạp hơn nhiều và tôi đoán là không hiệu quả nếu bạn muốn tìm kiếm trong dữ liệu của các mục nhập của NoQuery.

Bạn có thể tạo khóa cho mỗi quốc gia lưu trữ khóa của mọi người dùng sống ở quốc gia này và nhận người dùng của một quốc gia cụ thể bằng cách lấy tất cả các khóa được gửi vào khóa cho quốc gia này. Nhưng tôi nghĩ rằng techique này làm cho một bộ dữ liệu phức tạp thậm chí còn phức tạp hơn - khó thực hiện hơn và không hiệu quả như truy vấn Cơ sở dữ liệu SQL. Vì vậy, tôi nghĩ rằng đó không phải là cách bạn sẽ sử dụng trong sản xuất. Hoặc là nó?

Tôi không thực sự chắc chắn nếu tôi hiểu nhầm điều gì đó hoặc bỏ qua một số khái niệm hoặc thực tiễn tốt nhất để xử lý các trường hợp sử dụng đó. Có lẽ bạn có thể sửa các phát biểu của tôi và trả lời câu hỏi của tôi.

Mặc dù tôi đồng ý với tiền đề của bạn rằng NoQuery không phải là thuốc chữa bách bệnh cho tất cả các tai ương cơ sở dữ liệu, tôi nghĩ bạn hiểu sai một điểm chính.

Trong cơ sở dữ liệu NoQuery, bạn chỉ có một tiêu chí bạn có thể tìm kiếm một cách hiệu quả - khóa.

Điều này rõ ràng là không đúng sự thật.

Ví dụ MongoDB hỗ trợ các chỉ số. (từ https://docs.mongodb.org/v3.0/core/indexes-int sinhtion / )

Các chỉ mục hỗ trợ thực hiện hiệu quả các truy vấn trong MongoDB. Không có chỉ mục, MongoDB phải thực hiện quét bộ sưu tập, tức là quét mọi tài liệu trong bộ sưu tập, để chọn những tài liệu phù hợp với câu lệnh truy vấn. Nếu một chỉ mục thích hợp tồn tại cho một truy vấn, MongoDB có thể sử dụng chỉ mục để giới hạn số lượng tài liệu mà nó phải kiểm tra.

Các chỉ mục là các cấu trúc dữ liệu đặc biệt [1] lưu trữ một phần nhỏ dữ liệu của bộ sưu tập ở dạng dễ dàng di chuyển ngang. Chỉ mục lưu trữ giá trị của một trường cụ thể hoặc tập hợp các trường, được sắp xếp theo giá trị của trường. Thứ tự của các mục chỉ mục hỗ trợ khớp bằng hiệu quả và hoạt động truy vấn dựa trên phạm vi. Ngoài ra, MongoDB có thể trả về kết quả được sắp xếp bằng cách sử dụng thứ tự trong chỉ mục.

Cũng như couchbase (từ http://docs.couchbase.com/admin/admin/Views/view-intro.html )

Chế độ xem Couchbase cho phép lập chỉ mục và truy vấn dữ liệu.

Một khung nhìn tạo ra một chỉ mục trên dữ liệu theo định dạng và cấu trúc được xác định. Khung nhìn bao gồm các trường và thông tin cụ thể được trích xuất từ ​​các đối tượng trong Couchbase.

Trong thực tế, bất cứ thứ gì tự gọi là cơ sở dữ liệu NoQuery chứ không phải là kho lưu trữ khóa-giá trị thực sự nên hỗ trợ một số loại lược đồ lập chỉ mục.

Trong thực tế, chính sự linh hoạt của các lược đồ chỉ mục này làm cho NoQuery tỏa sáng. Theo tôi, ngôn ngữ được sử dụng để xác định các chỉ mục NoQuery thường biểu cảm hoặc tự nhiên hơn SQL và vì chúng thường sống bên ngoài bảng, bạn không cần thay đổi lược đồ bảng để hỗ trợ chúng. (Không phải nói rằng bạn không thể làm những điều tương tự trong SQL nhưng với tôi cảm giác như có rất nhiều hoạt động nhảy liên quan).

Nói chung, nếu quy trình làm việc của bạn phù hợp hoàn hảo cho các truy vấn cơ sở dữ liệu quan hệ, bạn sẽ thấy cơ sở dữ liệu quan hệ là cách tiếp cận hiệu quả nhất. Đó là loại tautological, nhưng nó đúng.

Khiếu nại mà nhiều người ủng hộ NoQuery sẽ đưa ra là nhiều quy trình công việc thực sự được mát xa thành một hình thức quan hệ và sẽ có hiệu quả hơn trước khi xoa bóp như vậy. Hiệu lực của khiếu nại này rất phức tạp để xác định. Rõ ràng có những công việc được mô tả rất tốt bởi các truy vấn SQL. Tôi có thể nói từ kinh nghiệm của mình rằng các tác vụ lập trình quan hệ cụ thể của tôi có thể đã được thực hiện bằng cách sử dụng NoQuery với mức độ hiệu quả gần như tương tự, nếu không muốn nói là nhiều hơn. Tuy nhiên, đó là một tuyên bố rất chủ quan dựa trên kinh nghiệm hẹp.

Tôi có cảm giác phần lớn việc bán phương pháp NoQuery xuất phát từ giả định cơ sở dữ liệu lớn. Cơ sở dữ liệu càng lớn, bạn càng phải chuẩn bị quy trình làm việc của mình để hỗ trợ các bộ dữ liệu lớn hơn. NoQuery dường như tốt hơn trong việc hỗ trợ nỗ lực chải chuốt đó. Do đó, cơ sở dữ liệu càng lớn, các tính năng của NoQuery càng quan trọng.

Để sử dụng ví dụ, trong SQL truy vấn theo quốc gia cũng chậm như quét NoQuery của tất cả người dùng, trừ khi bạn nói rõ ràng với SQL để lập chỉ mục usersbảng theo quốc gia. NoQuery có thể làm tương tự, trong đó bạn tạo một bộ sưu tập khóa-giá trị được đặt hàng là chỉ mục (giống như SQL thực hiện trong phần mềm) và duy trì nó.

Sự khác biệt? Các công cụ SQL có khái niệm lập chỉ mục bảng được tích hợp. Điều này có nghĩa là bạn phải thực hiện ít công việc hơn (tất cả những gì bạn phải làm là thêm một chỉ mục vào bảng). Tuy nhiên, nó cũng có nghĩa là bạn đã kiểm soát ít hơn. Đối với hầu hết các trường hợp, sự mất kiểm soát đó là chấp nhận được, để đổi lấy công cụ SQL thực hiện công việc cho bạn. Tuy nhiên, trong các bộ dữ liệu lớn, bạn có thể muốn một mô hình nhất quán khác với mô hình ACID SQL điển hình. Bạn có thể muốn sử dụng mô hình BASE hỗ trợ tính nhất quán cuối cùng. Điều đó có thể rất khó khăn trong SQL, bởi vì công cụ SQL đang thực hiện công việc cho bạn nên nó phải được thực hiện theo quy tắc của công cụ SQL. Trong NoQuery, các lớp đó thường được hiển thị, cho phép bạn hack chúng.

NoQuery là một thuật ngữ khá mơ hồ, vì về cơ bản nó bao gồm tất cả các hệ thống cơ sở dữ liệu không liên quan.

Những gì bạn mô tả là một kho lưu trữ khóa-giá trị , là một loại cơ sở dữ liệu trong đó một kho dữ liệu được lưu trữ dưới một khóa và có thể nhanh chóng tra cứu nếu bạn biết khóa. Các cơ sở dữ liệu này rất nhanh nếu bạn biết khóa chính xác, nhưng như bạn tự nói, nếu bạn cần tìm kiếm hoặc lọc trên nhiều thuộc tính trên dữ liệu, nó sẽ chậm và cồng kềnh.

Không ai trong tâm trí của họ sẽ tuyên bố rằng các cửa hàng giá trị khóa có thể thay thế cơ sở dữ liệu quan hệ nói chung. Tuy nhiên, có thể có các trường hợp sử dụng cụ thể trong đó cửa hàng khóa-giá trị là phù hợp. Các cửa hàng giá trị khóa thường được sử dụng để lưu vào bộ đệm, vì bạn thường lưu trữ các mục theo id, nhưng bạn không cần thực hiện các truy vấn đặc biệt qua bộ đệm. Ví dụ, chính trang web Stackoverflow sử dụng rộng rãi Redis (db-value-value) , nhưng chỉ để lưu vào bộ đệm. Dữ liệu chính tắc cơ bản vẫn được duy trì trong cơ sở dữ liệu quan hệ.

Vì vậy, câu trả lời là khá rõ ràng: Sử dụng một kho lưu trữ khóa-giá trị nếu bạn chỉ cần lưu trữ và tra cứu bằng một khóa duy nhất. Nếu không thì sử dụng một loại cơ sở dữ liệu khác nhau. Và nếu bạn nghi ngờ, hãy sử dụng cơ sở dữ liệu quan hệ, vì đây là loại cơ sở dữ liệu linh hoạt nhất, trong khi cơ sở dữ liệu NoQuery thường được tối ưu hóa cho các trường hợp sử dụng rất cụ thể.

Những khẳng định của bạn về cơ sở dữ liệu quan hệ đều hoàn toàn đúng, cho đến khi bạn có quá nhiều dữ liệu, bạn không thể phù hợp với một bản sao của nó trên một máy chủ nữa. Sau đó, bạn bắt đầu chạy vào tất cả các loại vấn đề thú vị. Làm thế nào để bạn chia nhỏ các bảng của bạn để hầu hết các truy vấn của bạn có thể chạy trên một máy chủ? Bạn tạo ra bao nhiêu bản sao của dữ liệu? Làm thế nào để bạn đối phó với sự không nhất quán giữa các bản sao? Làm thế nào để bạn giữ dữ liệu của người dùng trong một trung tâm dữ liệu tương đối gần với anh ấy hoặc cô ấy về mặt địa lý?

Những mục tiêu này thường xung đột với nhau. Rất nhiều người dùng twitter theo dõi mọi người từ khắp nơi trên thế giới. Cơ sở dữ liệu của twitter có nên được tối ưu hóa về mặt địa lý để đọc tweet hoặc viết tweet không?

Hóa ra khi bạn đối phó với loại quy mô đó, bạn bắt đầu phát minh ra các giải pháp, thêm các khoản dự phòng và áp đặt các hạn chế rất giống với cơ sở dữ liệu NoQuery. Nếu bạn có thể phù hợp với tất cả dữ liệu của mình trên một hộp, bạn chỉ nhận được các hạn chế và không có nhu cầu về lợi ích.

Các cơ sở dữ liệu NoQuery có rất ít liên quan đến với No No SQL.

Họ nói về việc thừa nhận rằng bạn không thể có một cơ sở dữ liệu ở quy mô luôn nhất quán và hỗ trợ các giao dịch phức tạp và có độ bền.

Trong cơ sở dữ liệu quan hệ bình thường, tất cả các chỉ mục được tự động cập nhật trong phạm vi giao dịch, do đó có thể được sử dụng cho mọi truy vấn.

Trong cơ sở dữ liệu NoQuery, lập trình viên chịu trách nhiệm duy trì rất nhiều chỉ mục và người ta cho rằng các chỉ mục sẽ luôn bị lỗi thời.

Ví dụ:

• Một chỉ số của những người theo số thuế có thể chứa một số người không bao giờ hoàn thành quá trình đăng ký thuế.
• Do đó, mã sử dụng chỉ mục phải có khả năng đối phó với việc đăng ký thuế không đầy đủ
• Một lựa chọn khác là có những lúc một người được đăng ký thuế không có trong chỉ mục. (Vì vậy, thiết kế của bạn phải đối phó với việc không có dữ liệu nhất quán và quyết định cách dữ liệu sẽ không nhất quán.)

Như một ví dụ thực tế, Amazon thà cho tôi xem mô tả lỗi thời của một cuốn sách hơn là trì hoãn việc hiển thị trang web bằng cách đợi 106 máy tính xác nhận rằng đã khóa chính xác.

Vì thế.....

Nếu một cơ sở dữ liệu quan hệ bình thường duy nhất có thể chứa tất cả dữ liệu của bạn và xử lý từng giao dịch đủ nhanh để việc khóa không ngăn hệ thống của bạn thực hiện công việc hữu ích, cơ sở dữ liệu quan hệ là lựa chọn tốt nhất.

Nhưng ngay khi bạn phải bắt đầu suy nghĩ về việc sử dụng nhiều hơn một cơ sở dữ liệu quan hệ hoặc chia nhỏ các giao dịch để tránh các lỗi khóa, bạn sẽ phải đối phó với các vấn đề bạn gặp phải khi sử dụng cơ sở dữ liệu của No No.

Vì cơ sở dữ liệu của Norton NoQuery không che giấu những vấn đề này, chúng có thể trở thành lựa chọn tốt nhất khi bạn mở rộng hệ thống. Nhưng hãy nhớ rằng Stackoverflow vẫn sử dụng cơ sở dữ liệu quan hệ để lưu trữ tất cả dữ liệu của nó, với việc sử dụng hạn chế NoQuery trong lớp bộ đệm - vì vậy bạn phải RẤT lớn trước khi bạn buộc phải sử dụng NoQuery để lưu trữ dữ liệu của mình.

Cơ sở dữ liệu quan hệ được tối ưu hóa để tìm kiếm bất kỳ giá trị nào trong cơ sở dữ liệu một cách hiệu quả.

Đừng nhầm lẫn khả năng tìm kiếm trên bất kỳ giá trị "bất kỳ" nào trong một hàng với giá trị "mọi" trong một hàng. Cách hiệu quả nhất để làm điều này đòi hỏi một hoặc nhiều chỉ mục. Bạn có thể có các chỉ mục bao gồm tất cả các trường, nhưng sau đó bạn chỉ cản trở khả năng thực hiện các thay đổi yêu cầu thay đổi chỉ mục (chèn, cập nhật, xóa). Bạn (hoặc DBA của bạn) phải hiểu dữ liệu, cách sử dụng, tắc nghẽn, v.v.

Đã có nhiều câu trả lời, nhưng tôi chỉ muốn thêm tóm tắt của mình.

Rõ ràng khái niệm NoQuery bao gồm nhiều cách tiếp cận khác nhau trong việc tổ chức dữ liệu trên đĩa, trong bộ nhớ và hiển thị thông qua ngôn ngữ truy vấn (một số thậm chí giống như SQL!). Theo quan điểm của tôi, sức mạnh đến từ hệ thống đa dạng này để bạn có thể chọn công cụ tốt nhất cho công việc. Nhưng vẫn hy vọng bạn có thể đáp ứng hàng tá nhu cầu khác nhau chỉ bằng một vài giải pháp khác nhau, bạn sẽ không muốn quản lý hàng tá hệ thống khác nhau.

Cơ sở dữ liệu quan hệ có thể giúp bạn đi rất xa và là một công nghệ đã được chứng minh, nhưng cũng giống như cơ sở dữ liệu bạn có thể muốn chọn ngôn ngữ lập trình dựa trên nhu cầu của từng dự án (nhưng cũng tính đến kinh nghiệm của nhóm).

Tôi đã sử dụng couchdb được hai năm rồi. Nó chủ yếu được sử dụng để quản lý nội dung và cấu hình.

Đối với các mối quan hệ phân cấp sẽ dễ quản lý hơn nhiều khi bạn có thể hình dung chúng. Đối với dữ liệu chủ yếu là đọc, việc chỉnh sửa JSON dễ dàng hơn so với việc viết câu lệnh CẬP NHẬT trong nhiều trường hợp. Thực tế, không cần một lập trình viên để chỉnh sửa JSON. Và SQL cung cấp cho bạn các hàng và cột, sau đó bạn phải ánh xạ vào một số loại cấu trúc đối tượng.

Bạn cũng được tăng hiệu suất vì bạn không tham gia 10-20 bảng trên các truy vấn phức tạp. Lượt xem Couchdb rất nhanh vì javascript mà chúng dựa trên không được thực thi tại thời điểm truy vấn.

Hầu hết các lập trình viên đều hiểu Javascript và đôi khi hầu hết các lập trình viên phải vật lộn với SQL.

Trong Couchdb, một khung nhìn có thể được coi là một bản tóm tắt của tài liệu JSON. Làm thế nào dữ liệu xem được cấu trúc là tùy thuộc vào bạn (bạn không bị ràng buộc bởi hệ thống phân cấp ban đầu).

Tôi sẽ không sử dụng Couchdb cho dữ liệu giao dịch cao, nhưng đối với dữ liệu bán tĩnh có cấu trúc kiểu nổ phần, thì nó dễ làm việc hơn so với SQL.

Tuy nhiên, xin lưu ý rằng không có 'bình thường hóa' rõ ràng nào có thể được áp dụng (mặc dù tránh trùng lặp dữ liệu là mục tiêu xứng đáng), và về cơ bản và chiến lược cập nhật 'lạc quan' gần giống với khóa lạc quan.