DBMS nào đủ nhanh cho một trò chơi trực tuyến (vài nghìn người chơi)? [đóng cửa]

Tôi hiện đang làm một game MMORPG, có thể có vài nghìn người chơi trực tuyến cùng một lúc (có lẽ là không; chỉ là mơ tưởng). Đầu tiên chúng tôi muốn sử dụng MySQL, nhưng tôi nghe nói nó không đủ nhanh cho quy mô này.

DBMS nào đủ nhanh? Nó giống như SQL Server như thế nào (như tôi đã học SQL Server ở trường)?

Đây là một câu hỏi thực sự khó trả lời. Bạn có thể lấy nền tảng cơ sở dữ liệu nhanh nhất trên thế giới, thiết kế một lược đồ khủng khiếp, viết một ứng dụng nhảm nhí xung quanh nó, và sau đó bị cám dỗ đổ lỗi cho nền tảng cơ sở dữ liệu. Đồng thời, bạn có thể sử dụng SQL Server Express miễn phí và, với thiết kế phù hợp, logic ứng dụng và cách tiếp cận ở khả năng mở rộng hợp lý (ví dụ: mở rộng các lần đọc bằng bộ đệm dữ liệu, v.v.), bạn có thể viết một ứng dụng xử lý 1000 giây người dùng không có vấn đề.

Tôi có tin SQL Server có thể xử lý 1000 người dùng không? Chắc chắn rồi. Tôi có tin rằng Oracle và DB2 cũng có thể làm như vậy không? Chắc chắn rồi. MySQL? Không chắc chắn, không đủ kinh nghiệm ở đó. Truy cập? Có lẽ không phải là một lựa chọn khôn ngoan chút nào. Nếu bạn đã quen thuộc với SQL Server, thì tôi khuyên bạn nên xem đó là lộ trình bạn xem xét, chỉ cần lưu ý rằng sự lựa chọn RDBMS của bạn sẽ không quyết định thành công hay thất bại.

Hãy để tôi nói theo cách này, hãy nhớ GameSpy Arcade từ đầu những năm 2000? Nó đã chạy hàng ngàn trò chơi và tất cả đều chạy trên SQL Server và hỗ trợ hàng chục nghìn người dùng cùng một lúc (vâng, chúng tôi có một số Máy chủ SQL trong đó làm nhiều việc khác nhau). Đó là tất cả về thiết kế cơ sở dữ liệu và cách bạn sử dụng hệ thống. Làm như vậy một cách chính xác và dự án của bạn sẽ thành công, làm không chính xác và dự án của bạn sẽ thất bại, tồi tệ.

Câu trả lời đúng phụ thuộc rất nhiều vào nền tảng bạn đang lập trình.

Nó chỉ xảy ra khi ai đó hỏi câu hỏi này cho một nền tảng cụ thể trong StackOverflow khoảng 1,5 năm trước.

Cho dù đó là MySQL, SQL Server, Oracle, PostgreSQL hoặc một số RDBMS khác, bạn phải rất sáng tạo với cơ sở hạ tầng cơ sở dữ liệu. Nếu bạn có một sổ séc mở cho phần cứng và DBMS có độ bền công nghiệp, thì Oracle là dành cho bạn (nếu thực tế, Oracle RAC sẽ được mong muốn hơn). Nếu bạn đang phát triển bằng IIS và môi trường Microsoft, thì đó là SQL Server. Nếu bạn có mối quan tâm về ngân sách và muốn có giao diện của Oracle, PostgreSQL sẽ giải cứu. Nếu bạn có mối quan tâm về ngân sách, trí tưởng tượng sống động và muốn điều khiển Công cụ lưu trữ theo ý thích của mình để phù hợp với tuân thủ ACID, đọc tốc độ cao và một loạt các kiến ​​trúc sao chép, tôi sẽ nói một cách định kiến ​​về MySQL.

DBMS nên là mối lo lắng tối thiểu của bạn với MMORPG. Vấn đề lập trình luôn luôn xuất hiện cá lớn hơn để chiên. Vì vậy, hãy đưa ra quyết định của bạn một cách thận trọng và sáng suốt, bởi vì bất kỳ DBMS nào bạn chọn, bạn phải sống với nó ( giống như cách FaceBook phải sống với MySQL ).

Đây không phải là câu hỏi đúng. Hiệu suất của trò chơi của bạn sẽ phụ thuộc vào kiến ​​trúc và công nghệ hoàn chỉnh mà bạn chọn và cách nó được triển khai. DBMS chỉ là một thành phần của ngăn xếp. Tôi sẽ mạo hiểm đoán rằng DBMS dường như không phải là một yếu tố hạn chế về hiệu suất trừ khi bạn thiết kế mọi thứ rất kém. Lớp tên miền của bạn, bộ đệm và cách bạn phân phối và mở rộng trang web dường như là mối quan tâm quan trọng hơn nhiều.

Bất kỳ RDBMS nào cũng sẽ giảm theo tỷ lệ tùy thuộc vào cách cấu hình, tỷ lệ và cách ứng dụng sử dụng nó.

Tôi nghĩ rằng, bạn đã có hai câu hỏi trong một. Thứ nhất, "những gì DBMS có khả năng duy trì dữ liệu trò chơi một cách hiệu quả." (chủ quan, imho) Thứ hai, "làm cách nào để chia tỷ lệ DBMS đó để thực hiện với 1000 người dùng?"

Nhiều dịch vụ trực tuyến đã tìm thấy sự kết hợp giữa MySQL và Memcached để cung cấp hiệu suất và quy mô tuyệt vời. Tuy nhiên, có một điểm mà giải pháp đó cũng rơi xuống. Tuy nhiên, nó có thể chính xác là những gì bạn cần.

Ngày càng có nhiều dịch vụ trực tuyến đang đưa vào giải pháp NoQuery vào kiến ​​trúc của họ. Tôi có một số kinh nghiệm với CouchBase và thấy nó hữu ích.

Mã, thiết kế và đĩa của bạn (để ghi) xác định hiệu suất nói chung. Không phải nền tảng.

Bạn có thể xem CUBRID . Đó là một RDBMS mã nguồn mở rất "nóng" ở Hàn Quốc ngay bây giờ. Giả sử hoạt động tốt nhất / thực sự nhanh đối với các ứng dụng web có số lượng người dùng cao (họ nói 50 nghìn hoặc đại loại như thế).

Tôi nghĩ rằng bất kỳ cơ sở dữ liệu chính nào cũng có thể xử lý tải nếu được thiết kế tốt. Đáng buồn là tôi sẽ ước tính rằng ít hơn 1% của tất cả các cơ sở dữ liệu được thiết kế tốt. (Cá nhân tôi đã xử lý dữ liệu từ hàng ngàn cơ sở dữ liệu khác nhau thực hiện nhiều chức năng khác nhau, vì vậy tôi nghĩ rằng tôi có một ý tưởng tốt về việc thiếu chất lượng ngoài thế giới thực.)

Tôi thực sự khuyên bạn nên lấy một số sách về điều chỉnh hiệu suất cho cơ sở dữ liệu bạn chọn và đọc chúng trước khi bắt đầu thiết kế. Có nhiều thứ sẽ giúp cơ sở dữ liệu của bạn hoạt động tốt hơn nên được thiết kế ngay từ đầu. Chỉ cần biết cách viết các truy vấn biểu diễn và chỉ mục thiết kế là rất quan trọng để có được một thiết kế tốt. Loại nghiên cứu và hiệu suất được thiết kế này không phải là tối ưu hóa sớm. Không có lý do nào để sử dụng các kỹ thuật tiêu diệt hiệu suất đã biết trong thiết kế. Cơ sở dữ liệu cần được thiết kế để thực hiện ngay từ đầu.

Chúng tôi có các trò chơi di động với 1000 người chơi và chúng tôi đã thấy giảm tải rất lớn bằng cách truy cập các nhóm kết nối IIS / .NET mysql liên tục. mysql 5.1

Hãy suy nghĩ về việc giữ dữ liệu "chỉ ghi" ở một nơi khác để giảm tải cho bất kỳ db nào bạn chọn Cassandra hoặc syslog. Hãy suy nghĩ về việc giữ nhanh chóng thay đổi, dữ liệu nhất thời nhưng có thể xây dựng lại trong một db nosql như memcache, riak, v.v.