Câu trả lời:
Cơ sở dữ liệu quan hệ thực thi ACID . Vì vậy, bạn sẽ có các cửa hàng dữ liệu theo định hướng giao dịch dựa trên lược đồ. Nó đã được chứng minh và phù hợp với 99% các ứng dụng trong thế giới thực. Bạn thực tế có thể làm bất cứ điều gì với cơ sở dữ liệu quan hệ.
Nhưng, có những hạn chế về tốc độ và tỷ lệ khi nói đến các kho dữ liệu sẵn sàng lớn. Ví dụ: Google và Amazon có terabyte dữ liệu được lưu trữ trong các trung tâm dữ liệu lớn. Truy vấn và chèn không thực hiện trong các trường hợp này do tính chất chặn / lược đồ / giao dịch của RDBM. Đó là lý do họ đã triển khai cơ sở dữ liệu của riêng họ (thực ra là các cửa hàng giá trị khóa) để đạt được hiệu suất và khả năng mở rộng lớn.
Cơ sở dữ liệu NoQuery đã xuất hiện từ lâu - chỉ thuật ngữ này là mới. Một số ví dụ là đồ thị, đối tượng, cột, XML và cơ sở dữ liệu tài liệu.
Đối với câu hỏi thứ 2 của bạn: Sử dụng cả hai trên cùng một trang có ổn không?
Tại sao không? Cả hai đều phục vụ những mục đích khác nhau phải không?
Các giải pháp NoQuery thường có nghĩa là để giải quyết vấn đề mà cơ sở dữ liệu quan hệ không phù hợp lắm, quá tốn kém để sử dụng (như Oracle) hoặc yêu cầu bạn thực hiện một cái gì đó phá vỡ bản chất quan hệ của db của bạn.
Các ưu điểm thường dành riêng cho việc sử dụng của bạn, nhưng trừ khi bạn gặp một số vấn đề khi mô hình hóa dữ liệu của mình trong RDBMS, tôi không thấy lý do nào khiến bạn chọn NoQuery.
Bản thân tôi sử dụng MongoDB và Riak cho các vấn đề cụ thể trong đó RDBMS không phải là giải pháp khả thi, cho tất cả những thứ khác tôi sử dụng MySQL (hoặc SQLite để thử nghiệm).
Nếu bạn cần một db NoQuery bạn thường biết về nó, lý do có thể là:
Nếu bạn không cần một giải pháp NoQuery, hãy nhớ rằng các giải pháp này không có nghĩa là thay thế cho RDBMS mà là các giải pháp thay thế mà trước đây không thành công và quan trọng hơn là chúng còn khá mới vì chúng vẫn còn nhiều lỗi và thiếu tính năng.
Ồ, và liên quan đến câu hỏi thứ hai, việc sử dụng bất kỳ công nghệ nào kết hợp với công nghệ khác là hoàn toàn tốt, vì vậy, để hoàn thành từ kinh nghiệm của tôi, MongoDB và MySQL hoạt động tốt với nhau miễn là chúng không nằm trên cùng một máy
Martin Fowler có một video tuyệt vời cung cấp một lời giải thích tốt về cơ sở dữ liệu NoQuery. Liên kết đi thẳng vào lý do của anh ta để sử dụng chúng, nhưng toàn bộ video chứa thông tin tốt.
Bạn có một lượng lớn dữ liệu - đặc biệt là nếu bạn không thể phù hợp với tất cả dữ liệu trên một máy chủ vật lý vì NoQuery được thiết kế để mở rộng quy mô.
Sự không phù hợp trở kháng quan hệ đối tượng - Các đối tượng miền của bạn không phù hợp với lược đồ cơ sở dữ liệu quan hệ. NoQuery cho phép bạn duy trì dữ liệu của mình dưới dạng tài liệu (hoặc biểu đồ) có thể ánh xạ chặt chẽ hơn nhiều đến mô hình dữ liệu của bạn.
NoQuery là hệ thống cơ sở dữ liệu nơi dữ liệu được tổ chức vào tài liệu (MongoDB), cặp giá trị khóa (MemCache, Redis), dạng cấu trúc biểu đồ (Neo4J).
Có lẽ đây là những câu hỏi và câu trả lời có thể có cho "Khi nào nên đi NoQuery":
Yêu cầu lược đồ linh hoạt hoặc đối phó với dữ liệu như cây?
Nói chung, trong phát triển nhanh, chúng tôi bắt đầu thiết kế hệ thống mà không biết tất cả các yêu cầu trước, trong đó sau này trong toàn bộ hệ thống cơ sở dữ liệu phát triển có thể cần điều chỉnh thay đổi thiết kế thường xuyên, giới thiệu MVP (sản phẩm tối thiểu khả thi). Hoặc bạn đang xử lý lược đồ dữ liệu có tính chất động. ví dụ: Nhật ký hệ thống, ví dụ rất chính xác là nhật ký đám mây AWS.
Tập dữ liệu có rộng / lớn?
Có cơ sở dữ liệu NoQuery là ứng cử viên tốt hơn cho các ứng dụng mà cơ sở dữ liệu cần quản lý hàng triệu hoặc thậm chí hàng tỷ bản ghi mà không ảnh hưởng đến hiệu suất.
Trao đổi giữa việc mở rộng quy mô về tính nhất quán
Không giống như RDMS, cơ sở dữ liệu NoQuery có thể mất dữ liệu nhỏ ở đây và ở đó (Lưu ý: xác suất là .x%), nhưng dễ dàng mở rộng về mặt hiệu suất. Ví dụ: Điều này có thể tốt cho việc lưu trữ những người đang trực tuyến trong ứng dụng nhắn tin tức thời, mã thông báo trong db, ghi lại số liệu thống kê lưu lượng truy cập trang web.
Thực hiện các hoạt động định vị địa lý: MongoDB băm hỗ trợ phong phú để thực hiện các hoạt động GeoQuerying & Geolocation. Tôi thực sự yêu thích tính năng này của MongoDB.
Tóm lại, MongoDB rất phù hợp cho các ứng dụng mà bạn có thể lưu trữ dữ liệu có cấu trúc động ở quy mô lớn.
Một số thông tin cần thiết bị thiếu để trả lời câu hỏi: Những trường hợp sử dụng nào cơ sở dữ liệu phải có khả năng bao gồm? Các phân tích phức tạp phải được thực hiện từ dữ liệu hiện có ( OLAP ) hay ứng dụng phải có khả năng xử lý nhiều giao dịch ( OLTP )? Cấu trúc dữ liệu là gì? Đó là xa kết thúc thời gian câu hỏi.
Theo quan điểm của tôi, thật sai lầm khi đưa ra quyết định công nghệ trên cơ sở những từ thông dụng táo bạo mà không biết chính xác những gì đằng sau chúng. NoQuery thường được khen ngợi về khả năng mở rộng. Nhưng bạn cũng phải biết rằng tỷ lệ ngang (qua một số nút) cũng có giá của nó và không miễn phí. Sau đó, bạn phải xử lý các vấn đề như tính nhất quán cuối cùng và xác định cách giải quyết xung đột dữ liệu nếu chúng không thể được giải quyết ở cấp cơ sở dữ liệu. Tuy nhiên, điều này áp dụng cho tất cả các hệ thống cơ sở dữ liệu phân tán.
Niềm vui của các nhà phát triển với từ "lược đồ ít hơn" tại NoQuery ngay từ đầu cũng rất lớn. Từ thông dụng này nhanh chóng bị loại bỏ sau khi phân tích kỹ thuật, bởi vì nó chính xác không yêu cầu một lược đồ khi viết, nhưng đi vào hoạt động khi đọc. Đó là lý do tại sao nó chính xác là "lược đồ khi đọc". Nó có thể hấp dẫn để có thể viết dữ liệu theo ý riêng của một người. Nhưng làm thế nào để tôi xử lý tình huống nếu có dữ liệu hiện có nhưng phiên bản mới của ứng dụng mong đợi một lược đồ khác?
Mô hình tài liệu (ví dụ như trong MongoDB) không phù hợp với các mô hình dữ liệu có nhiều mối quan hệ giữa dữ liệu. Việc tham gia phải được thực hiện ở cấp ứng dụng, đó là nỗ lực bổ sung và tại sao tôi nên lập trình những việc mà cơ sở dữ liệu nên làm.
Nếu bạn đưa ra lập luận rằng Google và Amazon đã phát triển cơ sở dữ liệu của riêng họ vì RDBMS thông thường không còn có thể xử lý lũ dữ liệu, bạn chỉ có thể nói: Bạn không phải là Google và Amazon. Các công ty này là mũi nhọn, khoảng 0,01% kịch bản trong đó cơ sở dữ liệu truyền thống không còn phù hợp, nhưng đối với phần còn lại của thế giới.
Điều không đáng kể: SQL đã tồn tại hơn 40 năm và hàng triệu giờ phát triển đã đi vào các hệ thống lớn như Oracle hoặc Microsoft SQL. Điều này phải đạt được bởi một số cơ sở dữ liệu mới. Đôi khi cũng dễ dàng tìm thấy một quản trị viên SQL hơn ai đó cho MongoDB. Điều này đưa chúng ta đến câu hỏi về bảo trì và quản lý. Một chủ đề không thực sự gợi cảm, nhưng đó là một phần của quyết định công nghệ.
Tôi đã gặp câu hỏi này trong khi tìm kiếm cơ sở thuyết phục để đi chệch khỏi thiết kế RDBMS.
Có một bài viết tuyệt vời của Julian Brown làm sáng tỏ những hạn chế của các hệ thống phân tán. Khái niệm này được gọi là Định lý CAP của nhà sản xuất, tóm lại:
Ba yêu cầu của hệ thống phân tán là: Tính nhất quán, Tính khả dụng và Dung sai phân vùng (viết tắt là CAP). Nhưng bạn chỉ có thể có hai trong số họ tại một thời điểm.
Và đây là cách tôi tóm tắt nó cho chính mình:
Tốt hơn hết là bạn nên dùng NoQuery nếu tính nhất quán là thứ bạn đang hy sinh.
Tôi đã thiết kế và triển khai các giải pháp với cơ sở dữ liệu NoQuery và đây là danh sách điểm kiểm tra của tôi để đưa ra quyết định đi với SQL hoặc NoQuery theo định hướng tài liệu .
Không
SQL không lỗi thời và vẫn là một công cụ tốt hơn trong một số trường hợp. Thật khó để biện minh cho việc sử dụng NoQuery theo định hướng tài liệu khi
LÀM
Nếu bạn không có những điều kiện đó hoặc có thể giảm thiểu chúng, thì đây là 2 lý do bạn có thể hưởng lợi từ NoQuery:
Thêm thông tin
Trong bài viết trên blog của tôi, tôi giải thích lý do chi tiết hơn:
Lưu ý: ở trên chỉ áp dụng cho NoQuery theo định hướng tài liệu. Có các loại NoQuery khác, đòi hỏi phải cân nhắc khác.
Xử lý một số lượng lớn các hoạt động đọc ghi
Nhìn về phía cơ sở dữ liệu NoQuery khi bạn cần mở rộng nhanh. Và khi nào bạn thường cần phải tăng quy mô nhanh?
Khi có một số lượng lớn các hoạt động đọc-ghi trên trang web của bạn và khi xử lý một lượng lớn dữ liệu, cơ sở dữ liệu NoQuery phù hợp nhất trong các tình huống này. Vì chúng có khả năng thêm các nút một cách nhanh chóng, chúng có thể xử lý lưu lượng đồng thời nhiều hơn và lượng dữ liệu lớn với độ trễ tối thiểu.
Linh hoạt với mô hình dữ liệu
Dấu hiệu thứ hai là trong các giai đoạn phát triển ban đầu khi bạn không chắc chắn về mô hình dữ liệu, thiết kế cơ sở dữ liệu, mọi thứ được dự kiến sẽ thay đổi với tốc độ nhanh. Cơ sở dữ liệu NoQuery cung cấp cho chúng tôi linh hoạt hơn.
Sự nhất quán cuối cùng trên sự nhất quán mạnh mẽ
Tốt nhất là chọn cơ sở dữ liệu NoQuery khi chúng tôi từ bỏ tính nhất quán mạnh mẽ và khi chúng tôi không yêu cầu giao dịch.
Một ví dụ điển hình của việc này là một trang web mạng xã hội như Twitter. Khi một tweet của một người nổi tiếng nổ tung và mọi người đều thích và tweet lại từ khắp nơi trên thế giới. Có vấn đề gì không nếu số lượt thích tăng hoặc giảm một chút trong một thời gian ngắn?
Người nổi tiếng chắc chắn sẽ không quan tâm nếu thay vì 5 triệu 500 lượt thích thực sự, hệ thống hiển thị số lượt thích là 5 triệu 250 trong một thời gian ngắn.
Khi một ứng dụng lớn được triển khai trên hàng trăm máy chủ trải rộng trên toàn cầu, các nút phân phối theo địa lý sẽ mất một thời gian để đạt được sự đồng thuận toàn cầu.
Cho đến khi họ đạt được sự đồng thuận, giá trị của thực thể không nhất quán. Giá trị của thực thể cuối cùng sẽ ổn định sau một thời gian ngắn. Đây là những gì nhất quán cuối cùng là.
Mặc dù sự không nhất quán không có nghĩa là có bất kỳ loại mất dữ liệu nào. Nó chỉ có nghĩa là dữ liệu mất một thời gian ngắn để đi qua toàn cầu thông qua các dây cáp internet dưới đại dương để đạt được sự đồng thuận toàn cầu và trở nên nhất quán.
Chúng tôi trải nghiệm hành vi này tất cả các thời gian. Đặc biệt là trên YouTube. Thường thì bạn sẽ thấy một video có 10 lượt xem và 15 lượt thích. Làm thế nào là điều này thậm chí có thể?
Nó không thể. Các lượt xem thực tế đã nhiều hơn lượt thích. Đó chỉ là số lượt xem không nhất quán và mất một thời gian ngắn để được cập nhật.
Chạy phân tích dữ liệu
Cơ sở dữ liệu NoQuery cũng phù hợp nhất cho các trường hợp sử dụng phân tích dữ liệu, trong đó chúng ta phải đối phó với một lượng lớn dữ liệu.