บริการฐานข้อมูล D1 ของ Cloudflare กำลังเผชิญกับเสียงวิจารณ์อย่างมากจากนักพัฒนาที่นำไปใช้ในสภาพแวดล้อมการผลิตจริง โดยหลายคนรายงานว่าประสิทธิภาพยังคงไม่ดีแม้จะพยายามปรับแต่งแล้วก็ตาม ในขณะที่บทความล่าสุดได้อธิบายเทคนิคต่างๆ ในการปรับแต่งคำสั่งค้นหาฐานข้อมูล D1 แต่ความคิดเห็นจากชุมชนบ่งชี้ว่าการปรับแต่งเหล่านี้อาจไม่เพียงพอที่จะเอาชนะข้อจำกัดพื้นฐานทางสถาปัตยกรรม
ปัญหาประสิทธิภาพทั่วโลก
นักพัฒนาจากหลายภูมิภาครายงานว่าเวลาตอบสนองของ Cloudflare D1 ช้าอย่างต่อเนื่อง โดยคำสั่งค้นหาง่ายๆ มักใช้เวลา 200-400 มิลลิวินาทีหรือมากกว่านั้น ปัญหาประสิทธิภาพนี้ดูเหมือนจะเด่นชัดนอกทวีปยุโรป โดยผู้ใช้บางรายรายงานว่าเวลาตอบสนองพุ่งสูงถึง 500 มิลลิวินาทีหรือมากกว่าในอเมริกาเหนือ การกระจายตัวทั่วโลกของเครือข่าย Cloudflare ซึ่งโดยปกติเป็นจุดแข็งสำหรับผลิตภัณฑ์อื่นๆ ของพวกเขา ดูเหมือนไม่สามารถเอาชนะข้อจำกัดทางสถาปัตยกรรมของ D1 ที่ฐานข้อมูลถูกเก็บไว้ในภูมิภาคหลักเพียงที่เดียว ซึ่งต้องอาศัยการสื่อสารข้ามศูนย์ข้อมูลสำหรับการดำเนินการหลายอย่าง
ผมได้ประเมิน D1 สำหรับโปรเจกต์เมื่อไม่กี่เดือนที่แล้ว และพบว่าประสิทธิภาพทั่วโลกแย่มาก ผมไม่ทราบว่าปัญหาที่แท้จริงของสถาปัตยกรรมของพวกเขาคืออะไร แต่ถ้าคุณดูตัวเลข time-to-first-byte คุณจะเห็นว่าแม้แต่สำหรับฐานข้อมูลสาธิตของ D1 ตัวเลขนอกยุโรปก็แย่มาก และแม้แต่ในยุโรปการมี TTFB มากกว่า 200 มิลลิวินาทีก็ไม่ดีนัก
ปัญหาด้านประสิทธิภาพของ D1 ที่รายงานโดยนักพัฒนา:
- คำสั่งค้นหาข้อมูลพื้นฐานใช้เวลา 200-400 มิลลิวินาทีขึ้นไปเป็นประจำ
- เวลาตอบสนองพุ่งสูงถึง 500 มิลลิวินาทีหรือมากกว่าในอเมริกาเหนือ
- การตอบสนองต่อคำสั่งค้นหาใช้เวลาตั้งแต่ 300-3000 มิลลิวินาทีเมื่อใช้ CF Workers + D1
- เมื่อเทียบกับช่วง 50-100 มิลลิวินาทีเมื่อใช้ CF Workers + PostgreSQL แบบโฮสต์
ข้อจำกัดทางสถาปัตยกรรมที่ระบุได้:
- ฐานข้อมูลถูกเก็บไว้ในภูมิภาคหลักเพียงแห่งเดียวสำหรับการเขียนทั้งหมด
- การเริ่มต้นใหม่ (Cold starts) ต้องมีการสร้างการเชื่อมต่อ
- การพลาดแคช (Cache misses) ต้องดึงข้อมูลจากภูมิภาคหลัก
- สร้างบน SQLite ซึ่งมีข้อจำกัดในการเขียนพร้อมกัน
- ขาดการแคชผลลัพธ์แบบแอคทีฟจากเซิร์ฟเวอร์หลักไปยังขอบ (edge)
ข้อจำกัดทางสถาปัตยกรรม
นักพัฒนาหลายคนได้ระบุลักษณะเฉพาะทางสถาปัตยกรรมที่น่าจะมีส่วนทำให้เกิดปัญหาประสิทธิภาพของ D1 ซึ่งรวมถึงการที่ฐานข้อมูลถูกเก็บไว้ในภูมิภาคหลักเพียงที่เดียวที่การเขียนทั้งหมดต้องได้รับการประมวลผล การเริ่มต้นเย็น (cold starts) ที่เกี่ยวข้องกับค่าโสหุ้ยในการสร้างการเชื่อมต่อ และการพลาดแคชในสำเนาท้องถิ่นที่ต้องการการดึงข้อมูลจากภูมิภาคหลัก นอกจากนี้ D1 ยังสร้างขึ้นบน SQLite ซึ่งมีข้อจำกัดที่ทราบกันดีสำหรับการเขียนพร้อมกันในสภาพแวดล้อมแบบกระจาย การขาดการแคชผลลัพธ์แบบแอคทีฟจากภูมิภาคหลักไปยังตำแหน่งขอบยิ่งทำให้ปัญหาเหล่านี้รุนแรงขึ้น
เทคนิคการปรับแต่ง vs ปัญหาพื้นฐาน
บทความเดิมได้อธิบายเทคนิคการปรับแต่งหลายประการ รวมถึงการใช้คำขอแบบกลุ่ม การไม่รวม ID ในการอัปเดต การหลีกเลี่ยงการสแกนตารางเต็ม การแยกการเชื่อมต่อหลายตาราง และการปรับแต่งการแทรกหลายระเบียน แม้ว่าเทคนิคเหล่านี้อาจช่วยลดการอ่านแถวและปรับปรุงประสิทธิภาพการค้นหา แต่ความคิดเห็นจากชุมชนบ่งชี้ว่าพวกเขาไม่ได้แก้ไขปัญหาความล่าช้าที่สำคัญ นักพัฒนาหลายคนรายงานว่าแม้หลังจากการนำการปรับแต่งที่คล้ายกันไปใช้ เวลาตอบสนองยังคงสูงเกินไปสำหรับแอปพลิเคชันการผลิต
เทคนิคการปรับประสิทธิภาพที่แนะนำสำหรับ D1:
- ใช้การดำเนินการแบบแบตช์สำหรับการทำงานกับฐานข้อมูลหลายรายการ
- ไม่รวมฟิลด์ ID ในการดำเนินการอัปเดต
- หลีกเลี่ยงการสแกนตารางเต็มรูปแบบสำหรับคำสั่ง count
- แยกการเชื่อมต่อตารางหลายตารางเป็นคำสั่งแยกต่างหาก
- ใช้การแทรกข้อมูลหลายรายการแบบเป็นชุดสำหรับการดำเนินการจำนวนมาก
- เปิดใช้งาน Smart Placement เพื่อเพิ่มประสิทธิภาพเล็กน้อย
กรณีการใช้งานที่เหมาะสมสำหรับ D1:
- โปรเจกต์ขนาดเล็กที่มีตารางน้อยกว่า 5 ตารางและมีการใช้ JOIN น้อย
- การนับจำนวนผู้เข้าชมหน้าเว็บ
- รายชื่อสำหรับการส่งอีเมล
- การติดตามการเข้าชมหน้าเว็บไซต์
- สถานการณ์ที่มีการอ่านข้อมูลสูงแต่การเขียนข้อมูลต่ำโดยใช้การแคชอย่างเข้มข้น
กรณีการใช้งานที่จำกัด
เนื่องจากข้อจำกัดด้านประสิทธิภาพ นักพัฒนากำลังพบว่าการใช้งาน D1 ในทางปฏิบัติมีข้อจำกัดมากกว่าที่หวังไว้แต่แรก บางคนแนะนำว่ามันอาจเหมาะสมสำหรับสถานการณ์เฉพาะเท่านั้น เช่น แอปพลิเคชันที่มีการอ่านสูงแต่เขียนน้อยพร้อมการแคชที่เข้มงวด หรือโปรเจกต์ขนาดเล็กมากที่มีความซับซ้อนของความสัมพันธ์ที่จำกัด ผู้ใช้หลายคนสังเกตว่า D1 ทำงานได้ดีที่สุดสำหรับกรณีการใช้งานง่ายๆ เช่น การนับผู้เข้าชมหน้า รายชื่อผู้รับจดหมาย หรือการติดตามการเข้าชมเว็บไซต์ที่ไม่ต้องการการเชื่อมต่อที่ซับซ้อนและขนาดตารางยังคงพอประมาณ
ทางเลือกและการเปรียบเทียบ
นักพัฒนาหลายคนที่ประเมิน D1 ในที่สุดก็เลือกทางแก้ปัญหาอื่น ผู้แสดงความคิดเห็นหลายคนกล่าวถึงการได้รับประสิทธิภาพที่ดีขึ้นอย่างมากโดยใช้ Cloudflare Workers กับฐานข้อมูล PostgreSQL แบบโฮสต์ดั้งเดิม โดยรายงานการตอบสนองการค้นหาในช่วง 50-100 มิลลิวินาทีเทียบกับ 300-3000 มิลลิวินาทีของ D1 คนอื่นๆ แนะนำว่าสำหรับแอปพลิเคชันที่ต้องการฟังก์ชันฐานข้อมูลที่แท้จริง ต้นทุนเริ่มต้นที่สูงกว่าของโซลูชันฐานข้อมูลแบบดั้งเดิมอาจถูกชดเชยด้วยเวลาวิศวกรรมที่ลดลงซึ่งมิฉะนั้นจะใช้ในการจัดการกับปัญหาของ serverless และการเรียกเก็บเงินที่อาจคาดเดาไม่ได้
Smart Placement และการปรับปรุงในอนาคต
ผู้ใช้บางรายรายงานว่าประสิทธิภาพดีขึ้นเล็กน้อยหลังจากเปิดใช้งานฟีเจอร์ Smart Placement ของ Cloudflare ซึ่งพยายามปรับตำแหน่งการทำงานของ worker ให้เหมาะสมที่สุด อย่างไรก็ตาม แม้จะเปิดใช้งานฟีเจอร์นี้แล้ว หลายคนยังคงพบว่าประสิทธิภาพไม่เพียงพอสำหรับแอปพลิเคชันการผลิต นักพัฒนาบางคนแสดงความหวังว่าปัญหาประสิทธิภาพของ D1 อาจได้รับการแก้ไขในการอัปเดตในอนาคต โดยแนะนำว่าการใช้งานในปัจจุบันอาจให้ความสำคัญกับการออกสู่ตลาดอย่างรวดเร็วมากกว่าการปรับแต่งประสิทธิภาพ
โดยสรุป แม้ว่า Cloudflare D1 จะนำเสนอตัวเลือกฐานข้อมูลแบบ serverless ที่น่าสนใจซึ่งรวมเข้ากับแพลตฟอร์ม Workers ของพวกเขา แต่ข้อจำกัดด้านประสิทธิภาพในปัจจุบันดูเหมือนจะมีนัยสำคัญมากพอที่ทำให้นักพัฒนาหลายคนมองหาที่อื่นสำหรับแอปพลิเคชันการผลิต เทคนิคการปรับแต่งที่อธิบายในบทความอาจช่วยปรับปรุงประสิทธิภาพ แต่ดูเหมือนจะไม่ได้แก้ไขข้อจำกัดทางสถาปัตยกรรมพื้นฐานที่ทำให้เกิดปัญหาความล่าช้า ในตอนนี้ D1 ดูเหมาะสมที่สุดสำหรับกรณีการใช้งานเฉพาะที่ความต้องการด้านประสิทธิภาพไม่สูงนักและความซับซ้อนของฐานข้อมูลมีจำกัด