แสดงบทความที่มีป้ายกำกับ database แสดงบทความทั้งหมด
แสดงบทความที่มีป้ายกำกับ database แสดงบทความทั้งหมด

วันอาทิตย์ที่ 20 เมษายน พ.ศ. 2557

เมื่อ web กลายเป็นพื้นฐานของการสื่อสารระหว่าง application

เมื่อพื้นฐานของการใช้งานข้อมูลนั้นไม่ได้ต้องคอยเรียกข้อมูลผ่านทาง SQL หรือ ฐานข้อมูลโดยตรง เช่นเรามักจะใช้ hibernate หรือ sqlalchemy ในการใช้งานข้อมูล

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

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

และนั่นเริ่มเห็นบทบาทของ web service ชัดเจนขึ้น แม้กระทั่งระบบจัดการ user ในระบบเดี๋ยวนี้ยังไม่ต้องพัฒนาเองเลย มีให้เรียกใช้กันข้ามแพลฟอร์มเลย

ขั้นตอนต่อมาภายหลังที่เราจะเห็นนี่คงถึงเวลาที่ web จะกลายเป็นพื้นฐานของการสื่อสารข้อมูลซักที

วันอังคารที่ 4 พฤษภาคม พ.ศ. 2553

การใช้งาาน PostgreSQL ในส่วนงานต่าง ๆ OLTP, DW, WEB

คราวก่อนนำเนื้อหามาแปะไว้ (PostgreSQL กับการกำหนดค่าที่น่าสนใจของ WEB, OLPT, DW ) กะว่าจะอธิบายต่อที่ตรงนี้ แต่เท่าที่ดูแล้วคิดว่านำออกมาอธิบายต่างหากดีกว่า

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

งานที่ต่าง ๆ กันก็ขอแบ่งออกเป็น 3 อย่างดังนี้ก่อน
  1. WEB - Web Transactional
  2. OLTP - Online Transactional Processing
  3. DW - Data Warehouse
งานทั้ง 3 ประเภทนี้ต่างกัน ทำให้การกำหนดค่าต่าง ๆ ของ Database แตกต่างกันด้วย ลองนึกถึงว่าถ้าหากเราต้องการขับรถ ไปยังที่แตกต่างกัน เราจะเลือกรถอย่างไรดี

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

ก่อนอื่นเราต้องทำความเข้าใจกับ ประเภทของงานทั้ง 3 กันก่อน
"WEB" การเรียกใช้งานส่วนใหญ่เป็นการแสดงผล มีการเรียกการใช้งาน Database บ้าง แต่ส่วนใหญ่จะถูกออกแบบมาเพื่อบริการข้อมูล ไม่ค่อยมีการทำ Transaction
"OLTP" มีการเรียกใช้งานข้อมูลเพื่อประกอบการใช้งาน และมีการบันทึกข้อมูล Transaction กลับไปยัง ฐานข้อมูล มีรายงานที่เกี่ยวกับทางด้าน Tranaction ในแต่ละวัน
"DW" Datawarehouse มีลักษณะเฉพาะ โดยมีจุดประสงค์เพื่อนำข้อมูลที่เก็บไว้มาทำเป็นการวิเคราะห์ และตัดสินใจ และบางครั้งส่งผลที่ได้กลับไปยัง OLTP เพื่อกำหนดวิธีการทำงานต่าง ๆ รายงานส่วนใหญ่ถูกออกแบบมาเพื่อ ทำเป็นข้อมูลเพื่อการตัดสินใจ

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


CPU
ปัจจุบันเท่าที่ประสบมา จำนวน CPU 4-8 cores ก็เพียงพอกับงานที่เกี่ยวกับ Database แล้ว และแต่ละ CPU ก็มีความเร็วที่ค่อนข้างมากแล้วด้วย

MEMORY
หลักง่าย ๆ คือ ถ้าอยากให้เร็วก็ใส่ เยอะ ๆ ปัจจุบันเท่าที่เห็นคือ 16GB

HARDDISK
"many spindles are better" หมายความว่า ถ้าทำ RAID ให้ใช้ HD หลาย ๆ ตัวทำ RAID ใน 1 Volume ในส่วนนี้มีผลต่อ การทำงานของ Database เป็นอย่างมาก เพราะว่า งานส่วนใหญ่ให้ Load Data แล้วประมวลผลใน MEMORY ไม่พอหรอก

NETWORK
หลาย ๆ คนซื้อ Server ที่มี Networks Interface เยอะ ๆ แต่ว่าใช้อันเดียวเอง (เป็นเพราะว่า ไม่เคยเจอ Traffice เยอะ ๆ อย่างผม)


คราวนี้มาดูการปรับแต่งของ Database กัน

max_connections หมายถึงจำนวน connection ที่สามารถเข้ามาใช้งานได้เมื่อขนาดที่มีการใช้งานมากที่สุด โดยแต่ละ connection นั้นจะใช้ ทรัพยากร shared_buffer ที่กำหนดไว้ แน่นอนว่า ถ้ากำหนดไม่ดีจะมีอาการที่บอกว่า "out of memory" นะ

max_connections = 200  # small server   max_connections = 700  # web application database   max_connections = 40   # data warehousing database
shared_buffer หมายถึงปริมาณของหน่วยความจำที่ต้องใช้งานเพื่อการประมวลผล process ก่อนที่จะมีการใช้ disk เพื่อทำ operation ประมาณว่ามี active operations ได้มากเท่าไหร่

# shared_buffers = ( Available RAM / 4 ) # shared_buffers = 512MB   # basic 2GB web server # shared_buffers = 8GB     # 64-bit server with 32GB RAM

work_mem หมายถึงปริมาณของหน่วยความจำที่สามารถใช้ในแต่ละ query ได้ ถ้า Query อะไรที่ซับซ้อนก็ต้องเพิ่มค่านี้เลยครับ
# Most web applications should use the formula below, because their  # queries often require no work_mem.  # work_mem = ( AvRAM / max_connections ) ROUND DOWN to 2^x # work_mem = 2MB  # for 2GB server with 700 connections    # Formula for most BI/DW applications, or others running many complex # queries: # work_mem = ( AvRAM / ( 2 * max_connections ) ) ROUND DOWN to 2^x # work_mem = 128MB   # DW server with 32GB RAM and 40 connections 
ในส่วนตัวแล้ว กว่าจะปรับค่านี้ลงตัวก็ต้องลองหลาย ๆ รอบเหมือนกัน บางทีดูรูปแล้วน่าจะเข้าใจมากขึ้น ref: http://momjian.us/main/presentations.html