noQuery - Đây có phải là một tùy chọn hợp lệ cho trò chơi dựa trên web không? [đóng cửa]

Hết cơ hội và chán nản, một người bạn và tôi quyết định làm một trò chơi dựa trên web. Đây là 'trò chơi' đầu tiên tôi sẽ thực hiện, vì thông thường tôi lập trình các ứng dụng web trong django.

Tôi đã chọn sử dụng cùng một khung cho trò chơi, nhưng tôi không hoàn toàn chắc chắn về việc lưu trữ dữ liệu, vì tôi không thể thấy trước các yêu cầu trong tương lai và các vấn đề liên quan đến DB. Gần đây, phong trào noQuery đang có được sức mạnh và tôi muốn khám phá khu vực đó.

Vì vậy, tôi có các câu hỏi sau đây:

• Liệu một kho lưu trữ dữ liệu noQuery (dựa trên tài liệu, chẳng hạn như MongoDB) sẽ phù hợp với trò chơi dựa trên web?
• Các vấn đề có thể phát sinh khi sử dụng RDBMS thông thường, chẳng hạn như MySQL là gì?
• Làm cách nào để bảo đảm tính nhất quán dữ liệu giữa những người dùng với MongoDB, trong khi chơi trò chơi hoặc tại các sự kiện được định thời gian, chẳng hạn như công việc định kỳ?

Tổng quan về trò chơi: Trò chơi phiêu lưu điển hình, với người chơi chiến đấu với quái vật và thu được vật phẩm và những thứ tương tự.

• Một số dữ liệu là tĩnh trên tất cả người chơi: vật phẩm, vũ khí, thuốc, bản đồ, v.v.
• Một số dữ liệu gắn với người chơi: hàng tồn kho, số liệu (số liệu thống kê), tiến độ, v.v.
• Một người chơi có thể cần biết số liệu thống kê và trạng thái của người chơi khác
• Nhiệm vụ theo lịch trình sẽ được chạy trong khoảng thời gian nhất định

Cơ sở dữ liệu noQuery có phù hợp với trò chơi dựa trên web không?

Chắc chắn rồi! Nói chung, các cơ sở dữ liệu không liên quan (như MongoDB) tốt hơn cho các trò chơi, vì chúng linh hoạt hơn trong cách chúng mô hình hóa dữ liệu, trong khi hiệu quả hơn so với cơ sở dữ liệu quan hệ (như SQL) - làm cho chúng trở thành "win-win" sự lựa chọn

Các vấn đề có thể phát sinh khi sử dụng RDBMS thông thường là gì?

Có hai nhược điểm chính khi sử dụng cơ sở dữ liệu quan hệ:

• Thiếu linh hoạt trong cách bạn mô hình hóa dữ liệu
• Hiệu suất

Thiếu linh hoạt trong cách bạn mô hình hóa dữ liệu là một nhược điểm lớn, bởi vì sử dụng cơ sở dữ liệu quan hệ buộc bạn phải lập mô hình dữ liệu để phù hợp với nhu cầu của cơ sở dữ liệu, thay vì cơ sở dữ liệu phù hợp với nhu cầu của mô hình. Ví dụ: hãy xem xét việc bạn đang tạo mô hình cho cách bạn sẽ lưu trữ các mục trong trò chơi bằng cơ sở dữ liệu quan hệ và bạn quyết định mô hình sau:

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

Bây giờ hãy xem xét cách bạn cần sửa đổi mô hình để đáp ứng, hãy làm như sau:

• Thêm một loại mặt hàng mới
• Tạo vũ khí với nhiều loại vũ khí
• Tạo một vật phẩm thuốc cũng có thể được sử dụng làm vũ khí

Chắc chắn tất cả những hành động này đều có thể thực hiện được, nhưng bạn sẽ không phải là người hạnh phúc nhất trong khi bạn thực hiện chúng, và có lẽ bạn sẽ tự hỏi, "có giải pháp nào tốt hơn ngoài kia cho những gì tôi muốn làm không?" thiết kế một mô hình linh hoạt hơn nhiều trong cơ sở dữ liệu không liên quan.

Lưu ý: Nếu bạn không quen với cách lưu trữ thông tin cơ sở dữ liệu dựa trên tài liệu, vui lòng kiểm tra liên kết này trước khi tiếp tục. Mô hình trình bày dưới đây được thiết kế để sử dụng logic tương tự như những gì được trình bày trong bài viết nói trên.

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

Có rất nhiều bài viết hay về hiệu năng của cơ sở dữ liệu NoQuery vs SQL, nhưng đây là một bài viết cung cấp các ví dụ ứng dụng để bạn có thể thực hiện các bài kiểm tra của riêng mình: MongoDB so với SQL Server 2008

Làm cách nào để đảm bảo tính nhất quán dữ liệu giữa những người dùng với MongoDB?

MongoDB hỗ trợ đọc / ghi các hoạt động nguyên tử trên các thực thể dữ liệu (tài liệu), do đó, kết quả truy vấn từ MongoDB phải luôn chính xác với những gì được lưu trữ trong cơ sở dữ liệu.

Chỉnh sửa: Được cung cấp ví dụ NoQuery của cơ sở dữ liệu mục

Vài từ để bảo vệ cơ sở dữ liệu SQL.

1 - Nếu bạn có cơ sở dữ liệu SQL, bạn có thể làm việc với dữ liệu của mình không chỉ bằng khóa chính. Hầu hết các truy vấn trong MMO đều đi theo PK nhưng khi bạn cần tìm tất cả người dùng có cấp độ> 30 bạn sẽ làm gì trong thế giới NoQuery?

2 - Nếu bạn có ngôn ngữ SQL, bạn có thể tạo "hotfix" để sửa chữa dữ liệu bị hỏng. Ví dụ: "update player_items đặt cờ = 0 trong đó item_type_id = 100". Làm thế nào bạn có thể sửa lỗi này trong NoQuery? Tôi nghĩ bạn sẽ phải tạo một kịch bản phân tích tất cả dữ liệu của bạn ...

3 - Cơ sở dữ liệu SQL không quá chậm như bạn có thể nghĩ. Đồng nghiệp của tôi tạo ra trò chơi MMO dựa trên web, thực hiện 5000 giao dịch mỗi giây trong MySQL. Nó không đủ cho bạn? Nếu không, bạn có thể sử dụng shending để mở rộng cơ sở dữ liệu của bạn.

4 - SQL có một ràng buộc khóa ngoài và những thứ tốt như vậy, điều này sẽ giúp bạn tìm ra các lỗi trong mã của bạn.

NoQuery không phải là viên đạn bạc. Nó chỉ giải quyết một vài vấn đề và mang lại nhiều vấn đề mới. Vì vậy, lời khuyên của tôi - suy nghĩ hai lần trước khi chọn NoQuery.

Câu trả lời là có, đó là một lựa chọn hợp lệ nhưng không, có lẽ đó không phải là một ý tưởng tuyệt vời .

Có hai vấn đề lớn với SQL mà NoQuery cố gắng giải quyết, khi nói đến các trò chơi.

Đầu tiên là độ trễ, hoặc độ trễ. Ở một khía cạnh nào đó, cơ sở dữ liệu SQL rất nhanh, xử lý hàng ngàn giao dịch trở lên trong một phần mười giây. Theo một nghĩa khác, chúng cực kỳ chậm, bởi vì việc xử lý chỉ một vài giao dịch có thể mất cùng thời gian đó. Đối với hầu hết các cơ sở dữ liệu sử dụng, điều này không thành vấn đề, nhưng các trò chơi có thành phần thời gian thực, do đó, không chỉ là về số lượng giao dịch bạn có thể thực hiện mỗi giây, mà còn về thời gian trung bình để đáp ứng với giao dịch cơ sở dữ liệu.

Độ trễ này là một vấn đề lớn đối với các trò chơi thời gian thực. Nhiều nhà phát triển cần cơ sở dữ liệu lớn (thường là MMO) xây dựng một lớp bộ đệm nằm giữa cơ sở dữ liệu và máy chủ trò chơi để tránh các quầy hàng này, sau đó xả bộ đệm theo định kỳ. Vấn đề? Bạn chỉ cần đưa ra những lý do chính để sử dụng cơ sở dữ liệu - tính nguyên tử, tính nhất quán, sự cô lập và độ bền .

Nhưng vấn đề đó không áp dụng cho các trò chơi web.Bạn đã có một kết nối có độ trễ cao giữa người chơi và trò chơi, do đó bạn cũng có thể nhận được thông lượng SQL cung cấp, cũng như các lợi ích của phần mềm nổi tiếng, trưởng thành.

Tuy nhiên, vấn đề thứ hai áp dụng cho bạn và đó là sự không phù hợp trở kháng quan hệ đối tượng . Trò chơi đối phó với các đối tượng, cơ sở dữ liệu đối phó với các hàng. Nếu bạn may mắn, một đối tượng có thể được tạo thành một hàng chỉ bằng cách liệt kê các trường của nó, nhưng hầu hết các đối tượng thời gian là phân cấp và bạn phải làm phẳng chúng theo một cách nào đó để đưa chúng vào hàng.

Các cơ sở dữ liệu dựa trên tài liệu, như CouchDB và MongoDB, giải quyết vấn đề này bằng cách quảng cáo tài liệu lên đối tượng cấp cao nhất, thay vì hàng ("tài liệu" trong trường hợp này là từ đồng nghĩa với "đối tượng"). Nhưng bằng cách này, họ mất nhiều lợi ích của cơ sở dữ liệu SQL. Thông lượng thấp hơn nhiều, và các thuật toán khóa trở nên phức tạp hơn nhiều.

Tin tốt là, đã có rất nhiều ánh xạ quan hệ đối tượng (ORM) công cụ có sẵn cho bất kỳ ngôn ngữ nào bạn đang sử dụng. Chúng cho phép bạn dịch giữa các đối tượng trong bộ nhớ và các hàng trong cơ sở dữ liệu khá trong suốt. Các công cụ này thường không phù hợp với các trò chơi thời gian thực quy mô lớn, bởi vì chúng có thể trình bày các khía cạnh hiệu suất tồi tệ nhất của cơ sở dữ liệu SQL và NoQuery. Nhưng thật tốt cho một trò chơi trên web - tệ nhất là khi bạn gặp vấn đề về hiệu suất, bạn có thể quay lại thực hiện các giao dịch theo cách lỗi thời. Vấn đề độ trễ không làm tổn thương bạn và thông lượng tăng giúp bạn.

Cuối cùng, để tin vào một điểm tôi đã thực hiện ở nơi khác : Đây không phải là về dữ liệu trò chơi tĩnh. Tôi không nói về các mô tả vật phẩm của bạn hoặc thiệt hại hoặc vũ khí của bạn hoặc bất cứ điều gì ở đây. Ý tôi là dữ liệu trò chơi thực sự, có thể thay đổi, như những gì trong kho của người chơi hoặc số liệu thống kê của họ. Tất cả bạn cần cho dữ liệu tĩnh là một kho lưu trữ dữ liệu. Có thể nó chỉ ra rằng điều dễ nhất để làm là sử dụng cùng một cơ sở dữ liệu như kho lưu trữ dữ liệu vì bạn có một ORM tuyệt vời; có lẽ bạn sẽ chỉ cần hệ thống tập tin. Đó là hai vấn đề riêng biệt và một câu trả lời không cần (và có lẽ sẽ không) phù hợp với cả hai trường hợp.

• Liệu một kho lưu trữ dữ liệu noQuery (dựa trên tài liệu, chẳng hạn như MongoDB) sẽ phù hợp với trò chơi dựa trên web?

Tôi khuyên bạn nên nhìn vào couchdb

Giao diện của nó dựa trên javascript, vì vậy nó sẽ kết hợp khá tốt với các trò chơi dựa trên HTML5 / javascript.

Nó cũng có thể hoạt động 'ngoại tuyến' (tạo một bản sao cục bộ của db) và sau đó tự đồng bộ hóa với máy chủ sau này (ví dụ: bạn có thể sử dụng điều này cho các dungeon được kích hoạt)

• Các vấn đề có thể phát sinh khi sử dụng RDBMS thông thường, chẳng hạn như MySQL là gì?

Vấn đề chính là cơ sở dữ liệu không có sql xử lý khá khác với cơ sở dữ liệu quan hệ. Làm cho việc chuyển đổi tinh thần có thể khó khăn.

Ví dụ, hãy xem cách " truy vấn " được thực hiện trong couchdb. Tất cả mọi thứ được thực hiện trong javascript.

• Làm cách nào để bảo đảm tính nhất quán dữ liệu giữa những người dùng với MongoDB, trong khi chơi trò chơi hoặc tại các sự kiện được định thời gian, chẳng hạn như công việc định kỳ?

Quá trình 'đồng bộ hóa' cơ sở dữ liệu được gọi là sao chép trong biệt ngữ của couchdb. Bạn cũng sẽ thấy thuật ngữ nhất quán rất nhiều. Có một số dịch vụ tích hợp liên quan đến nhân rộng và tính nhất quán. Xem ví dụ quá trình nhân rộng gia tăng .

Tùy thuộc vào những gì bạn có trong trò chơi của mình, bạn có thể sẽ sử dụng cả hai và kết nối chúng thông qua các mô hình trong trò chơi của mình. Ví dụ: trình phát có thể và nên có trong RDB (thông tin đăng nhập) nhưng kho lưu trữ / lưu trữ biến của trình phát có thể chuyển sang noQuery, vì vậy mô-đun trình phát của bạn có thể login()sử dụng RDB vàfetchInventory() sử dụng noQuery bằng khóa chính.

Ví dụ, các bản đồ tốt hơn sẽ được lưu trong NoQuery (ví dụ: tọa độ của các đối tượng khác nhau) tôi không tưởng tượng việc lưu một khu vực chứa trong RDB (ngoại trừ một chuỗi được xê-ri hóa mà bạn cần phải hủy xác định hoàn toàn để đọc một phần của? và RAM bị lãng phí!) bạn vẫn có thể lưu các khu vực trong RDB, ví dụ như khu vực "thành phố X" có chứa các dây / khối sau ([3,4], [8,7] ...)

bạn có thể và có thể nên sử dụng cả hai, và xem xét lưu trữ dễ bay hơi như memcache mà bạn có thể cần hoặc một số dữ liệu tạm thời (sẽ nhanh hơn sử dụng đĩa cứng! và tiết kiệm cho bạn rất nhiều CPU nhưng chắc chắn không phải RAM)

vì vậy cuối cùng>

nó phụ thuộc vào những gì bạn muốn có trong trò chơi của bạn! cổ vũ