Odpowiedzi:
Zrobiliśmy to, mam nadzieję, że Ben Z poda lepsze wyjaśnienie powodów niż ja, ponieważ był on oryginalnym autorem naszej bazy danych. Krótka wersja jest taka, że relacyjne bazy danych nie są zbyt przydatne w grach, ponieważ nie mogą skutecznie przechowywać silnie ustrukturyzowanych danych hierarchicznych, które stanowią ogromną większość danych, których MMO potrzebuje do normalnego działania. Zdecydowaliśmy się zbudować niestandardową bazę danych obiektów i część rozproszonego systemu przetwarzania transakcji, który obecnie produkuje i zasila nasze dwie gry na żywo.
A jeśli powinieneś zrobić to samo? Prawdopodobnie nie, przynajmniej na początku. Nadal opowiadałbym się za unikaniem SQL, ale w świecie „NoSQL” istnieje wiele innych opcji, które jeszcze kilka lat temu nie istniały.
To powiedziawszy, większość MMO działa na bazach danych SQL (relacyjnych). Wiem, że Eve działa na instalacji SQL Server na kilku RAMSANach o wielu TB (prawdopodobnie nigdy w życiu nie będę miał tyle pieniędzy, ile kosztują te rzeczy).
EDIT: Mam nadzieję, że nie przeszkadza mi delegowania to tutaj, ale to jest notka z niektórych linków i komentarzy na temat prezentacji daliśmy na GDC'08 o naszej bazie danych.
Dobra, ta odpowiedź jest raczej spostrzeżeniem.
Pełne ujawnienie Nie pracowałem nad MMORPG. Pracowałem w jednej z 10 najczęściej odwiedzanych stron w 2009 roku i pracowałem w firmie zajmującej się silnikami gier, która myślała, że produkuje technologię MMORPG (nie wiem, czy została dostarczona).
Jeśli spojrzysz na firmy, które osiągnęły masową skalę (Google, Facebook, Twitter itp.), Wiem, że nie są to firmy z branży gier, ale warto na nie spojrzeć w tej przestrzeni), są dwie rzeczy, które moim zdaniem są ważne.
Dużym błędem jest złapanie jakiejś drogiej rzeczy pod klucz i spodziewanie się, że magicznie się skaluje. To nie działa w ten sposób. Kluczem do zwiększenia jest odpowiednie podejście do każdego nowego wyzwania. Potrzebujesz elastycznych, łatwych w użyciu rozwiązań, które możesz łatwo wprowadzać i wychodzić.
Tak więc moja rada byłaby dla ciebie, jeśli zaczynasz, po prostu zdobądź najmniej kłopotliwy ból głowy.
Zasadniczo istnieje cała gama podejść i myślę, że są one wybierane bardziej na podstawie doświadczeń ich programistów niż właściwości bazy danych. Z jednej strony wiele MMO korzysta ze standardowych relacyjnych baz danych - np. Używane / używane przez Dark Ages of Camelot (czy nadal będą?) MySQL , FreeRealms używają zmodyfikowanego Postgresqla itp.
Poruszając się po skali, masz Guild Wars: używają SQL Servera , ale umieszczają tam swoje dane jako jedną BLOBĘ. Oznacza to, że czerpią korzyści ze swoich zwykłych formatów binarnych z pewnymi korzyściami zapewnianymi przez bazę danych. Nie trzeba dodawać, że prawdopodobnie można zauważyć pewne wady tego podejścia, ale dla firmy przyzwyczajonej do pracy z plikami płaskimi prawdopodobnie nadal jest to krok naprzód.
Prawdopodobnie są miejsca, w których stosuje się różne sformalizowane metody NoSQL, choć wciąż są jeszcze wczesne dni. Farmville używa membase , którą wykonali do tego celu, na podstawie najwyraźniej memcached. Dzieje się tak z wieloma funkcjami, takimi jak MongoDB, CouchDB itp. Znowu dzięki tym podejściom zwykle tworzysz własne formaty pamięci, ale zyskujesz korzyści z dystrybucji, buforowania, redundancji itp.
Niektórzy całkowicie wprowadzają własny NoSQL: Cryptic powiedział, że zrobili coś podobnego, ale powiedział również, że nie używali go w produkcji. ( EDYCJA : ale patrz komentarze poniżej.)
A potem przychodzisz do ludzi, którzy używają płaskich plików tekstowych lub plików binarnych - jak rozumiem, starsze gry, takie jak Ultima Online, Everquest itp. Poszły tą drogą, a dla firmy z doświadczeniem w tworzeniu gier, ale z niewielkim doświadczeniem w bazach danych, działa to dobrze też.
Zauważ też, że prawie nigdy nie omija Cię pisanie własnej bazy danych w luźnym znaczeniu tego słowa - w grach zawsze masz indywidualne dane, które musisz zarządzać w pamięci lub na dysku w sposób, który nie jest dla nich odpowiedni. do ogólnego oprogramowania. Nie możesz wykonywać zapytań SQL za każdym razem, gdy chcesz mieć jakieś dane, więc będziesz musiał dublować wiele informacji w kodzie, bez względu na to, jakiego używasz zaplecza.
W Pirates of the Burning Sea zaczęliśmy od MySQL (choć szczerze mówiąc wolałbym Postgres), a kiedy zaczął spadać pod obciążeniem, przeszliśmy na Microsoft SQL Server. Szczerze mówiąc, prawdopodobnie w przyszłości nie pójdę tą drogą. Większość danych PotBS jest wstępnie serializowana, zanim zostaną utrwalone, więc duża część tego, co znajduje się w DB, jest niczym więcej niż przerośniętym kluczem / wartością. Ponadto, aby uzyskać lepszą wydajność z naszej warstwy trwałości i lepszą kontrolę nad tym, jak dane są buforowane w pamięci, ostatecznie napisaliśmy serwer buforujący, który stał przed bazą danych.
Więc Kylotan ma rację, że nie będziesz się kręcił na pewnym poziomie. Serwery relacyjnych baz danych SQL nie są zaprojektowane do wykorzystania danych przez gry. Zamiast zakładać, że relacyjne serwery DB są końcowymi bazami danych, naprawdę powinniśmy więcej pomyśleć o korzyściach, których szukaliśmy przed wyborem narzędzia.
Następnym razem zajrzę bardziej do rzeczy takich jak BerkleyDB lub niektóre inne bazy danych w stylu NoSQL.
Należy również zauważyć, że jeśli masz (względnie) statyczny zestaw danych, nie przechowuj go w bazie danych! Nie ma naprawdę dobrego powodu do przechowywania definicji zaklęć, definicji przedmiotów, map itp. W bazie danych. Rzadko je odpytujesz, z wyjątkiem nazwiska. Widzę, jak wielu ludzi skacze do tworzenia gier, przechowując te rzeczy wraz z utrwalonymi danymi graczy, i to jest zupełnie inna klasa rzeczy.
Potrzebujesz do tego magazynu danych, takiego jak system plików. Poza programowaniem nie potrzebujesz ACID, nie potrzebujesz CRUD, nie potrzebujesz bazy danych dla tego rodzaju danych. W trakcie programowania potrzebujesz bazy danych, ale i tak potrzebujesz VCS, a twój wybór VCS dokona dla ciebie wyboru bazy danych.
(Jeśli pracujesz nad grą, w której gracze mogą tworzyć niestandardowe zaklęcia, przedmioty lub zadania, to te dane są tego samego rodzaju co dane gracza i potrzebujesz bazy danych ponownie).
MMORPG to intensywne aplikacje i ogromne przedsięwzięcie. Jeśli zaczynasz od tworzenia gier, zdecydowanie zalecamy zrobienie czegoś mniejszego.
To powiedziawszy, że będziesz potrzebować dwóch najlepszych wyników w swojej konfiguracji. Oczywiście potrzebujesz farmy serwerów / gałęzi serwerów. Ponieważ komunikacja sieciowa jest stosunkowo droga (a większość MMORPG odbywa się w czasie rzeczywistym), możesz chcieć zreplikować swoją centralną bazę danych na każdym z serwerów gry (odpowiednik replikacji w czasie rzeczywistym o niskiej latencji w wybranej bazie danych).
Jeśli każdy z Twoich serwerów obsługuje określony segment świata gry (tak jak działa WoW); coś jak rozproszone widoki partycjonowane . DPV umożliwiają segmentację wierszy bazy danych na różnych serwerach; zgodnie z ograniczeniami na kolumnach na każdym serwerze. Zarówno MSSQL, jak i Oracle są wystarczająco inteligentne, aby rozmawiać tylko z serwerem, który zawiera dane objęte klauzulą WHERE lub ON. Nie jestem pewien, czy któraś z ofert open source ma DPV.
Rezultatem tego wszystkiego jest to, że nie ma znaczenia, jakiego DB używasz , wystarczy użyć jednego z dobrą nazwą: MSSQL, Oracle, MySQL, PostgreSQL. Napisz bazę danych w ANSI SQL i zobacz, który system działa najlepiej - to jedyny sposób, aby się dowiedzieć.
Trasa NoSQL może być również dobrym pomysłem, ponieważ została zaprojektowana z myślą o wysokiej współbieżności. Sugestia Pranny może załatwić sprawę.
Użyłem MongoDB (NoSQL), jest to bardzo szybki magazyn dokumentów, do którego można uzyskać dostęp przez TCP. Spróbuj! To jest zajebiste!
Pisanie własnej bazy danych to trudne zadanie. Sugeruję, aby najpierw zbadać, co już tam jest, a jeśli nie możesz znaleźć niczego, co pasowałoby do określonego zestawu kryteriów, zbuduj własne. Aha, i nie zapomnij go otworzyć. :)
Myślę, że to zależy w dużej mierze od tego, jakiego rodzaju dane potrzebujesz przechowywać i pod jaką postacią.
Myślę, że większość ludzi używa „standardowych” baz danych SQL do „dynamicznych” danych, takich jak informacje o graczach, czy to SQL Server, MySQL, PostgreSQL.
Jednak „wewnętrzne” dane (stan świata, treść,…) mogą być przechowywane w dowolnej formie, i przypuszczam, że większość firm pisze przynajmniej częściowo niestandardowe systemy baz danych dla tej części, dostosowane do ich specyficznych potrzeb .
To pytanie jest dość stare, ale mój pomysł na to, jak sobie z tym poradzić, jest tak samo ważny, jak został zadany, tak jak dziś.
Jeśli używasz relacyjnej bazy danych, musisz zmniejszyć obciążenie, więc ten pomysł powinien pomóc.
Przechowuj wszystkie informacje publiczne w lokalnej bazie danych w każdym systemie klienta, a także w bazie danych serwerów.
Przechowuj wszystkie tabele z elementami w bazie danych klienta. Zamiast patrzeć na serwer, gdy najedziesz myszką na tę broń w celu uzyskania statystyk, klient sprawdza statystyki w lokalnej bazie danych. Serwer ma własną bazę danych do pobierania statystyk podczas obliczania i przekazywania klientom obrażeń i zdrowia.
Najgorszym przypadkiem tego pomysłu jest to, że każdy może zobaczyć statystyki wszystkich broni, jeśli uda im się dostać do bazy klientów. nie ma to jednak znaczenia, ponieważ nawet jeśli zmienią wartości, wartości bazy danych na serwerze są tym, co oblicza w grze.