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

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

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

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.

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.

• 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 .

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