Format log game untuk server MMO

Log peristiwa permainan (sebagai kebalikan dari log kesalahan / debug) untuk seluruh klaster / beling sangat berguna untuk MMO komersial yang berada dalam lingkungan produksi langsung, memberikan dukungan vital untuk layanan pelanggan, dan sarana untuk analisis historis.

Proyek yang sedang saya kerjakan menggunakan database relasional untuk menyimpan semua log peristiwa permainan, dan sementara metode itu berfungsi dengan baik, bagi saya tampaknya sifat log yang hanya dapat dibaca dan kronologis akan memungkinkan format penyimpanan yang lebih efisien .

Saya tidak yakin di mana harus mulai belajar tentang membangun format log biner kustom. Apa pengalaman Anda membuat format log kustom, atau makalah / artikel yang direkomendasikan tentang masalah ini?

Di Stendhal kami memecahkan masalah kinerja dengan menambahkan acara permainan ke antrian dan kemudian memprosesnya secara tidak sinkron di latar belakang .

Dalam kasus kami, peristiwa bukan hanya catatan tetapi objek yang memiliki sedikit logika karena dalam beberapa kasus kita perlu melakukan dua sisipan dengan tautan di antara mereka. Misalnya saat item pertama kali ditangani dalam game, item tersebut harus dimasukkan ke dalam tabel item terlebih dahulu sebelum peristiwa-item dapat dicatat.

Tetapi menulis log hanya satu sisi dari masalah:

Pertanyaan apa yang ingin Anda jawab dengan log?

Sangat mudah untuk hanya membaca log lengkap dalam urutan kronologis; atau untuk memfilternya untuk satu pemain.

Tetapi mungkin ada pertanyaan seperti:

• Barang apa yang telah diletakkan Anton di tanah yang diambil oleh Beth kemarin? Pemain mana yang memiliki mereka sekarang? (Anton mengeluh tentang barangnya dicuri)
• Berapa lama waktu yang dibutuhkan pemain rata-rata untuk mencapai level 100? Pemain mana yang lebih cepat secara signifikan? hanya untuk karakter pertama?
• Apakah ada pemain yang menangani uang permainan dalam jumlah besar? Untuk pemain mana ia lulus? Tanpa imbalan apa pun yang berharga?
• Apakah pemain yang lemah dapat membunuh makhluk yang kuat sehingga mereka tidak dapat membunuh secara legal?
• ...

Di Stendhal kami menggunakan basis data relasional untuk log game karena itu adalah cara termudah untuk memungkinkan kueri ad-hoc pemain. Jika Anda menggunakan format log kustom, pada dasarnya Anda harus mengkodekan semua permintaan itu ketika diperlukan. Dan melakukan itu dengan kinerja yang cukup menjadi agak sulit.

Tabel gameEvents kami memiliki 51.429.139 baris (tahun lalu) dan kami memiliki tabel itemlog khusus yang memiliki 60.360.657 baris (sepanjang waktu) untuk 15.893.831 item.

Apa yang Anda maksud dengan efisiensi? Apakah itu ukuran pada disk atau kecepatan query, database relasional hampir pasti akan mengalahkan atau menyamai format biner milik Anda, dan menjadi jauh lebih mudah dan lebih fleksibel untuk digunakan.

Setiap tabel yang Anda gunakan dalam DB relasional cukup banyak memungkinkan Anda menentukan dengan byte yang tepat berapa banyak ruang per baris yang akan Anda izinkan. Jika Anda tidak mencatat teks biasa - dan "log peristiwa permainan (sebagai kebalikan dari log kesalahan / debug)" menyiratkan bahwa Anda tidak, atau setidaknya tidak perlu - maka pendekatan bidang lebar-tetap dari Database relasional agak dekat dengan optimal dalam hal ruang, yang membuatnya cukup cepat. Selain itu, basis data relasional cukup berguna untuk membuat indeks untuk akses yang sangat cepat, dan mengoptimalkan kueri untuk memaksimalkannya.

Jadi saya sarankan tetap dengan apa yang Anda miliki.

Memang benar Anda mungkin dapat menyimpan beberapa byte dengan format khusus, atau pernah hanya gzip teks, penyimpanan murah sehingga benar-benar tidak layak untuk dioptimalkan lagi. Yang lebih penting adalah berurusan dengan hal-hal seperti I / O buffering dan querying, yang keduanya SQL server mungkin berhasil dengan cukup baik. Jika itu bekerja untuk Anda di bidang itu, saya akan menjalankannya. Kami menulis server log buffering kami sendiri yang menulis ke file kustom dan kemudian memiliki program parser terpisah untuk membacanya ke dalam database untuk permintaan, saya tidak akan merekomendasikan hal ini.

Basis data relasional akhir-akhir ini mengetuk karena tidak efisien, tetapi ketika menyimpan jenis log yang Anda bicarakan, Anda tidak benar-benar membutuhkan efisiensi karena mereka tidak akan selalu diakses oleh permainan atau penggunanya - hanya tim Anda yang akan membutuhkan untuk membaca data.

Jadi "efisiensi" tidak masalah. Yang lebih penting adalah memesan data dengan cara yang membuatnya mudah untuk menceritakan kisah tentang apa yang dilakukan pengguna dalam game. Pengembang Anda biasanya perlu menggunakan data ini dan menampilkannya dalam antarmuka yang mudah dibaca karena analis dan analis terkadang perlu meminta data untuk menggali lebih dalam perilaku pengguna. Misalnya, jika pemain membeli item tertentu sebelum pembaruan, tetapi berhenti membelinya setelah pembaruan, analis akan mendapat manfaat dengan menulis pertanyaan tertentu yang mengekspos angka-angka tertentu tentang perilaku di sekitar pembelian untuk menentukan mengapa pengguna tidak lagi membelinya. Paling baik jika mereka memiliki bahasa permintaan standar untuk bekerja dengan yang didokumentasikan dengan baik. Jika mereka harus membuat kueri ini menjadi format biner khusus, pekerjaan mereka akan menjadi JAUH lebih sulit,

Umumnya acara permainan terlihat seperti ini (ini adalah format DeltaDNA khususnya)

{
 "eventName":"specific event code – eg. gameStarted",
 "userID":"ABCD1-4321a879b185fcb9c6ca27abc5387e914",
 "sessionID":"4879bf37-8566-46ce-9f3b-bd18d6ac614e",
 "eventTimestamp":"yyyy-mm-dd hh:mm:ss.SSS",
 "eventParams":
  {
   "platform":"WEB",
   "param1":"stringParam",
   "param2":true,
   "param3":1234,
   "param4":["a","b","c"]
  },
}

Acara biasanya menyertakan nama acara, ID pengguna, ID sesi, cap waktu, dan parameter yang memungkinkan Anda untuk merekam data apa pun yang menurut Anda berguna untuk direkam di sekitar acara tersebut. Dan dalam pengalaman saya, format basis data relasional adalah yang terbaik untuk merekam struktur seperti itu.