Tôi muốn một ví dụ tầm thường về nơi MongoDB có thể mở rộng nhưng cơ sở dữ liệu quan hệ sẽ gặp sự cố [đóng]

Tôi chỉ đang học cách sử dụng MongoDB và khi thảo luận với các lập trình viên khác, tôi muốn có một ví dụ nhanh về lý do tại sao NoQuery có thể là một lựa chọn tốt so với RDBMS truyền thống - tuy nhiên các kịch bản tôi đưa ra và có thể thấy trực tuyến có vẻ khá khó hiểu.

Ví dụ: một blog có nhiều lưu lượng truy cập có thể được trình bày theo quan hệ, nhưng sẽ yêu cầu một số điều chỉnh hiệu suất và tham gia trên các bảng (giả sử sử dụng không chuẩn hóa hoàn toàn đang được sử dụng). Trong khi đó MongoDB sẽ cho phép truy xuất trực tiếp từ một bộ sưu tập cho cùng một hiệu ứng.

Nhưng phản hồi tôi nhận được từ các lập trình viên khác là "tại sao không giữ nó liên quan và sau đó thêm một số bộ nhớ đệm tầm thường sau này?"

Có ai có một ví dụ ít tranh cãi hơn, nơi MongoDB sẽ thực sự tỏa sáng và một db quan hệ sẽ rơi nhanh hơn nhiều không? Dự án / hệ thống càng nhỏ càng tốt, bởi vì nó để lại ít chỗ cho sự bất đồng.

Một cái gì đó dọc theo sự phức tạp của ví dụ blog sẽ thực sự hữu ích.

Cảm ơn.

Đầu tiên, nó có quy mô tốt.

Khi cơ sở dữ liệu MongoDB quá thường xuyên hoặc quá lớn cho một máy chủ, bạn có thể dễ dàng thêm nhiều máy chủ hơn bằng cách tạo một cụm hoặc bản sao của nhiều phân đoạn. Nó quy mô gần như tuyến tính. Điều này không hoạt động gần như tốt với hầu hết các cơ sở dữ liệu quan hệ. Ví dụ, hãy xem danh sách các giới hạn của MySQL khi hoạt động như một cụm . Hầu hết các mục trong danh sách không có vấn đề gì với MongoDB (hoặc không áp dụng).

Thứ hai, nó cho phép dữ liệu không đồng nhất.

Hãy tưởng tượng, ví dụ, cơ sở dữ liệu sản phẩm của một cửa hàng phần cứng máy tính. Những tính chất nào làm sản phẩm có? Tất cả các sản phẩm có một mức giá và một nhà cung cấp. Nhưng CPU có tốc độ xung nhịp, ổ cứng và chip RAM có dung lượng (và những dung lượng này không thể so sánh được), màn hình có độ phân giải, v.v. Làm thế nào bạn sẽ thiết kế này trong một cơ sở dữ liệu quan hệ? Bạn sẽ tạo một bảng giá trị sản phẩm-thuộc tính rất dài hoặc bạn sẽ tạo một bảng sản phẩm rất rộng và thưa thớt với mọi thuộc tính bạn có thể tưởng tượng, nhưng hầu hết chúng đều NULLdành cho hầu hết các sản phẩm. Cả hai giải pháp đều không thực sự thanh lịch. Nhưng MongoDB có thể giải quyết điều này tốt hơn nhiều vì nó cho phép mỗi tài liệu trong một bộ sưu tập có một bộ thuộc tính khác nhau.

Một số ví dụ trong thế giới thực về một vấn đề tôi sẽ không biết làm thế nào để giải quyết một cách hợp lý với SQL và một cơ sở dữ liệu quan hệ (có thể là lỗi của tôi).

Vì vậy, chúng tôi có một cơ sở dữ liệu (quan hệ phổ biến) với khoảng 30.000 sản phẩm. Không có gì lớn cho đến nay. Mỗi sản phẩm này có nhiều thuộc tính. Có những nhóm phổ biến như nhóm (dây cáp, ăng-ten, vỏ iphone ... khoảng 80), các loại (tương tự như các nhóm: xe hơi, hifi, mp3, chỉ 15), nhãn hiệu (30).

Sau đó đến dữ liệu kỹ thuật. Mỗi mặt hàng có nhiều trong số đó như màu sắc, chiều dài cáp, trọng lượng, khối lượng. khoảng 200 loại giá trị như vậy và hàng ngàn giá trị.

Và phức tạp nhất: Nhiều sản phẩm trong số đó thuộc về một số loại xe hơi (hoặc một vài trong số chúng) hoặc một loại thiết bị di động. Những thứ đó được phân cấp theo dạng như: kiểu thương hiệu (apple) (ipad) (1,2,3,4) và trong một số trường hợp tạo ra. (đối với ô tô, nó tương tự nhau, mặc dù thay vì thế hệ chúng ta đã xây dựng nhiều năm)

Vấn đề bước một:

Chúng tôi muốn số lượng sản phẩm cho từng thuộc tính đó. Có bao nhiêu màu đỏ? Có bao nhiêu trong nhóm cáp? Và như thế.

Điều này có thể được giải quyết một phần với SQL. Nó sẽ là rất nhiều truy vấn và khá xấu xí nhưng tôi nghĩ là có thể. Có thể chậm nhưng chúng ta có thể làm điều đó thậm chí còn xấu xí hơn và giữ các quầy trong mỗi bảng và cập nhật mỗi khi thay đổi. Đặc biệt khó khăn với những thuộc tính mà một sản phẩm có thể có nhiều (như hoạt động với iPhone và 12 điện thoại di động khác)

Nhưng đây là vấn đề bước hai:

Khi một khách hàng chọn một thuộc tính (nói rằng anh ta chỉ muốn nhìn thấy các sản phẩm có màu đỏ), chúng tôi muốn cập nhật tất cả các bộ đếm đó trong thời gian thực. Điều này có nghĩa là chúng ta sẽ có các truy vấn cực kỳ phức tạp (dù sao cũng không đủ nhanh) hoặc giữ các bộ đếm cho các kết hợp thuộc tính có thể (hàng tỷ).

Khi tôi bắt đầu dự án này, họ đã cho tùy chọn bộ đếm thử và thực hiện điều này cho một tập hợp con rất nhỏ của các thuộc tính (nhóm, phân loại, nhãn hiệu). Mã này là xấu xí, lỗi và chậm. Ngoài ra, bây giờ họ có một cái bàn với các quầy lớn hơn nhiều so với bàn sản phẩm.

Sử dụng các khía cạnh của Apache Solr thực sự là giải pháp. Làm phẳng các bảng thành một danh sách Tài liệu (mỗi sản phẩm) được phép lấy tất cả dữ liệu này trong thời gian thực với các truy vấn đơn giản hơn nhiều.

Bạn có thể nghĩ bất cứ lúc nào bạn nghĩ rằng bảng EAV là cách tốt nhất để làm mọi thứ (nổi tiếng là chậm trong các cơ sở dữ liệu thực tế và khó truy vấn), bạn có thể cần một cơ sở dữ liệu nosql. Điều này đặc biệt đúng khi bạn không có cách nào biết trước các lĩnh vực sẽ là gì. Một ví dụ sẽ được lưu trữ các chi tiết của các xét nghiệm y tế. Mỗi thử nghiệm mới có thể có dữ liệu hoàn toàn khác nhau mà bạn sẽ cần lưu trữ. Và mặc dù bạn có thể (về lý thuyết) mô hình các xét nghiệm hiện có (với rất nhiều thời gian và công sức vì có hàng nghìn người trong số họ), làm thế nào bạn biết những thử nghiệm mới nào bạn có thể nhận được kết quả từ các xét nghiệm (và có thể là thiết bị y tế) t thậm chí đã phát minh ra.

Dự án / hệ thống càng nhỏ càng tốt, bởi vì nó để lại ít chỗ cho sự bất đồng.

Điều này thật khó vì NoQuery chỉ tốt hơn trong môi trường lớn. Tôi hiểu rằng bạn có nghĩa là một ví dụ đơn giản và tôi có một ví dụ hoàn hảo cho bạn.

Giả sử bạn đang tạo một trang web Du lịch và bạn cần phải có người dùng đi du lịch từ và trong số 5.170 sân bay Hoa Kỳ dành cho bất kỳ sân bay nào trong số 5,170 sân bay khác của Hoa Kỳ ...

Nhưng đây là Kicker, không phải tất cả các chuyến bay đều trực tiếp, bạn cần nói với người dùng tất cả các tùy chọn dừng, đôi khi là 2 hoặc 3 điểm dừng. Bạn cũng cần nói với người dùng tất cả các tùy chọn trong một cửa sổ 5 giờ! Và bạn cần tính toán điều này trong vòng dưới 10 giây trong khi người dùng đang chờ.

Đây là Cơn ác mộng DB có liên quan ... Đến NoSql, các chuyến bay thường được đặt trước một vài tuần, vì vậy bạn có thể tính toán tất cả các Gazillions của các lần xuất hiện có thể trong cửa hàng trước so với trong cụm DB NoSql đơn giản ...

NoSql là người chiến thắng rõ ràng là một kịch bản như vậy.