SQL so với NoSQL cho hệ thống quản lý hàng tồn kho

1. Hàng đợi để quản lý cập nhật khoảng không quảng cáo cho từng kênh.

Đây không nhất thiết là một vấn đề cơ sở dữ liệu. Bạn có thể tốt hơn nên xem xét một hệ thống nhắn tin (ví dụ:RabbitMQ)

1. Bảng khoảng không quảng cáo có ảnh chụp nhanh chính xác về phân bổ trên mỗi kênh.
2. Giữ Id phiên và dữ liệu truy cập nhanh khác trong bộ nhớ cache.

dữ liệu phiên có thể nên được đặt trong một cơ sở dữ liệu riêng phù hợp hơn cho tác vụ (ví dụ:memcached, redis, v.v.) Không có DB một kích thước phù hợp với tất cả

1. Cung cấp trang tổng quan giống facebook (XMPP) để cập nhật người bán càng sớm càng tốt.

Những ràng buộc của tôi là:1. Cập nhật khoảng không quảng cáo không thể bị mất.

Có 3 cách để trả lời câu hỏi này:

1. Tính năng này phải được cung cấp bởi ứng dụng của bạn. Cơ sở dữ liệu có thể đảm bảo rằng một bản ghi xấu sẽ bị từ chối và khôi phục lại, nhưng không đảm bảo rằng mọi truy vấn sẽ được nhập. Ứng dụng sẽ phải đủ thông minh để nhận ra khi có lỗi xảy ra và thử lại.

2. một số DB lưu trữ các bản ghi trong bộ nhớ và sau đó chuyển bộ nhớ vào đĩa chung, điều này có thể dẫn đến mất dữ liệu trong trường hợp mất điện. (ví dụ:Mongo hoạt động theo cách này theo mặc định trừ khi bạn bật tính năng ghi nhật ký. CouchDB luôn gắn vào các bản ghi (ngay cả việc xóa cũng là một cờ được thêm vào bản ghi nên việc mất dữ liệu là vô cùng khó khăn))

3. Một số DB được thiết kế để cực kỳ đáng tin cậy, ngay cả khi động đất, bão hoặc thiên tai khác xảy ra, chúng vẫn bền. chúng bao gồm Cassandra, Hbase, Riak, Hadoop, v.v.

Bạn đang đề cập đến loại độ bền nào?

1. Hàng đợi công việc phải được thực hiện theo thứ tự và tốt nhất là không bao giờ bị mất.

Hầu hết các giải pháp noSQL thích chạy song song. vì vậy bạn có hai lựa chọn ở đây.1. sử dụng một DB khóa toàn bộ bảng cho mọi truy vấn (chậm hơn) 2. xây dựng ứng dụng của bạn trở nên thông minh hơn hoặc phù hợp hơn (xếp hàng tuần tự phía máy khách)

1. Phát triển dễ dàng / nhanh chóng và bảo trì trong tương lai.

nói chung, bạn sẽ thấy rằng SQL phát triển nhanh hơn lúc đầu, nhưng các thay đổi có thể khó triển khai hơn .noSQL có thể yêu cầu lập kế hoạch nhiều hơn một chút, nhưng dễ thực hiện các truy vấn đột xuất hoặc thay đổi lược đồ hơn.

Những câu hỏi bạn có thể cần tự hỏi mình nhiều hơn như:

1. "Tôi có cần phải có các truy vấn cường độ cao hoặc phân tích sâu mà một Bản đồ / Rút gọn phù hợp hơn không?"

2. "tôi có cần thay đổi giản đồ của mình thường xuyên không?

3. "dữ liệu của tôi có quan hệ cao không? theo cách nào?"

4. "nhà cung cấp đằng sau DB đã chọn của tôi có đủ kinh nghiệm để giúp tôi khi tôi cần không?"

5. "tôi có cần tính năng đặc biệt như lập chỉ mục không gian địa lý, tìm kiếm toàn văn, v.v. không?"

6. "tôi sẽ cần dữ liệu của mình gần đến thời gian thực đến mức nào? Sẽ rất phiền nếu tôi không thấy các bản ghi mới nhất hiển thị trong các truy vấn của mình cho đến 1 giây sau đó? Mức độ trễ nào có thể chấp nhận được?"

7. "tôi thực sự cần gì trong điều kiện thất bại"

8. "dữ liệu của tôi lớn đến mức nào? nó có vừa trong bộ nhớ không? nó có vừa trên một máy tính không? mỗi bản ghi riêng lẻ lớn hay nhỏ?

9. "dữ liệu của tôi sẽ thay đổi bao lâu một lần? Đây có phải là kho lưu trữ không?"

Nếu bạn sẽ có nhiều khách hàng (kênh?), Mỗi khách hàng có lược đồ khoảng không quảng cáo của riêng họ, thì DB dựa trên tài liệu có thể có lợi thế. Tôi nhớ có lần tôi đã xem xét một hệ thống thương mại điện tử có khoảng không quảng cáo và nó có gần 235 bảng! Sau đó, một lần nữa, nếu bạn có một số dữ liệu quan hệ nhất định, giải pháp SQL thực sự cũng có thể có một số lợi thế.

Tôi chắc chắn có thể thấy cách tôi có thể xây dựng một giải pháp bằng cách sử dụng mongo, couch, riak hoặc orientdb với các ràng buộc đã cho. Nhưng đối với cái nào là tốt nhất? Tôi sẽ thử nói chuyện trực tiếp với các nhà cung cấp DB và có thể xem băng nosql