Cơ sở dữ liệu nào (RDBMS vs NoQuery vs BOTH) để sử dụng cho trò chơi nhiều người chơi trong thời gian thực?

Tôi đang làm việc trên một trò chơi nhiều người chơi thời gian thực sẽ yêu cầu cơ sở dữ liệu (đối với các tính năng như hồ sơ người chơi, bạn bè, mở khóa, tin tức, v.v.) Đây là trò chơi PC tiêu chuẩn (không dựa trên trình duyệt) và sẽ sử dụng máy chủ-máy khách ngành kiến ​​trúc. Tôi mới sử dụng cơ sở dữ liệu và đã thực hiện một số nghiên cứu trong vài ngày qua khi tôi vấp phải cuộc tranh luận sôi nổi: RDBMS vs NoQuery. Hiện tại tôi đang nghiêng về NoQuery nhưng sau khi đọc về cách sử dụng cho từng (RDBMS và NoQuery), tôi rất muốn sử dụng cả hai. Tôi biết điều đó có vẻ lạ, nhưng hãy để tôi giải thích tình huống của mình:

Nhóm của tôi có gói chia sẻ webhosting cung cấp lưu trữ và băng thông myQuery không giới hạn, điều đáng chú ý duy nhất là chúng tôi chỉ có thể mở 25 kết nối cùng một lúc (quy tắc lưu trữ được chia sẻ). Tôi đang có ý định sử dụng điều này cho trang web của mình (một cách sử dụng thông thường không nghi ngờ gì) để đăng cập nhật tin tức, hỗ trợ các tính năng cộng đồng (như bình luận, tải lên fan art, v.v.) và tương tự. Đó là tất cả tốt và tốt - nhưng! đây là nơi mọi thứ trở nên thú vị ... Tôi muốn hiển thị cùng thông tin được đăng trên trang web của mình, trong trò chơi. Điều này có nghĩa là sử dụng myQuery cho cả trang web và trò chơi của tôi. Ngoài các bài đăng tin tức và những thứ tương tự, tôi dự định sử dụng nó trong trò chơi cho những thứ như trò chuyện và danh sách máy chủ. Tôi lo ngại về quy tắc 25 kết nối đó.

Điều đó dẫn tôi đến câu hỏi số 1: Điều này có hiệu quả không và có cách nào khác tốt hơn không?

Bây giờ bên cạnh điều này, tôi đã đọc về việc NoQuery hoạt động tốt như thế nào và phù hợp với các trò chơi thời gian thực (tôi có thể sai, tôi đã trải qua một cuộc chiến rực lửa RDBMS vs NoQuery để đến đây và có lẽ bị đốt cháy). Về cơ bản, tôi muốn sử dụng MongoDB cho tất cả dữ liệu đối tượng trò chơi của mình.

Và một lần nữa, sẽ rất hữu ích nếu tôi cung cấp một số ngữ cảnh: Tôi đã tìm thấy một máy chủ lưu trữ (MongoLab) cung cấp gói MongoDB 240 MB miễn phí, tôi dự định sử dụng cho đến khi cần nâng cấp. Với 240 MB, tôi đã tính toán rằng tôi sẽ có thể lưu trữ khoảng 60.000 người chơi (nếu mỗi người chơi khoảng 4KB và chúng tôi bỏ qua những thứ khác có thể được lưu trữ). Không gian lưu trữ và phải trả nhiều tiền hơn trong tương lai (nếu trò chơi của chúng tôi thành công) không phải là vấn đề. Lý do duy nhất hiện tại tôi có ý định sử dụng MongoDB cho tất cả dữ liệu đối tượng trò chơi của mình là vì tần suất dữ liệu của đối tượng trò chơi này sẽ được truy cập (chẳng hạn như bất cứ khi nào người chơi bị giết, nhặt một vật phẩm, bắn súng, v.v.) cũng giống như các tài liệu không có lược đồ chuyển tiếp thẳng (giúp cho việc ánh xạ dữ liệu đối tượng trò chơi dễ dàng hơn). Tôi nên lưu ý rằng, tại một thời điểm,

Tôi dự định sử dụng cùng MongoDB trong trang web của mình, để hiển thị thông tin hồ sơ người chơi (Tôi không quan tâm đến tính nhất quán hoàn toàn, một số chậm trễ từ các bản cập nhật trong trò chơi là ổn). Điều này dẫn tôi đến câu hỏi thứ hai của tôi, Câu hỏi số 2: Đây có phải là một ý tưởng tốt hay tôi nên làm gì tốt hơn?

Trò chơi sẽ có trải nghiệm khởi động tương tự như thế này:

1. Đăng nhập ứng dụng khách (MongoDB)
2. Khách hàng đang ở trang chủ trong trò chơi với các phòng trò chuyện (MySQL)
3. Máy khách đi đến danh sách máy chủ (MySQL)

4. Máy khách kết nối với máy chủ và chơi trong đó

5. Máy chủ truyền thông cập nhật cho tất cả người chơi (MongoDB)

Đây chỉ là cách tôi tưởng tượng nó sẽ hoạt động. Điều này có vẻ tốt với bạn, hoặc bạn có gợi ý về cách cải thiện kế hoạch này không?

Đề nghị của tôi là để trò chơi của bạn giao tiếp với một dịch vụ web mà bạn đã tạo mà chính nó xử lý truy vấn cơ sở dữ liệu. Vào thời điểm đó, thật đơn giản để thử các loại cơ sở dữ liệu khác nhau bằng cách "chuyển đổi" triển khai dịch vụ web (giao diện dịch vụ web của bạn luôn giữ nguyên để trò chơi của bạn không bị hỏng) và quyết định loại nào phù hợp với bạn.

Nó cũng an toàn hơn rất nhiều khi không để lộ cơ sở dữ liệu của bạn trực tiếp lên internet.

chúng tôi chỉ có thể mở 25 kết nối cùng một lúc (quy tắc lưu trữ được chia sẻ).

Thế là quá đủ cho trò chơi của bạn. Vấn đề là nếu trang web của bạn sử dụng nhiều kết nối, bạn có thể hết. Bạn cần định cấu hình máy chủ web của mình để chỉ sử dụng một số lượng nhỏ trong số chúng, phần còn lại cho máy chủ trò chơi của bạn. Máy chủ trò chơi của bạn không thực sự cần nhiều hơn 1 kết nối, nhưng có thể có lợi từ việc có một số ít.

Bây giờ bên cạnh điều này, tôi đã đọc về việc NoQuery hoạt động tốt như thế nào và phù hợp với các trò chơi thời gian thực (tôi có thể sai, tôi đã trải qua một cuộc chiến rực lửa RDBMS vs NoQuery để đến đây và có lẽ bị đốt cháy). Về cơ bản, tôi muốn sử dụng MongoDB cho tất cả dữ liệu đối tượng trò chơi của mình.

Đó là một chút tranh luận sai lầm, bởi vì cả hai hệ thống đều không đủ nhanh để sử dụng làm kho lưu trữ chính cho trò chơi thời gian thực có nhịp độ nhanh - bạn thực sự cần phải giữ và thao tác các giá trị trong bộ nhớ. Vì vậy, bạn chỉ truy cập cơ sở dữ liệu khi bạn hoàn toàn phải làm vậy, có thể chỉ là lưu toàn bộ nhân vật thường xuyên (ví dụ: một lần một phút), tại thời điểm đó, sự khác biệt về tốc độ trở nên không đáng kể.

Điều thú vị là, nếu bạn tinh chỉnh MongoDB ở tốc độ cao nhất, bạn có thể đưa nó đến một điểm đủ nhanh để bạn thực hiện ghi đồng bộ từ trong một trò chơi có nhịp độ nhanh hợp lý, nhưng điều này sẽ phải trả giá toàn vẹn dữ liệu vì ghi được đệm. Điều này có nghĩa là bạn mất dữ liệu đó trong trường hợp xảy ra sự cố, do đó, có rất ít điểm thực hiện việc ghi và nó vẫn chậm hơn so với khi bạn chỉ thực hiện chỉnh sửa trong bộ nhớ và lưu lại sau đó, do đó bạn gặp phải điều tồi tệ nhất của cả hai thế giới .

Lý do duy nhất tôi hiện đang có ý định sử dụng MongoDB cho tất cả dữ liệu đối tượng trò chơi của mình là vì tần suất dữ liệu đối tượng trò chơi này sẽ được truy cập (chẳng hạn như bất cứ khi nào người chơi bị giết, nhặt một vật phẩm, bắn súng, v.v.)

Hãy tự hỏi tại sao bạn cần phải ghi vào cơ sở dữ liệu khi người chơi bắn súng. Tại sao không thể xử lý trong bộ nhớ trên máy chủ trò chơi? Nếu trò chơi của bạn gặp sự cố và sau đó khởi động lại và người chơi phát hiện ra họ có 3 viên đạn nhiều hơn họ mong đợi, đó có phải là một vấn đề kinh doanh quan trọng không?

Tôi cũng thích các tài liệu không có lược đồ thẳng (giúp cho việc ánh xạ dữ liệu đối tượng trò chơi dễ dàng hơn).

Đây là một lý do tốt hơn nhiều để chọn cách tiếp cận NOSQL so với vấn đề hiệu suất.

Tôi dự định sử dụng cùng MongoDB trong trang web của mình, để hiển thị thông tin hồ sơ người chơi (Tôi không quan tâm đến tính nhất quán hoàn toàn, một số chậm trễ từ các bản cập nhật trong trò chơi là ổn).

Điều đó tốt, và hợp lý. Sau này, bạn có thể muốn sử dụng một cá thể riêng biệt, để các trang web đọc không tranh chấp với việc đọc và viết trò chơi, nhưng vấn đề đó là một vấn đề nhỏ để giải quyết so với vấn đề phổ biến đủ để điều này trở thành một vấn đề.

Cá nhân tôi sẽ chỉ chọn một trong hai cơ sở dữ liệu, dựa vào đó cơ sở dữ liệu nào sẽ ít làm việc hơn cho tôi và chuẩn hóa điều đó - nhưng không có lý do gì bạn không thể giữ với hai nếu bạn muốn.

Tất cả dữ liệu thời gian thực cần được lưu trong bộ nhớ ứng dụng, mọi thứ khác sẽ là ngớ ngẩn.

Giữ cho người dùng đăng nhập dữ liệu, số liệu thống kê, vv là một nhiệm vụ khá nhẹ, vì vậy tôi sẽ in đậm và nói rằng bạn có thể sử dụng khá nhiều bất cứ thứ gì bạn muốn. Mặc dù bạn có thể muốn cẩn thận với trang web, nhưng những thứ như danh sách người dùng có thể chiếm rất nhiều hiệu suất cơ sở dữ liệu nếu bạn không tạo một hệ thống bộ đệm phù hợp.

Và như bummzack đã nói, bạn nên giữ mọi thứ trong cùng một mạng. Trên hết, hãy cẩn thận với những thứ miễn phí, lưu trữ cơ sở dữ liệu miễn phí 240 MB nghe có vẻ tốt, nhưng vì máy có thể được phân chia giữa một số lượng lớn dịch vụ người dùng miễn phí có thể khá chậm.

Bạn có tin tưởng 60.000 người dùng của bạn trên mỗi cơ sở dữ liệu? Nếu không, bạn nên kết hợp ý tưởng "truy cập cơ sở dữ liệu từ máy khách", trừ khi mức độ chuyên môn của bạn về bảo mật phần mềm cơ sở dữ liệu là hàng đầu, và bạn tự tin rằng bạn có thể giải quyết mọi vấn đề dẫn đến.