รูปแบบบันทึกเกมสำหรับเซิร์ฟเวอร์ MMO

บันทึกเหตุการณ์ของเกม (ตรงข้ามกับบันทึกข้อผิดพลาด / การดีบัก) สำหรับทั้งคลัสเตอร์ / ส่วนแบ่งมีประโยชน์อย่างมากสำหรับ MMO เชิงพาณิชย์ที่อยู่ในสภาพแวดล้อมการผลิตจริงให้การสนับสนุนที่สำคัญสำหรับการบริการลูกค้าและวิธีการวิเคราะห์ประวัติ

โครงการที่ฉันกำลังใช้งานอยู่ในปัจจุบันใช้ฐานข้อมูลเชิงสัมพันธ์เพื่อจัดเก็บบันทึกเหตุการณ์ของเกมทั้งหมดและในขณะที่วิธีดังกล่าวใช้งานได้ดีดูเหมือนว่าฉันจะอ่านได้อย่างเดียวเท่านั้น .

ฉันไม่แน่ใจว่าจะเริ่มเรียนรู้เกี่ยวกับการสร้างรูปแบบแฟ้มบันทึกไบนารีแบบกำหนดเองได้อย่างไร ประสบการณ์ของคุณในการสร้างรูปแบบบันทึกที่กำหนดเองหรือบทความ / บทความที่แนะนำในหัวข้อนั้นคืออะไร

ในStendhalเราแก้ไขปัญหาประสิทธิภาพการทำงานโดยเพิ่มกิจกรรมเกมคิวแล้วประมวลผลให้พวกเขาถ่ายทอดสดในพื้นหลัง

ในกรณีของเราเหตุการณ์ไม่ได้เป็นเพียงการบันทึก แต่วัตถุที่มีลอจิกเล็กน้อยเพราะในบางกรณีเราต้องแทรกสองอันด้วยลิงก์ระหว่างกัน ตัวอย่างเช่นครั้งแรกที่มีการจัดการรายการในเกมจะต้องมีการแทรกลงในตารางรายการก่อนก่อนที่จะสามารถบันทึกรายการเหตุการณ์ได้

แต่การเขียนบันทึกเป็นปัญหาด้านเดียว:

คุณต้องการตอบคำถามใดกับบันทึก

ง่ายต่อการอ่านบันทึกที่สมบูรณ์ตามลำดับเวลา หรือเพื่อกรองสำหรับผู้เล่นหนึ่งคน

แต่อาจมีคำถามเช่น:

• รายการใดที่แอนตันวางไว้บนพื้นที่เบ ธ หยิบขึ้นมาเมื่อวาน? ตอนนี้ผู้เล่นคนใดเป็นเจ้าของ (แอนตันบ่นว่าสินค้าของเขาถูกขโมย)
• ผู้เล่นเฉลี่ยต้องใช้เวลาเท่าไหร่ถึงระดับ 100? ผู้เล่นคนไหนที่เร็วกว่ากันมาก? สำหรับตัวละครแรกเท่านั้น?
• มีผู้เล่นที่จัดการกับเงินเกมจำนวนมากหรือไม่? ผู้เล่นคนไหนที่มันผ่าน? ไม่มีสิ่งใดที่มีค่าตอบแทน?
• ผู้เล่นที่อ่อนแอสามารถฆ่าสัตว์ประหลาดที่แข็งแกร่งซึ่งพวกเขาไม่สามารถฆ่าอย่างถูกกฎหมายได้หรือไม่?
• ...

ในสเตนดาห์ลเราใช้ฐานข้อมูลเชิงสัมพันธ์สำหรับบันทึกเกมเพราะนั่นเป็นวิธีที่ง่ายที่สุดในการอนุญาตการค้นหาแบบเฉพาะกิจ หากคุณใช้รูปแบบบันทึกที่กำหนดเองโดยทั่วไปคุณจะต้องใช้รหัสแบบสอบถามทั้งหมดที่จำเป็นเมื่อเกิดขึ้น และการทำเช่นนั้นด้วยประสิทธิภาพที่เพียงพอนั้นค่อนข้างยาก

ตาราง gameEvents ของเรามี 51,429,139 แถว (ปีที่แล้ว) และเรามีตาราง itemlog เฉพาะซึ่งมี 60,360,657 แถว (ตลอดเวลา) สำหรับ 15,893,831 รายการ

คุณหมายถึงอะไรอย่างมีประสิทธิภาพ? ไม่ว่าจะเป็นขนาดของดิสก์หรือความเร็วในการสืบค้นฐานข้อมูลเชิงสัมพันธ์นั้นเกือบจะแน่นอนที่จะเอาชนะหรือเท่ากับรูปแบบไบนารีที่เป็นกรรมสิทธิ์ของคุณและง่ายกว่ามากและยืดหยุ่นกว่าในการใช้งาน

แต่ละตารางที่คุณใช้ในฐานข้อมูลเชิงสัมพันธ์ช่วยให้คุณระบุจำนวนไบต์ที่แน่นอนต่อจำนวนแถวที่คุณจะอนุญาต หากคุณไม่ได้บันทึกข้อความธรรมดา - และ"บันทึกกิจกรรมของเกม (ตรงข้ามกับบันทึกข้อผิดพลาด / การดีบัก")แสดงว่าคุณไม่ได้หรืออย่างน้อยก็ไม่จำเป็นต้อง - จากนั้นเข้าใกล้ฟิลด์ความกว้างคงที่ของ ฐานข้อมูลเชิงสัมพันธ์ค่อนข้างใกล้เคียงกับความเหมาะสมที่สุดในแง่ของพื้นที่ซึ่งทำให้พวกมันค่อนข้างเร็วในตอนแรก ด้านบนของฐานข้อมูลเชิงสัมพันธ์นั้นค่อนข้างสะดวกในการจัดทำดัชนีเพื่อการเข้าถึงที่รวดเร็วมากและปรับการค้นหาให้ได้ประโยชน์สูงสุด

ดังนั้นฉันขอแนะนำให้ติดกับสิ่งที่คุณมี

มันเป็นความจริงที่คุณอาจบันทึกสองสามไบต์ด้วยรูปแบบที่กำหนดเองหรือเคยแค่ gzipped ข้อความพื้นที่เก็บข้อมูลราคาถูกดังนั้นมันจึงไม่คุ้มค่าที่จะเพิ่มประสิทธิภาพอีกต่อไป สิ่งที่สำคัญกว่านั้นคือการจัดการกับสิ่งต่าง ๆ เช่นการบัฟเฟอร์ I / O และการสืบค้นซึ่งทั้งสองอย่างนั้นเซิร์ฟเวอร์ SQL ที่ไม่ได้วางจำหน่ายนั้นอาจทำได้ค่อนข้างดี ถ้ามันเหมาะกับคุณบนเสื้อผ้าเหล่านั้นฉันก็จะวิ่งไปหามัน เราเขียนเซิร์ฟเวอร์บันทึกบัฟเฟอร์ของเราเองซึ่งเขียนไปยังไฟล์ที่กำหนดเองจากนั้นมีโปรแกรมแยกวิเคราะห์เพื่ออ่านลงในฐานข้อมูลสำหรับการสืบค้นฉันไม่แนะนำ

วันนี้ฐานข้อมูลเชิงสัมพันธ์ล้มลงเพราะไม่มีประสิทธิภาพ แต่เมื่อจัดเก็บประเภทของบันทึกที่คุณพูดถึงคุณไม่ต้องการประสิทธิภาพอย่างแท้จริงเพราะเกมหรือผู้ใช้ไม่สามารถเข้าถึงได้ตลอดเวลา - เฉพาะทีมของคุณเท่านั้นที่จะต้องมี เพื่ออ่านข้อมูล

ดังนั้น "ประสิทธิภาพ" ไม่สำคัญมาก สิ่งสำคัญคือการสั่งซื้อข้อมูลในแบบที่ทำให้ง่ายต่อการบอกเล่าเรื่องราวของสิ่งที่ผู้ใช้กำลังทำในเกม โดยทั่วไปแล้วนักพัฒนาของคุณจะต้องใช้ข้อมูลนี้และแสดงในอินเทอร์เฟซที่อ่านง่ายสำหรับนักวิเคราะห์และบางครั้งนักวิเคราะห์จะต้องค้นหาข้อมูลเพื่อเจาะลึกพฤติกรรมของผู้ใช้ ตัวอย่างเช่นหากผู้เล่นซื้อไอเท็มบางอย่างก่อนการอัปเดต แต่หยุดการซื้อหลังจากอัปเดตนักวิเคราะห์จะได้รับประโยชน์จากการเขียนเคียวรีบางอย่างที่เปิดเผยตัวเลขจำนวนหนึ่งเกี่ยวกับพฤติกรรมรอบการซื้อนั้นเพื่อพิจารณาว่าทำไมผู้ใช้ไม่ซื้ออีก เป็นการดีที่สุดหากพวกเขามีภาษาคิวรีมาตรฐานที่จะทำงานกับเอกสารนั้นได้ดี หากพวกเขาต้องทำให้แบบสอบถามเหล่านี้เป็นรูปแบบไบนารีที่กำหนดเองงานของพวกเขาจะทำให้หนักขึ้น

โดยทั่วไปกิจกรรมของเกมจะมีลักษณะเช่นนี้ (นี่เป็นรูปแบบของ DeltaDNA โดยเฉพาะ)

{
 "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"]
  },
}

เหตุการณ์มักจะมีชื่อเหตุการณ์, userID, ID เซสชัน, เวลาประทับและพารามิเตอร์ที่ช่วยให้คุณสามารถบันทึกข้อมูลใด ๆ ที่คุณพบว่ามีประโยชน์ในการบันทึกโดยรอบเหตุการณ์นั้น และจากประสบการณ์ของฉันรูปแบบฐานข้อมูลเชิงสัมพันธ์ที่ดีที่สุดสำหรับการบันทึกโครงสร้างดังกล่าว