คลังเก็บป้ายกำกับ: POSTGRESQL

กูเกิลเปิดตัว AlloyDB ฐานข้อมูลคลาวด์ เข้ากันได้กับ PostgreSQL 100% แต่เร็วกว่า 4 เท่า

Google Cloud เปิดตัวบริการใหม่ที่สำคัญในงาน I/O 2022 ปีนี้คือ ฐานข้อมูล AlloyDB ที่เข้ากันได้กับ PostgreSQL 100% (อิงอยู่บน PostgreSQL 14 เวอร์ชันล่าสุด) แต่สถาปัตยกรรมข้างหลังออกแบบใหม่หมด มีความเร็วอ่านเขียนทั่วไปเพิ่มขึ้นจาก PostgreSQL 4 เท่า และถ้าเป็นการคิวรีข้อมูลมาวิเคราะห์จะเร็วขึ้นสูงสุด 100 เท่า

เราสามารถเรียก AlloyDB ว่าเป็นคู่แข่งของ Amazon Aurora ที่ AWS นำ MySQL/PostgreSQL มาปรับแต่งเพิ่มเติม (แต่ฝั่งกูเกิลมีเฉพาะ PostgreSQL) ซึ่งกูเกิลก็ชูว่า AlloyDB เร็วกว่า Aurora PostgreSQL 2 เท่าด้วยเช่นกัน

ฟีเจอร์อื่นของ AlloyDB คือฟีเจอร์ด้านวิเคราะห์ข้อมูล และใช้ machine learning ช่วยจัดการฐานข้อมูล ทั้งการแบ็คอัพ แพตช์ สเกล และ replication ให้อัตโนมัติ กูเกิลการันตี SLA ที่ 99.99% ซึ่งน้อยกว่าฐานข้อมูล Cloud Spanner หนี่งหลัก (99.999%) แต่ก็มีโจทย์การใช้งานและราคาที่ต่างกัน

No Description

No Description

สถาปัตยกรรมเบื้องหลัง AlloyDB คือการแยกส่วน compute และ storage ออกจากกัน ในฐานข้อมูล relational database แบบดั้งเดิม เซิร์ฟเวอร์เครื่องเดียวมีทั้งส่วน compute/storage รวมกัน ทำงานจบในตัว และขยายด้วยวิธี scale up เพิ่มเครื่องให้ใหญ่ขึ้น ซีพียูแรงขึ้น สตอเรจมากขึ้น ซึ่งไม่ค่อยยืดหยุ่นนัก

ฐานข้อมูลยุคถัดมาที่เริ่มมีคลาวด์ เปลี่ยนมาใช้วิธี scale out เพิ่มจำนวนเครื่องแทน ข้อดีคือแก้ปัญหาเรื่องปริมาณพื้นที่สตอเรจให้ยืดหยุ่นกว่าเดิม แต่ยังเจอข้อจำกัดเรื่องการวางแผนพื้นที่สตอเรจให้เหมาะสม ต้องบาลานซ์ระหว่างพื้นที่เยอะเกินความต้องการ กับพื้นที่หรือ I/O ไม่เพียงพอในจังหวะโหลดหนักๆ (spike หรือ hotspot)

AlloyDB แก้ปัญหาข้างต้นด้วยการแยกส่วน compute และ storage จากกันอย่างสิ้นเชิง ทั้งสองส่วนสามารถสเกลแบบคลัสเตอร์ได้ และใช้แคชมาคั่นกลางในหลายจุดเพื่อรองรับโหลดแต่ละประเภท

No Description

จุดเด่นอย่างหนึ่งของ AlloyDB คือแก้ปัญหาเรื่อง read-only replica หรือการทำซ้ำฐานข้อมูลให้อ่านได้อย่างเดียว (แก้ปัญหาฐานข้อมูลเดียวรองรับโหลดการอ่านไม่ไหว ซึ่งมีข้อจำกัดเรื่องการซิงก์ข้อมูลระหว่าง replica ตามมา) ด้วยการสร้าง multiple read-only replica instances ขึ้นมาหลายๆ ชุด โดยไม่ต้องทำสำเนาฐานข้อมูลจริงๆ

เหตุผลเป็นเพราะ AlloyDB แยกตัวข้อมูลที่เก็บจริง (storage layer) กระจายอยู่หลายๆ โซนของคลาวด์อยู่แล้ว ดังนั้นก็แค่สร้าง replica instance ขึ้นมาหลายๆ ตัว ซึ่งอาจเรียกข้อมูลจริงที่อยู่คนละแห่งกันได้เลย

สถาปัตยกรรมส่วน storage layer ของ AlloyDB (กรอบสีฟ้าในภาพ) แยกได้เป็น 3 ส่วนย่อยคือ

  1. log storage สำหรับเขียน write-ahead log (WAL) แบบรวดเร็วมาก
  2. log processing service (LPS) เพื่อประมวลผล WAL และสร้างบล็อคสำหรับเก็บข้อมูล
  3. block storage พื้นที่เก็บข้อมูลจริงๆ โดยมีฟีเจอร์ sharding, แยกเก็บตาม region ของคลาวด์ เพื่อป้องกันปัญหาสตอเรจพังทั้งโซน

จากภาพ เริ่มจาก primary database instance เขียนการเปลี่ยนแปลงของฐานข้อมูล (INSERT/DELETE/UPDATE) เป็น WAL log ส่งเข้ามาที่ log processing service (LPS) ให้ดำเนินการเปลี่ยนแปลงข้อมูลจริงๆ ที่เก็บใน block storage อีกที

จากนั้น บล็อคข้อมูลสามารถถูกส่งให้ replica instance อื่นๆ ได้โดยตรง เมื่อนำมาประกอบเข้ากับ WAL log ที่ส่งมาจาก primary instance เราก็จะได้ replica instance ที่สามารถทำงานได้เหมือนกันทันที โดยไม่ต้องสร้างสำเนาข้อมูลขึ้นมาทั้งก้อน

No Description

กูเกิลอธิบายว่า สถาปัตยกรรมนี้แยกส่วน compute/storage จากกันอย่างสิ้นเชิง ในการประมวลผล log (LPS) สามารถ scale-out ต่างหากได้โดยไม่ต้องยุ่งกับการสำเนาข้อมูล ฝั่งการเก็บข้อมูลบล็อค ก็สามารถกระจายความเสี่ยงข้อมูลพังทั้งโซน (zonal failure) โดยสำเนาบล็อคทั้งหมดข้ามโซนของคลาวด์ได้

การแยก compute/storage ด้วยกันยังช่วยแก้ปัญหาคอขวด IO และไม่จำเป็นต้องทำจุด checkpoint ของฐานข้อมูลทั้งก้อน เลเยอร์ของ compute ทำหน้าที่แค่คิวรีงานตามสั่งอย่างเดียว ส่วนเลเยอร์ storage ก็เก็บข้อมูลอย่างเดียว การสั่งแบ็คอัพ ทำที่เลเยอร์ storage ไม่กระทบทรัพยากรที่ใช้ในเลเยอร์ของ compute

รายละเอียดทางเทคนิคเพิ่มเติมอ่านได้จาก Google Cloud

No Description

กูเกิลเน้นกลุ่มลูกค้าที่ต้องการย้ายจากฐานข้อมูลแบบเดิมๆ (เช่น Oracle) มายัง AlloyDB ที่เป็นฐานข้อมูลโอเพนซอร์ส แต่มีประสิทธิภาพสูงกว่า และออกบริการช่วยย้ายข้อมูล Oracle to PostgreSQL มาให้พร้อมกัน

ส่วนวิธีคิดเงินของ AlloyDB แยกคิด 3 ส่วน (ตัวอย่างราคาเขต us-central1) คือ

  • CPU/memory ($0.06608 / vCPU hour + $0.0112 / GB hour)
  • Storage ($0.0004109 per GB)
  • Networking (ingress ฟรี, egress ข้ามเขต $0.02/GB)

ที่มา – Google

from:https://www.blognone.com/node/128484

Timescale บริษัทฐานข้อมูลที่พัฒนาต่อจาก PostgreSQL ระดมทุนรอบ C 110 ล้านดอลาร์

Timescale ผู้พัฒนาส่วนขยาย PostgreSQL ในชื่อ TimescaleDB สำหรับการเก็บข้อมูลตามเวลา (time-series) เช่น ข้อมูลล็อกหรือเซ็นเซอร์ต่างๆ ได้รับเงินทุน 110 ล้านดอลลาร์ มูลค่าบริษัทเกิน 1 พันล้านดอลลาร์ โดยระบุว่าช่วงสองปีที่ผ่านามีลูกค้าจ่ายเงินแล้วกว่า 500 องค์กร รายได้เพิ่มขึ้น 20 เท่าตัว

ทาง Timescale ระบุว่านอกจากการพัฒนาสินค้าแล้ว เงินทุนก้อนนี้จะนำไปสร้างทีมเฉพาะสำหรับการพัฒนาตัว PostgreSQL ในโครงการต้นน้ำโดยตรง จากเดิมที่บริษัทจ้างนักพัฒนาโครงการต้นน้ำเป็นพนักงานเต็มเวลาอยู่แล้ว

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

ที่มา – Timescale

No Description

Topics: 

from:https://www.blognone.com/node/127294

สรุปขั้นตอนการเตรียมระบบ IT Infrastructure สำหรับ Migrate Enterprise Database ไปสู่ PostgreSQL โดย TN Incorporation

ท่ามกลางกระแสของธุรกิจในแบบ Data-Driven Business ที่ทุกกลยุทธ์และการตัดสินใจล้วนต้องขับเคลื่อนด้วยข้อมูล ระบบฐานข้อมูล (DBMS) นั้นจึงกลายเป็นหัวใจสำคัญของธุรกิจองค์กรในทุกขนาดและทุกอุตสาหกรรม

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

ในบทความนี้ ทีมงาน TN Incorporation (TN) จะมาแบ่งปันขั้นตอนที่ธุรกิจจะต้องเตรียมตัวก่อนการ Migrate Enterprise Database ไปยัง PostgreSQL ระบบ Open Source Database Software ที่ได้รับความนิยมเป็นอย่างมากในปัจจุบัน ทั้งในการใช้งานแบบ On-Premises และ Cloud เพื่อให้ธุรกิจมีทางเลือกในการใช้งานระบบ Database สำหรับธุรกิจได้โดยไม่ต้องกังวลถึงค่าใช้จ่ายด้าน License ในการใช้งานที่เคยมีราคาสูงอย่างการใช้ Commercial Database ในอดีตอีกต่อไป ดังนี้

3 ขั้นตอนการประเมินและกำหนดความต้องการด้าน Service Level Agreement (SLA) ของระบบ Database

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

โดยข้อกำหนดทางด้าน Service Level Agreement ที่สำคัญที่ต้องทำการตรวจสอบ ปรับปรุง และตกลงให้เรียบร้อยก่อนทำการ Migrate ระบบ Database นั้นได้แก่

1. การกำหนด System Availability

ขั้นตอนแรกคือการสำรวจว่าระบบ Database ที่ใช้งานอยู่เดิมนั้นมีการใช้งานและมีระดับของ SLA อยู่ที่ระดับใด เช่น สำหรับระบบที่มีผู้ใช้งานใช้เป็นหลักนั้นก็อาจมี ช่วงการใช้งานเพียง 8 ชั่วโมงใน 5 วันทำการ (8×5) สำหรับเฉพาะช่วงเวลาทำงานเท่านั้น แต่สำหรับระบบที่มีความสำคัญสูงและต้องถูกเข้าถึงใช้งานอยู่ตลอดเวลา ก็อาจมีช่วงการใช้งานตลอด 24 ชั่วโมง 7 วันในแต่ละสัปดาห์ (24×7) เป็นต้น

ถัดมาก็คือการกำหนด Availability Target สำหรับแต่ละระบบเพื่อระบุถึงความพร้อมในการให้ใช้งานแต่ระบบในรูปแบบของ % ของ Uptime ในระบบต่อปี (% Availability) เช่น 99% หรือ 99.9% เป็นต้น

การกำหนด Availability ที่ถูกต้องจะทำให้สามารถออกแบบระบบ Database ได้ตรงกับ Business Requirement ภายใต้งบประมาณที่เหมาะสม

2. การกำหนด Performance Target

Performance Target เป็นการประเมินว่า Database จะต้องมีความสามารถในการรองรับ Workload ได้ในประสิทธิภาพระดับใด โดยการประเมิน Performance ของ Database จะมี SLA ที่สำคัญได้แก่

  • จำนวน Concurrent Connection สูงสุดสำหรับการเชื่อมต่อ Database
  • ปริมาณ Query Throughput เช่น Select, Insert, Update, Delete ว่าจะต้องรองรับได้สูงสุดกี่ Query per Second
  • Query Response Time จะต้องใช้เวลาประมวลผลไม่เกินเท่าใด เช่น Average 10 millisecond เป็นต้น

การกำหนด Performance Target ของ Database จะทำให้สามารถออกแบบ Database รวมถึงการเลือกใช้ Platform Infrastructure ได้เหมาะสมต่อ Workload Characteristic ที่จะเกิดขึ้นจริงในการใช้งาน

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

3. การกำหนด Security Baseline

Enterprise Database เป็นระบบที่ต้องเก็บข้อมูลที่มีความสำคัญสำหรับองค์กร ดังนั้นการกำหนดความต้องการทางด้าน Security จึงเป็นเรื่องสำคัญอย่างยิ่ง

ขั้นแรกคือการจัดกลุ่มประเภทของข้อมูลที่เก็บภายใน Database ตาม Confidentiality Level เช่น ระบบหนึ่งอาจจะมีการจัดเก็บเพียงข้อมูลทั่วไป ในขณะที่อีกระบบนั้นอาจมีการจัดเก็บ Sensitive Data แตกต่างกันออกไป

การแบ่งกลุ่มนี้จะทำให้สามารถออกแบบ Database ตามระดับของ Data Security ได้ เช่น การเลือกใช้เทคโนโลยี Data Encryption ประเภทต่างๆ ให้เหมาะสม หรือการกำหนด Access Control Matrix สำหรับผู้ดูแลระบบและ Account ของระบบต่างๆ หรือการกำหนดค่าในการทำ Security Auditing เป็นต้น

โดยทั่วไปแล้วการวางแผนสำหรับการย้ายระบบ Database ในประเทศไทยในระยะหลังนี้ มักจะต้องมีการปรับปรุง Security Baseline ค่อนข้างมากเพื่อให้สอดคล้องต่อการนำไปใช้งาน เช่น การเสริมความมั่นคงปลอดภัยสำหรับการใช้งานบน Cloud, การตอบรับต่อข้อกฎหมายด้านความมั่นคงปลอดภัยและความเป็นส่วนตัวของข้อมูล ไปจนถึงการรองรับ Compliance ต่างๆ ภายในองค์กรที่ถูกกำหนดเพิ่มเติมขึ้นมา

5 ขั้นตอนการเตรียมความพร้อมระบบ Database Infrastructure

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

สำหรับประเด็นสำคัญในการเตรียม Platform Infrastructure ให้กับระบบสำหรับระบบฐานข้อมูล ได้แก่

1. การเลือก System Infrastructure ที่เหมาะสมกับความการใช้งานจริง

ในปัจจุบันเทคโนโลยีของ System Infrastructure ที่สามารถเลือกใช้งานสำหรับระบบ Database มีหลายหลายรูปแบบ เช่น การใช้งาน Server แบบ On-premise, การใช้งาน Public หรือ Private Cloud, หรือการใช้ Database-as-a-Service (DBaaS) เป็นต้น Infrastructure ในแต่ละรูปแบบก็จะมีจุดเด่นและข้อจำกัดที่แตกต่างกัน

ด้วยเหตุนี้ การเลือก Infrastructure สำหรับระบบ Database จึงต้องเข้าใจปัจจัยความแตกต่างเหล่านี้ เช่น การใช้งาน Public Cloud มีจุดเด่นสำหรับการเพิ่มขยาย Capacity แต่จะมีข้อจำกัดหรือมีค่าใช้จ่ายในการรับส่งข้อมูลเข้าออก รวมถึงการพิจารณาถึงข้อกำหนดนโยบายของการเก็บข้อมูลในองค์กร การใช้งาน DBaaS ช่วยลดภาระในการบริหารจัดการ Database สำหรับผู้ดูแลระบบ แต่อาจจะไม่เหมาะสำหรับ Database ที่ต้องการประสิทธิภาพสูง ที่ต้องปรับแต่ง Database Parameter ให้สามารถรองรับ Workload ตามที่ต้องการได้ เป็นต้น

2. การเตรียมระบบ Database Backup & Recovery

ผู้ดูแลระบบฐานข้อมูล ล้วนเห็นความสำคัญของการสำรองและการกู้คืนระบบ แต่การออกแบบ Backup and Recovery Strategy ที่สอดคล้องกับ Business Requirement เป็นเรื่องที่ท้าทายและต้องมีการออกแบบที่เหมาะสม

การกำหนด Backup Strategy มีองค์ประกอบที่ต้องพิจารณาได้แก่

  • ความครบถ้วนในการสำรองข้อมูล เช่น Database file, Transaction log ที่จำเป็นในการ recover ระบบ รวมถึงระยะเวลาของการเก็บข้อมูล backup ย้อนหลัง (Backup retention) ที่สอดคล้องกับ requirement
  • การเลือกใช้วิธีการ Backup ที่ไม่กระทบกับการทำงานของระบบ Application เช่น หาก application มีช่วงเวลาที่อยู่นอก service hour การ backup จะต้องสามารถทำได้โดยมี backup throughput เพียงพอเพื่อให้เสร็จภายใน backup window หรือหากระบบงาน application เป็นแบบ 24×7 การ backup จะต้องทำในลักษณะ online หรือ snapshot โดย application จะยังคงทำงานได้ต่อเนื่องและมี response time เป็นปกติ

นอกเหนือจากการกำหนด Backup Strategy แล้ว การกำหนด Recovery Strategy ก็เป็นอีกส่วนที่มีความสำคัญไม่น้อยไปกว่ากัน โดยประเด็นที่ควรต้องพิจารณานั้นได้แก่

  • การกำหนด Target SLA ที่ชัดเจน ได้แก่ Recovery Time Objective (RTO) คือ กรอบเวลาที่ใช้ในการกู้ระบบกลับ เช่น ภายในไม่เกิน 3 ช.ม. และต้องมี Recovery Point Objective (RPO) คือ ระยะเวลาที่สามารถกู้ข้อมูลย้อนหลังได้ เช่น รายการข้อมูลสุดท้าย 30 นาทีก่อนระบบจะมีปัญหา หรือในบางครั้งอาจจะเป็น last transaction ในกรณีที่ระบบมีความสำคัญสูง
  • การวาง Recovery Procedure ที่ชัดเจน เช่น การ restore datafile, การ restore transaction log, การ rollback-rollforward recovery รวมไปถึงการตรวจสอบความถูกต้อง data integrity ภายหลังจากการกู้ระบบ
  • การทดสอบและซักซ้อมการ Recover ระบบ เพื่อให้มั่นใจว่าสามารถทำได้จริง และทำได้ตามเวลาที่กำหนด ผู้ดูแลระบบฐานข้อมูลจำเป็นต้องเห็นความสัมพันธ์ในภาพรวมเพื่อให้สามารถ correlate และ drill down เพื่อแก้ไขปัญหาได้ตรงจุด
  • การเก็บข้อมูล Performance Measurement จะทำให้สามารถบริหารจัดการแบบ pro-active ได้ เช่น การทำ capacity planning และการตรวจสอบ anomaly detection and remediation

3. Failure Recovery

สำหรับระบบฐานข้อมูลที่มีความสำคัญสูง นอกจากการออกแบบ Backup and Recovery ที่ดีแล้ว ยังอาจจำเป็นต้องออกแบบ Database Infrastructure ที่สามารถรองรับ Failure Scenario ต่างๆ ได้ เช่น Hardware component failure, Database server failure, Data center failure เป็นต้น

  • Hardware Component Failure เช่น กรณี hard disk มีปัญหา หรือ power supply ของเครื่อง server มีปัญหา โดยส่วนใหญ่ จะสามารถป้องกันได้โดยการใช้ Hardware ที่มี redundancy เช่น การทำ disk RAID หรือการใช้ redundant power supply
  • Database Server Failure ในกรณีที่ server ที่ทำหน้าที่เป็น Database server มีปัญหา จะสามารถออกแบบป้องกันได้โดยการให้มี server สำรอง เช่น hot standby server โดยการ failover shared storage หรือการทำ database replication ซึ่งสามารถทำได้ทั้งแบบ synchronous และ asynchronous
  • Data Center Failure สำหรับระบบที่มีความสำคัญสูง จะมีการวางแผนให้มี Data Recover Center (DRC) เพื่อสำรองในกรณีที่ Data Center หลักไม่สามารถให้บริการได้ การออกแบบ Infrastructure จะต้องสำรองข้อมูลโดยการ replicate data ไปยัง DRC ซึ่งสามารถทำได้แบบ snapshot sync เป็นระยะ หรือ real time replication ทั้งแบบ synchronous และ asynchronous ซึ่งจะมีข้อดีและข้อจำกัดแตกต่างกันไป

การเลือกออกแบบ solution สำหรับ Failure recover ในลักษณะต่างๆ จะต้องสอดคล้องกับ business requirement และพิจารณาถึงความซับซ้อนของ solution และข้อจำกัดต่างๆ เช่น การใช้ shared storage จะมี single point of failure และต้องการ storage ที่มีเสถียรภาพสูง การเลือกใช้ synchronous replication จะส่งผลกับ application performance และระยะทางระหว่าง data center เป็นต้น นอกจากนั้นผู้ดูแลระบบจำเป็นต้องทดสอบขั้นตอนการกู้ระบบตาม Failure recovery procedure ในลักษณะต่างๆ เป็นประจำเพื่อให้มั่นใจว่า solution และ procedure ที่วางไว้จะสามารถใช้งานได้จริง

4. Monitoring and Alert

การวางระบบ Monitoring and Alert เป็น foundation ที่สำคัญในการ manage DBMS ผู้ดูแลระบบจำเป็นต้องมีเครื่องมือเพื่อให้เห็น workload และ system resource utilization ของระบบ DBMS เมื่อมีความผิดปกติเกิดขึ้น

การออกแบบ Alert channel, Alert level และ Pre-define action ที่ชัดเจนจะทำให้สามารถแก้ไขปัญหาได้อย่างรวดเร็ว ลดผลกระทบหากเกิดปัญหาขึ้นในระบบ

ทั้งนี้ การเลือก tools และ measurement ที่ดีก็เป็นอีกองค์ประกอบสำคัญสำหรับ Monitoring and Alert เช่น ความสามารถในการ monitor ระบบในภาพรวมแบบ Full stack ได้แก่

  • Application & End-user Measurement เพื่อรวบรวมและตรวจสอบข้อมูลให้ครบถ้วนทั้งฝั่งของ Server และผู้ใช้งาน ช่วยให้สามารถทำการแก้ไขปัญหาได้อย่างสะดวกรวดเร็วยิ่งขึ้น
  • Database Performance Indicator สำหรับชี้วัดประสิทธิภาพการทำงานของ Database ในแต่ละช่วงเวลาหรือแต่ละคำสั่ง
  • Slow Query, Expensive SQL เพื่อช่วยในการตรวจสอบและปรับปรุงประสิทธิภาพการทำงานของระบบให้สูงขึ้นอย่างต่อเนื่อง โดยเฉพาะอย่างยิ่งเมื่อมีการเพิ่มชุดคำสั่งใหม่ๆ เข้ามาในระบบ
  • CPU, Memory, Disk I/O Utilization สำหรับตรวจสอบประสิทธิภาพในระดับของ Hardware และใช้วางแผนในการลงทุนเพิ่มขยายระบบได้อย่างเหมาะสม
  • Network Utilization สำหรับใช้ตรวจสอบประสิทธิภาพในระดับของระบบเครือข่าย เพื่อให้แก้ไขปัญหาคอขวดที่เกิดขึ้นบน Network ได้ทันท่วงที โดยเฉพาะอย่างยิ่งเมื่อเกิดเหตุระบบเครือข่ายล่ม หรือมีการโอนถ่ายข้อมูลปริมาณมหาศาลในระหว่าง Backup หรือเมื่อเกิดเหตุ Data Breach

5. Security

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

  • การออกแบบ security ควรทำตั้งแต่การเลือก solution และออกแบบ Database infrastructure เช่น ปัจจุบันหลายองค์กรเห็นความจำเป็นในการเข้ารหัสข้อมูล ดังนั้นการออกแบบ data encryption ควรพิจารณาในระดับ design เช่น การกำหนดระดับ data confidential level, การเลือก encryption strategy, การ manage encryption key, การเลือก hardware หรือ software encryption ที่มีประสิทธิภาพตรงกับการใช้งานจริง
  • การกำหนดและบังคับใช้ Security Guideline เช่น ข้อกำหนดเรื่อง authentication and authorization, การทำ security monitoring เช่น audit log และการกำหนด process ของการ monitor and action
  • การทำ Security Test เช่น VA scan หรือ Penetration test และการแก้ไขปัญหา security vulnerability ที่พบ เช่น การการติดตั้ง security fix หรือ implement workaround ซึ่งผู้ดูแลระบบฐานข้อมูลต้องวางแผนเพื่อป้องกันช่องโหว่ทางด้าน security ในระบบ DBMS

สนใจทำโครงการ Enterprise Database Migration ติดต่อทีมงาน TNI ได้ทันที

การบริหารจัดการระบบ DBMS มีความสำคัญสำหรับองค์กร หน่วยงานทางด้าน IT มีความจำเป็นต้องสร้างและพัฒนาศักยภาพของ Database Administrator เพื่อให้สามารถตอบสนองความต้องการขององค์กรได้ T.N. Incorporation เล็งเห็นความสำคัญและมี Professional service สำหรับองค์กร ดังต่อไปนี้

• Database platform consulting ให้บริการออกแบบและให้คำปรึกษาในระดับ database infrastructure เพื่อให้ได้ solution ที่เหมาะสมตรงกับความต้องการ

• Database migration service

• Production technical support แบบ 24×7 โดยทีมงานภายในประเทศไทย ซึ่งมีประสบการณ์ในการ support ระบบในระดับ mission critical มีเข้าใจความต้องการที่เป็นลักษณะเฉพาะของระบบงาน IT ในองค์กรในประเทศไทย

สำหรับผู้ที่สนใจใช้งาน PostgreSQL สามารถติดต่อสอบถามหรือทำการทดสอบระบบได้ทันทีกับทีมงาน TNI ที่  Marketing Team  หมายเลขโทรศัพท์ 02 3439100  หรือ Email: mkt_bd@tnis.com

from:https://www.techtalkthai.com/how-to-prepare-your-database-for-migrate-to-postgresql-by-tn-incorporation/

4 ขั้นตอน การทำ Migration ระบบ Enterprise Database สู่ PostgreSQL ลดค่าใช้จ่ายในระยะยาว จากประสบการณ์ตรงของ TN

การย้ายระบบ Enterprise Database ของ Business Application สำคัญไปสู่ Open Source Database เพื่อลดค่าใช้จ่ายในระยะยาวขององค์กรนั้นเป็นแนวทางที่ได้รับความนิยมมากขึ้นทุกๆปีและในบทความนี้ทีมงาน TN ก็จะมาแบ่งปันแนวทางและประสบการณ์การย้ายระบบ Enterprise Database ชื่อดังไปสู่ PostgreSQL เพื่อเป็นประโยชน์ให้กับผู้อ่าน TechTalkThai ทุกท่านดังนี้ครับ

1. เตรียมการโครงการ

1.1 สำรวจการทำงานของระบบเดิม เพื่อทำความเข้าใจการใช้งาน

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

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

1.2 ประเมินคุณสมบัติของ Open Source Database ทางเลือกต่างๆ และเลือกใช้เทคโนโลยีที่เหมาะสมกับงาน

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

ทีมงานของ TN ได้ระบุถึง 4 ปัจจัย ในการเลือกใช้ Open Source Database คือ

  • Features การสำรวจว่าระบบเดิมนั้นใช้ความสามารถใดบน Enterprise Database ที่เป็น commercial software อยู่บ้าง ความสามารถใดจำเป็นหรือไม่จำเป็น และนำมาเทียบกับ Open Source Database ว่าสำหรับแต่ละความสามารถในระบบเดิมนั้น ระบบใหม่จะนำความสามารถใดมาใช้ทดแทนได้บ้างในเชิงเทคนิค ซึ่งโดยทั่วไปทางทีมงานก็พบว่าธุรกิจส่วนใหญ่ใช้งานความสามารถเพียงแค่ 20-30% ของ Enterprise Database เท่านั้น ซึ่งก็ถือว่ายังไม่คุ้มค่านักกับค่าใช้จ่ายที่เสียไปในแต่ละปี ดังนั้นการเลือกใช้ opensource ที่มีความสามารถครอบคลุมการใช้งานดังกล่าวได้มาทดแทน ก็เพียงพอแล้ว ซึ่ง Open Source Database สมัยนี้สามารถทำงานในเรื่องเหล่านี้ได้ทัดเทียมกับ Commercial Database ได้สบาย
  • Performance ควรเป็น Opensource Database ในระดับ Enterprise สามารถรองรับการ scale ในอนาคตที่อาจจะเกิดขึ้นได้
  • Community มี Community ที่แข็งแกร่ง เพื่อสนับสนุนการแก้ปัญหาจากการใช้งานจริง และมีการพัฒนาความสามารถต่อยอดเพิ่มเติมในอนาคต
  • Site References เพื่อให้ผู้บริหารมีความมั่นใจในการเปลี่ยนเทคโนโลยี การเลือกใช้ Open Source Database ที่ธุรกิจองค์กรใหญ่แห่งอื่นๆเลือกใช้มาแล้ว สามารถเชื่อมั่นได้ว่าทำงานได้จริง

ในหลายโครงการที่ผ่านมา TN ได้เลือกใช้งาน PostgreSQL เพื่อทดแทน Enterprise Database ชื่อดังหลายแบรนด์ให้ลูกค้าของบริษัท เนื่องจากเป็น Open Source Database ที่ตอบโจทย์ข้างต้นนี้ได้อย่างครบถ้วนที่สุด และมีความยืดหยุ่นสำหรับนำไปปรับแต่งใช้งานได้ในหลากหลายสถานการณ์ ทั้งยังมีผู้ให้บริการ Cloud ชั้นนำระดับโลกหลายรายที่นำไปเปิดให้บริการเป็นทางเลือกแกลูกค้า ในการ Deploy ระบบทั้งแบบ On-Premises และ On Cloud

1.3 การเตรียม Resource สำหรับ Migration

เพื่อให้การ Migrate Database ดำเนินการสำเร็จตามเป้าหมายที่วางไว้ การวางแผน Resource ที่จะใช้ในโครงการจึงเป็นสิ่งสำคัญเช่นกัน โดยสามารถแยกออกเป็นสองส่วน คือ

  • ด้านเทคนิค จะต้องมีการวางแผนในเรื่อง Workload and Resource Sizing เพื่อประเมินปริมาณ workload ที่ database จะต้องสามารถรองรับได้ เช่น จำนวนผู้ใช้งาน ขนาด data concurrent database connection ปริมาณ database query per second เพื่อกำหนดขนาดของ CPU, memory, disk space และ network bandwidth ที่เพียงพอให้สามารถรองรับปริมาณการใช้งานจริงได้ นอกจากนั้นอาจจะต้องวางวิธีการ scale resource capacity เพิ่มในกรณีที่ workload มากขึ้นในอนาคต
  • ด้านบุคคลากร การเตรียมทีมงานโครงการให้พร้อมเป็นส่วนสำคัญมากที่จะทำให้โครงการสำเร็จ ทีมงานปกติจะประกอบไปด้วย ผู้รับผิดชอบโครงการหลัก Project director ผู้ดำเนินโครงการ Project manager บุคคลกรด้าน technical เช่น System engineer, Database Specialist เป็นต้น Key Success Factor หนึ่งที่เป็นสิ่งสำคัญต่อการดำเนินการโครงการ คือ ทางเจ้าของโครงการต้องมีการมอบหมายผู้รับผิดชอบโครงการหลักเพื่อทำงานร่วมกับทีมงานโครงการ รวมถึงมอบหมายแนวทางในการตัดสินใจหรือกำหนดผู้มีอำนาจในการตัดสินใจในการดำเนินโครงการ ก็จะยิ่งทำให้โครงการมีความราบรื่นเป็นไปตามเป้าหมาย

2. วางแผนการทำ Migration

เมื่อมั่นใจแล้วว่าเทคโนโลยี Open Source Database ที่เราเลือกนำมาใช้ทดแทน Enterprise Database นั้นจะสามารถตอบโจทย์การใช้งานในเชิงเทคนิคได้อย่างครบถ้วนแล้ว ก็ถึงขั้นตอนของการวางแผนด้านการทำ Migration โดยจะแบ่งออกเป็น 3 ส่วนใหญ่ๆ ด้วยกัน

ส่วนแรก คือ การวางแผนในการทำ Application Migration ที่จะต้องลงรายละเอียดให้ชัดว่าในแต่ละความสามารถที่เปิดใช้บน Enterprise Database เดิมนั้นจะต้องใช้ความสามารถใดบน Open Source Database ใหม่ หรือแต่ละ Query ที่ใช้งานนั้นจะต้องมีการเปลี่ยนแปลงแก้ไขอย่างไรบ้าง หรือการตั้งค่าใน Enterprise Database เดิมนั้น หากย้ายมายังระบบใหม่จำเป็นที่จะต้องมีการปรับแต่งการตั้งค่าอย่างไรบ้าง

จากประสบการณ์ของ TN 80% ของการใช้งานระบบ Enterprise Database เดิมจะสามารถย้ายไปยังระบบ Open Source Database ใหม่แทบจะทันทีโดยที่ไม่ต้องมีการปรับแต่งแก้ไขใดๆ ในขณะที่อีก 20% ที่เหลือนั้นจะต้องมีการแก้ไขหรือไม่ขึ้นอยู่รายละเอียดของแต่ละโครงการ

มุมหนึ่งที่น่าสนใจนั้นก็คือสำหรับระบบ Enterprise Application ขนาดใหญ่ของหลายๆ องค์กรที่มีการใช้งานอยู่นั้น มักมีการใช้งาน Middleware หรือ Object-Relational Mapping (ORM) อยู่แล้ว ทำให้การย้ายระบบเหล่านี้ง่ายขึ้น เนื่องจากไม่ต้องไปแก้ไข Application ในส่วนของ Query โดยตรง แต่ก็จะเป็นโจทย์ที่ผู้ทำ Migration ระบบจะต้องมีความรู้ความสามารถด้านการจัดการ Middleware หรือ ORM ด้วย ซึ่งทีมงานของ TN เองก็มีประสบการณ์ในส่วนนี้อยู่แล้วจึงสามารถทำงานลักษณะนี้ได้ดี

ส่วนที่สอง คือ การวางแผนในการทำ Data Migration ที่จะมีรายละเอียดปลีกย่อยหลายประการ เช่น

  • Schema Migration เป็นการ Migrate โครงสร้างอย่างเช่น Table , View , Index , Function , Sequence , Data Type , Aggregate Function และอื่นๆ
  • Role Migration เป็นการ Migrate User และ Role สำหรับระบบ Database
  • Administrator เป็นการวางแผนการตั้งค่า Session Manager, Lock Manager และอื่นๆ
  • Extension เป็นการติดตั้ง Extension ที่จำเป็นต่อการใช้งานเพิ่มเติม
  • Storage วางแผนการตั้งค่า Tablespace
  • Data Migration วางแผนในการย้ายข้อมูล โดยเลือกใช้เทคโนโลยีหรือกระบวนการให้เหมาะสมกับการใช้งาน เช่น การ Migrate ข้อมูลส่วนใหญ่โดยไม่กระทบต่อระบบ Production, การอัปเดตข้อมูลย่อยที่ถูกเพิ่มหรือแก้ไขในแต่ละวัน และอื่นๆ
  • Data Verification วางแผนการตรวจสอบความถูกต้องของข้อมูลที่ย้ายมา ว่าจะตรวจสอบความถูกต้องและครบถ้วนอย่างไร เพื่อให้มั่นใจก่อนการย้ายระบบทั้งหมดและขึ้นระบบสำหรับการใช้งาน

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

3. ลงมือทำ Database Migration

3.1 งาน Infrastructure

เมื่อมีความต้องการของระบบและแผนการที่ชัดเจนแล้ว ขั้นถัดมาก็คือลงมือการออกแบบระบบ Open Source Database ใหม่ว่าจะมีสถาปัตยกรรมการทำงานของระบบเป็นอย่างไร ใช้ Software รุ่นไหน มีส่วนประกอบอื่นๆ ที่จำเป็นอย่างไรบ้าง จะติดตั้งลงบน VM Cloud หรือ Hardware ที่มีขนาดเท่าไหร่อย่างไร ต้องติดตั้งกี่ระบบให้ทำงานร่วมกันด้วยวิธีการใด จะมีการปกป้องข้อมูลอย่างไร จะมีการสำรองหรือกู้คืนข้อมูลได้อย่างไร และอื่นๆ เพื่อให้ระบบมีความพร้อมต่อการนำไปใช้งานจริง

เมื่อทุกอย่างพร้อมแล้ว ก็สามารถทำการติดตั้ง Open Source Database ใหม่ได้ตามการออกแบบที่วางเอาไว้ได้ทันที โดย infrastructure ที่ออกแบบนี้ต้องมีความมั่นคงปลอดภัย ลดความเสี่ยงที่ระบบจะถูกโจมตี รองรับการขยายระบบในอนาคต รวมถึงสามารถรองรับ peak load ที่อาจจะมีโอกาสเพิ่มขึ้น ฯลฯ ไว้ด้วย

3.2 เริ่มต้นทำ Data Migration ให้ข้อมูลถูกย้ายไปอย่างครบถ้วนสมบูรณ์

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

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

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

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

3.3 ทำ Application Migration ให้ระบบพร้อมใช้งาน

แต่ละระบบนั้นอาจมีการทำ Application Migration ในระดับที่ต่างกัน บางระบบนั้นอาจแทบไม่ต้องทำการปรับแต่งแก้ไขในส่วนของ Application เลย ในขณะที่บางระบบก็อาจต้องมีโค้ดอีกชุดเพื่อรองรับการทำงานร่วมกับระบบ Open Source Database ใหม่โดยเฉพาะ รวมถึงยังต้องมีการตั้งค่าให้กับระบบ Application Server หรือ Parameter ต่างๆ ให้ทำงานร่วมกับ Open Source Database ได้อีกด้วย

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

3.4 การทดสอบ performance test

การทำ performance test มีความสำคัญเพื่อทดสอบว่าระบบฐานข้อมูลจะสามารถทำงานได้อย่างมีประสิทธิภาพหลังจาก migrate data แล้ว การทดสอบ performance ระบบจะต้องประเมินจากลักษณะ load pattern ที่จะเกิดขึ้นจริง เพื่อทดสอบว่าระบบมี response time เป็นไปตามข้อกำหนด SLA ที่ตั้งไว้ ผลของการทดสอบ performance test จะทำให้ทราบถึง resource utilization ที่จะเกิดขึ้นจริงก่อนการใช้งานระบบ และนอกจากนั้นจะทำให้ทราบถึงปัญหาหรือ bottleneck ยกตัวอย่างเช่น การ lock record, expensive SQL, หรือค่า database parameter ที่ควรปรับปรุง เพื่อที่จะได้ปรับปรุงทั้งในส่วนของ system parameter หรือ query tuning ก่อนที่จะใช้งานจริงบนระบบ production

4. เก็บรายละเอียดของระบบให้ครบถ้วน ก่อนส่งมอบงาน

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

จะเห็นได้ว่าการย้ายระบบ Enterprise Database ไปสู่ Open Source Database นั้นนอกจากจะมีประเด็นทางด้านเทคนิคที่ต้องคำนึงถึงแล้ว ประเด็นทางด้านกระบวนการการทำงานที่เหมาะสมนั้นก็มีส่วนสำคัญไม่น้อย ดังนั้นในโครงการทำ Database Migration ที่ผ่านมาของ TN นี้จึงต้องมีการวางแผนอย่างรอบคอบ และต้องอาศัยความมีส่วนร่วมกันของทั้งเจ้าหน้าที่ฝ่าย IT และฝ่ายธุรกิจในองค์กร เพื่อให้โครงการดำเนินออกมาได้อย่างราบรื่น บรรลุเป้าหมาย ซึ่งทาง TN จะจัดเตรียมทีมงานซึ่งประกอบไปด้วยผู้รับผิดชอบโครงการหลัก (Project director) ผู้ดำเนินโครงการ (Project manager)
และ บุคลากรที่มีความชำนาญในด้านต่าง ๆ เช่น System engineer, Database Specialist, Application Analyst เป็นต้น ซึ่งทาง TN มีผู้เชี่ยวชาญ local support ที่เป็นคนไทย สามารถให้บริการได้ทันที ไม่จำเป็นต้องรอผู้เชี่ยวชาญจากต่างประเทศ เข้าใจวัฒนธรรมการทำงานแบบไทย ทำงานสำเร็จมาแล้วและเรายังมีช่องทางการเข้าถึง world class support กรณีโครงการมีความซับซ้อนอย่างมาก เพื่อให้ลูกค้ามั่นใจใน support ของบริษัท

ทั้งนี้ทีมงาน TN ก็พร้อมที่จะช่วยธุรกิจองค์กรไทยลดค่าใช้จ่ายด้วยการย้ายมาใช้งานระบบ Open Source Database แทน Enterprise Database ที่มีอยู่เดิม หากธุรกิจองค์กรใดสนใจย้ายระบบมาใช้งาน Open Source Database สามารถติดต่อทีมงาน TN เพื่อพูดคุยและทำ Assessment ประเมินความพร้อมและตรวจสอบประเด็นทางเทคนิคได้ทันที

สนใจเปลี่ยนมาใช้งาน PostgreSQL แทนระบบ Commercial Database Software เดิม ติดต่อ TN ได้ที่
Marketing Team หมายเลขโทรศัพท์ 081 4429591 หรือ Email: mkt_bd@tnis.com

from:https://www.techtalkthai.com/4-steps-of-enterprise-database-migration-to-postresql-by-tni/

AWS เปิดตัว Babelfish ระบบแปลงให้ PostgreSQL ใช้แทน SQL Server เต็มตัว พร้อมเปิดเป็นโอเพนซอร์ส

เมื่อปีที่แล้ว AWS เปิดตัวโครงการ Babelfish for PostgreSQL ตัวแปลงให้ซอฟต์แวร์ต่างๆ ที่เชื่อมต่อกับ Microsoft SQL Server สามารถเชื่อมกับฐานข้อมูล PostgreSQL ได้เพื่อประหยัดค่าไลเซนส์ ตอนนี้โครงการก็เข้าสถานะ GA ให้ทุกคนใช้งาน พร้อมกับโครงการโอเพนซอร์สออกมาพร้อมกัน

Babelfish รับผิดชอบการแปลงโปรโตคอล 3 ระดับ ได้แก่

  • ตัวโค้ด SQL เอง แม้ SQL จะเป็นมาตรฐานแต่ในความเป็นจริงการอิมพลีเมนต์ก็มีความแตกต่างกัน เช่น ชนิดข้อมูล, ฟังก์ชั่นและโอเปอร์เรเตอร์ที่มีไม่เท่ากันหรือบางครั้งก็ทำงานไม่เหมือนกัน
  • ภาษา T-SQL ที่เป็นส่วนขยายจาก SQL เฉพาะของไมโครซอฟท์ มีฟีเจอร์หลายอย่างที่ SQL ปกติไม่มี เช่น การประกาศตัวแปร, exceptions, if-else
  • โปรโตคอล TDS สำหรับการเชื่อมต่อกับไคลเอนต์เดิมที่เชื่อมต่อกับ SQL Server อยู่แล้ว การที่ Babelfish แปลงโปรโตคอลเป็น PostgreSQL ทำให้แอปพลิเคชั่นเดิมๆ สามารถใช้งานได้ทันทีโดยไม่ต้องเปลี่ยนไดร์เวอร์หรือไลบรารีใหม่

ตัวโครงการแก้ไข PostgreSQL อย่างหนัก มีตั้งแต่แพตช์ตัวฐานข้อมูลเอง โดย AWS ระบุว่าจะพยายามส่งแพตช์เข้าไปยังโครงการ PostgreSQL เองในอนาคต และยังเป็นส่วนขยายของ PostgreSQL อีก 4 ตัวเพื่อรองรับฟีเจอร์ต่างๆ เมื่อรัน PostgreSQL เวอร์ชั่นที่ติดตั้ง Babelfish ตัวฐานข้อมูลจะรองรับการเชื่อมต่อแบบ PostgreSQL เดิมที่พอร์ต 5432 และการเชื่อมต่อ TDS ที่พอร์ต 1433 เหมือน SQL Server

สำหรับผู้ใช้งานผ่านบริการ RDS หลังจากนี้เมื่อเลือกฐานข้อมูลเป็น PostgreSQL เวอร์ชั่น 13.4 ขึ้นไป จะมีตัวเลือก Babelfish ให้เปิดใช้งาน เมื่อเลือกแล้วสามารถใช้ไคลเอนต์ของไมโครซอฟท์ เช่น SSMS เชื่อมต่อเข้าไปเหมือน SQL Server ได้ทันที

ที่มา – AWS, Babelflish

No Description

from:https://www.blognone.com/node/125561

PostgreSQL ออกเวอร์ชั่น 14 คิวรี JSON เหมือนจาวาสคริปต์แล้ว

PostgreSQL ซอฟต์แวร์ฐานข้อมูลโอเพนซอร์สออกเวอร์ชั่น 14 โดยมีความเปลี่ยนแปลงด้านประสิทธิภาพภายในหลายอย่าง แต่สำหรับภาษา SQL ที่ใช้คิวรีในเวอร์ชั่นนี้เพิ่มเอาฟีเจอร์ subscripting เข้ามา ทำให้การเขียนคิวรี JSON นั้นเหมือนกับการเขียนจาวาสคริปต์มากขึ้น

PostgreSQL รองรับ JSONB มาตั้งแต่เวอร์ชั่น 9.2 แต่การคิวรีนั้นใช้เครื่องหมาย (operator) เฉพาะทาง ทำให้โปรแกรมเมอร์ค่อนข้างสับสน เช่นการดึงข้อมูลในออปเจกต์นั้นใช้เครื่องหมาย ->> เช่น '{"a":1,"b":2}'::json->>'b' การรองรับ subscripting ทำให้ SQL ที่คิวรีเขียนเหมือนกับโค้ดจาวาสคริปต์ที่นิยมใช้งานกัน

นอกจากฟีเจอร์ JSON แล้วเวอร์ชั่นนี้ยังรองรับข้อมูลประเภท multirange ทำให้เช็คช่วงของข้อมูลที่ซ้อนทับกับได้ เช่น ร้านที่เปิดในช่วงเวลาที่ต้องการ จากฐานข้อมูลเวลาเปิดปิด โดยข้อมูลประเภท range นั้นรองรับมาตั้งแต่ PostgreSQL 9.2 การรองรับ multirange ทำให้ระบุช่วงข้อมูลเป็นชุดได้ เช่น ร้านอาหารเปิดช่วงเช้า แล้วเปิดอีกทีช่วงบ่าย

ที่มา – PostgreSQL

No Description

Topics: 

from:https://www.blognone.com/node/125029

ลดค่าใช้จ่ายในการดูแลรักษาระบบ Database ของธุรกิจ ด้วยการเปลี่ยนมาใช้ Fully Managed PostgreSQL Services จาก TN Incorporation

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

บริษัท TN Incorporation จำกัด หรือ TN ในฐานะของผู้ที่พัฒนาและดูแลรักษาระบบ Application สำหรับสถาบันการเงินและธุรกิจองค์กรขนาดใหญ่มาอย่างยาวนานได้เล็งเห็นถึงปัญหาดังกล่าว และมองว่าหลายธุรกิจองค์กรสามารถลดค่าใช้จ่ายในการดูแลรักษาระบบ IT ได้อย่างทันทีด้วยการเปลี่ยนจากการใช้ระบบ Commercial Database Software มาสู่ระบบ Database ในแบบ Open Source Software ที่ไม่มีค่าใช้จ่ายด้านลิขสิทธิ์การใช้งานอย่างเช่น PostgreSQL จึงได้เปิดบริการ Fully Managed PostgreSQL Services เพื่อตอบโจทย์นี้ให้กับธุรกิจองค์กรแล้ววันนี้

เมื่อข้อมูลกลายเป็นหัวใจสำคัญของธุรกิจ ค่าใช้จ่ายในการดูแลรักษาระบบ Commercial Database Software ก็ยิ่งสูงขึ้นอย่างต่อเนื่อง

ที่ผ่านมานั้นธุรกิจมักมีการใช้งานระบบ Business Application อย่างเช่น ERP, CRM, WMS, ระบบบัญชี, ระบบการเงิน และระบบอื่นๆ ภายในองค์กร ซึ่งระบบเหล่านี้ก็มักมีการใช้งาน Commercial Database อย่างเช่น Oracle Database, Microsoft SQL Server หรือระบบฐานข้อมูลอื่นๆ เพื่อให้เกิดความมั่นใจว่าระบบงานสำคัญขององค์กรเหล่านี้จะทำงานได้อย่างต่อเนื่อง มั่นคงทนทาน และปลอดภัย ทำให้ธุรกิจดำเนินต่อไปได้อย่างไม่สะดุดติดขัด

อย่างไรก็ดีระบบฐานข้อมูลในแบบ Commercial Database เหล่านี้มักมีค่าใช้จ่ายในการจัดซื้อแรกเริ่มที่ค่อนข้างสูง รวมถึงมีค่าใช้จ่ายในการดูแลรักษาต่อสัญญาในแต่ละปีที่สูงไม่แพ้กัน อีกทั้ง License ในการใช้งานนั้นมักผูกอยู่กับพลังประมวลผลของระบบอย่างเช่น CPU Socket หรือ CPU Core ทำให้ในอนาคตหากระบบมีข้อมูลที่มากขึ้น หรือต้องการต่อยอดด้วยการนำเทคโนโลยีสมัยใหม่มาใช้วิเคราะห์ข้อมูลมากขึ้น หรือต้องการย้ายระบบขึ้นสู่ Cloud หรือต้องการทำ Disaster Recovery เพิ่มเติม ก็ทำให้เกิดค่าใช้จ่ายเพิ่มเติมในการเพิ่มขยายระบบฐานข้อมูลเหล่านี้

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

 

Open Source Database Software: ทางออกของธุรกิจองค์กรในยุคของ Hybrid Multicloud

Credit: ShutterStock.com

จากปัจจัยข้างต้นได้ส่งผลให้บรรดาธุรกิจองค์กรไทยและทั่วโลกนั้นต้องเริ่มมองหาทางเลือกใหม่ในการใช้งานระบบฐานข้อมูลสำหรับธุรกิจ และเหล่าชุมชนนักพัฒนา Open Source Software เองก็ได้ทำการตอบรับต่อโจทย์นี้ด้วยการพัฒนาเทคโนโลยี Open Source Database Software ขึ้นมาหลากหลาย ไม่ว่าจะเป็น PostgreSQL หรือ MariaDB ที่ต่างก็มีความสามารถใหม่ๆ ที่ทัดเทียมกับ Commercial Database มากขึ้นเรื่อยๆ จนผู้ให้บริการ Cloud ชั้นนำหลายรายทั่วโลกเองก็เริ่มนำเอา Open Source Database Software เหล่านี้ไปเปิดให้บริการบน Cloud ของตนเองด้วยเช่นกัน

แนวโน้มเหล่านี้ได้ทำให้เหล่าธุรกิจองค์กรนั้นหันมาใช้งาน Open Source Database Software ในภาคธุรกิจกันมากขึ้นอย่างต่อเนื่อง ไม่ว่าจะเป็นระบบเล็กๆ อย่าง Website ของบริษัท ไปจนถึงระบบขนาดใหญ่อย่างเช่น CRM, Mobile Application หรือแม้แต่ Big Data ด้วยข้อดีดังต่อไปนี้

  • การไม่มีค่าใช้จ่ายด้าน License และการต่อสัญญาในระยะยาว ทำให้ธุรกิจมีอิสระที่จะเลือกใช้งานเทคโนโลยีเหล่านี้ได้อย่างเต็มที่
  • สามารถเพิ่มขยายระบบได้อย่างอิสระ ใช้งานได้ทั้งบนระบบ On-Premises และ Cloud รองรับการย้ายระบบในภายหลังเพื่อทำ Hybrid Multi cloud ได้อย่างสะดวก
  • การรองรับความสามารถอย่างเช่น Cluster, High Availability, Disaster Recovery และ Backup ได้อย่างครอบคลุม
  • สามารถปรับแต่งทำ Performance Tuning ได้ในเชิงลึก รองรับการนำไปใช้งานในระบบได้หลากหลายรูปแบบ
  • มีชุมชนของนักพัฒนาและผู้ใช้งานคอยสนับสนุนการใช้งานจริง
  • มีการพัฒนาระบบต่อยอดรองรับ Business Application ชั้นนำเพิ่มขึ้นอยู่เสมอ

ข้อดีเหล่านี้ได้ส่งผลให้หลายธุรกิจที่หันไปใช้งาน Open Source Database Software สามารถริเริ่มโครงการพัฒนาระบบใหม่ๆ ในองค์กรได้อย่างรวดเร็ว และประหยัดค่าใช้จ่าย รวมถึงหลายองค์กรที่ได้ใช้งานเทคโนโลยีเหล่านี้จนมั่นใจในการดูแลรักษาระบบได้ด้วยตนเองแล้ว ก็มีแนวโน้มที่จะย้ายระบบ Business Application สำคัญที่ใช้งานอยู่เดิมมาสู่ Open Source Database Software กันมากขึ้น เพื่อลดค่าใช้จ่ายในการดูแลรักษาระบบในระยะยาว

 

PostgreSQL: ระบบ Open Source Database Software ที่ได้รับความไว้วางใจจากธุรกิจองค์กรและผู้ให้บริการ Cloud ชั้นนำทั่วโลก

PostgreSQL คือระบบ Open Source Object-Relational Database System ที่ถูกพัฒนามายาวนานกว่า 30 ปี และมีชื่อเสียงทางด้านความมั่นคงทนทาน ความสามารถที่หลากหลายและใช้งานได้จริง ไปจนถึงประสิทธิภาพที่สูง ทำให้ปัจจุบันนี้มีผู้ใช้งานจำนวนหลายล้านคน และมีชุมชนของนักพัฒนามากกว่า 600 คนที่สนับสนุนโครงการนี้อยู่

ปัจจุบันนี้ผู้ให้บริการ Cloud ชั้นนำทั่วโลกไม่ว่าจะเป็น AWS, Google Cloud Platform, Microsoft Azure, Alibaba Cloud หรือ Huawei Cloud นั้นต่างก็มีบริการ PostgreSQL ให้ใช้งานได้บน Cloud ทั้งสิ้น เพื่อรองรับ Workload หลากหลายรูปแบบไม่ว่าจะเป็น Website, Enterprise Application หรือแม้แต่ Cloud-Native Application ก็ตาม เป็นทางเลือกควบคู่ไปกับการใช้ Commercial Database บน Cloud ที่จะมีค่าใช้จ่ายเพิ่มเติมในส่วนของ License นั่นเอง

ผู้ที่สนใจรายละเอียดเพิ่มเติมเกี่ยวกับ PostgreSQL สามารถเยี่ยมชมเว็บไซต์ได้ที่ https://www.postgresql.org/

 

บริการ Fully Managed PostgreSQL Service จาก TN Incorporation ตอบโจทย์การออกแบบ ย้ายระบบ ดูแลรักษา เพิ่มขยาย และปรับแต่งแก้ไขอย่างครบวงจรด้วยทีมงานมืออาชีพที่พัฒนาระบบ Application ให้กับสถาบันการเงิน

TN Incorporation หรือ TN ในฐานะผู้ที่พัฒนาและดูแลรักษาระบบ Application สำหรับสถาบันการเงินและธุรกิจองค์กรขนาดใหญ่มาอย่างยาวนาน ต้องการจะช่วยธุรกิจองค์กรให้สามารถลดค่าใช้จ่ายและฝ่าฟันผ่านวิกฤตเศรษฐกิจและโรคระบาดในครั้งนี้ไปให้ได้ จึงได้ทำการเปิดบริการ Fully Managed PostgreSQL Service เพื่อช่วยให้ธุรกิจองค์กรสามารถเปลี่ยนมาใช้งาน PostgreSQL แทนระบบ Commercial Database เดิมได้อย่างสมบูรณ์และมั่นใจ

ภายใต้บริการดังกล่าวนี้ ประกอบด้วย ทีมงานวิศวกรผู้เชี่ยวชาญทั้ง Software Developer, Database Engineer และ System Engineer ร่วมกันให้บริการในทุกๆ ส่วนเพื่อให้การเปลี่ยนระบบ Database ของธุรกิจองค์กรเป็นไปได้อย่างราบรื่น ด้วยกระบวนการดังต่อไปนี้

  • System Assessment ให้บริการการตรวจสอบวิเคราะห์ระบบเดิม เพื่อนำเสนอว่าระบบส่วนใดบ้างที่สามารถย้ายมาใช้งาน PostgreSQL ได้โดยที่ระบบเดิมยังคงทำงานได้อย่างครบถ้วนสมบูรณ์หรือดีขึ้น และจะมีความคุ้มค่าในการลงทุนเป็นอย่างไร สามารถประหยัดค่าใช้จ่ายได้มากน้อยเพียงใด เพื่อให้ธุรกิจองค์กรได้เลือกทำการประเมินวางแผนโครงการได้อย่างแม่นยำ
  • Database & Application Migration การออกแบบระบบให้สามารถทำ HA/DR/Backup ได้ตามความต้องการ จัดหา Software หรือบริการ Cloud ตามความเหมาะสม ทำ Performance Tuning เพื่อให้ระบบมีประสิทธิภาพสูง ประเมินว่าต้องเปลี่ยน SQL Query ในระบบเดิมอย่างไรและช่วยทำการแก้ไข วางแผนการ Sync ข้อมูลจากระบบเดิม และทำการเปลี่ยนระบบมาใช้งาน PostgreSQL โดยเกิด Downtime น้อยที่สุดต่อระบบ
  • Quality Assurance การตรวจสอบความถูกต้องในการทำงานของระบบว่าพบปัญหาใดหรือไม่ และทำการแก้ไขปัญหาที่ตรวจพบในขั้นตอนนี้
  • 24×7 Maintenance การช่วยเหลือดูแลให้บริการหลังการขาย ตั้งแต่การแก้ปัญหา การให้คำปรึกษาในการขยายหรือต่อยอดระบบ, การอัปเกรด PostgreSQL เพื่ออุดช่องโหว่หรือเพิ่มเติมความสามารถใหม่ๆ ไปจนถึงการฝึกอบรมเพื่อให้ทีมงานขององค์กรมีความรู้ความเข้าใจเกี่ยวกับเทคโนโลยีและความสามารถของ PostgreSQL มากขึ้น โดยมีบริการให้เลือกหลากหลายแบบ รวมถึงบริการ 24×7 ระดับเดียวกับที่ให้บริการสถาบันการเงิน

บริการ Fully Managed PostgreSQL Service โดย TN Incorporation นี้จะช่วยให้ธุรกิจองค์กรประหยัดค่าใช้จ่ายในการบำรุงรักษา database ได้ประมาณ 30% – 50% จากการที่ธุรกิจองค์กรจะไม่ต้องเสียค่าใช้จ่ายไปกับ License ของระบบ Commercial Database และการต่ออายุสัญญาการใช้งานหรือบริการกับผู้ผลิตอีกต่อไป เหลือค่าใช้จ่ายเพียงแค่ส่วนของบริการ Managed Services เท่านั้น ทำให้หลายๆ องค์กรที่พิจารณาเลือกใช้บริการดังกล่าวนี้ สามารถคืนทุนจากค่าใช้จ่ายที่ลดลงได้ในระยะเวลาที่เร็วขึ้น และยังได้บริการที่เหนือชั้นยิ่งกว่าเดิม

นอกจากนี้ TN Incorporation มีทีมงานที่ครบทุกมิติทั้งในส่วนของการพัฒนาซอฟต์แวร์ไปจนถึงทีมงานดูแลรักษาระบบ IT ทำให้สามารถให้บริการได้แบบ One Stop Service ช่วยอำนวยความสะดวกให้กับธุรกิจที่ต้องเร่งรีบลดค่าใช้จ่ายในการลงทุนระบบ IT ได้อย่างเบ็ดเสร็จในรายเดียว

 

สนใจเปลี่ยนมาใช้งาน PostgreSQL แทนระบบ Commercial Database Software เดิม ติดต่อ TN Incorporationได้ทันที

สำหรับผู้ที่สนใจใช้งาน PostgreSQL สามารถติดต่อสอบถามกับทีมงาน TN  ที่ Marketing Team 02 3439100

Email: mkt_bd@tnis.com หรือเยี่ยมชมเว็บไซต์ของ TN ได้ที่ www.tnis.com

from:https://www.techtalkthai.com/fully-managed-postgresql-services-from-tn-incorporation/

Alibaba โอเพนซอร์ส PolarDB ฐานข้อมูล PostgreSQL แบบกระจายตัว ใช้งานแอปเดิมได้ทันที

Alibaba เปิดโครงการ PolarDB ชุดแพตช์และส่วนขยายสำหรับ PostgreSQL เพื่อให้กลายเป็นระบบฐานข้อมูลแบบกระจายตัว (distributed database) สามารถขยายระบบโดยโดยเพิ่มโหนดเข้าไปในคลัสเตอร์

ตัวโครงการระบุว่า PolarDB รองรับ SQL เท่ากับ PostgreSQL เดิม รวมถึงฟีเจอร์เช่น ACID สำหรับทำ transaction ข้อมูลแต่ละตารางจะถูกแยกออกเป็น shard กระจายไปตามโหนดต่างๆ พร้อมกับสำเนาอีก 2 โหนด ทำให้คลัสเตอร์ขั้นต่ำต้องมี 3 โหนด สามารถมีโหนดขนาดเล็กเพื่อเก็บ write ahead log เท่านั้น โดยไม่ต้องรันคิวรีจริงทำให้มีขนาดเล็กกว่า

นอกจาก PoloarDB แล้ว ทาง Alibaba ยังมีฐานข้อมูลแบบกระจายตัวอีกตัวคือ OceanBase ที่พัฒนาภายในสำหรับให้บริการบนคลาวด์ของตัวเอง โดยรองรับ SQL เหมือนกับ Oracle หรือ MySQL สัปดาห์ที่ผ่านมามีข่าวว่าบริษัทจะเปิดซอร์สของ OceanBase ในวันที่ 1 มิถุนายนนี้

ที่มา – GitHub: PolarDB

No Description

from:https://www.blognone.com/node/122927

AWS เปิดตัว Babelfish for PostgreSQL ย้ายแอปใน Microsoft SQL Server มารันบน PostgreSQL

AWS เปิดโครงการโอเพนซอร์ส Babelfish for PostgreSQL ตัวแปลงโปรโตคอล ทำให้แอปที่พัฒนาเพื่อเชื่อมต่อกับ Microsoft SQL Server ผ่านทางโปรโตคอล TDS และภาษาคิวรี T-SQL สามารถเชื่อมต่อเข้ากับ PostgreSQL และทำงานต่อไปได้โดยไม่ต้องเสียค่าไลเซนส์ Microsoft SQL Server อีกต่อไป

Babelfish รับคำสั่ง SQL บางส่วนที่ SQL Server รองรับ เช่น คำสั่ง SQL ทั่วไป, cursors, catalog views, data types, triggers, stored procedures, และ function หากแอปพลิเคชั่นใช้งานเฉพาะส่วนที่ Babelfish รองรับก็จะสามารถรันแอปต่อไปได้เลย แม้เอนจินฐานข้อมูลด้านหลังจะกลายเป็น PostgreSQL ไปแล้วก็ตาม

ทาง AWS ยอมรับว่าช่วงแรก Babelfish จะไม่สมบูรณ์ เนื่องจากความความต่างเล็กๆ น้อยๆ ในเอนจินทั้งสอง และหวังว่าการเปิดโครงการเป็นโอเพนซอร์จะมีชุมชนเข้ามาช่วยกันปรับปรุงให้ดียิ่งๆ ขึ้น โดยโครงการใช้สัญญาอนุญาตแบบ Apache 2.0 และพัฒนาอย่างเปิดเผยใน GitHub ตัวซอร์สโค้ดจะเปิดออกมาภายในไตรมาส 1 ปี 2021

ที่มา – AWS Blog

No Description

from:https://www.blognone.com/node/119888

Google เปิดตัวระบบไมเกรตฐานข้อมูลภาคองค์กรเข้าสู่ Cloud SQL

Google เปิดตัวระบบ Database Migration Service หรือ DMS สำหรับไมเกรตฐานข้อมูลภาคองค์กรขึ้นสู่ Google Cloud อย่างราบรื่น ลดปัญหาต่าง ๆ รวมถึงใช้เวลาดาวน์ไทม์ที่น้อยที่สุดในขณะไมเกรตระบบ

Google DMS ใช้ระบบทำสำเนาข้อมูลจากต้นทางทั้ง MySQL, PostgreSQL และ SQL Server ไปยังระบบ Cloud SQL โดยก่อนหน้านี้ Google จะให้บริการไมเกรตฐานข้อมูลผ่านพาร์ทเนอร์ (ในขณะที่คู่แข่งอย่าง AWS และ Azure มีมานานแล้ว) แต่เนื่องจากทุกวันนี้มีผู้สนใจย้ายมาคลาวด์มากขึ้น การออก DMS เองจะช่วยอำนวยความสะดวกให้ลูกค้าที่ต้องการไมเกรตระบบ ลดเวลาและขั้นตอนที่ใช้ในการไมเกรตระบบได้มาก

ปัจจุบัน DMS ยังอยู่ในสถานะพรีวิวเท่านั้น ตอนนี้รองรับฐานข้อมูล MySQL แบบโฮสต์เอง (ทั้ง on-premise และคลาวด์) และ managed database บนคลาวด์อื่น ๆ มายัง Cloud SQL ส่วน PostgreSQL ยังเปิดเป็นสถานะพรีวิวแบบจำกัดลูกค้า ส่วน SQL Server จะตามมาภายหลัง

ที่มา – Google Cloud Blog

No Description

from:https://www.blognone.com/node/119585