เน็ตหายระหว่างทาง ค่าจากเซนเซอร์ควรหายไปด้วยไหม

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

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

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

แยกสถานะล่าสุดออกจากประวัติ

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

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

MQTT retained message มีหน้าที่ช่วยคนรับใหม่เห็นค่าที่ broker เก็บไว้ตาม topic แต่ไม่ได้เป็นคิวของข้อมูลที่บอร์ดยังไม่เคยส่งถึง broker ดังนั้นตอนบอร์ดหลุดเครือข่าย เราก็ยังต้องดูแลข้อมูลที่เกิดฝั่งอุปกรณ์ตามความต้องการเอง

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

ขนาดคิวต้องคิดเป็นข้อมูลจริง

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

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

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

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

RAM กับที่เก็บถาวรเสียข้อมูลต่างจังหวะ

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

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

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

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

เวลาอ่านกับเวลาส่งต้องอยู่คนละช่อง

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

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

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

กลับมาเชื่อมต่อแล้ว อย่าเทคิวจนงานปัจจุบันรอ

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

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

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

สรุป

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