Pracuję nad grą wieloosobową w czasie rzeczywistym, która będzie wymagać bazy danych (dla takich funkcji, jak profile graczy, znajomi, odblokowania, aktualności itp.). Jest to standardowa gra na PC (nie oparta na przeglądarce) i wykorzystująca serwer-klient architektura. Nie jestem nowy w korzystaniu z baz danych i przeprowadziłem kilka badań w ciągu ostatnich kilku dni, kiedy natknąłem się na gorącą debatę: RDBMS kontra NoSQL. Obecnie skłaniam się ku NoSQL, ale po przeczytaniu o zastosowaniach dla każdego (RDBMS i NoSQL) kusi mnie, aby użyć obu. Wiem, że to może wydawać się dziwne, ale pozwól mi wyjaśnić moją sytuację:
Mój zespół ma wspólny pakiet hostingowy, który oferuje nieograniczone miejsce do przechowywania mySQL i przepustowość, z zastrzeżeniem, że możemy mieć tylko 25 połączeń jednocześnie (reguła współdzielonego hostingu). Mam zamiar używać tego do mojej witryny (typowe użycie bez wątpienia) w celu publikowania aktualizacji wiadomości, wspierania funkcji społeczności (takich jak komentarze, przesyłanie grafik fanów itp.) I tym podobnych. Wszystko w porządku i dobrze - ale! w tym miejscu robi się interesująco ... Chcę wyświetlić te same informacje, które są zamieszczone na mojej stronie internetowej, w grze. Oznacza to używanie mySQL zarówno w mojej witrynie, jak i w mojej grze. Oprócz postów z wiadomościami i tym podobnych, planuję używać go w grze do takich rzeczy jak czat i lista serwerów. Martwię się głównie tą zasadą 25 połączeń.
Co prowadzi mnie do pytania nr 1: Czy to zadziała i czy istnieje lepsza alternatywa?
Poza tym przeczytałem o tym, jak dobrze działa NoSQL i nadaje się do gier w czasie rzeczywistym (mogłem się mylić, przeszedłem przez wielką wojnę płomieniową RDBMS kontra NoSQL, aby się tu dostać i prawdopodobnie jestem spalony). Zasadniczo chciałbym używać MongoDB do wszystkich moich danych obiektów gry.
I znowu, pomocne będzie podanie kontekstu: znalazłem hosta (MongoLab), który oferuje pakiet 240 MB MongoDB za darmo, którego zamierzam używać, dopóki nie będzie konieczna aktualizacja. Biorąc pod uwagę 240 MB, obliczyłem, że będę w stanie pomieścić około 60 000 graczy (jeśli każdy z graczy ma około 4KB i zignorujemy inne rzeczy, które mogą być przechowywane). Przestrzeń dyskowa i konieczność płacenia za więcej w przyszłości (jeśli nasza gra się powiedzie) nie stanowi problemu. Jedynym powodem, dla którego obecnie zamierzam używać MongoDB do wszystkich moich danych obiektów gry, jest to, jak często będą uzyskiwane dostęp do tych danych obiektów gry (na przykład za każdym razem, gdy gracz zostanie zabity, podnosi przedmiot, strzela z broni itp.) I również lubią proste dokumenty bez schematu (które ułatwiają mapowanie danych obiektów gry). Powinienem zauważyć, że kiedyś
Zamierzam używać tego samego MongoDB na mojej stronie, aby wyświetlać informacje o profilu gracza (nie jestem zainteresowany pełną spójnością, pewne opóźnienie od aktualizacji w grze jest w porządku). Co prowadzi mnie do drugiego pytania: Pytanie 2: Czy to dobry pomysł, czy jest coś lepszego, co powinienem zrobić?
Gra będzie miała początkowe doświadczenie podobne do tego:
- Klient loguje się (MongoDB)
- Klient znajduje się na stronie głównej w grze w / czatach (MySQL)
- Klient przechodzi na listę serwerów (MySQL)
Klient łączy się z serwerem i gra na nim
Serwer komunikuje aktualizacje dla wszystkich graczy (MongoDB)
Tak sobie wyobrażałem, że to zadziała. Czy to ci odpowiada, czy masz sugestie dotyczące ulepszenia tego planu?
Odpowiedzi:
Sugeruję, aby twoja gra komunikowała się z utworzoną przez ciebie usługą internetową, która sama zajmuje się sprawdzaniem bazy danych. W tym momencie bardzo łatwo jest wypróbować różne rodzaje baz danych, „przełączając” implementacje usług internetowych (interfejs usług internetowych zawsze pozostaje taki sam, więc gra się nie psuje) i decyduje, która z nich jest dla Ciebie odpowiednia.
Dużo bezpieczniej jest też nie narażać bazy danych na bezpośredni dostęp do Internetu.
źródło
To więcej niż wystarcza dla twojej gry. Problem polega na tym, że jeśli Twoja witryna korzysta z wielu połączeń, możesz się skończyć. Musisz skonfigurować serwer WWW, aby używał tylko niewielkiej liczby z nich, pozostawiając resztę serwerowi gier. Twój serwer gier tak naprawdę nie potrzebuje więcej niż jednego połączenia, ale może skorzystać z garści.
To trochę fałszywy argument, ponieważ żaden system nie jest wystarczająco szybki, aby można go było wykorzystać jako główny magazyn szybkiej gry w czasie rzeczywistym - naprawdę musisz przechowywać i manipulować wartościami w pamięci. Tak więc trafiasz do bazy danych tylko wtedy, gdy jest to absolutnie konieczne, co może być po prostu zapisywaniem całej postaci co jakiś czas (np. Raz na minutę), w którym to momencie różnice prędkości stają się znikome.
Zabawne jest to, że jeśli dostosujesz MongoDB do maksymalnej prędkości, możesz prawie doprowadzić go do punktu, w którym będzie wystarczająco szybki, aby wykonywać synchroniczne zapisy z rozsądnie szybkiej gry, ale byłoby to kosztem integralności danych, ponieważ zapisy są buforowane. Oznacza to, że tracisz te dane w razie awarii, więc zapisywanie nie było w ogóle sensu, a nadal jest wolniejsze niż gdybyś właśnie wykonał edycję w pamięci i zapisał ją później, aby uzyskać najgorsze z obu światów .
Zadaj sobie pytanie, dlaczego musisz pisać do bazy danych, gdy gracz strzela z pistoletu. Dlaczego nie można tego po prostu obsłużyć w pamięci na serwerze gry? Jeśli Twoja gra zawiesza się, a następnie uruchamia ponownie, a gracz dowiaduje się, że ma 3 pociski więcej, niż się spodziewał, czy jest to poważny problem biznesowy?
Jest to znacznie lepszy powód, aby wybrać podejście NOSQL niż problem z wydajnością.
To dobrze i rozsądnie. Później możesz chcieć użyć osobnej instancji, aby odczyty internetowe nie konkurowały z odczytami i zapisami gier, ale ten problem jest trywialny do rozwiązania w porównaniu z problemem uzyskania wystarczającej popularności, aby był to problem.
Osobiście wybrałbym jedną z dwóch baz danych, na podstawie których jedna byłaby dla mnie mniej pracy, i ustandaryzowałem ją - ale nie ma powodu, dla którego nie możesz trzymać się dwóch, jeśli chcesz.
źródło
Wszystkie dane w czasie rzeczywistym muszą być przechowywane w pamięci aplikacji, wszystko inne byłoby głupie.
Utrzymywanie danych logowania użytkowników, statystyk itp. Jest dość lekkim zadaniem, więc będę odważny i powiem, że możesz używać prawie wszystkiego, co chcesz. Chociaż możesz być ostrożny ze stroną internetową, rzeczy takie jak listy użytkowników mogą pochłonąć dużo wydajności bazy danych, jeśli nie stworzysz odpowiedniego systemu buforowania.
I jak powiedział bummzack, powinieneś trzymać wszystko w tej samej sieci. Ponadto, uważaj na darmowe rzeczy, 240 MB darmowego przechowywania bazy danych brzmi dobrze, ale ponieważ maszyna jest prawdopodobnie podzielona między dużą liczbę bezpłatnych użytkowników, usługa może być dość powolna.
źródło
Czy ufasz swoim 60 000 użytkownikom na bazę danych? Jeśli nie, powinieneś pogodzić się z ideą „dostępu do bazy danych od klienta”, chyba że Twój poziom wiedzy specjalistycznej w zakresie bezpieczeństwa oprogramowania bazy danych jest na najwyższym poziomie i masz pewność, że możesz rozwiązać wszelkie wynikające z tego problemy.
źródło