Format log game untuk server MMO

12

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?

— Charles Ellis
sumber

7

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.

— Hendrik Brummermann
sumber

Seberapa cepat mencari melalui databse Anda? Saya punya data yang mirip dengan log dan kami punya sekitar 100.000.000 baris setelah tiga bulan. Kami menggunakan MySQL sebagai penyimpanan dan kinerjanya buruk. Kueri sederhana yang mencantumkan semua tindakan pemain (hanya 20.000) baris membutuhkan waktu lebih dari 60 detik.

— Balon

1

Permintaan sederhana pada kolom indeks instan. Permintaan yang kompleks mungkin butuh sedikit, 60 detik permintaan bisa terjadi, tetapi mereka sangat jarang. Kami mengindeks tabel dengan sangat berat dan memberi kompensasi penalti saat memasukkan dengan melakukannya secara sinkron.

— Hendrik Brummermann

Hmmm saya pikir masalah saya adalah set hasil yang cukup besar, sering antara 3000 dan 150000 catatan untuk satu pemain. Jadi ini mungkin alasan mengapa ini membutuhkan waktu yang lama, karena ini bekerja sangat cepat untuk set hasil yang kecil.

— Balon

4

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.

— Kylotan
sumber

Terima kasih atas tanggapannya (dan terima kasih kepada yang lain yang mengirimkan jawaban di bawah)! Semakin saya memikirkannya, semakin terlihat seperti RDBMS yang cocok untuk jenis logging ini. Tidak akan terlalu sulit untuk merancang format log khusus yang diindeks dengan baik untuk jenis pencarian dasar, tetapi dengan jenis pertanyaan rumit yang sering digunakan oleh CSR dan analitik permainan diperlukan pendekatan yang lebih umum - pada titik mana produk mapan akan mengungguli dalam kebanyakan kasus.

— Charles Ellis

Pengaturan log peristiwa khusus akan sangat berguna untuk pemutaran demo kronologis ala FPS, tapi itu masalah yang sangat berbeda untuk dipecahkan. Adakah yang punya pengalaman mengembangkan sesuatu yang mirip dengan rekaman demo untuk game server-server multipemain masif?

— Charles Ellis

Bergantung pada model pemrosesan logika sisi server Anda, dimungkinkan untuk hanya menyimpan setiap input, dicap dengan waktu kedatangan di server, yang dapat diputar ulang. Masalahnya cenderung datang dalam pemutaran, karena Anda perlu memutar ulang setiap input tunggal serta memodelkan faktor lain (mis. Benih acak, input tersirat seperti hal-hal yang mengubah berdasarkan latensi, dll). Tetapi tidak ada sistem satu ukuran untuk semua di sini - tergantung pada cara kerja server Anda.

— Kylotan

3

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.

— pembuat kode
sumber

0

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.

— Raja Zaphod
sumber