Odpowiedź brzmi: tak, to ważna opcja, ale nie, to prawdopodobnie nie jest świetny pomysł .
Istnieją dwa główne problemy z SQL, które NoSQL próbuje rozwiązać, jeśli chodzi o gry.
Pierwszym z nich jest opóźnienie lub opóźnienie. W pewnym sensie bazy danych SQL są niezwykle szybkie, przetwarzając tysiące transakcji lub więcej w dziesiątych części sekundy. W innym sensie są niezwykle powolne, ponieważ przetworzenie zaledwie kilku transakcji może zająć tyle samo czasu. W przypadku większości zastosowań baz danych nie ma to znaczenia, ale gry zawierają komponent czasu rzeczywistego, więc nie chodzi tylko o liczbę transakcji na sekundę, ale o średni czas potrzebny na odpowiedź na transakcję w bazie danych.
Opóźnienie to jest poważnym problemem w przypadku gier w czasie rzeczywistym. Wielu programistów, którzy potrzebują dużych baz danych (zwykle dla MMO), buduje warstwę buforowania, która znajduje się między bazą danych a serwerami gry, aby uniknąć tych opóźnień, a następnie okresowo opróżnia pamięć podręczną. Problem? Właśnie wyrzuciłeś główne powody korzystania z bazy danych - atomowość, spójność, izolacja i trwałość .
Ale ten problem nie dotyczy gier internetowych. Masz już połączenie z odtwarzaczem i grą o dużym opóźnieniu, więc równie dobrze możesz uzyskać przepływność zapewnianą przez SQL, a także zalety dojrzałego, dobrze znanego oprogramowania.
Drugi problem dotyczy ciebie i to niedopasowanie impedancji relacyjnej względem obiektu . Gry zajmują się obiektami, bazy danych zajmują się rzędami. Jeśli masz szczęście, obiekt można przekształcić w wiersz, po prostu wymieniając jego pola, ale w większości przypadków obiekty są hierarchiczne i musisz je w jakiś sposób spłaszczyć, aby umieścić je w rzędach.
Bazy danych oparte na dokumentach, takie jak CouchDB i MongoDB, rozwiązują ten problem, promując dokument do obiektu najwyższego poziomu, a nie wiersza („dokument” w tym przypadku jest synonimem „obiektu”). Ale robiąc to, tracą wiele zalet baz danych SQL. Przepustowość jest znacznie niższa, a algorytmy blokowania stają się znacznie bardziej skomplikowane.
Dobra wiadomość jest taka, że istnieje już wiele mapowania obiektowo-relacyjnego (ORM) narzędzi dla dowolnego używanego języka. Pozwalają na dość przejrzyste tłumaczenie między obiektami w pamięci i wierszami w bazie danych. Narzędzia te na ogół nie są odpowiednie dla dużych gier w czasie rzeczywistym, ponieważ mogą prezentować najgorsze aspekty wydajności baz danych SQL i NoSQL. Ale jest to w porządku dla gry internetowej - w najgorszym przypadku, gdy napotkasz problemy z wydajnością, możesz wrócić do robienia transakcji w staromodny sposób. Problem opóźnień Cię nie boli, a zwiększona przepustowość pomaga.
Wreszcie, aby pokusić się o stwierdzenie, które omówiłem gdzie indziej : nie chodzi o statyczne dane gry. Nie mówię tu o twoich opisach przedmiotów, obrażeniach zadawanych przez ciebie broni, sprajtach itp. Mam na myśli prawdziwe, zmienne dane gry, takie jak to, co znajduje się w ekwipunku gracza lub jakie są jego statystyki. Wszystko, czego potrzebujesz do danych statycznych, to magazyn danych. Może okazuje się, że najłatwiej jest do tego celu użyć tej samej bazy danych, co magazyn danych, ponieważ masz świetną ORM; może potrzebujesz systemu plików. To dwa osobne problemy, a jedna odpowiedź nie musi (i prawdopodobnie nie będzie) pasować do obu przypadków.