Database mana (RDBMS vs NoSQL vs KEDUA) yang akan digunakan untuk Game Multi-Waktu Nyata?

Saya sedang mengerjakan game multipemain realtime yang akan membutuhkan basis data (untuk fitur seperti profil pemain, teman, membuka kunci, berita, dll.) Ini adalah game PC standar (bukan berbasis browser) dan akan menggunakan server klien Arsitektur. Saya baru menggunakan database, dan telah melakukan penelitian selama beberapa hari terakhir ketika saya menemukan perdebatan sengit: RDBMS vs NoSQL. Saat ini saya condong ke NoSQL tetapi setelah membaca tentang kegunaan untuk masing-masing (RDBMS dan NoSQL), saya tergoda untuk menggunakan keduanya. Saya tahu itu mungkin tampak aneh, tetapi izinkan saya menjelaskan situasi saya:

Tim saya memiliki paket webhosting bersama yang menawarkan penyimpanan dan bandwidth mySQL tanpa batas, satu-satunya peringatan adalah bahwa kita hanya dapat memiliki 25 koneksi terbuka pada satu waktu (aturan shared hosting). Saya bermaksud menggunakan ini untuk situs web saya (penggunaan tipikal tidak diragukan) untuk memposting pembaruan berita, mendukung fitur komunitas (seperti komentar, mengunggah seni penggemar, dll.) Dan sejenisnya. Semuanya baik dan bagus - tetapi! Di sinilah segalanya menjadi menarik ... Saya ingin menampilkan informasi yang sama ini yang diposting di situs web saya, dalam game. Ini berarti menggunakan mySQL untuk situs web dan permainan saya. Selain posting berita dan sejenisnya, saya berencana menggunakannya dalam game untuk hal-hal seperti obrolan dan daftar server. Saya khawatir tentang 25-koneksi-aturan kebanyakan.

Yang membuat saya bertanya Pertanyaan # 1: Apakah ini akan berhasil dan apakah ada alternatif yang lebih baik?

Sekarang selain ini, saya telah membaca tentang bagaimana kinerja NoSQL dan cocok untuk permainan waktu nyata (saya bisa saja salah, saya telah berjalan melalui RDBMS vs NoSQL api perang besar untuk sampai ke sini dan mungkin terbakar). Pada dasarnya, saya ingin menggunakan MongoDB untuk semua data objek game saya.

Dan lagi, akan sangat membantu jika saya memberikan beberapa konteks: Saya telah menemukan sebuah host (MongoLab) yang menawarkan paket MongoDB 240MB secara gratis, yang ingin saya gunakan sampai perlu ditingkatkan. Diberikan 240MB, saya telah menghitung bahwa saya akan dapat menyimpan sekitar 60.000 pemain (jika setiap pemain kira-kira 4KB dan kami mengabaikan hal-hal lain yang mungkin disimpan). Ruang penyimpanan, dan harus membayar lebih di masa depan (jika game kami berhasil) tidak menjadi masalah. Satu-satunya alasan saya saat ini berniat menggunakan MongoDB untuk semua data objek game saya adalah karena seberapa sering data objek game ini akan diakses (seperti setiap kali pemain terbunuh, mengambil item, menembakkan senjata, dll.) I juga menyukai dokumen bebas skema langsung (yang membuatnya lebih mudah untuk memetakan data objek game). Saya harus mencatat bahwa, pada suatu waktu,

Saya bermaksud menggunakan MongoDB yang sama di situs web saya, untuk menampilkan informasi profil pemain (saya tidak peduli dengan konsistensi lengkap, beberapa penundaan dari pembaruan dalam game baik-baik saja). Yang mengarahkan saya ke pertanyaan kedua saya, Pertanyaan # 2: Apakah ini ide yang bagus atau ada sesuatu yang lebih baik yang harus saya lakukan?

Gim ini akan memiliki pengalaman memulai yang mirip dengan ini:

1. Log masuk klien (MongoDB)
2. Klien ada di halaman beranda dalam game di ruang obrolan (MySQL)
3. Klien pergi ke daftar server (MySQL)

4. Klien terhubung ke server dan bermain di dalamnya

5. Server mengkomunikasikan pembaruan untuk semua pemain (MongoDB)

Ini hanya cara saya membayangkan itu akan berhasil. Apakah ini terlihat baik bagi Anda, atau apakah Anda memiliki saran tentang bagaimana rencana ini dapat ditingkatkan?

Saran saya agar permainan Anda berkomunikasi dengan layanan web yang Anda buat yang berkaitan dengan permintaan basis data. Pada titik itu, sangat mudah untuk mencoba berbagai jenis database dengan "mengalihkan" implementasi layanan web (antarmuka layanan web Anda selalu tetap sama sehingga permainan Anda tidak rusak) dan memutuskan mana yang tepat untuk Anda.

Ini juga jauh lebih aman untuk tidak mengekspos database Anda ke internet secara langsung.

kami hanya dapat memiliki 25 koneksi terbuka pada satu waktu (aturan shared hosting).

Itu lebih dari cukup untuk gim Anda. Masalahnya adalah bahwa jika situs web Anda menggunakan beberapa koneksi, Anda bisa kehabisan. Anda perlu mengkonfigurasi server web Anda untuk hanya menggunakan sejumlah kecil dari mereka, meninggalkan sisanya untuk server game Anda. Server game Anda tidak benar-benar membutuhkan lebih dari 1 koneksi, tetapi mungkin mendapat manfaat dari memiliki beberapa.

Sekarang selain ini, saya telah membaca tentang bagaimana kinerja NoSQL dan cocok untuk permainan waktu nyata (saya bisa saja salah, saya telah berjalan melalui RDBMS vs NoSQL api perang besar untuk sampai ke sini dan mungkin terbakar). Pada dasarnya, saya ingin menggunakan MongoDB untuk semua data objek game saya.

Ini sedikit argumen yang salah, karena tidak ada sistem yang cukup cepat untuk digunakan sebagai toko utama untuk permainan waktu nyata yang serba cepat - Anda benar-benar perlu menyimpan dan memanipulasi nilai dalam memori. Jadi Anda hanya menekan basis data ketika Anda benar-benar harus, yang mungkin hanya menyimpan seluruh karakter begitu sering (mis. Satu menit sekali), di mana titik perbedaan kecepatan menjadi diabaikan.

Yang lucu adalah, jika Anda men-tweak MongoDB untuk kecepatan tertinggi, Anda bisa membawanya ke titik di mana itu akan cukup cepat bagi Anda untuk melakukan penulisan sinkron dari dalam permainan yang cukup cepat, tetapi ini akan menjadi biaya integritas data karena penulisan buffer. Ini berarti Anda kehilangan data itu saat terjadi kerusakan, jadi ada gunanya melakukan penulisan sama sekali, dan itu masih lebih lambat daripada jika Anda hanya melakukan edit dalam memori dan menyimpannya nanti, sehingga Anda mendapatkan yang terburuk dari kedua dunia .

Satu-satunya alasan saya saat ini berniat menggunakan MongoDB untuk semua data objek game saya adalah karena seberapa sering data objek game ini akan diakses (seperti setiap kali pemain terbunuh, mengambil item, menembakkan senjata, dll.)

Tanyakan kepada diri sendiri mengapa Anda perlu menulis ke database ketika seorang pemain menembakkan pistol. Mengapa itu tidak bisa ditangani hanya dalam memori di server game? Jika game Anda crash, dan kemudian restart, dan pemain menemukan mereka memiliki 3 peluru lebih dari yang mereka perkirakan, apakah itu masalah bisnis yang kritis?

Saya juga suka dokumen bebas skema langsung (yang membuatnya lebih mudah untuk memetakan data objek game).

Ini adalah alasan yang jauh lebih baik untuk memilih pendekatan NOSQL daripada masalah kinerja.

Saya bermaksud menggunakan MongoDB yang sama di situs web saya, untuk menampilkan informasi profil pemain (saya tidak peduli dengan konsistensi lengkap, beberapa penundaan dari pembaruan dalam game baik-baik saja).

Itu baik, dan masuk akal. Nanti Anda mungkin ingin menggunakan contoh terpisah, sehingga membaca web tidak bersaing dengan permainan membaca dan menulis, tetapi masalah itu adalah hal yang sepele untuk dipecahkan dibandingkan dengan masalah mendapatkan cukup populer untuk ini menjadi masalah.

Secara pribadi saya hanya akan memilih salah satu dari dua database, berdasarkan yang mana akan menjadi kurang bekerja untuk saya, dan menstandarkan itu - tetapi tidak ada alasan Anda tidak dapat menyimpan dua jika Anda mau.

Semua data real time perlu disimpan dalam memori aplikasi, yang lainnya konyol.

Membuat data masuk pengguna, statistik, dll. Adalah tugas yang cukup ringan, jadi saya akan berani dan mengatakan bahwa Anda dapat menggunakan hampir semua yang Anda inginkan. Meskipun Anda mungkin ingin berhati-hati dengan situs web, hal-hal seperti daftar pengguna dapat menyedot banyak kinerja database jika Anda tidak membuat sistem cache yang tepat.

Dan seperti kata bummzack, Anda harus menyimpan semuanya di jaringan yang sama. Selain itu, waspadalah terhadap hal-hal gratis, penyimpanan basis data gratis 240 MB terdengar bagus, tetapi karena mesin ini mungkin terbagi antara sejumlah besar layanan pengguna gratis bisa jadi sangat lambat.

Apakah Anda mempercayai 60.000 pengguna Anda per basis data? Jika tidak, Anda harus membatalkan ide "akses basis data dari klien", kecuali tingkat keahlian Anda dalam keamanan perangkat lunak basis data adalah yang terbaik, dan Anda yakin dapat mengakomodasi setiap masalah yang diakibatkannya.