าด้วย Big data
ประมาณเกือบ 10 ปีที่แล้วผมมีงานนึงที่ต้องกับฐานข้อมูลแล้วต้องทำงานกับจุด GPS ที่ส่งมาจาก Device จำนวนหนึ่ง
ทีนี้พอใช้ไปซักพัก GPS เป็นร้อยล้านจุด พอใส่ในตางราง SQL มัน query ช้ามากๆ เลยพอแถวมันเยอะ สมัยนั้นไม่มี Big data แล้วเราแก้ยังไง
ผมก็ดูว่า use-case ของมันส่วนมากคือเราจะหาข้อมูลทีละวัน แทบไม่เคยมีกรณีไหนเลยที่จะต้องเอา GPS ข้ามวันมาคำนวน
ผมก็แบ่งข้อมูลเป็นวันๆ แยกลงแต่ละตาราง ผมก็สร้างตาราง gps_201701_01, gps_2017-01-02 ... ตามวัน ส่วนวันล่าสุดผมก็สร้าง gps_today เก็บไว้
ทีนี้ตัว Query GPS ผมก็ให้ Object มันต้องรับด้วยว่าจะ Query วันที่เท่าไหร่ แล้วก็บอกว่าชื่อตารางใน FROM clause ให้เป็น gps_ ตามด้วยวันที่ หรือถ้าไม่ใส่วันที่ให้เป็น today เอา
แต่ละตารางก็มีข้อมูลไม่มากนักแล้ว ก็ Query ได้ตามปกติ ตัวระบบก็รันไหลลื่นดี จบ
-------------------------------------------
ทีนี้ทำไมยกเรื่องนี้มา คือ จะบอกว่าพวก Sophisicated tool ทั้งหลายที่มันทำ Scaling, Big data หรืออะไรก็ตาม มันก็คือผลรวมของแนวคิดคอนเซปต์พื้นๆ พวกนี้รวมกันน่ะครับ
มันก็เริ่มมาจากคนมีปัญหากับการจัดการข้อมูลใหญ่ๆ เริ่ม Implement วิธีแก้แบบพื้นๆ ก่อน จะแบ่งตารางแบบผม หรืออาจจะมีวิธีอื่นอีกก็ได้ ก็มีเยอะ
ซักพักมีคนเริ่มจับจุดได้ว่าเห้ยทุกที่มีปัญหาเดียวกันนี่นา ถ้ารวมวิธีแก้พวกนี้แล้วสร้าง Concept ข้างบน มันก็จะใช้แก้ปัญหาข้อมูลใหญ่ได้เกิน 80% ของ Use-case บนโลกนี้เลยนะ มันก็เกิดเป็น Technology Big data มา
ทีนี้ที่ผมจะสื่อคือ
ข้อแรก ผมไม่อยากให้กังวลหรือตื่นตกใจเวลาเจอปัญหาพวกนี้ ลองค่อยๆ คิดดู อะไรพื้นๆ ก็ได้ที่มันแก้ได้ อย่างโจทย์ผม ถ้าผมรีบสรุปว่า SQL ไม่รองรับหรอกของใหญ่แบบนี้ต้องเปลี่ยน Tools หมด ต้องรื้อใหม่หมดเลยนะ ต้องซื้อ Tools แพงๆ มาใช้นะ มันก็มิใช่ ต่อให้วิธีที่ผมใช้สุดท้ายมันอาจจะต้องรื้อหรือล้าสมัยไป อย่างน้อย มันก็เป็นพื้นฐานความรู้
ผมกล้าบอกว่า เวลาผมอ่านพวก Sharding อ่านพวกการออกแบบระบบ ผมปิ๊งบ่อยนะว่า "เห้ย เคยเจอมาแล้ว ตอนนั้นเราเคยแก้ยังงี้" แล้วพอเอามาเทียบกับที่เขาออกแบบ บางทีอ่านเสร็จก็คิดว่า "อ้อ ทำเหมือนเราเลย แค่ในสเกลใหญ่กว่า" บางทีก็คิดว่า "โอ้ เราโง่เอง ที่แท้ทำแบบนี้เจ๋งกว่าเยอะเลย"
ไม่ว่าผมจะคิดมาโง่ตกโน่นลืมนี่หรือคิดมาดีก็ตาม แต่การได้ลองคิดก่อนอ่านวิธีคนอื่น มันทำให้ผมเข้าใจได้เร็วมากนะ
อย่างน้อยกับตัวเอง เทียบกับ ปัญหาที่ไม่เคยต้องแก้เองเลย ผมอ่าน Doc แล้วเข้าใจ System design ที่มันพยายามจัดการปัญหาที่ผมเคยลองแก้แล้วได้เร็วกว่าปัญหาที่เรายังไม่เคยรู้ว่ามีตัวตนเยอะ
ข้อสอง เราไม่ควรดูถูกตัวเองกับปัญหาพวกนี้ ถ้าเจอปัญหาแล้วมัวแต่ติตัวเองว่าเราไม่เก่งพอหรอก แก้ไม่ได้หรอก หรือแก้แล้วกลัวว่าคิดไม่ครอบคลุมเลยไม่คิดดีกว่า มันก็ทำให้เราไม่เติบโต
ท่าแบ่งตารางเป็นวันๆ ที่ผมเคยใช้ ส่วนตัวผมว่ามันไม่ยากที่จะคิดมันออกมา แต่มันจะยากกว่าเวลาที่เราดูถูกตัวเองว่า "แก้ไม่ได้หรอก", "เราไม่มีประสบการณ์", "ขนาดระบบ SQL ยังทำให้ค้นหาไวๆ ไม่ได้ เราเป็นใครจะไปคิดวิธีออก"
ข้อสาม ผมโชคดีที่วันนั้นทำงานแบบทั้งไม่มีใครช่วยและไม่มีใครตำหนิ เลยได้สร้างสรรค์อะไรพื้นๆ โดยไม่มีใครมาด่าว่า "ถ้าคิดได้แค่นี้อย่าคิดเลย ลืม Edge case โน่นนั่นนี่"
แน่นอนผมก็ไม่ได้คิดออกมาสมบูรณ์แบบ แต่ ดังนั้น ถ้าอยากให้ Junior ในทีมเติบโต ก็ให้โอกาสเขาได้ลองแก้ปัญหานะ ไม่ดีตรงไหนก็ช่วยกันคิดไปช่วยปรับกันไป มันดีกว่าไปบอกว่า "ถ้าคิดได้แค่นี้อย่าคิด ไปซื้อซอฟต์แวร์แพงๆ มาแก้ปัญหาเหอะ คุณพึ่งจบคุณไม่มีปัญญาหรอก" มันก็ไม่โตอ่ะนะ
ข้อสุดท้าย พื้นฐานพวกคณิตศาสตร์หรือแนวคิดพื้นๆ พวกนี้เป็นสิ่งสำคัญมาก ถ้าในศาสตร์คอมพิวเตอร์ผมว่ามีไม่กี่อย่างจริงๆ นะ (อย่างเช่น Compression Algorithm บางแบบ) ที่มันไม่ได้เกิดจากการประกอบแนวคิดพื้นๆ จำนวนมากเข้ามารวมกัน ซึ่งพอดูเป็นหีบห่อระบบใหญ่ๆ อย่าง Kafka เงี้ย มันดูเจ๋งมากน่าจะซับซ้อนน่าจะแบบยากจนเข้าใจไม่ได้ใช่มั้ย
แต่พอคุณลองอ่าน Design document มันก็เป็นแค่ Math ง่ายๆ หลายตัวที่มาประกอบกันอย่างสวนงามแล้วไม่ลืม Edge case ในการ Operate at scale แค่นั้นเอง
ดังนั้น ก็จงแค่ Happy coding แล้วก็เรียนรู้กับมันไปเรื่อยๆ แหละครับ กำแพงที่ใหญ่ที่สุดอันนึงที่ผมเจอในวงการซอฟต์แวร์ไทยคือการตื่นตระหนกกับระบบจนไม่กล้าเผชิญหน้ากับความซับซ้อน (ที่อาจจะไม่ได้ซับซ้อนอะไรมากมาย) นี่แหละครับ