Upstash เริ่มต้นการเดินทางด้วยภารกิจที่จะเป็นตัวเลือกฐานข้อมูลที่ดีที่สุดสำหรับฟังก์ชัน AWS Lambda ของคุณ ในขณะเดียวกัน เราค้นพบตัวเลือกที่ยอดเยี่ยมอีกตัวเลือกหนึ่งในการสร้างฟังก์ชันแบบไร้เซิร์ฟเวอร์ของคุณ:Cloudflare Workers เป็นผลิตภัณฑ์ที่น่าตื่นเต้นเพราะรับประกันเวลาแฝงที่ดีขึ้นทั่วโลกด้วยต้นทุนที่ต่ำกว่าและไม่มีการสตาร์ทเย็น แต่มีข้อจำกัดมากมายเมื่อเทียบกับ AWS Lambda ข้อจำกัดเพิ่มเติมทำให้รายการตัวเลือกฐานข้อมูลสั้นลง เราเห็นว่านี่เป็นโอกาสในการวางตำแหน่ง Upstash ให้เป็นโซลูชันที่ยอดเยี่ยมสำหรับคำถาม:CF Workers are stateless. Where should I keep my data then?
ความท้าทาย
การเข้าถึง
Cloudflare Workers เป็นสภาพแวดล้อมที่ปิดมากกว่า ไม่เหมือน AWS คุณไม่สามารถตั้งค่าฐานข้อมูลของคุณเองในภูมิภาคเดียวกันและเข้าถึงได้ผ่าน VPC ดังนั้น คุณต้องเข้าถึงฐานข้อมูลของคุณจากฟังก์ชัน Workers Cloudflare Workers ใช้ V8 Isolates เป็นรันไทม์ ไม่อนุญาตให้มีการเชื่อมต่อ TCP ดังนั้นฐานข้อมูลควรสามารถเข้าถึงได้ผ่าน HTTP
การจำลองแบบทั่วโลก
พนักงานมีความได้เปรียบในการนำไปใช้ได้ทุกที่ ในขณะที่ฟังก์ชันของคุณสามารถเข้าถึงได้โดยมีเวลาแฝงต่ำจากทั่วทุกมุมโลก คุณไม่ควรใช้เวลาหลายร้อยมิลลิวินาทีในการเข้าถึงฐานข้อมูลของคุณ ฐานข้อมูลของคุณควรอยู่ใกล้กับตำแหน่งที่ฟังก์ชันของคุณดำเนินการ ซึ่งทำได้โดยการจำลองข้อมูลของคุณไปยังหลายภูมิภาคและหลายทวีป
เวลาแฝงต่ำ
นักพัฒนาชอบโซลูชัน Edge Computing เนื่องจากให้เวลาแฝงต่ำในทุกที่ ฐานข้อมูลไม่ควรเป็นคอขวด ฐานข้อมูลในหน่วยความจำ เช่น Redis ให้เวลาแฝงต่ำกว่ามิลลิวินาที
การเดินทางของอัพสแตช
REST API
เราเปิดตัว Upstash ด้วยการสนับสนุน Redis API ดั้งเดิม รองรับไคลเอนต์ Redis ทั้งหมด ซึ่งเหมาะสำหรับแอปพลิเคชัน Redis รุ่นเก่า แต่ในไม่ช้า เราก็เริ่มเห็นผู้ใช้มีปัญหาในการเชื่อมต่อกับฟังก์ชันแบบไร้เซิร์ฟเวอร์ นอกจากนี้ยังไม่สามารถเข้าถึงได้จาก Cloudflare Workers ดังนั้นเราจึงเริ่มใช้งาน GraphQL API ก่อน แต่เราไม่พอใจกับ GraphQL API เนื่องจากมีค่าใช้จ่ายด้านประสิทธิภาพเนื่องจากชั้นพร็อกซี นอกจากนี้ GraphQL ไม่ใช่วิธีที่ง่ายที่สุดในการรันคำสั่ง Redis เราตัดสินใจสร้างเซิร์ฟเวอร์ REST ภายในกลไกจัดการฐานข้อมูลเพื่อลดค่าใช้จ่ายด้านประสิทธิภาพ เราคิดว่า REST เหมาะสมกว่าสำหรับ Redis เราเปิดตัว REST API และเห็นว่าเป็นที่นิยมในหมู่นักพัฒนาที่ต้องการเข้าถึง Redis จาก Cloudflare Workers และ Webassembly
การแคชขอบ
ขอบคุณ REST API ทำให้ Upstash สามารถเข้าถึงได้จาก Workers แต่เวลาแฝงนั้นไม่เหมาะ นักพัฒนาบางคนพยายามใช้การแคชของ Cloudflare เพื่อแคชการตอบสนองของ Redis แต่มันเป็นวิธีแก้ปัญหาที่ซับซ้อน Redis ควรจะเร็วมากอยู่แล้ว จึงไม่รู้สึกดีที่จะ cache Redis ที่อื่น. นั่นเป็นเหตุผลที่เราตัดสินใจสร้างการแคชขอบที่เราแคชการตอบสนอง Redis REST ที่ตำแหน่งขอบทั้งหมด เราใช้ผู้ให้บริการ CDN เพื่อแคชการตอบสนอง Redis นี่เป็นการปรับปรุงอย่างมากที่เวลาแฝงของขอบ โดยมีประสิทธิภาพเพิ่มขึ้นถึง 80%
ฐานข้อมูลทั่วโลก
การแคชขอบเป็นวิธีแก้ปัญหาที่ยอดเยี่ยมสำหรับปัญหาเวลาแฝงทั่วโลก แต่ก็มีข้อเสียบางประการสำหรับกรณีการใช้งานบางกรณี ประการแรก ไม่รองรับการทำให้แคชใช้ไม่ได้ (ล้างข้อมูล) หากเวลาหมดอายุของแคชคือ 30 วินาที จากนั้นจะมีหน้าต่าง 30 วินาทีที่ลูกค้าของคุณอาจอ่านข้อมูลเก่า กรณีการใช้งานเว็บหลายกรณีสามารถยอมรับได้ แต่ไม่ใช่ทั้งหมด ประการที่สอง การแคชขอบรองรับเฉพาะ REST API เท่านั้น ลูกค้า Redis ไม่สามารถได้รับประโยชน์จากการแคชขอบ ดังนั้นเราจึงตัดสินใจออกแบบฐานข้อมูลประเภทใหม่ซึ่งจำลองข้อมูลไปยังหลายภูมิภาค การออกแบบให้มีความพร้อมใช้งานสูงและสอดคล้องกันนั้นเป็นเรื่องที่ท้าทายมาก ปัจจุบัน Upstash มีข้อเสนอฐานข้อมูลทั่วโลกซึ่งจำลองข้อมูลของคุณไปยังภูมิภาค AWS ที่แตกต่างกัน 5 แห่ง (อเมริกาเหนือตะวันออกและตะวันตก ยุโรป เอเชีย อเมริกาใต้) ฐานข้อมูลส่วนกลางไม่ใช่แคช ดังนั้นจึงไม่มีปัญหาในการตรวจสอบความถูกต้องของแคช การเขียนจะถูกจำลองแบบทันทีไปยังแบบจำลองทั้งหมด เพื่อประสิทธิภาพและความพร้อมใช้งาน ฐานข้อมูลทั่วโลกได้รับการออกแบบให้มีความสอดคล้องกันในที่สุด
Edge Caching เทียบกับ Global Database (หรือทั้งสองอย่าง)
หากคุณต้องการแคชสำหรับโซลูชัน Edge ของคุณ การแคช Edge อาจเป็นวิธีแก้ปัญหาที่ดี แต่ถ้าคุณต้องการเขียนเพื่อทำให้แคชใช้ไม่ได้ในทันที คุณควรเลือกใช้ฐานข้อมูลส่วนกลาง นอกจากการแคชแล้ว ฐานข้อมูลส่วนกลางยังสามารถใช้เป็นที่เก็บข้อมูลส่วนกลางที่มีความพร้อมใช้งานสูง นอกจากนี้ โปรดทราบว่าการแคช Edge จะใช้ได้เฉพาะสำหรับการโทร REST เท่านั้น หากคุณกำลังใช้ไคลเอนต์ Redis ฐานข้อมูลส่วนกลางเป็นตัวเลือกเดียวที่มีเวลาแฝงต่ำที่ edge
ทั้ง Edge caching และ Global database ได้รับการออกแบบมาเพื่อลดเวลาแฝงในการอ่านให้เหลือน้อยที่สุด หากกรณีการใช้งานของคุณมีการเขียน 90% การตั้งค่าภูมิภาคเดียวจะเหมาะสมกว่า การเขียนมีเวลาแฝงเท่ากันสำหรับฐานข้อมูลทั้งแบบหลายภูมิภาคและแบบภูมิภาคเดียว แต่การตั้งค่าส่วนกลางมีราคาแพงกว่าถึง 5 เท่า
เมื่อเปิดใช้งานการแคชขอบ Upstash จะดึงคำขอแรกจากต้นทางแล้วแคชที่ขอบ หากต้นทางไม่อยู่ใกล้ๆ เวลาแฝงจะสูง หากคุณต้องการเวลาแฝงที่ดีที่สุดสำหรับทุกกรณี คุณสามารถใช้ทั้งสองอย่างได้โดยเปิดใช้งาน Edge Caching บน Global Database
ดูแอปพลิเคชันการวัดประสิทธิภาพซึ่งเปรียบเทียบเวลาแฝงของการแคชขอบและฐานข้อมูลทั่วโลก
ถัดไปคืออะไร
ต่อไปนี้คือบางสิ่งที่เราสามารถทำได้เพื่อปรับปรุง Upstash at Edge:
- เวลาแฝงต่ำสำหรับการเขียน:ปัจจุบัน ฐานข้อมูลทั่วโลกได้รับการออกแบบมาเพื่อเพิ่มประสิทธิภาพเวลาแฝงในการอ่านด้วยสถาปัตยกรรมผู้นำเดี่ยว เราคิดว่าสิ่งนี้ครอบคลุมกรณีการใช้งานส่วนใหญ่ แต่ทั้งนี้ขึ้นอยู่กับความคิดเห็นและกรณีการใช้งานใหม่ของคุณ เราสามารถทำงานบนสถาปัตยกรรมที่ให้เวลาในการเขียนและการอ่านที่มีเวลาแฝงต่ำ
- รองรับ Kafka:เรากำลังวางแผนที่จะเปิดตัว Kafka นอกเหนือจาก Redis ในอีกไม่กี่สัปดาห์ข้างหน้า Kafka จะเปิดใช้งานกรณีการใช้งานใหม่ๆ ที่ Edge เช่น การวิเคราะห์คลิกสตรีม หรือการพุชบันทึกไปยัง kafka จากฟังก์ชันไร้เซิร์ฟเวอร์/ขอบ
เรายังคงปรับปรุงและพัฒนา Upstash ตามข้อเสนอแนะของคุณ แจ้งให้เราทราบความคิดเห็นของคุณบน Twitter หรือ Discord
