แนวทางปฏิบัติที่ดีที่สุดสำหรับข้อมูลจัดเก็บ

ใช้แนวทางเหล่านี้ในการจัดระเบียบและจัดการข้อมูลที่เชื่อถือได้ ขยายได้ และสามารถสังเกตได้ตลอดวงจรชีวิตของมัน

จัดระเบียบข้อมูลของคุณ

สร้างข้อมูลจัดเก็บให้น้อยลง

ข้อมูลจัดเก็บทำงานคล้ายกับตารางในฐานข้อมูล ใช้ชุดข้อมูลจัดเก็บที่เล็กและคงที่ และจัดระเบียบระเบียนภายในโดยใช้คีย์ ตัวอย่างเช่น เก็บโปรไฟล์ของผู้เล่นทุกคนในข้อมูลจัดเก็บ PlayerData แทนที่จะสร้างข้อมูลจัดเก็บสำหรับผู้เล่นแต่ละคน

ใช้คีย์เดียวหรือไม่กี่คีย์ต่อผู้เล่น

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

หากส่วนต่าง ๆ ของข้อมูลผู้เล่นมีรูปแบบการเข้าถึงที่แตกต่างกันหรือเข้าใกล้ขีดจำกัดขนาดหรืออัตราการส่งข้อมูลต่อคีย์ ให้แยกระเบียนออกเป็นคีย์ที่กำหนดไว้ล่วงหน้าจำนวนน้อย เก็บข้อมูลที่ต้องเปลี่ยนแปลงเป็นอะตอมในคีย์เดียวกัน

ใช้รูปแบบคีย์และคำนำหน้าคงที่

สร้างชื่อคีย์จากตัวระบุที่เสถียรและรูปแบบคงที่ เช่น User_{UserId} อย่าใช้ชื่อแสดงผลหรือค่าต่าง ๆ ที่อาจเปลี่ยนแปลง รูปแบบคงที่จะทำให้คีย์คาดเดาได้ข้ามเซิร์ฟเวอร์และเครื่องมือ สำหรับข้อมูลจัดเก็บ พวกเขายังช่วยให้ การประมวลผลสิทธิในการถูกลืมโดยอัตโนมัติ สามารถระบุข้อมูลผู้เล่นได้

ใช้ คำนำหน้า เพื่อจัดกลุ่มคีย์ที่เกี่ยวข้อง ตัวอย่างเช่น ประสบการณ์ที่รองรับโปรไฟล์ตัวละครหลายตัวอาจใช้ User_123456/Profile/Warrior และ User_123456/Profile/Mage คุณสามารถส่ง User_123456/Profile ไปยัง ListKeysAsync() เพื่อแสดงโปรไฟล์ของผู้เล่นนั้น

Scopes เป็นอีกวิธีหนึ่งในการแบ่งข้อมูลจัดเก็บ ขอบเขตจะเพิ่มสตริงไปยังคีย์ทุกคีย์ในอินสแตนซ์ข้อมูลจัดเก็บนั้น และค่าเริ่มต้นคือ global

ประเมินโมดูลข้อมูลจัดเก็บ

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

ลดและกระจายคำขอ

บัฟเฟอร์ข้อมูลผู้เล่นในหน่วยความจำ

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

จัดลำดับคำขอที่เกิดขึ้นซ้ำ

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

ลองใหม่เมื่อเกิดความล้มเหลวชั่วคราว

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

ประมวลผลการลองใหม่ของข้อมูลจัดเก็บตามลำดับสำหรับแต่ละคีย์ คำขอที่เก่ากว่าที่ลองใหม่หลังจากคำขอที่ใหม่กว่าประสบความสำเร็จอาจเขียนทับข้อมูลใหม่กว่า นอกจากนี้ยังต้องคำนึงถึงการเขียนที่มีผลลัพธ์ที่ไม่รู้จัก: การเรียกที่ล้มเหลวหมายความว่าเซิร์ฟเวอร์ไม่ได้รับการตอบสนองที่สำเร็จ แต่เบื้องหลังอาจได้ทำการเขียนเสร็จสิ้น สำหรับข้อมูลเพิ่มเติม ดูที่ รหัสข้อผิดพลาดและขีดจำกัดของข้อมูลจัดเก็บ และ การลองใหม่

ชอบ UpdateAsync มากกว่า SetAsync

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

ใช้ SetAsync() เมื่อคุณสร้างคีย์ใหม่หรือแทนที่ค่าที่ไม่ขึ้นอยู่กับค่าก่อนหน้า สำหรับการเปรียบเทียบระหว่างสองวิธีนี้ ดูที่ Set vs update

แบ่งคีย์ร้อน

แต่ละคีย์มี ขีดจำกัดอัตราการอ่านและเขียน หากระเบียนเชิงตรรกะหนึ่ง ๆ ถึงขีดจำกัดเหล่านี้อย่างสม่ำเสมอหลังจากที่คุณลดคำขอที่ไม่จำเป็น ให้แบ่งมันออกเป็นคีย์ที่กำหนดไว้ล่วงหน้า เลือกชิ้นส่วนที่เสถียรจากตัวระบุ เช่น User_{UserId}_Inventory_{ShardId} เพื่อให้เซิร์ฟเวอร์ทุกตัวส่งข้อมูลเดียวกันไปยังชิ้นส่วนเดียวกัน

การแบ่งชิ้นส่วนทำให้การรักษาความสอดคล้องและการดำเนินการย้ายในอนาคตซับซ้อนมากขึ้น อย่าแบ่งข้อมูลที่อยู่ภายในคีย์เดียวและยังคงอยู่ภายใต้ขีดจำกัดอัตราการส่งข้อมูล

สร้างเวิร์กโฟลว์การดำเนินงาน

ใช้เครื่องมือที่มีอยู่ร่วมกัน:

1. สังเกต. ใช้ แดชบอร์ดการสังเกตข้อมูลจัดเก็บ เพื่อติดตามคำขอ สถานะการตอบสนอง อัตราการส่งข้อมูล และการจัดเก็บ กำหนด การแจ้งเตือนที่กำหนดเอง สำหรับเมตริกข้อมูลจัดเก็บที่สำคัญเพื่อให้ทีมของคุณสามารถตอบสนองต่อความล้มเหลวที่ยืดเยื้อหรือการเติบโตที่ไม่คาดคิด การแจ้งเตือนใน Creator Hub ยังแจ้งให้คุณทราบเมื่อการจัดเก็บใกล้เคียงหรือเกินขีดจำกัดและรวมถึงคำแนะนำและลิงก์ไปยังแดชบอร์ด
2. ตรวจสอบ. ใช้ Data Stores Manager เพื่อตรวจสอบข้อมูลจัดเก็บ คีย์ การใช้งานการจัดเก็บ และค่าใช้จ่ายที่ประมาณการ หากประสบการณ์มีข้อมูลจัดเก็บมากกว่า 100 รายการ รายการข้อมูลจัดเก็บจะไม่แสดงขนาดและจำนวนคีย์ ใช้ Open Cloud หรือ Data Stores Batch Processor สำหรับเมตริกเหล่านั้น
3. แก้ไข. ใช้ Data Stores Manager สำหรับระเบียนแต่ละรายการ ใช้ Open Cloud data store APIs หรือ Data Stores Batch Processor สำหรับเวิร์กโฟลว์ที่สามารถทำซ้ำได้หรือขนาดใหญ่
4. ขยายอย่างตั้งใจ. ก่อนอื่นให้ลดการจัดเก็บและคำขอที่ไม่จำเป็น หากการใช้งานที่ถูกต้องเกินขีดจำกัดเริ่มต้น ให้ประเมิน บริการที่ขยาย

Open Cloud และเซิร์ฟเวอร์เกมแชร์งบประมาณคำขอในระดับประสบการณ์ จำกัดอัตราในการดำเนินการสคริปต์ Open Cloud เพื่อไม่ให้รบกวนการจราจรสด

จัดการวงจรชีวิตข้อมูล

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

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

ลบข้อมูลทดสอบเมื่อการทดสอบสิ้นสุดและลบข้อมูลสำหรับเหตุการณ์ที่หมดอายุหรือฟีเจอร์ที่เลิกใช้ หลังจากที่คุณทำเครื่องหมายข้อมูลจัดเก็บสำหรับการลบ จะมีระยะเวลา 30 วันที่คุณสามารถกู้คืนได้ หลังจาก 30 วันนั้น Roblox จะลบข้อมูลจัดเก็บอย่างถาวร สำหรับข้อมูลเพิ่มเติม ดูที่ Data Stores Manager

ตั้งค่าการประมวลผลสิทธิในการถูกลืม

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

หาก RTBF โดยอัตโนมัติไม่รองรับสคีมาข้อมูลของคุณ ให้ใช้ เว็บฮุคสิทธิในการลบ เพื่อเรียกใช้เวิร์กโฟลว์การลบที่กำหนดเอง ตรวจสอบให้แน่ใจว่าเวิร์กโฟลว์ใด ๆ ลบข้อมูลผู้เล่นที่ตรงกันทั้งหมด