noSQL - Apakah ini opsi yang valid untuk game berbasis web? [Tutup]

20

Karena kesempatan dan kebosanan, seorang teman dan saya memutuskan untuk membuat game berbasis web. Ini adalah 'permainan' pertama yang akan saya buat, karena biasanya saya memprogram aplikasi web di Django.

Saya telah memilih untuk menggunakan kerangka kerja yang sama untuk game, tetapi saya tidak sepenuhnya yakin tentang penyimpanan data, karena saya tidak dapat melihat persyaratan di masa depan dan masalah terkait DB. Akhir-akhir ini, gerakan noSQL mendapatkan kekuatan dan saya ingin menjelajahi daerah itu.

Karena itu saya punya pertanyaan berikut:

  • Apakah penyimpanan data noSQL (berbasis dokumen, seperti MongoDB) akan cocok untuk game berbasis web?
  • Apa masalah yang mungkin timbul menggunakan RDBMS konvensional, seperti MySQL?
  • Bagaimana cara mengasuransikan konsistensi data di antara pengguna dengan MongoDB, selama bermain game atau pada acara dengan waktu tertentu, seperti pekerjaan cron?

Gambaran umum permainan: Gim petualangan biasa, dengan pemain yang bertarung dengan monster dan mendapatkan item dan semacamnya.

  • Beberapa data statis di semua pemain: item, senjata, ramuan, peta, dll.
  • Beberapa data terkait dengan pemain: inventaris, metrik (statistik), kemajuan, dll.
  • Seorang pemain mungkin perlu mengetahui statistik dan keadaan pemain lain
  • Tugas yang dijadwalkan akan dijalankan pada interval waktu tertentu
Pran
sumber
1
Masalah dengan beberapa basis data noSQL adalah bahwa mereka tidak dapat melakukan kueri yang tidak terduga pada waktu "desain" dengan cepat pada kumpulan data besar seperti log peristiwa: gamedev.stackexchange.com/q/4465/450 Perlu diingat bahwa basis data noSQL memerlukan hal yang sama teknik terhadap injeksi permintaan normal daripada database normal.
Hendrik Brummermann
1
@nhnb: Salah satu cara yang bagus untuk menyatakan kembali poin Anda adalah "menggunakan database relasional untuk data relasi, dan gunakan objek / database dokumen untuk objek / data dokumen". Sayangnya saya tidak berpikir kebanyakan orang memiliki pengalaman dengan atau menghabiskan banyak waktu untuk berpikir tentang pemodelan, yang mengarah ke desain yang buruk tidak peduli apa yang mereka pilih.
2
Menanggapi pertanyaan Anda, "Apakah NoSQL pilihan yang valid untuk game berbasis web?" Saya yakin jawabannya adalah ya. Database NoSQL telah digunakan untuk permainan berbasis web sebelumnya (seperti FarmVille) dan menawarkan banyak fleksibilitas. Titik utama pertentangan untuk pertanyaan ini tampaknya "mana yang lebih baik (NoSQL atau SQL)?". Setiap sistem memiliki pro dan kontra, tetapi keduanya adalah opsi yang sah sepenuhnya. Jika Anda mencari daftar terperinci tentang kelebihan dari satu sistem di atas yang lain, Anda mungkin ingin membayar Programmer StackExchange. :)
Ari Patrick

Jawaban:

21

Apakah basis data noSQL cocok untuk gim berbasis web?

Benar! Secara umum, database non-relasional (seperti MongoDB) jauh lebih baik untuk gim, karena mereka lebih fleksibel dalam memodelkan data, sementara lebih berkinerja daripada database relasional (seperti SQL) - menjadikannya "win-win" pilihan.

Apa masalah yang mungkin timbul menggunakan RDBMS konvensional?

Ada dua kelemahan utama untuk menggunakan database relasional:

  • Kurangnya fleksibilitas dalam cara Anda memodelkan data
  • Performa

Kurangnya fleksibilitas dalam cara Anda memodelkan data adalah kelemahan utama, karena menggunakan basis data relasional memaksa Anda untuk memodelkan data agar sesuai dengan kebutuhan basis data, daripada basis data yang mengakomodasi kebutuhan model. Misalnya, pertimbangkan Anda membuat model untuk bagaimana Anda akan menyimpan item dalam game menggunakan database relasional dan Anda memutuskan model berikut:

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

Sekarang pertimbangkan bagaimana Anda perlu memodifikasi model untuk melakukan hal-hal berikut:

  • Tambahkan jenis barang baru
  • Buat senjata dengan beberapa jenis senjata
  • Buat item ramuan yang juga bisa digunakan sebagai senjata

Tentu saja semua tindakan ini bisa dilakukan, tetapi Anda tidak akan menjadi orang yang paling bahagia saat Anda melakukannya, dan Anda mungkin akan bertanya-tanya, "adakah solusi yang lebih baik di luar sana untuk apa yang ingin saya lakukan ?," ketika Anda bisa mendesain model yang jauh lebih fleksibel dalam database non-relasional.

Catatan: Jika Anda tidak terbiasa dengan bagaimana basis data berbasis dokumen menyimpan informasi, silakan periksa tautan ini sebelum melanjutkan. Model yang disajikan di bawah ini dirancang untuk menggunakan logika yang mirip dengan apa yang disajikan dalam artikel tersebut.

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

Ada banyak artikel bagus tentang kinerja database NoSQL vs SQL, tetapi di sini ada yang menyediakan contoh aplikasi sehingga Anda dapat melakukan tes sendiri: MongoDB vs SQL Server 2008 Showdown Kinerja

Bagaimana cara memastikan konsistensi data di antara pengguna dengan MongoDB?

MongoDB mendukung operasi atom baca / tulis pada entitas data tunggal (dokumen), jadi hasil kueri dari MongoDB harus selalu akurat dengan apa yang disimpan dalam database.

Sunting: Diberikan contoh NoSQL dari basis data barang

Ari Patrick
sumber
Dalam contoh yang Anda tulis menggunakan sql, bagaimana Anda, pada tingkat tinggi, memodelkannya menggunakan nosql?
Pran
4
-1, jawaban Anda hanya menunjukkan data statis. Seluruh perdebatan tentang SQL vs NoSQL untuk basis data game melibatkan data yang sangat dinamis. Hal terbaik untuk dilakukan adalah menunjukkan transaksi NoSQL yang memperdagangkan sesuatu antara dua pemain - kejadian yang sangat umum, dan satu permainan yang paling salah terlepas dari jenis apa yang mereka pilih.
3
@Ari: Ada lebih banyak data statis, tetapi tidak ada yang peduli dengan throughput untuk menulis ke sana, karena tidak ada yang menulis untuk itu - tidak ada menulis, tidak ada transaksi, tidak ada ACID, tidak ada pertanyaan database nyata, bahkan jika Anda menyimpannya jadi satu. Pertanyaan itu kemudian mudah dijawab - simpan saja dalam ingatan. Tentu saja "Bagaimana kita dapat memuat data statis lebih cepat?" adalah pertanyaan yang menarik, tapi saya pikir itu sama sekali tidak terkait dengan pertanyaan SQL vs NoSQL. - Sedangkan untuk operasi multi-dokumen, apakah ini berarti database Anda akan memiliki satu dokumen dengan misalnya semua pemain di dalamnya?
2
@ Ari: Tolong jangan bingung NoSQL, yang merupakan ide, dan MongoDB, yang merupakan database tertentu. Pada pekerjaan terakhir saya, kami mengirimkan dua game pada basis data NoSQL dan mendapatkan konkurensi yang sangat baik dengan latensi rendah. Tetapi basis data NoSQL kami juga mendukung transaksi multi-dokumen dengan penguncian tingkat lapangan. NoSQL bukan "hal" tunggal seperti SQL, itu hanya merujuk pada database yang tidak menggunakan SQL (dan biasanya tidak menggunakan skema relasional).
5
Hanya $ 0,02 saya, tetapi "tidak berkinerja" bukan kelemahan RDBMS. Ini adalah kelemahan menyimpan data non-relasional dalam RDBMS, tidak menyetel RDBMS Anda, tidak memahami apa yang dilakukan SQL Anda, bukan pengindeksan, dll. Dll. Jika Anda memiliki data relasional, Anda akan menemukan RDBMS sangat dioptimalkan.
Robbie
19

Beberapa kata mempertahankan database SQL.

1 - Jika Anda memiliki database SQL, Anda dapat bekerja dengan data Anda tidak hanya dengan kunci primer. Sebagian besar kueri di MMO dijalankan oleh PK tetapi ketika Anda harus menemukan semua pengguna dengan level> 30 apa yang akan Anda lakukan di dunia NoSQL?

2 - Jika Anda memiliki bahasa SQL, Anda dapat membuat "perbaikan terbaru" untuk memperbaiki data yang rusak. Misalnya: "perbarui player_items atur flag = 0 di mana item_type_id = 100". Bagaimana Anda bisa memperbaikinya di NoSQL? Saya pikir Anda harus membuat skrip yang akan mem-parsing semua data Anda ...

3 - Database SQL tidak terlalu lambat seperti yang Anda pikirkan. Kolega saya membuat game MMO berbasis web, yang melakukan 5.000 transaksi per detik di MySQL. Apakah itu tidak cukup untukmu? Jika tidak, Anda dapat menggunakan sharding untuk mengukur basis data Anda.

4 - SQL memiliki batasan kunci asing dan hal-hal bagus seperti itu, yang akan membantu Anda menemukan bug dalam kode Anda.

NoSQL bukan peluru perak. Ini hanya memecahkan beberapa masalah dan membawa banyak masalah baru. Jadi saran saya - pikirkan dua kali sebelum memilih NoSQL.

Andrey Frolov
sumber
1
Ini semua adalah alasan bagus untuk menghindari NoSQL sampai Anda benar-benar membutuhkannya. Terutama # 3. Kecuali Anda sudah memiliki miliaran pengguna (dan menolak untuk membuang apa pun), Anda mungkin akan jauh lebih produktif dengan MySQL.
ojrac
5
1. Anda akan menggunakan: "untuk x di db.user.find ({" level ": {" $ gt ": 30}})" 2. Secara teknis, apa yang Anda tulis adalah skrip juga, jadi saya tidak yakin apa maksud Anda. 3. SANGAT mungkin untuk membuat MMO menggunakan SQL, dan pada kenyataannya, banyak MMO telah dikembangkan menggunakan teknologi. Teknologi NoSQL cukup baru dan telah diadopsi oleh layanan seperti Amazon, Google, dan Facebook untuk kinerja dan fleksibilitasnya. 4. Dalam NoSQL Anda perlu menulis batasan Anda sendiri, tetapi itu hanyalah biaya untuk fleksibilitas tambahan.
Ari Patrick 8-10
2
Saya setuju dengan pernyataan pemikiran Anda dua kali. Itu sebagian yang saya lakukan di sini dengan pertanyaan ini :)
Pran
10
SQL bukan peluru sliver. NoSQL bukan peluru perak. Berpikir dua kali sebelum menggunakan teknologi apa pun.
stonemetal
5
Mengenai 3, masalahnya tidak begitu banyak bahwa SQL lambat , tapi itu SQL adalah laggy . Secara umum, database SQL mendapatkan throughput yang sangat baik dengan mengorbankan latensi. Untuk game berbasis web, mungkin itulah yang Anda inginkan! Untuk gim jaringan real-time, mungkin tidak, dan sebagian besar MMO "mirip WoW" yang menggunakan SQL menggunakan lapisan caching di depannya yang menghilangkan sebagian besar manfaat SQL, itulah sebabnya NoSQL adalah langkah besar bagi mereka.
18

Jawabannya adalah ya, itu opsi yang valid tetapi tidak, itu mungkin bukan ide yang bagus .

Ada dua masalah utama dengan SQL yang NoSQL coba atasi, ketika datang ke game.

Yang pertama adalah latensi, atau lag. Di satu sisi, database SQL sangat cepat, memproses ribuan transaksi atau lebih dalam sepersepuluh detik. Dalam arti lain, mereka sangat lambat, karena memproses hanya beberapa transaksi dapat memakan waktu yang sama. Untuk sebagian besar penggunaan basis data, ini tidak masalah, tetapi permainan memiliki komponen waktu nyata sehingga ini bukan hanya tentang berapa banyak transaksi yang dapat Anda lakukan per detik, tetapi tentang waktu rata-rata yang diperlukan untuk menanggapi transaksi basis data.

Latensi ini merupakan masalah utama untuk game waktu nyata. Banyak pengembang yang membutuhkan basis data besar (biasanya untuk MMO) membangun lapisan caching yang berada di antara basis data dan server game untuk menghindari warung ini, dan kemudian membersihkan cache secara berkala. Masalah? Anda baru saja membuang alasan utama untuk menggunakan database - atomicity, konsistensi, isolasi, dan daya tahan .

Tapi masalah itu tidak berlaku untuk game web. Anda sudah mendapatkan koneksi latensi tinggi antara pemain dan gim, jadi Anda bisa mendapatkan throughput yang disediakan SQL, serta manfaat dari perangkat lunak yang matang dan terkenal.

Masalah kedua, bagaimanapun, tidak berlaku untuk Anda, dan itu ketidakcocokan impedansi objek-relasional . Game menangani objek, database menangani baris. Jika Anda beruntung suatu objek dapat dibuat menjadi baris hanya dengan mendaftar bidangnya, tetapi sebagian besar objek waktu bersifat hierarkis, dan Anda harus meratakannya dengan beberapa cara untuk membuatnya menjadi baris.

Basis data berbasis dokumen, seperti CouchDB dan MongoDB, menyelesaikan masalah ini dengan mempromosikan dokumen ke objek tingkat atas, daripada baris ("dokumen" dalam hal ini adalah sinonim untuk "objek"). Tetapi dengan melakukan ini, mereka kehilangan banyak manfaat dari database SQL. Throughput jauh lebih rendah, dan algoritma penguncian menjadi jauh lebih rumit.

Berita baiknya adalah, sudah ada banyak alat pemetaan objek-relasional (ORM) yang tersedia untuk bahasa apa pun yang Anda gunakan. Mereka memungkinkan Anda menerjemahkan antara objek dalam memori dan baris dalam database cukup transparan. Alat-alat ini umumnya tidak sesuai untuk game real-time skala besar, karena mereka dapat menyajikan aspek kinerja terburuk dari database SQL dan NoSQL. Tapi itu bagus untuk gim web - paling buruk, ketika Anda mengalami masalah kinerja, Anda dapat kembali melakukan transaksi dengan cara kuno. Masalah latensi tidak melukai Anda, dan peningkatan throughput membantu Anda.

Akhirnya, untuk memperjelas poin yang saya buat di tempat lain : Ini bukan tentang data game statis. Saya tidak berbicara tentang deskripsi item Anda atau kerusakan senjata atau sprite atau apa pun di sini. Maksud saya, data game yang benar-benar bisa berubah, seperti apa yang ada dalam inventaris pemain atau apa statistik mereka. Yang Anda butuhkan untuk data statis adalah penyimpanan data. Mungkin ternyata hal yang paling mudah untuk dilakukan adalah menggunakan database yang sama dengan data store untuk itu karena Anda memiliki ORM yang hebat; mungkin Anda hanya perlu sistem file. Ini adalah dua masalah yang terpisah, dan satu jawaban tidak perlu (dan mungkin tidak akan) cocok dengan kedua kasus tersebut.

Komunitas
sumber
1
+1 Terima kasih atas perbandingan kedua opsi. Selain itu, Anda membuat poin yang baik dengan mengatakan bahwa data statis tidak boleh ada di database.
Pran
1
+1 Namun saya pikir Anda lalai menyebutkan salah satu pro utama (baik, pro atau kontra tergantung pada perspektif) dari No SQL, yaitu skema-kurang, yang memungkinkan untuk menyimpan data yang sangat dinamis. Saya sebenarnya akan menggunakan campuran keduanya untuk proyek saya saat ini dengan PostgreSQL untuk hal-hal yang cocok dengan model relasional, dan Mongo untuk hal-hal semi-statis yang tidak. (misalnya log yang dapat digunakan untuk menghasilkan replay, di mana secara relasional saya harus memiliki salah satu kolom yang menyimpan PK dari salah satu dari banyak tabel lainnya, atau tabel dengan nama kolom umum misalnya param1 param2)
Davy8
1
@ Davy88: noSQL tidak perlu skema-kurang, dan memiliki database "sangat dinamis" tidak benar-benar plus. Jika yang Anda miliki adalah sup data, Anda tidak dapat melakukan pengindeksan, Anda tidak dapat melakukan penguncian tingkat lapangan, dan bahkan pertanyaan sederhana pun menjadi penuh dengan pertanyaan tentang apa yang terjadi jika kunci tidak ada.
@ user744, apa hal-hal yang Anda sebut capai?
expiredninja
5
  • Apakah penyimpanan data noSQL (berbasis dokumen, seperti MongoDB) akan cocok untuk game berbasis web?

Saya menyarankan untuk melihat couchdb

Antarmukanya berbasis javascript, sehingga akan menyatu dengan cukup baik dengan game berbasis HTML5 / javascript.

Ia juga dapat bekerja 'off-line' (membuat salinan lokal dari db) dan kemudian menyinkronkan dirinya dengan server nanti (misalnya, Anda mungkin menggunakan ini untuk ruang bawah tanah yang dipasang)

  • Apa masalah yang mungkin timbul menggunakan RDBMS konvensional, seperti MySQL?

Masalah utama adalah bahwa database no-sql menangani sangat berbeda dari database relasional. Membuat perubahan mental bisa jadi sulit.

Misalnya, lihat bagaimana " kueri " dilakukan di couchdb. Semuanya dilakukan dalam javascript.

  • Bagaimana cara mengasuransikan konsistensi data di antara pengguna dengan MongoDB, selama bermain game atau pada acara dengan waktu tertentu, seperti pekerjaan cron?

Proses 'sinkronisasi' database disebut replikasi dalam istilah couchdb. Anda juga akan melihat istilah konsistensi banyak. Ada beberapa layanan bawaan yang menangani replikasi & konsistensi. Lihat misalnya proses replikasi tambahan .

egarcia
sumber
Ya, saya pernah mendengar tentang couchdb juga, pada kenyataannya, bahkan di situs web mongodb, mereka biasanya membandingkannya. Saya pikir saya perlu meneliti couchdb vs mongodb.
Pran
2

Bergantung pada apa yang Anda miliki di dalam gim, Anda mungkin akan menggunakan keduanya, dan menghubungkannya melalui model di gim Anda. Misalnya pemain bisa dan harus berada di RDB (info masuk) tetapi inventaris pemain / penyimpanan variabel bisa masuk ke noSQL, sehingga modul pemain Anda bisa login()menggunakan RDB dan fetchInventory()menggunakan noSQL dengan kunci utama.

Peta misalnya lebih baik disimpan di NoSQL (koordinat => array objek yang berbeda misalnya) saya tidak membayangkan menyimpan apa yang terdapat dalam suatu RDB (kecuali string serial yang Anda perlu sepenuhnya unserialize untuk membaca beberapa bagian dari? Lebih banyak CPU dan RAM terbuang!) yah Anda masih bisa menyimpan area di RDB misalnya area "kota X" berisi koordinat / blok berikut ([3,4], [8,7] ...)

Anda bisa dan mungkin harus menggunakan keduanya, dan melihat ke dalam penyimpanan volatile seperti memcache yang mungkin Anda butuhkan atau data sementara (pasti akan lebih cepat daripada menggunakan hard-disk! Pasti! dan menghemat banyak CPU tetapi tentu saja tidak RAM)

jadi pada akhirnya>

itu tergantung pada apa yang ingin Anda miliki dalam gim Anda! bersorak

Ronan Dejhero
sumber
fitur mana yang menurut Anda akan menyeret Anda lebih ke NoSQL atau lapisan kegigihan karena saya suka memikirkannya?
expiredninja
1
mungkin sistem koordinat jika game Anda berbasis gps, sesuatu yang mungkin perlu pencarian lanjutan. pada dasarnya jika Anda baik dengan MySQL maka tetap menggunakannya, apakah mungkin untuk menggunakannya sebagai nosql juga
Ronan Dejhero