Query วินาทีละ 100 ครั้ง mysql ไหวไหมครับ(+คำถามจุกจิกเล็กน้อย)

คือตอนนี้ผมจะทำโครงการๆนึงอยู่ซึ่งโดยผลจากการวิเคราะห์นั้น

ฐานข้อมูลของผมจะต้อง Query เฉลี่ยวินาทีละ 100 ครั้งเลยทีเดียว

และฐานข้อมูลผมต้องเก็บข้อมูลมหาศาลถึงเกือบๆ ล้าน Record

ที่ผมอยากทราบถึง Mysql มันจะรองรับขนาดนี้ไหวไหมครับหรือต้องมีเทคนิคพิเศษอะไรไหม

ที่ผมอยากใช้ Mysql เพราะผมไม่มีงบเรื่องการซื้อ software จึงอยากได้ราคาประหยัดที่สุด


ส่วนอีกเรื่องนึงนะครับ Stored Procs. คืออะไรหรอครับ มันดี/เสีย ยังไงบ้าง

พอดีเห็นหลายๆเว็บมักจะพูดถึงกัน

และคำถามสุดท้ายนะครับ เราจะให้ mysql มัน backup ฐานข้อมูลเองทุกๆวันตอน 8 โมงเช้าได้ไหมครับ

หรือต้องเขียนโปรแกรมมาคุมในจุดนี้



ยังไงผมก็ขอขอบคุณสำหรับทุกท่านที่ตอบและทุกท่านที่แวะมาอ่านนะครับ

ผมหวังว่าสิ่งที่ผมถามจะมีประโยชน์ต่อหลายๆคนที่มีปัญหาเช่นผม^^

ความต้องการเบื้องต้น จากข้อมูลที่คุณแจ้งไว้ ผมว่าสบายครับ นอกนั้นขึ้นกับ resource เครื่อง และการ tuning ครับ ตรงการ Query 100 ครั้ง ต่อ sec (นึกภาพไม่ออก จะตรวจวัดกันยังไง) จึงขึ้นอยู่กับ mem และ cpu และ I/O โดยตรงครับ.. ส่วน stored procedure ก็แปลกันตรง ๆ อ่ะครับ รับมาเก็บแล้วจึงทำ ปัจจุบัน Enterprise DB ส่วนมามีการทำงานแบบนี้ เห็นหลายเว็บพูดกันก็ต้องลองศึกษาแล้วครับ มีประโยชน์ครับ เล่าแล้วยาววววว .. เรื่อง ปริมาณการเก็บข้อมูลขึ้นอยู่กับพื้นที่ของ Disk และข้อมจำกัดของ File System แต่ละแบบ ต้องออกแบบ และวางแผนรอบครอบหน่อย เพราะ go live แล้วแก้ตัวลำบาก.. สุดท้าย การ backup .. พื้น ๆ ครับ ทำได้.. command ของ MySql แล้ว สามารถจับใส่ script แล้วทำการสั่งงานด้วย crontab ครับ (Unix/Linux) .. ผมเป็นห่วงแค่งบประมาณซื้อ Hardware อ่ะครับ.. อย่าบอกนะว่าจะใช้ PC Server .. อิอิ .. ล้อเล่นครับ.. โชคดีครับผม

ถ้าอ่านอย่างเดียวก็ขึั้นอยู่กับการ Index ครับ
สามารถปรับปรุงได้หลากหลาย ตั้งแต่การทำ index/ query optimize หรือ data partitioning


แต่ถ้ามีเขียน Update/Insert ด้วย ก็เรื่องยาวเลย ต้องทำหลายอย่างเลยครับ กว่าจะให้วิ่งได้ไวๆ

ส่วนจะรับไหวไม่ไหวขึ้นอยู่กับว่าข้อมูลมีอะไร ใหญ่ขนาดไหน Hardware Spec อะไร Tune ดีรึยัง MySQL รุ่นอะไร



ทางที่ดีคือลองไปเรื่อยๆ ครับ ใช้โปรแกรมพวก mysqlbench ทดลองดูเรื่อยๆ ว่าปรับอะไรดีขึ้นยังไง ไม่มีสูตรตายตัว

100 query ต่อนาทีนี่ต้อง join หลาย table ไหมครับ สรุปว่า query อย่างเดียวไม่ได้ update ใช่ไหมครับ อย่างนั้นผมว่าถ้าเป็นไปได้ใช้ MYSQL หลายๆ ตัวดีกว่าไหมครับ จะได้ไม่ต้องห่วงเรื่อง load ด้วย จะใช้เท่าไรก็ได้
เรื่องกระจายโหลด ถ้าไม่อยากลงทุน ก็ใช้ DNS server ทำ round-robin ก็ได้
ทั้งนี้ทั้งนั้น ต้อง query อย่างเดียวนะครับ

**Hidden Content: To see this hidden content your post count must be 1 or greater.**

ถ้าประมวลผลเยอะๆแบบนี้ ข้อมูลหลักล้าน record ก็อืดเหมือนกัน

ต้องใช้ Online Analytical Processing (OLAP) ครับ

ผมเองก้กำลังศึกษาเรื่องนี้อยู่เหมือนกัน

Quote:

---

คือตอนนี้ผมจะทำโครงการๆนึงอยู่ซึ่งโดยผลจากการวิเคราะห์นั้น

ฐานข้อมูลของผมจะต้อง Query เฉลี่ยวินาทีละ 100 ครั้งเลยทีเดียว

และฐานข้อมูลผมต้องเก็บข้อมูลมหาศาลถึงเกือบๆ ล้าน Record

ที่ผมอยากทราบถึง Mysql มันจะรองรับขนาดนี้ไหวไหมครับหรือต้องมีเทคนิคพิเศษอะไรไหม

"ไหวนะไหว แต่ต้องอาศัยการ tuning ทำindex ให้ดีด้วยครับ
อีกเรื่องก็คงเป็นฮาร์ดแวร์+memory ที่ต้องให้สัมพันธ์กัน ลองศึกษาเรื่อง optimize ให้เยอะครับ เวบสอนพวกนี้ภาษาไทยก็มีนะ แต่ถ้าลองแปลปะกิตนิดๆ ก็แนะนำ forums.mysql.com เวิร์กสุดๆแล้วครับ ลองใช้อากู๋ทานสเลด ช่วยก็ได้นะ"


[/b]

---

:lol: ศึกษาผลเป็นยังไงก็ เล่าสู่กันฟังเน้อ ผมก็อยากเปลื่ยนจาก SQL2005 มาเป็น My เช่นกัน
กะลังศึกษาอยุ่

มีอะไรให้ช่วย บอกได้นะครับ
เพื่อผมจะช่วยแนะอะไรให้ได้

สำหรับ 100/s นั้น ไม่น่ามีปัญหาอะไร
ข้อมูลเป็นล้านก็ไม่ใช่ปัญหาเช่นเดียวกัน
เพราะปัญหาทุกอย่างแก้ไขได้
ใช้ access ยังไหวเลย ถ้าปรับจูนเป็น

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

อันนี้คุณสามารถ import ข้อมูลลง mysql ได้ก่อนเลย
แล้วจำลอง load ใส่เข้าไปดู
จากนั้นก็ optimized ด้วยเทคนิคต่าง ๆ
เช่น index, storage engine, server variable ฯลฯ
จนกว่าจะยอมรับได้ ซึ่งขั้นตอนนี้สำคัญมาก ๆ
ไม่ว่าคุณจะใช้ฐานข้อมูลอะไร ก็ต้องทดสอบแบบนี้


ส่วน OLAP นั้นเป็นการวิเคราะห์ข้อมูลมากกว่า
มักจะทำจาก data warehouse
ถ้า app ของคุณ query เพื่อออกรายงาน วิเคราะห์ข้อมูล
ไม่ใช่เพื่อ OLTP แล้วล่ะก็ ก็เลือกใช้ OLAP ถูกต้องแล้ว
เพียงแต่ mysql ไม่มี OLAP นะครับ
คงต้องใช้ sql server analysis services ซึ่งถ้าใช้ sql server อยู่แล้ว
ก็ไม่ต้องจ่ายเพิ่ม ใช้ได้เลย

ยังไม่เคยโอนข้อมูล แล้วลองใน MySQL นะครับแต่คิดว่าน่าจะลื่น สบายๆ เพราะ Query ส่วนใหญ่จะเสียเวลาไปในการ Join ข้อมูลซะมากกว่า หากข้อมูลนั้นมันไม่ค่อยมีการ Update การ Normalize นั้นกลายเป็นไม่จำเป็นเลย OLAP มันดันเอาข้อมูลทุกอย่างมารวมกันแทบจะเป็น Field เดียว และเหมาะกับข้อมูลที่มีมิติเกี่ยวกับเวลา

ผมเคยอ่านบทความหนึ่งนานมาแล้ว เขียนโดย นศ. ม. ชื่อดัง ข้อมูลที่ดีต้อง Normalize ยิ่งได้ระดับสูงๆ ยิ่งดี นั่นเพราะข้อมูลที่มีการ update บ่อยๆ มันกระจายกันออกไป แต่พอกลับกันมาเป็น Data Analysis กลับกันชนิดว่ากลับหัวกลับหางเลย แน่นอนคนที่เรียนปวดหัวแน่นอน

ตัว Store Procedure คือ ชุดคำสั่งที่เราเขียนฝังไว้ใน Server ข้อดีคือมันอยู่ใน Server การประมวลผลก็อยู่ภายในฐานข้อมูลเลย มันลดคำสั่งที่ ฝั่ง User/client ใช้ หรืออีกอย่างคือ ปิดไม่ให้ User / Developer รู้ว่าแท้จริงข้อมูลมันมีอะไรบ้างที่ต้องไปไล่อัพเดท หรือง่ายๆ คือรู้เท่าที่ต้องใช้ ทิ้งภาระให้ DB Admin ไปจัดการส่วนที่เหลือ มักใช้คู่กับ View เท่าที่เห็นระบบเมืองนอกใช้กัน หลังจาก Encrypt มันจะประมวลผลเร็วขึ้น และต้องพึ่งผู้พัฒนามันขึ้นมาเท่านั้น นอกจากนั้นยังมี Fuction, Trigger อีก

ข้อเสียอยู่ที่ความยุ่งยากของการ Deploy เพราะใช้คำสั่งโอนข้อมูลมันไม่ได้ตามไปด้วย, ยุ่งยากในการ Support, ต้องศึกษาเพิ่มเติม เพราะมันเป็นภาษาเฉพาะ

การ Backup เขียนคำสั่ง Dump ข้อมูลได้ ด้วย mysqldump และฝากคำสั่งให้ Run ใน Windows Schedual ยังได้เลยมันมีใน Window NT Core เลยก็ว่าได้

Quote:

---

และคำถามสุดท้ายนะครับ เราจะให้ mysql มัน backup ฐานข้อมูลเองทุกๆวันตอน 8 โมงเช้าได้ไหมครับ

หรือต้องเขียนโปรแกรมมาคุมในจุดนี้ [/b]

---

ผมใช้ webmin สามารถไปตั้งให้ backup อย่างที่คุณต้องการได้ครับ
แต่ถ้าคุณใช้อย่างอื่นผมไม่รู้นะครับ ไม่เคยใช้