Câu trả lời:
Chúng tôi đã làm, hy vọng Ben Z sẽ đưa ra một lời giải thích tốt hơn về những lý do hơn tôi có thể vì ông thực sự là tác giả ban đầu của cơ sở dữ liệu của chúng tôi. Phiên bản ngắn là các DB quan hệ không hữu ích cho các trò chơi vì chúng không thể lưu trữ hiệu quả dữ liệu phân cấp có cấu trúc mạnh, chiếm phần lớn dữ liệu mà MMO cần cho hoạt động bình thường. Chúng tôi chọn xây dựng cơ sở dữ liệu đối tượng tùy chỉnh và một phần của hệ thống xử lý giao dịch phân tán, hiện đang được sản xuất và cung cấp năng lượng cho hai trò chơi trực tiếp của chúng tôi.
Nếu bạn nên làm như vậy? Có lẽ là không, ít nhất là không phải lúc đầu. Tôi vẫn sẽ ủng hộ việc tránh SQL, nhưng hiện tại có nhiều tùy chọn hơn trong thế giới "NoQuery" không tồn tại vài năm trước.
Điều đó nói rằng, hầu hết các MMO đều chạy trên cơ sở dữ liệu SQL (quan hệ). Tôi biết rằng Eve chạy trên bản cài đặt SQL Server, nằm trên một vài RAMAN nhiều TB (có lẽ trong đời tôi sẽ không bao giờ có nhiều tiền như những thứ đó).
EDIT: Hy vọng anh ấy sẽ không phiền tôi đăng bài này ở đây, nhưng đây là một mục blog với một số liên kết và nhận xét về bản trình bày chúng tôi đã đưa ra tại GDC'08 về cơ sở dữ liệu của chúng tôi.
Được rồi câu trả lời này là nhiều hơn một quan sát.
Tiết lộ đầy đủ Tôi chưa từng làm việc trên MMORPG. Tôi đã làm việc tại một trong 10 trang web được truy cập nhiều nhất vào năm 2009 và tôi đã làm việc tại công ty game engine nghĩ rằng họ đang tạo ra công nghệ MMORPG (tôi không biết nếu được giao hàng).
Nếu bạn nhìn vào các công ty đã đạt được quy mô lớn (Google, Facebook, Twitter, v.v., tôi biết họ không phải là công ty trò chơi, nhưng họ đáng để xem xét trong không gian này) có hai điều mà tôi nghĩ là quan trọng.
Một sai lầm lớn là lấy một số thứ chìa khóa trao tay đắt tiền và mong đợi nó có quy mô kỳ diệu cho bạn. Nó không hoạt động theo cách đó. Chìa khóa để nhân rộng là đối phó với từng thử thách mới một cách thích hợp. Bạn cần linh hoạt dễ sử dụng các giải pháp mà bạn có thể di chuyển ra vào dễ dàng.
Vì vậy, lời khuyên của tôi cho bạn sẽ là nếu bạn bắt đầu, chỉ cần có được những gì dường như ít đau đầu nhất để giải quyết.
Về cơ bản, có một loạt các phương pháp tiếp cận và tôi nghĩ rằng chúng được chọn dựa trên kinh nghiệm của các nhà phát triển của họ cũng như các thuộc tính của cơ sở dữ liệu. Cuối cùng, nhiều MMO đang sử dụng cơ sở dữ liệu quan hệ tiêu chuẩn - ví dụ. Dark Ages of Camelot đã sử dụng / sử dụng (chúng vẫn còn hoạt động phải không?) MySQL , FreeRealms sử dụng một Postgresql đã được sửa đổi , v.v.
Di chuyển theo quy mô, bạn có Guild Wars: họ sử dụng SQL Server , nhưng họ gắn dữ liệu của họ vào đó dưới dạng một BLOB duy nhất. Điều này có nghĩa là họ nhận được lợi ích của các định dạng nhị phân thông thường của họ với một số lợi ích mà cơ sở dữ liệu cung cấp. Không cần phải nói, có lẽ bạn cũng có thể thấy một số nhược điểm của phương pháp này, nhưng đối với một công ty đã từng làm việc với các tệp phẳng, có lẽ nó vẫn là một bước tiến.
Sau đó, có thể có một số nơi sử dụng các cách tiếp cận NoQuery chính thức hóa khác nhau, mặc dù vẫn còn sớm. Farmville sử dụng membase , mà họ đã thực hiện cho mục đích này, dựa trên memcached rõ ràng. Điều này chia sẻ nhiều tính năng giống như MongoDB, CouchDB, v.v. Một lần nữa với những cách tiếp cận này, bạn thường cuộn các định dạng lưu trữ của riêng mình nhưng nhận được lợi ích của việc phân phối, lưu trữ, dự phòng, v.v.
Một số người đang hoàn thành NoQuery của riêng họ: Cryptic cho biết họ đã làm một cái gì đó tương tự nhưng cũng nói rằng họ không sử dụng nó trong sản xuất. ( EDIT : nhưng xem bình luận bên dưới.)
Và sau đó bạn đến với những người đang sử dụng văn bản phẳng hoặc tệp nhị phân - theo tôi hiểu thì các trò chơi cũ hơn như Ultima Online, Everquest, v.v ... đều đi theo con đường này và đối với một công ty có kinh nghiệm phát triển trò chơi nhưng ít kinh nghiệm cơ sở dữ liệu này hoạt động tốt quá.
Cũng lưu ý rằng bạn hầu như không bao giờ viết về cơ sở dữ liệu của riêng mình theo nghĩa lỏng lẻo của thuật ngữ - trong các trò chơi, bạn sẽ luôn có dữ liệu mà bạn cần để quản lý trong bộ nhớ hoặc trên đĩa theo cách không cho vay để phần mềm chung chung. Bạn không thể thực hiện các truy vấn SQL mỗi khi bạn muốn một số dữ liệu, do đó bạn sẽ cần phải phản chiếu nhiều thông tin của mình trong mã cho dù bạn sử dụng back end nào.
Trên Cướp biển biển, chúng tôi đã sử dụng MySQL (mặc dù thật lòng tôi sẽ thích Postgres hơn) và khi nó bắt đầu rơi xuống dưới tải, chúng tôi đã chuyển sang Microsoft SQL Server. Thành thật mà nói, có lẽ tôi sẽ không đi con đường đó một lần nữa trong tương lai. Hầu hết các dữ liệu PotBS được tuần tự hóa trước khi nó vẫn tồn tại, vì vậy một phần lớn những gì trong DB không gì khác hơn là một kho lưu trữ khóa / giá trị phát triển quá mức. Trên hết, để có được hiệu suất tốt hơn từ lớp kiên trì của chúng tôi và kiểm soát tốt hơn cách dữ liệu được lưu trong bộ nhớ, chúng tôi đã kết thúc việc viết một máy chủ bộ đệm lưu trữ trước cơ sở dữ liệu.
Vì vậy, Kylotan rất đúng, bạn sẽ không phải tự mình xoay sở ở một cấp độ nào đó. Các máy chủ cơ sở dữ liệu quan hệ SQL không được thiết kế cho cách các trò chơi sử dụng dữ liệu. Thay vì cho rằng các máy chủ DB quan hệ là cuối cùng của tất cả các cơ sở dữ liệu, chúng tôi thực sự nên nghĩ nhiều hơn về những lợi ích mà chúng tôi đang tìm kiếm trước khi chọn một công cụ.
Thời gian tới, tôi sẽ tìm hiểu thêm về những thứ như BerkleyDB hoặc một số DB kiểu NoQuery khác.
Một điều khác cần lưu ý là nếu bạn có một bộ dữ liệu tĩnh (tương đối), đừng lưu trữ nó trong cơ sở dữ liệu! Không có lý do thực sự tốt để lưu trữ định nghĩa chính tả, định nghĩa vật phẩm, bản đồ, v.v. trong cơ sở dữ liệu. Bạn hiếm khi truy vấn chúng ngoại trừ theo tên. Tôi thấy rất nhiều người nhảy vào phát triển trò chơi lưu trữ những thứ này ngay bên cạnh dữ liệu người chơi kiên trì và đó là một loại thứ hoàn toàn khác.
Bạn cần một kho lưu trữ dữ liệu, như hệ thống tập tin, cho những thứ này. Ngoài sự phát triển, bạn không cần ACID, bạn không cần CRUD, bạn không cần cơ sở dữ liệu cho loại dữ liệu đó. Bên trong sự phát triển, bạn cần một cơ sở dữ liệu, nhưng dù sao bạn cũng cần một VCS và lựa chọn VCS của bạn sẽ đưa ra lựa chọn cơ sở dữ liệu đó cho bạn.
(Nếu bạn đang làm việc trong một trò chơi nơi người chơi có thể tạo phép thuật hoặc vật phẩm hoặc nhiệm vụ tùy chỉnh, thì dữ liệu đó sẽ giống với dữ liệu người chơi và bạn cần lại cơ sở dữ liệu.)
MMORPG là những ứng dụng chuyên sâu và là một công việc khổng lồ. Nếu bạn đang bắt đầu với việc phát triển trò chơi, tôi thực sự khuyên bạn nên làm một cái gì đó nhỏ hơn.
Điều đó nói rằng bạn sẽ cần hai hiệu năng tối đa trong thiết lập của bạn. Bạn rõ ràng là sẽ cần một trang trại / tổ ong. Vì giao tiếp mạng tương đối đắt tiền (và hầu hết các MMORPG là thời gian thực), bạn có thể muốn sao chép cơ sở dữ liệu trung tâm của mình sang từng máy chủ trò chơi của mình (tương đương với sao chép độ trễ thấp trong thời gian thực trong cơ sở dữ liệu bạn chọn).
Nếu mỗi máy chủ của bạn đang phục vụ một phân khúc cụ thể của thế giới trò chơi (như WoW hoạt động); một cái gì đó như Chế độ xem phân tán . DPV cho phép bạn phân đoạn các hàng cơ sở dữ liệu của mình trên các máy chủ khác nhau; theo các ràng buộc trên các cột tại mỗi máy chủ. Cả MSSQL và Oracle đều đủ thông minh để chỉ nói chuyện với máy chủ chứa dữ liệu nằm trong mệnh đề WHERE hoặc ON của bạn. Tôi không chắc chắn nếu bất kỳ dịch vụ nguồn mở nào có DPV.
Kết quả cuối cùng của tất cả là nó không quan trọng bạn sử dụng DB gì , chỉ cần sử dụng một cái có tên hay: MSSQL, Oracle, MySQL, PostgreQuery. Viết cơ sở dữ liệu của bạn bằng ANSI SQL và xem hệ thống nào hoạt động tốt nhất - đó là cách duy nhất để tìm hiểu.
Tuyến NoQuery cũng có thể là một ý tưởng hay vì nó được thiết kế cho tính đồng thời cao. Đề nghị của Pranny có thể làm điều đó.
Tôi đã sử dụng MongoDB (NoQuery), đây là kho lưu trữ tài liệu rất nhanh có thể truy cập qua TCP. Hãy thử một lần! Thật tuyệt vời!
Viết DB của riêng bạn là một nhiệm vụ khó khăn. Tôi khuyên bạn trước tiên nên khám phá những gì đã có ngoài đó và nếu bạn không thể tìm thấy bất kỳ điều gì phù hợp với bộ tiêu chí cụ thể của mình, hãy xây dựng tiêu chí của riêng bạn. Ồ, và đừng quên mở nguồn. :)
Tôi đoán nó phụ thuộc khá nhiều vào loại dữ liệu bạn cần lưu trữ và dưới dạng nào.
Tôi nghĩ rằng hầu hết mọi người ở ngoài đó sử dụng cơ sở dữ liệu SQL "tiêu chuẩn" cho dữ liệu "động" như thông tin của người chơi, có thể là SQL Server, MySQL, PostgreQuery.
Tuy nhiên, dữ liệu "nội bộ" (trạng thái của thế giới, nội dung, ....) có thể được lưu trữ dưới bất kỳ hình thức nào và tôi đoán rằng hầu hết các công ty đều viết ít nhất một phần hệ thống cơ sở dữ liệu tùy chỉnh cho phần đó, phù hợp với nhu cầu cụ thể của họ .
Câu hỏi này khá cũ nhưng Ý tưởng của tôi về cách xử lý nó có giá trị như được hỏi như ngày nay.
Nếu bạn đang sử dụng cơ sở dữ liệu quan hệ, bạn cần giảm tải cho nó để ý tưởng này có ích.
Lưu trữ tất cả thông tin công khai trên một DB cục bộ trên mỗi hệ thống máy khách cũng như trong DB máy chủ.
Lưu trữ tất cả các bảng với các mục trên cơ sở dữ liệu khách hàng. Thay vì máy khách tìm đến máy chủ khi bạn di chuột qua vũ khí đó để lấy số liệu thống kê, máy khách chỉ kiểm tra cơ sở dữ liệu cục bộ để tìm số liệu thống kê. Máy chủ có cơ sở dữ liệu riêng để lấy số liệu thống kê khi tính toán và chỉ chuyển tiếp thiệt hại và sức khỏe còn lại cho khách hàng.
Trường hợp xấu nhất với ý tưởng này là mọi người đều có thể thấy các số liệu thống kê cho tất cả các vũ khí nếu họ quản lý để vào cơ sở dữ liệu khách hàng. mặc dù điều đó không quan trọng ngay cả khi họ thay đổi các giá trị, các giá trị cơ sở dữ liệu trên máy chủ là những gì tính toán trong trò chơi.