ยิ่งทำรายงานเยอะ ระบบหน้าร้านยิ่งช้า — ปัญหาที่แก้ที่หน้าจอไม่ได้

30 สิงหาคม 2569อ่าน 9 นาที
ยิ่งทำรายงานเยอะ ระบบหน้าร้านยิ่งช้า — ปัญหาที่แก้ที่หน้าจอไม่ได้

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

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

ทำไมงานสองแบบนี้ถึงอยู่ด้วยกันไม่ได้

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

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

POS
CRM
Excel
แอป
ETL

Data Warehouse

คลังข้อมูลรวมที่สะอาด

BI / Dashboard

รายงานที่ตัดสินใจได้

ชั้นข้อมูลกลางรับภาระการอ่านทั้งหมด แทนที่จะให้รายงานไปแตะระบบที่ใช้ขายของ

ทำไมการเพิ่มเครื่องถึงซื้อเวลาได้แค่ไม่กี่เดือน

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

Loadread≈U×q×r\text{Load}_{read} \approx U \times q \times r
ภาระการอ่านโดยประมาณเท่ากับจำนวนผู้ใช้ที่เปิดรายงาน คูณจำนวนคำถามที่แต่ละคนถามต่อวัน คูณปริมาณข้อมูลที่แต่ละคำถามต้องอ่าน ตัวอย่างเช่น เริ่มจากผู้ใช้ 3 คน เปิดวันละ 4 ครั้ง อ่านครั้งละ 200,000 แถว จะได้ราว 2.4 ล้านแถวต่อวัน เมื่อขยายให้หัวหน้าสาขาทั้ง 12 คนใช้ด้วย และแต่ละคนเปิดเพิ่มเป็นวันละ 6 ครั้ง ตัวเลขจะกลายเป็นราว 18 ล้านแถวต่อวัน โตขึ้นเจ็ดเท่าโดยที่ยอดขายไม่ได้เปลี่ยนเลย นี่คือเหตุผลที่การเพิ่มเครื่องตามหลังการใช้งานเสมอ

ทางแก้ที่แก้ได้จริง คือแยกชั้นสำหรับอ่านออกมา

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

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

ประโยชน์ที่ได้เพิ่มมา และมักสำคัญกว่าความเร็ว

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

คำถามที่พบบ่อย

ต้องซื้อเครื่องมือ BI ราคาแพงก่อนไหม

ไม่ต้อง งานที่ตัดสินว่าปัญหาจะหายหรือไม่คือการแยกชั้นข้อมูลสำหรับอ่านออกมา ซึ่งเกิดขึ้นก่อนเครื่องมือแสดงผลเสมอ เครื่องมือที่ใช้อยู่แล้ว ไม่ว่าจะเป็น Looker Studio, Power BI หรือแม้แต่ Google Sheets ก็ต่อเข้ากับชั้นกลางได้ทั้งหมด และมักไม่ต้องเปลี่ยนหน้าจอที่ทีมคุ้นเคยแล้ว

ข้อมูลที่อ่านจากชั้นกลางจะเก่ากว่าความจริงเท่าไร

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

ธุรกิจที่มีระบบเดียวจำเป็นต้องทำไหม

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

Data Platformรายงานธุรกิจฐานข้อมูลBI

บริการที่เกี่ยวข้อง

รับทำ Data Platform และ BI

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

WhaleScope

ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope

รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล

อ่านต่อ

อยากได้ตัวเลขต้องขอ แล้วรอสามวัน — วิธีเลิกเป็นคิวรอรายงาน

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

อยากเทียบย้อนหลังสามปี แต่ระบบเก็บให้แค่หกเดือน

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

Feature Store: คลังตัวแปรกลาง ที่ทำให้งาน AI ไม่ต้องเริ่มนับหนึ่งทุกครั้ง

ทุกโมเดล AI ต้องการตัวแปรอย่างยอดซื้อเฉลี่ยหรือความถี่การใช้งาน และทุกทีมมักคำนวณเองซ้ำ ๆ ด้วยสูตรที่ต่างกันเล็กน้อยจนผลไม่ตรงกัน Feature Store คือคลังกลางที่นิยามและคำนวณตัวแปรครั้งเดียว ให้ทุกโมเดลใช้ร่วมกัน

Data Mesh: กระจายความเป็นเจ้าของข้อมูล ให้ทีมที่รู้จักข้อมูลดีที่สุด

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