เข้ามาลงชื่อฟังด้วยครับ

จากประสบการณ์คือกับ MySQL ส่วนมากสเกลใหญ่คือทำ Cluster โดยจะแยกระหว่างเครื่องเขียนกับอ่านออกจากกัน ส่วนสัดส่วนระหว่างเครื่องเขียนกับงานจะดูตามงาน (โดยมากคือดูจากระดับโปรแกรมที่จะมาใช้ก็จะรู้แล้ว) อย่างถ้าอ่านเยอะเขียนน้อย จะเครื่องเขียนจะ 1 ตัว เครื่องอ่านอาจตั้งแต่ 2-4 เลย ของพวกนี้ต้องมอนิเตอร์แล้ว scale out ออกไป (อันนี้ต้องดูสภาพการใช้งานจริง)

โดยส่วนตัวถ้า MySQL สิ่งที่ต้องระวังคือ

1. Slow Query
2. DB Lock ตอนขาเขียน
3. การตั้งค่า TCP Connection พวก wait_timeout connect_timeout
4. การทำ index field ให้พอดี

ของพวกนี้โปรแกรมเมอร์กับอินฟราฯ ต้องร่วมมือกัน ระบุงานให้ชัดๆ ไปว่าจะเขียนกันแบบไหน อย่างที่ผมทำมาจะเขียนเน้นไม่ให้เกิด slow query เอาให้น้อยๆ ป้องกันเรื่อง DB Lock โดยเลี่ยงไปใช้ Transaction ช่วย และพวก timeout เอาน้อยๆ ไปเลย อันนี้ก็คือแบบหนึ่ง

แต่จากที่เจอมา มีงานบางกลุ่มเหมือนกัน แต่ slow query ยอมได้ join table เอาให้ระเบิดกันไปข้าง (ผมไม่รู้เหตุผลนะ ไมไ่ด้อยู่ทีมเขา) ซึ่งเรื่องพวกนี้ server จะจูนไปอีกแบบ ดังนั้นถึงบอกโปรแกรมเมอร์กันอินฟราฯ ควรคุยกับให้เคลียร์ของเซ็ต env เซ็ต staging

ส่วนเรื่อง การทำ index field ให้พอดี อันนี้ตามเนื้องานครับ คือทำน้อยไป select ช้า ทำมากไป insert ช้า เผลอๆ table lock ดังนั้นเลือกให้เหมาะครับ ของพวกนี้อาศัยประสบการณ์จริงๆ ไม่มีหรอก เซ็ตครั้งเดียวแล้ว perfect น่ะ (แต่ก็เคยเห็นเทพๆ อยู่นะ น้อยคนจริงๆ) เรื่องพวกนี้อินฟราฯ ต้องร่วมมือด้วยการให้ slow query report ด้วยนะครับ ไม่งั้นโปรแกรมเมอร์ก็หน้ามืด หรือถ้ามี DBA ก็ อันนี้หน้าที่คุณล่ะ

และสุดท้ายที่ต้องระวังในกรณีบริษัทใหญ่มักจะมีเรื่อง share resource อันนี้จากที่พูดไป อย่าให้งานคนล่ะสไตล์มาใช้ resource ร่วมกัน เพราะการตั้งค่าต่างกันเอง แม้คุณจะแยก config variable ในระดับ user ได้ก็เถอะ แต่ที่มันไม่เปลี่ยนคือแรมกับcpu ดังนั้น slow query แยกไปเครื่อง fast query แยกไปอีกเครื่อง อันนี้จะดีกว่านะ

แถมนิดเรื่อง DB Lock หรือ Table Lock

ส่วนตัวถ้างานไหนที่ transaction ขาเขียนมันเยอะจนโหด ผมแนะนำถ้าไม่เปลี่ยน DB ไปใช้ที่ไวกว่า พวก MongoDB หรือ Cassandra หรือยัดใส่ Redis ไว้ชั่วคราวก็ได้ ไม่ก็ถ้าพวก job manager มาเป็นคน insert แทน (Gearman Beantalk บลาๆๆ) แบบนี้จะช่วยได้ครับ

สำหรับโปรแกรมเมอร์ คำสั่ง sql ที่ควรรู้เรื่องนี้มีสองคำสั่ง

SHOW PROCESSLIST;

อันนี้ใช้ดู tcp connection ครับ ดูเลยว่าค้างเท่าไร มีรอ timeout เท่าไร และนรกแตกว่ากลายเป็น zombie ไปเท่าไร ซึ่งคือ connection ที่ reuse ไม่ได้ อันนี้เราคอยดูได้บ้างครับ

อีกคำสั่งคือ
SHOW VARIABLES;

ใช้ดูการตั้งค่าของ MySQL ครับ ส่วนตัวแนะนำให้ดูกลุ่มคำสั่ง timeout นั้นแหละ เหตุผลก็ตามข้างต้นที่พิมพ์ไปแล้ว
SHOW VARIABLES LIKE '%timeout%'

ผมขออธิบายเท่านี้ครับ จริงๆ มีอีกเยอะ เรื่องพวกนี้คุยกันได้ยาวครับ เช่น zombie process เกิดได้ไง จะมีผลยังไง เรื่อง table lock ถ้าระดับ software ควรทำยังไง ควรจะเขียนโค้ดแนวไหนถึงจะช่วยลดภาระอินฟราฯ แม้กระทั่งการออกแบบ schema ให้เหมาะสมควรทำยังไงครับ มีเยอะแยะครับ

ปล. ผมไม่ใช่อินฟราฯ ไม่ใช่ DBA ผมเป็นแค่ PHP Programmer ดังนั้นใครเห็นข้อผิดพลาดก็เสริมด้วยนะครับ

ปล2. ขอโฆษณาหน่อย LOL

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

ประกาศที่พี่ๆ เขาเคยลงไว้
https://www.blognone.com/node/61513
https://www.blognone.com/node/47908
https://www.facebook.com/jQueryTips/posts/953491481329182

ดังนั้นถ้ามาทำงานด้วยกันจะเล่าต่อให้ฟังครับ 555+

"ใหญ่" สุดเท่าที่เคยทำมาคือข้อมูล "เพิ่ม" วันละประมาณ 50 GB ครับ เก็บมาแล้วประมาณสองปี data รวมก็เฉียดๆ 40TB

ส่วน generic case ข้อมูลเพิ่มจริงวันละประมาณ 5GB ครับ

คร่าวๆ นะครับ

• สำหรับ full data ลืม mysql ไปได้เลย scale ขนาดนี้ให้ตายยังไงก็เอาไม่อยู่
• mysql/rdbms เอาไว้เก็บผลลัพท์จากการประมวลผลแล้วที่ไว้โชว์หน้าเว็บเท่านั้น
• เก็บข้อมูลหลายๆ format โดยเฉพาะ plain text แบบ log file สำคัญมาก
• unix command line tool (grep / find) เวิร์กมากสำหรับการค้นแบบด่วนๆ เพราะเร็วมากๆ
• เครื่องมือที่ออกแบบมารองรับการ scale out อยู่แล้วให้ผลดีกว่ากันเยอะมากๆ (ใช้ elasticsearch ซึ่งทำงานบน apache lucene)
• เครื่องมือพวกนี้ หลักการง่ายที่สุดที่ทำให้เร็วคือ อัดจำนวนเครื่องเยอะๆ เข้าว่า
• ideal case คือ เก็บเครื่องละประมาณ 50-100GB ซึ่งจากปริมาณข้อมูลเพิ่มนี่ แทบจะต้องเพิ่ม node ทุกวัน
• ใช้งานจริงเลยเป็นเครื่องที่แรม 32GB เก็บเครื่องละเกือบๆ 1TB ทำให้ไม่ต้องเพิ่มเครื่องบ่อยมาก
• แต่ elasticsearch เดี่ยวๆ ก็ไม่รอดเหมือนกัน เลยต้องทำเป็น multi tier database (raw data ==> redis == map ==> elasticsearch + plain text log == reduce ==> mysql)

สรุปแล้วมี db หลักทั้งหมด 3 service (redis, elasticsearch, mysql) ไม่นับ memcache แล้วก็เอา log ไป store ใน plain text ซ้ำอีกเพื่อการทำ filter แบบด่วนๆ

อ่านสนุกดีครับ อยากอ่านอีก

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

พอจบงานนี้ทาง บ ก็เลิกรับงานแนวนี้อีกเลย

รอฟังด้วยครับ สนใจมากเป็นพิเศษ

ผมเป็นมือสมัครเล่น ระบบไม่ได้ใหญ่เท่าไหร่ ก็ลองปรับไปเรื่อยๆแหละครับ ตาม Hardware ที่มีอย่างจำกัด
ใช้ mysql mongodb ผสมๆ กันไป เพราะบางส่วนถ้าจะย้ายจาก mysql ไป mongodb นี่งานช้างเลย

ส่วนด้าน write จะใช้ Redis และ memcache มาช่วย โดยเก็บลง redis ก่อนแล้วใช้ nodeJS เป็น distribute worker มา aggregate / reduce ก่อน Write ลง DB

ด้าน read ก็ใช้ redis / memcache มา cache query ไว้ บางส่วน
บางส่วนที่ไม่ได้อัพเดทบ่อยก็ใช้วิธีสร้าง static html ให้ web server ดึงตรงไปเลย

ผมเคยทำ DB ไว้รองรับข้อมูลขนาดใหญ่ครับ แต่ถึงเวลาจริงๆมันไม่ใหญ่อย่างที่คิด 5555
ผมเอาทุกอย่างยัดลง Cassandra ครับ ศึกษา data model design + db architech อยู่เปนเดือน ทำเสร็จแล้วมาถึงคิดได้ว่าน่าจะรอให้มันใหญ่จริงๆแล้วค่อยทำดีกว่า 5555
แต่ผลลัพที่ได้น่าประทับใจมากนะครับ เวลาในการ select ข้อมูลออกมานี่เร็วมาก ยิ่งใช้ Go เขียนเป็น Backend นี่ response เร็วมากครับ (ไม่ได้เก็บ log ไว้นะครับจำตัวเลขไม่ได้)
สุดท้ายนี้ขอฝาก Go lang และ Cassandra ไว้ในอ้อมอกของทุกคนด้วยนะครับ

ผมลง PostgressSQL ในโน้ตบุ้คของตัวเอง แล้วสร้าง table เดี่ยว ๆ ไม่ join table อื่น
ข้อมูลเกี่ยวกับยอดขายและสต็อคของสาขา แล้วทำการ random gen data 100 ล้านเรคอร์ด size 36 GB
เป็นข้อมูล by date,store,inv_no,barcode แล้วทำการ selecu sum()
date,store,barcode ใช้เวลาในการ sum() 3.18 นาที ถือว่าช้าหรือใช้ได้แล้วครับ
ผมต้องทดลองกับเครื่องโน้ตบุ้คตัวเองก่อน ยังไม่กล้าไปลองกับ Server on Cloud

กระทู้นานมาก แต่ละเม้นมีประโยชน์ๆ