Tại sao NoQuery nhanh hơn SQL?

48

Gần đây tôi được hỏi:

Tại sao NoQuery nhanh hơn SQL?

Tôi đã không đồng ý với tiền đề của câu hỏi ... cá nhân tôi thật vô lý. Tôi không thể thấy bất kỳ sự tăng hiệu suất nào bằng cách sử dụng NoQuery thay vì SQL. Có thể SQL qua NoQuery, có nhưng không phải theo cách đó.

Tôi có thiếu điều gì về NoQuery không?

performance nosql

— cnd
nguồn

3

Nếu bạn không thể thấy tăng hiệu suất, đó là những gì bạn nói. Thực tế là hầu hết các giải pháp NoQuery đều bỏ qua một (hoặc nhiều) thuộc tính ACID của cơ sở dữ liệu quan hệ, do đó chúng làm ít hơn.

— Oded

1

Có một số quy trình công việc (và cấu trúc dữ liệu) không thể dễ dàng được ánh xạ tới cơ sở dữ liệu quan hệ hỗ trợ ACID truyền thống. Đối với những người này, bạn có thể thấy hiệu suất tăng rất lớn bằng cách sử dụng cơ sở dữ liệu NoQuery. Tuy nhiên, nếu bạn chỉ cần lấy một DB DB (được thiết kế tốt) hiện có và đưa nó vào Cơ sở dữ liệu NoQuery, thì hiệu suất của bạn chắc chắn sẽ bị ảnh hưởng.

— Joachim Sauer

1

Câu trả lời là: Nó đã được thành lập nhanh hơn? Và nhanh hơn trong những gì? Thời gian phát triển? Thơi gian đọc? Viết thời gian? Những loại viết? Chúng ta đang so sánh nó với cái gì? Truy vấn nhiều bảng? Tham gia?

— Rolf

65

Có rất nhiều giải pháp NoQuery xung quanh, mỗi giải pháp đều có điểm mạnh và điểm yếu riêng, vì vậy những điều sau đây phải được thực hiện bằng một hạt muối.

Nhưng về cơ bản, những gì nhiều cơ sở dữ liệu NoQuery làm là dựa vào việc không chuẩn hóa và cố gắng tối ưu hóa cho trường hợp không chuẩn hóa. Ví dụ, giả sử bạn đang đọc một bài đăng blog cùng với các bình luận trong cơ sở dữ liệu hướng tài liệu. Thông thường, các bình luận sẽ được lưu cùng với chính bài đăng. Điều này có nghĩa là sẽ nhanh hơn để truy xuất tất cả chúng cùng nhau, vì chúng được lưu trữ ở cùng một nơi và bạn không phải thực hiện nối.

Tất nhiên, bạn có thể làm tương tự trong SQL và việc không chuẩn hóa là một cách phổ biến khi một người cần hiệu năng. Chỉ có nhiều giải pháp NoQuery được thiết kế từ đầu để luôn được sử dụng theo cách này. Sau đó, bạn nhận được sự đánh đổi thông thường: ví dụ, việc thêm một nhận xét trong ví dụ trên sẽ chậm hơn vì bạn phải lưu toàn bộ tài liệu với nó. Và một khi bạn đã không chuẩn hóa, bạn phải bảo toàn tính toàn vẹn dữ liệu trong ứng dụng của mình.

Hơn nữa, trong nhiều giải pháp NoQuery, không thể thực hiện các phép nối tùy ý, do đó các truy vấn tùy ý. Một số cơ sở dữ liệu, như CouchDB, yêu cầu bạn phải suy nghĩ trước các truy vấn bạn sẽ cần và chuẩn bị chúng bên trong DB.

Nói chung, nó tập trung vào việc mong đợi một lược đồ không chuẩn hóa và tối ưu hóa các lần đọc cho tình huống đó và điều này hoạt động tốt đối với dữ liệu không liên quan cao và yêu cầu đọc nhiều hơn ghi.

— Andrea
nguồn

4

Điều này, bằng cách này có thể được nhận ra với chế độ xem được vật chất hóa đơn giản hoặc một lớp bộ đệm, trong khi vẫn được hưởng lợi từ tất cả các tính tốt của SQL. Bất cứ điều gì được mô hình hóa đúng là quan hệ và sao chép dữ liệu lôgic không phải là một giải pháp (chế độ xem mat là một bản sao nhưng không phải là sao chép logic vì nó chỉ là hình ảnh của một cái gì đó khác).

— Mẹ ơi.

Như tôi đã nói trong câu trả lời, người ta có thể làm tương tự trong SQL; chỉ là khi điều này trở thành quy tắc thay vì ngoại lệ, cơ sở dữ liệu NoQuery thường nhanh hơn và tự nhiên hơn để sử dụng. Về lý thuyết, SQL là mô hình tốt nhất mà người ta có thể sử dụng, nhưng khi dữ liệu phát triển trên một kích thước nhất định, nó không thể chứa được một số mô hình và việc sao chép dữ liệu trở nên nhanh hơn và dễ dàng hơn để lý giải.

— Andrea

3

Đó là con bò. Mô hình quan hệ bao gồm mọi thứ bạn có thể thực hiện trong NoQuery và hơn thế nữa. Ưu điểm duy nhất của NoQuery là cách tiếp cận đơn giản và không nhất quán để mở rộng quy mô được tích hợp và dễ sử dụng. Nó không liên quan gì đến SQL và mọi thứ liên quan đến việc không quan tâm đến các thuộc tính ACID. Bạn có thể có các công việc đồng bộ giữa các nút SQL độc lập sẽ có các thuộc tính tỷ lệ và tính nhất quán giống hệt nhau (rất xấu) mà các cửa hàng NoQuery có. Sự khác biệt là các nút SQL có thể CSONG có tính nhất quán nếu bạn chọn.

— Mẹ ơi.

1

Điều gì sẽ xảy ra nếu bạn có 5.000.000 triệu hàng dữ liệu và bạn muốn nhận được nhận xét từ tất cả chúng theo một số điều kiện. Sẽ không nhanh hơn nếu bạn có một chỉ mục trên trường nhận xét của bảng bằng SQL? Lập chỉ mục toàn văn sẽ cải thiện hơn nữa điều này.

— jwize

@morg - "Mô hình quan hệ bao gồm mọi thứ bạn có thể thực hiện trong NoQuery và hơn thế nữa." Không thực sự, không. Có rất nhiều ví dụ về các loại dữ liệu rất phù hợp với mô hình quan hệ buộc dữ liệu vào đó dẫn đến sự kém hiệu quả. Ví dụ: một trò chơi trực tuyến có một cơ sở để lưu trữ hàng tồn kho của người chơi. Người chơi có một bộ hữu hạn các vị trí được đánh số, mỗi vị trí có thể lưu trữ một hoặc nhiều vật phẩm thuộc một loại cụ thể. Có khoảng 50 loại vật phẩm khác nhau, mỗi loại có từ 4 đến 6 thuộc tính được liên kết, với một số thuộc tính trùng lặp, do đó, có khoảng 80 thuộc tính có thể ...

— Jules

27

Điều bạn còn thiếu về NoQuery là NoSQl không thể so sánh với SQL theo bất kỳ cách nào. NoQuery là tên của tất cả các công nghệ bền bỉ không phải là SQL. DB tài liệu, DB giá trị khóa, DB sự kiện đều là NoQuery. Chúng đều khác nhau ở hầu hết các khía cạnh, có thể là cấu trúc của dữ liệu đã lưu, truy vấn, hiệu suất và các công cụ có sẵn.

Vì vậy, nếu ai đó hỏi bạn câu hỏi như vậy khi phỏng vấn, đây sẽ là câu trả lời.

— Hưng phấn
nguồn

4

Nếu có một tính năng giết người của NoQuery, tôi sẽ nói đó là khả năng mở rộng. Đó là lý do tại sao Facebook và Googles sử dụng nó. Bởi vì khối lượng dữ liệu khổng lồ. NoQuery: khi bạn phải xử lý lượng dữ liệu khổng lồ.

— Pieter B

16

Các cơ sở dữ liệu 'NoQuery' (hay chính xác hơn là: không liên quan) từ bỏ một số tính năng của cơ sở dữ liệu truyền thống về tốc độ, nhưng quan trọng hơn là khả năng mở rộng theo chiều ngang.

Các tính năng còn thiếu phụ thuộc vào sản phẩm cụ thể, nói chung các thuộc tính ACID đầy đủ hoặc thậm chí các hoạt động tham gia không được hỗ trợ. Đó là giá cho hiệu suất tăng.

— Karl
nguồn

1

Việc mô tả NoQuery là không liên quan không chính xác hơn. Có những DB không liên quan cũ khác không thuộc danh mục NoQuery. NoQuery có nghĩa là nhiều hơn là không liên quan. Đọc phần này để biết thêm thông tin: martinfowler.com/bliki/NosqlDefDef.html

— eddyP23

8

Bạn nói đúng, sẽ là vô nghĩa khi nói rằng trong một tuyên bố chăn. Mà có lẽ là toàn bộ điểm; thay vì một câu trả lời duy nhất, người phỏng vấn có thể mong đợi bạn trả lời bằng các câu hỏi để giúp bạn tìm ra bối cảnh của vấn đề là gì (loại dữ liệu nào, bao nhiêu, trong môi trường hoạt động, v.v.), giải pháp cụ thể của NoQuery . Họ sẽ cố gắng tìm hiểu cách bạn phân tích vấn đề và trên đường đi để biết được bạn biết bao nhiêu về các giải pháp khác nhau hiện có.

— Lươn
nguồn

Vâng, đó là một tuyên bố chăn, và nếu chúng ta chấp nhận nó là sự thật, thì câu trả lời cho câu hỏi là: nó phụ thuộc.

— Rolf

5

Cơ sở dữ liệu NoQuery thường chỉ có ý nghĩa nếu bạn thiết kế dữ liệu của mình xung quanh chúng.

Nếu bạn dự định chỉ sử dụng chúng như một sự thay thế RDBMS, thì bạn có thể nhận được hiệu suất thấp hơn thay vì nhiều hơn, đặc biệt là nếu bạn không có đủ ngân sách để trả cho các máy chủ có lượng RAM lớn.

Hãy xem bài viết này so sánh việc sử dụng không gian đĩa MySQL với MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— Vách đá
nguồn

3

Cơ sở dữ liệu nào của NoQuery? Cơ sở dữ liệu SQL nào? Nếu ai đó nói với bạn rằng NoQuery nhanh hơn SQL thì bạn nên bỏ đi. Hoặc tốt hơn là xem video này:

http://www.youtube.com/watch?v=b2F-DItXtZs

Tôi sẽ không nói một nửa những điều được tuyên bố về NoQuery là sai, nhưng tôi sẽ nói rằng có rất nhiều sự cuồng tín của NoQuery từ những người thực sự không hiểu rõ về nó.

SQL có giới hạn của nó (tất nhiên) nhưng nó cũng là một công nghệ rất trưởng thành, được hiểu rõ và có một nhóm lớn các nhà phát triển hiểu cách sử dụng nó tốt. Tôi không thể nói tương tự cho tất cả các dạng của NoQuery.

— Zachary K
nguồn

-2

NoSql được hỗ trợ bởi các cơ sở dữ liệu định hướng cột trong đó RDBMS là cơ sở dữ liệu theo hàng ... Và ví dụ: chúng tôi có bảng Nhân viên với Tên, Tuổi, Salery, Địa chỉ, EmployeeId, v.v. (Hỗ trợ NoQuery). Nếu một khách hàng / khách hàng viết một truy vấn để có được thông tin chi tiết về Độ tuổi hoặc Mức lương trung bình từ hồ sơ của nhân viên 1Lakh ... điều gì xảy ra?

Trong RDBMS, nó sẽ đi xung quanh mỗi hàng và thu thập giá trị và tổng & chia cho kết quả. Khi nói đến cơ sở dữ liệu Cột, không cần phải lo lắng về tất cả các lần lặp hàng lakh. Nhưng đối phó với chỉ một hàng nhanh hơn để tính toán. Vì vậy, cách này đôi khi NoQuery nhanh hơn SQL. Trường hợp này NoQuery không quan tâm đến khiếu nại ACID có giá trị!

— kiran teja avvaru
nguồn

2

Tôi đã sửa lỗi định dạng một chút, mặc dù tôi không chắc bạn đang cố gắng nhận được gì giữa hai người. Và ACID không phải lúc nào cũng được RDBMS hỗ trợ.

-3

Quên lý thuyết xung quanh cơ sở dữ liệu .... điểm một khi bạn hiểu các truy vấn của mình, bạn có thể lưu dữ liệu trong cơ sở dữ liệu nosql theo cách chính xác mà chúng thực sự được sử dụng trong ứng dụng của bạn ....

Ví dụ: lấy ví dụ này, bạn có một mô hình khách hàng với nhiều đơn hàng và nhiều mặt hàng được liên kết với mỗi đơn hàng, sau đó họ cũng có nhiều mặt hàng được lưu cho các lần mua sau ... nếu bạn là một cửa hàng thương mại điện tử lớn với giả sử 10 triệu khách hàng và 50 triệu đơn đặt hàng. Và khách hàng đó đăng nhập vào bảng điều khiển của họ để hiển thị dữ liệu chính xác này, cơ sở dữ liệu sql sẽ cần bao nhiêu công việc để tìm kiếm khách hàng, tham gia các đơn đặt hàng và từng chi tiết đơn hàng và các mục đã lưu. Trong cơ sở dữ liệu sql, tất cả dữ liệu này có thể sẽ cần phải được nối theo một cách nào đó ... hoặc bạn có thể tạo một bộ sưu tập trong cơ sở dữ liệu của bạn được gọi là usercache và lưu dữ liệu này chính xác như cách bạn sử dụng nó trong cuộc sống thực. Vì vậy, đây thực sự có thể là một truy vấn duy nhất trên một trường [id] để lấy lại tất cả dữ liệu này. Trên hết, cơ sở dữ liệu nosql không '

Vì vậy, một sql db có thể truy vấn một trường Id duy nhất nhanh như vậy nếu không nhanh hơn nosql? Có nhưng cơ sở dữ liệu sql có thể trả về tất cả dữ liệu bạn cần bằng cách truy vấn một bảng và một trường không? Không, trừ khi bạn làm điều gì đó như lưu dữ liệu trong Json bên trong một trường văn bản lớn. Nhưng bây giờ dữ liệu đó không thể truy vấn để sử dụng trong tương lai.

— Steffan Perry
nguồn