นักพัฒนาแบ็กเอนด์เข้าใจได้อย่างไรว่าการสืบค้น SQL จะทำงานได้ดีกับ "ผลิตภัณฑ์" ในบริษัทขนาดใหญ่หรือเติบโตอย่างรวดเร็ว ไม่ใช่ทุกคนที่จะสามารถเข้าถึง "ผลิตภัณฑ์" ได้ และด้วยการเข้าถึง ไม่ใช่ทุกคำขอที่จะตรวจสอบได้อย่างไม่ลำบาก และการสร้างสำเนาของฐานข้อมูลมักจะใช้เวลาหลายชั่วโมง เพื่อแก้ปัญหาเหล่านี้ เราได้สร้าง DBA เทียม - Joe มีการนำไปใช้อย่างประสบความสำเร็จในหลายบริษัทและช่วยนักพัฒนามากกว่าหนึ่งโหล
วิดีโอ:
สวัสดีทุกคน! ฉันชื่ออนาโตลี สแตนสเลอร์ ฉันทำงานให้กับบริษัท . เรามุ่งมั่นที่จะเร่งกระบวนการพัฒนาโดยขจัดความล่าช้าที่เกี่ยวข้องกับงานของ Postgres ออกจากนักพัฒนา DBA และ QA
เรามีลูกค้าที่ยอดเยี่ยม และส่วนหนึ่งของรายงานในวันนี้จะกล่าวถึงกรณีที่เราพบในขณะที่ทำงานกับพวกเขา ฉันจะพูดคุยเกี่ยวกับวิธีที่เราช่วยพวกเขาแก้ปัญหาที่ค่อนข้างร้ายแรง
เมื่อเรากำลังพัฒนาและดำเนินการย้ายข้อมูลที่มีโหลดสูงที่ซับซ้อน เราถามตัวเองว่า "การย้ายข้อมูลครั้งนี้จะเกิดขึ้นหรือไม่" เราใช้การทบทวน เราใช้ความรู้ของเพื่อนร่วมงานที่มีประสบการณ์มากกว่า ผู้เชี่ยวชาญ DBA และบอกได้ว่ามันจะบินหรือไม่
แต่บางทีมันอาจจะดีกว่าหากเราสามารถทดสอบด้วยตัวเองกับสำเนาขนาดเต็ม และวันนี้เราจะพูดถึงแนวทางการทดสอบในปัจจุบันและวิธีการทดสอบให้ดีขึ้นและด้วยเครื่องมือใดบ้าง นอกจากนี้ เราจะพูดถึงข้อดีข้อเสียของแนวทางดังกล่าว และสิ่งที่เราสามารถแก้ไขได้ที่นี่
ใครเคยทำดัชนีโดยตรงกับ prod หรือทำการเปลี่ยนแปลงอะไรบ้าง? ค่อนข้างน้อย. และสิ่งนี้นำไปสู่ข้อเท็จจริงที่ว่าข้อมูลสูญหายหรือหยุดทำงานเพื่อใคร แล้วคุณจะรู้ว่าความเจ็บปวดนี้ ขอบคุณพระเจ้าที่มีการสำรองข้อมูล
วิธีแรกคือการทดสอบในผลิตภัณฑ์ หรือเมื่อนักพัฒนานั่งอยู่บนเครื่องท้องถิ่น เขามีข้อมูลการทดสอบ มีตัวเลือกบางอย่างที่จำกัด และเราเริ่มออกผลิตภัณฑ์ และเราได้รับสถานการณ์นี้
มันเจ็บ มันแพง อาจเป็นการดีที่สุดที่จะไม่ทำ
และวิธีที่ดีที่สุดคืออะไร?
ลองมาจัดเตรียมและเลือกผลิตภัณฑ์บางส่วนที่นั่น หรืออย่างดีที่สุด ลองใช้ผลิตภัณฑ์จริง ข้อมูลทั้งหมด และหลังจากที่เราพัฒนาในพื้นที่แล้ว เราจะตรวจสอบเพิ่มเติมสำหรับการจัดเตรียม
วิธีนี้จะช่วยให้เราลบข้อผิดพลาดบางส่วนได้ เช่น ป้องกันไม่ให้อยู่ในผลิตภัณฑ์
ปัญหาคืออะไร?
- ปัญหาคือเราแบ่งปันการแสดงละครนี้กับเพื่อนร่วมงาน และบ่อยครั้งมากที่คุณทำการเปลี่ยนแปลงบางอย่าง แบม - และไม่มีข้อมูล งานก็หมดลง การจัดเตรียมเป็นหลายเทราไบต์ และคุณต้องรอเป็นเวลานานกว่าที่มันจะขึ้นอีกครั้ง และเราตัดสินใจที่จะทำให้เสร็จในวันพรุ่งนี้ เท่านี้เราก็มีการพัฒนา
- และแน่นอนว่าเรามีเพื่อนร่วมงานที่ทำงานอยู่ที่นั่นหลายทีม และต้องทำด้วยตนเอง และนี่ไม่สะดวก
และมันก็คุ้มค่าที่จะบอกว่าเรามีความพยายามเพียงครั้งเดียว ช็อตเดียว หากเราต้องการทำการเปลี่ยนแปลงบางอย่างกับฐานข้อมูล แตะข้อมูล เปลี่ยนโครงสร้าง และหากมีข้อผิดพลาดเกิดขึ้น หากเกิดข้อผิดพลาดในการย้ายข้อมูล เราจะไม่ย้อนกลับอย่างรวดเร็ว
วิธีนี้ดีกว่าวิธีก่อนหน้า แต่ก็ยังมีความเป็นไปได้สูงที่จะเกิดข้อผิดพลาดบางอย่างในกระบวนการผลิต
อะไรทำให้เราไม่สามารถมอบม้านั่งทดสอบซึ่งเป็นสำเนาขนาดเต็มให้กับนักพัฒนาซอฟต์แวร์แต่ละราย ฉันคิดว่ามันชัดเจนว่าอะไรขวางทาง
ใครมีฐานข้อมูลขนาดใหญ่กว่าเทราไบต์ เกินครึ่งห้อง.
และเป็นที่ชัดเจนว่าการเก็บเครื่องจักรสำหรับนักพัฒนาแต่ละราย เมื่อมีการผลิตจำนวนมากนั้นมีราคาแพงมาก และนอกจากนี้ยังใช้เวลานานอีกด้วย
เรามีลูกค้าที่ตระหนักว่าการทดสอบการเปลี่ยนแปลงทั้งหมดบนสำเนาขนาดเต็มเป็นสิ่งสำคัญมาก แต่ฐานข้อมูลของพวกเขามีขนาดน้อยกว่าเทราไบต์ และไม่มีทรัพยากรที่จะเก็บม้านั่งทดสอบสำหรับนักพัฒนาแต่ละราย ดังนั้นพวกเขาจึงต้องดาวน์โหลดการถ่ายโอนข้อมูลลงในเครื่องและทดสอบด้วยวิธีนี้ ต้องใช้เวลามาก
แม้ว่าคุณจะทำภายในโครงสร้างพื้นฐาน การดาวน์โหลดข้อมูลหนึ่งเทราไบต์ต่อชั่วโมงก็ดีมากแล้ว แต่พวกเขาใช้โลจิคัลดัมพ์ พวกเขาดาวน์โหลดในเครื่องจากระบบคลาวด์ สำหรับพวกเขา ความเร็วประมาณ 200 กิกะไบต์ต่อชั่วโมง และยังต้องใช้เวลาในการเปลี่ยนกลับจากการถ่ายโอนข้อมูลแบบลอจิคัล สะสมดัชนี ฯลฯ
แต่พวกเขาใช้วิธีนี้เพราะช่วยให้ผลิตภัณฑ์มีความน่าเชื่อถือ
เราทำอะไรที่นี่ได้บ้าง? มาสร้างม้านั่งทดสอบราคาถูกและมอบม้านั่งทดสอบของตนเองให้กับนักพัฒนาทุกคนกันเถอะ
และนี่เป็นไปได้
และด้วยแนวทางนี้ เมื่อเราสร้าง thin clones สำหรับนักพัฒนาแต่ละราย เราสามารถแชร์บนเครื่องเดียวได้ ตัวอย่างเช่น หากคุณมีฐานข้อมูลขนาด 10TB และต้องการมอบให้กับนักพัฒนา 10 คน คุณไม่จำเป็นต้องมีฐานข้อมูลขนาด XNUMX x XNUMXTB คุณต้องการเพียงเครื่องเดียวในการทำสำเนาแบบบางสำหรับนักพัฒนาแต่ละรายโดยใช้เครื่องเดียว ฉันจะบอกคุณว่ามันทำงานอย่างไรในภายหลัง
ตัวอย่างจริง:
-
DB - 4,5 เทราไบต์
-
เราสามารถรับสำเนาอิสระได้ใน 30 วินาที
คุณไม่ต้องรอแท่นทดสอบและขึ้นอยู่กับว่ามันใหญ่แค่ไหน คุณจะได้รับในไม่กี่วินาที มันจะเป็นสภาพแวดล้อมที่แยกจากกันอย่างสมบูรณ์ แต่จะใช้ข้อมูลร่วมกัน
นี้เป็นสิ่งที่ดี เรากำลังพูดถึงเวทมนตร์และจักรวาลคู่ขนาน
ในกรณีของเรา การทำงานนี้ใช้ระบบ OpenZFS
OpenZFS เป็นระบบไฟล์แบบ copy-on-write ที่รองรับสแนปช็อตและโคลนแบบสำเร็จรูป มีความน่าเชื่อถือและปรับขนาดได้ เธอจัดการได้ง่ายมาก สามารถใช้งานได้จริงในสองทีม
มีตัวเลือกอื่น ๆ :
-
แอลวีเอ็ม,
-
ที่เก็บข้อมูล (เช่น Pure Storage)
Database Lab ที่ฉันกำลังพูดถึงเป็นแบบโมดูลาร์ สามารถดำเนินการได้โดยใช้ตัวเลือกเหล่านี้ แต่สำหรับตอนนี้ เราได้มุ่งเน้นไปที่ OpenZFS เนื่องจากมีปัญหาเฉพาะกับ LVM
มันทำงานอย่างไร? แทนที่จะเขียนทับข้อมูลทุกครั้งที่เราเปลี่ยนแปลง เราจะบันทึกโดยทำเครื่องหมายว่าข้อมูลใหม่นี้มาจากช่วงเวลาใหม่ สแน็ปช็อตใหม่
และในอนาคต เมื่อเราต้องการย้อนกลับหรือต้องการสร้างการโคลนใหม่จากเวอร์ชันเก่าบางเวอร์ชัน เราก็แค่พูดว่า: "โอเค ให้บล็อกข้อมูลเหล่านี้ที่มีเครื่องหมายแบบนี้"
และผู้ใช้รายนี้จะทำงานกับชุดข้อมูลดังกล่าว เขาจะค่อยๆเปลี่ยนพวกเขาสร้างภาพรวมของเขาเอง
และเราจะแยกสาขา นักพัฒนาแต่ละคนในกรณีของเราจะมีโอกาสที่จะมีโคลนของตัวเองซึ่งเขาแก้ไข และข้อมูลที่แบ่งปันจะถูกแบ่งปันระหว่างทุกคน
ในการปรับใช้ระบบดังกล่าวที่บ้าน คุณต้องแก้ปัญหาสองประการ:
-
ประการแรกคือแหล่งที่มาของข้อมูลที่คุณจะนำมาจากที่ใด คุณสามารถตั้งค่าการจำลองแบบด้วยการผลิต ฉันหวังว่าคุณสามารถใช้ข้อมูลสำรองที่คุณกำหนดค่าไว้ได้แล้ว WAL-E, WAL-G หรือบาร์เทนเดอร์ และแม้ว่าคุณจะใช้โซลูชันระบบคลาวด์บางประเภท เช่น RDS หรือ Cloud SQL คุณก็สามารถใช้ดัมพ์แบบลอจิคัลได้ แต่เรายังคงแนะนำให้คุณใช้การสำรองข้อมูล เพราะด้วยวิธีนี้ คุณจะยังคงรักษาโครงสร้างทางกายภาพของไฟล์ไว้ได้ ซึ่งจะช่วยให้คุณเข้าใกล้เมตริกที่คุณจะเห็นในการผลิตมากยิ่งขึ้น เพื่อตรวจจับปัญหาที่มีอยู่
-
ประการที่สองคือที่ที่คุณต้องการโฮสต์ฐานข้อมูลแล็บ อาจเป็นคลาวด์ อาจเป็นในองค์กรก็ได้ สิ่งสำคัญคือต้องพูดที่นี่ว่า ZFS รองรับการบีบอัดข้อมูล และทำได้ค่อนข้างดี
ลองนึกภาพว่าสำหรับแต่ละโคลนดังกล่าว ขึ้นอยู่กับการดำเนินการที่เราทำกับฐาน ผู้พัฒนาบางประเภทจะเติบโตขึ้น สำหรับสิ่งนี้ dev ก็ต้องการพื้นที่เช่นกัน แต่เนื่องจากเราใช้ฐาน 4,5 เทราไบต์ ZFS จะบีบอัดเป็น 3,5 เทราไบต์ สิ่งนี้อาจแตกต่างกันไปขึ้นอยู่กับการตั้งค่า และเรายังมีที่ว่างสำหรับ dev
ระบบดังกล่าวสามารถใช้กับกรณีต่างๆ
-
เหล่านี้คือนักพัฒนา, DBA สำหรับการตรวจสอบแบบสอบถาม, สำหรับการเพิ่มประสิทธิภาพ
-
สามารถใช้ในการทดสอบ QA เพื่อทดสอบการย้ายข้อมูลเฉพาะก่อนที่เราจะเปิดตัวผลิตภัณฑ์ และเรายังสามารถยกระดับสภาพแวดล้อมพิเศษสำหรับ QA ด้วยข้อมูลจริง ซึ่งพวกเขาสามารถทดสอบการทำงานใหม่ๆ และจะใช้เวลาไม่กี่วินาทีแทนที่จะรอนานหลายชั่วโมง และอาจเป็นวันในบางกรณีที่ไม่ได้ใช้สำเนาบาง
-
และอีกกรณีหนึ่ง หากบริษัทไม่ได้ตั้งค่าระบบการวิเคราะห์ เราสามารถแยกการโคลนนิ่งของฐานผลิตภัณฑ์และมอบให้กับการค้นหาแบบยาวหรือดัชนีพิเศษที่สามารถใช้ในการวิเคราะห์ได้
ด้วยวิธีนี้:
-
มีโอกาสเกิดข้อผิดพลาดต่ำใน "ผลิตภัณฑ์" เนื่องจากเราได้ทดสอบการเปลี่ยนแปลงทั้งหมดกับข้อมูลขนาดเต็ม
-
เรามีวัฒนธรรมของการทดสอบ เพราะตอนนี้คุณไม่ต้องรอเป็นชั่วโมงเพื่อยืนหยัดด้วยตัวเอง
-
และไม่มีอุปสรรค ไม่ต้องรอระหว่างการทดสอบ คุณสามารถไปตรวจสอบได้จริง และจะดีกว่านี้เมื่อเราเร่งการพัฒนา
-
จะมีการรีแฟคเตอร์น้อยลง ข้อผิดพลาดน้อยลงจะสิ้นสุดลงในผลิตภัณฑ์ เราจะปรับโครงสร้างให้น้อยลงในภายหลัง
-
เราสามารถย้อนกลับการเปลี่ยนแปลงที่เปลี่ยนแปลงไม่ได้ นี่ไม่ใช่แนวทางมาตรฐาน
- สิ่งนี้มีประโยชน์เพราะเราแบ่งปันทรัพยากรของม้านั่งทดสอบ
ดีอยู่แล้ว แต่จะเร่งอะไรอีก
ด้วยระบบดังกล่าว เราสามารถลดเกณฑ์ในการเข้าสู่การทดสอบดังกล่าวได้อย่างมาก
ขณะนี้เกิดวงจรอุบาทว์ขึ้น เมื่อนักพัฒนาจะต้องกลายเป็นผู้เชี่ยวชาญเพื่อให้เข้าถึงข้อมูลขนาดจริงได้ เขาต้องได้รับความไว้วางใจในการเข้าถึงดังกล่าว
แต่จะเติบโตได้อย่างไรหากไม่มี จะเกิดอะไรขึ้นถ้าคุณมีข้อมูลการทดสอบชุดเล็ก ๆ สำหรับคุณ แล้วคุณจะไม่ได้รับประสบการณ์จริง
จะออกจากวงกลมนี้ได้อย่างไร? ในฐานะอินเทอร์เฟซแรก สะดวกสำหรับนักพัฒนาทุกระดับ เราเลือกบอท Slack แต่จะเป็นอินเทอร์เฟซอื่นก็ได้
มันให้คุณทำอะไรได้บ้าง? คุณสามารถใช้แบบสอบถามเฉพาะและส่งไปยังช่องทางพิเศษสำหรับฐานข้อมูล เราจะปรับใช้ thin clone โดยอัตโนมัติในไม่กี่วินาที ลองเรียกใช้คำขอนี้ เรารวบรวมเมตริกและคำแนะนำ มาแสดงให้เห็นภาพกัน จากนั้นโคลนนี้จะยังคงอยู่เพื่อให้สามารถปรับแต่งแบบสอบถามนี้เพิ่มดัชนี ฯลฯ
นอกจากนี้ Slack ยังเปิดโอกาสให้เราทำงานร่วมกันนอกกรอบ เนื่องจากนี่เป็นเพียงช่องทาง คุณสามารถเริ่มพูดคุยเกี่ยวกับคำขอนี้ได้โดยตรงในเธรดสำหรับคำขอดังกล่าว ping เพื่อนร่วมงานของคุณ DBA ที่อยู่ในบริษัท
แต่แน่นอนว่ามีปัญหา เนื่องจากนี่คือโลกแห่งความจริง และเรากำลังใช้เซิร์ฟเวอร์ที่โฮสต์การโคลนจำนวนมากพร้อมกัน เราจึงต้องบีบอัดจำนวนหน่วยความจำและพลังงาน CPU ที่มีให้กับการโคลน
แต่เพื่อให้การทดสอบเหล่านี้เป็นไปได้ คุณต้องแก้ปัญหานี้ด้วยวิธีใดวิธีหนึ่ง
เป็นที่ชัดเจนว่าจุดสำคัญคือข้อมูลเดียวกัน แต่เรามีอยู่แล้ว และเราต้องการให้ได้การกำหนดค่าเดียวกัน และเราสามารถให้การกำหนดค่าที่เหมือนกันเกือบทั้งหมดได้
คงจะดีหากมีฮาร์ดแวร์แบบเดียวกับที่ใช้งานจริง แต่อาจแตกต่างออกไป
จำวิธีการทำงานของ Postgres กับหน่วยความจำ เรามีสองแคช หนึ่งรายการจากระบบไฟล์และหนึ่ง Postgres ดั้งเดิม เช่น แคชบัฟเฟอร์ที่ใช้ร่วมกัน
สิ่งสำคัญคือต้องสังเกตว่า Shared Buffer Cache ได้รับการจัดสรรเมื่อ Postgres เริ่มทำงาน ขึ้นอยู่กับขนาดที่คุณระบุในการกำหนดค่า
และแคชที่สองใช้พื้นที่ที่มีอยู่ทั้งหมด
และเมื่อเราสร้างโคลนหลายตัวในเครื่องเดียว ปรากฎว่าเราค่อยๆ เติมหน่วยความจำ และในทางที่ดี แคชบัฟเฟอร์ที่ใช้ร่วมกันคือ 25% ของหน่วยความจำทั้งหมดที่มีอยู่ในเครื่อง
และปรากฎว่าหากเราไม่เปลี่ยนพารามิเตอร์นี้ เราจะสามารถเรียกใช้ได้เพียง 4 อินสแตนซ์ในเครื่องเดียว นั่นคือ 4 ของบางโคลนดังกล่าวทั้งหมด และแน่นอนว่าไม่ดีเพราะเราต้องการมีมากกว่านี้
แต่ในทางกลับกัน Buffer Cache ใช้เพื่อดำเนินการค้นหาดัชนี นั่นคือแผนจะขึ้นอยู่กับขนาดแคชของเรา และถ้าเราแค่ใช้พารามิเตอร์นี้และลดลง แผนของเราก็สามารถเปลี่ยนแปลงได้มากมาย
ตัวอย่างเช่น หากเรามีแคชขนาดใหญ่ใน prod ดังนั้น Postgres จะใช้ดัชนีแทน และถ้าไม่เช่นนั้นก็จะมี SeqScan แล้วจะมีประโยชน์อะไรถ้าแผนการของเราไม่ตรงกัน?
แต่ที่นี่เราได้ข้อสรุปว่าแท้จริงแล้วแผนใน Postgres ไม่ได้ขึ้นอยู่กับขนาดเฉพาะที่ระบุใน Shared Buffer ในแผน แต่ขึ้นอยู่กับ
Effective_cache_size คือจำนวนแคชโดยประมาณที่เราสามารถใช้ได้ เช่น ผลรวมของแคชบัฟเฟอร์และแคชของระบบไฟล์ สิ่งนี้ถูกกำหนดโดยการกำหนดค่า และหน่วยความจำนี้ไม่ได้รับการจัดสรร
และเนื่องจากพารามิเตอร์นี้ เราสามารถหลอก Postgres ได้ โดยบอกว่าเรามีข้อมูลจำนวนมาก แม้ว่าเราจะไม่มีข้อมูลนี้ก็ตาม ดังนั้นแผนจะสอดคล้องกับการผลิตอย่างสมบูรณ์
แต่สิ่งนี้อาจส่งผลต่อเวลา และเราปรับข้อความค้นหาให้เหมาะสมตามเวลา แต่สิ่งสำคัญคือเวลาขึ้นอยู่กับหลายปัจจัย:
-
ขึ้นอยู่กับโหลดที่อยู่ในผลิตภัณฑ์
-
ขึ้นอยู่กับลักษณะของเครื่องเอง
และนี่คือพารามิเตอร์ทางอ้อม แต่อันที่จริงแล้ว เราสามารถเพิ่มประสิทธิภาพได้ตรงตามจำนวนข้อมูลที่แบบสอบถามนี้จะอ่านเพื่อให้ได้ผลลัพธ์
และถ้าคุณต้องการให้เวลาใกล้เคียงกับสิ่งที่เราจะเห็นในผลิตภัณฑ์ เราจำเป็นต้องใช้ฮาร์ดแวร์ที่คล้ายกันมากที่สุด และอาจมากกว่านั้นเพื่อให้โคลนทั้งหมดเข้ากันได้ แต่นี่เป็นการประนีประนอม กล่าวคือ คุณจะได้รับแผนเดียวกัน คุณจะเห็นจำนวนข้อมูลที่จะอ่านในแบบสอบถามหนึ่งๆ และคุณจะสามารถสรุปได้ว่าแบบสอบถามนี้ดี (หรือย้ายข้อมูล) หรือไม่ดี ยังคงต้องได้รับการปรับให้เหมาะสม .
มาดูกันว่า Joe ได้รับการปรับแต่งเป็นพิเศษอย่างไร
มารับคำขอจากระบบจริง ในกรณีนี้ ฐานข้อมูลคือ 1 เทราไบต์ และเราต้องการนับจำนวนโพสต์ใหม่ที่มีมากกว่า 10 ไลค์
เรากำลังเขียนข้อความถึงช่อง มีการปรับใช้ตัวโคลนสำหรับเราแล้ว และเราจะเห็นว่าคำขอดังกล่าวจะเสร็จสิ้นภายใน 2,5 นาที นี่เป็นสิ่งแรกที่เราสังเกตเห็น
B Joe จะแสดงคำแนะนำอัตโนมัติตามแผนและตัวชี้วัด
เราจะเห็นว่าคิวรีประมวลผลข้อมูลมากเกินไปเพื่อให้ได้จำนวนแถวที่ค่อนข้างน้อย และจำเป็นต้องใช้ดัชนีเฉพาะบางประเภท เนื่องจากเราสังเกตว่ามีแถวที่กรองมากเกินไปในแบบสอบถาม
มาดูกันดีกว่าว่าเกิดอะไรขึ้น เราเห็นว่าเราได้อ่านข้อมูลเกือบหนึ่งกิกะไบต์ครึ่งจากไฟล์แคชหรือแม้กระทั่งจากดิสก์ และนี่ไม่ดีเพราะเรามีเพียง 142 บรรทัด
และดูเหมือนว่าเรามีการสแกนดัชนีที่นี่และน่าจะได้ผลอย่างรวดเร็ว แต่เนื่องจากเรากรองบรรทัดมากเกินไป (เราต้องนับ) คำขอจึงทำงานช้าลง
และสิ่งนี้เกิดขึ้นในแผนเนื่องจากเงื่อนไขในแบบสอบถามและเงื่อนไขในดัชนีไม่ตรงกันบางส่วน
มาลองทำให้ดัชนีมีความแม่นยำมากขึ้นและดูว่าการดำเนินการค้นหาเปลี่ยนไปอย่างไรหลังจากนั้น
การสร้างดัชนีใช้เวลาค่อนข้างนาน แต่ตอนนี้เราตรวจสอบข้อความค้นหาแล้วพบว่าเวลาแทนที่จะเป็น 2,5 นาทีมีเพียง 156 มิลลิวินาที ซึ่งดีพอ และเราอ่านข้อมูลเพียง 6 เมกะไบต์
และตอนนี้เราใช้การสแกนดัชนีเท่านั้น
อีกเรื่องที่สำคัญคือเราต้องการนำเสนอแผนในรูปแบบที่เข้าใจมากขึ้น เราได้ใช้การแสดงภาพโดยใช้กราฟเปลวไฟ
นี่เป็นคำขอที่แตกต่าง รุนแรงมากขึ้น และเราสร้าง Flame Graphs ตามพารามิเตอร์สองตัว: นี่คือจำนวนข้อมูลที่โหนดหนึ่งๆ นับในแผนและเวลา เช่น เวลาดำเนินการของโหนด
ที่นี่เราสามารถเปรียบเทียบโหนดเฉพาะกับแต่ละโหนดได้ และจะชัดเจนว่าอันไหนใช้เวลามากหรือน้อย ซึ่งมักจะทำได้ยากในวิธีการเรนเดอร์อื่นๆ
แน่นอนว่าทุกคนรู้จัก expand.depesz.com คุณลักษณะที่ดีของการสร้างภาพนี้คือเราบันทึกแผนข้อความและใส่พารามิเตอร์พื้นฐานบางอย่างลงในตารางเพื่อให้เราสามารถเรียงลำดับได้
และนักพัฒนาซอฟต์แวร์ที่ยังไม่ได้เจาะลึกในหัวข้อนี้ก็ให้ใช้explain.depesz.com เพราะจะง่ายกว่าสำหรับพวกเขาที่จะทราบว่าเมตริกใดสำคัญและไม่สำคัญ
มีแนวทางใหม่ในการแสดงภาพ - นี่คือ expand.dalibo.com พวกเขาสร้างภาพต้นไม้ แต่มันยากมากที่จะเปรียบเทียบโหนดต่างๆ ที่นี่คุณสามารถเข้าใจโครงสร้างได้ดี อย่างไรก็ตาม หากมีคำขอจำนวนมาก คุณจะต้องเลื่อนไปมา แต่ก็มีตัวเลือกเช่นกัน
การทำงานร่วมกัน
และอย่างที่ฉันพูด Slack เปิดโอกาสให้เราได้ทำงานร่วมกัน ตัวอย่างเช่น หากเราพบคำถามที่ซับซ้อนซึ่งไม่ชัดเจนว่าจะเพิ่มประสิทธิภาพอย่างไร เราสามารถชี้แจงปัญหานี้กับเพื่อนร่วมงานของเราในเธรดใน Slack
สำหรับเราแล้ว ดูเหมือนว่าการทดสอบกับข้อมูลขนาดเต็มเป็นสิ่งสำคัญ ในการทำเช่นนี้ เราสร้างเครื่องมือ Update Database Lab ซึ่งมีให้ใช้งานในโอเพ่นซอร์ส คุณสามารถใช้บอท Joe ได้เช่นกัน คุณสามารถนำไปใช้ได้ทันทีและนำไปใช้ในสถานที่ของคุณ มีคำแนะนำทั้งหมดอยู่ที่นั่น
สิ่งสำคัญคือต้องทราบว่าโซลูชันนั้นไม่ได้ปฏิวัติเพราะมี Delphix แต่เป็นโซลูชันระดับองค์กร ปิดมิดชิดก็แพงมาก เราเชี่ยวชาญด้าน Postgres โดยเฉพาะ ทั้งหมดนี้เป็นผลิตภัณฑ์โอเพ่นซอร์ส เข้าร่วมกับเรา!
นี่คือจุดสิ้นสุดของฉัน ขอบคุณ!
คำถาม
สวัสดี! ขอบคุณสำหรับรายงาน! น่าสนใจมาก โดยเฉพาะอย่างยิ่งสำหรับฉัน เพราะฉันแก้ไขปัญหาเดียวกันนี้มาได้ระยะหนึ่งแล้ว ดังนั้นฉันมีคำถามจำนวนหนึ่ง หวังว่าฉันจะได้รับอย่างน้อยส่วนหนึ่ง
ฉันสงสัยว่าคุณคำนวณสถานที่สำหรับสภาพแวดล้อมนี้ได้อย่างไร เทคโนโลยีนี้หมายความว่าภายใต้สถานการณ์บางอย่าง โคลนของคุณสามารถเติบโตได้จนถึงขนาดสูงสุด พูดอย่างคร่าว ๆ ถ้าคุณมีฐานข้อมูล 10 เทราไบต์และ 10 โคลน จะเป็นการง่ายที่จะจำลองสถานการณ์ที่แต่ละโคลนมีน้ำหนัก XNUMX ข้อมูลที่ไม่ซ้ำกัน คุณคำนวณสถานที่นี้ได้อย่างไร ซึ่งก็คือเดลต้าที่คุณพูดถึง ซึ่งร่างโคลนเหล่านี้จะอาศัยอยู่
คำถามที่ดี. สิ่งสำคัญคือต้องติดตามการโคลนเฉพาะที่นี่ และถ้าการโคลนมีการเปลี่ยนแปลงที่ใหญ่เกินไป มันเริ่มใหญ่ขึ้น จากนั้นเราสามารถออกคำเตือนแก่ผู้ใช้เกี่ยวกับสิ่งนี้ก่อน หรือหยุดการโคลนนี้ทันทีเพื่อไม่ให้เกิดสถานการณ์ที่ล้มเหลว
ใช่ ฉันมีคำถามซ้อนอยู่ นั่นคือ คุณจะมั่นใจได้อย่างไรว่าวงจรชีวิตของโมดูลเหล่านี้ เรามีปัญหานี้และเรื่องราวที่แยกจากกันทั้งหมด สิ่งนี้เกิดขึ้นได้อย่างไร?
มี ttl บางส่วนสำหรับแต่ละโคลน โดยทั่วไปเรามี ttl คงที่
แล้วถ้าไม่ใช่ความลับล่ะ?
1 ชั่วโมง เช่น ว่าง - 1 ชั่วโมง ถ้าไม่ใช้เราก็ทุบทิ้ง แต่ก็ไม่แปลกใจที่นี่เนื่องจากเราสามารถยกร่างโคลนขึ้นได้ภายในไม่กี่วินาที และถ้าคุณต้องการอีกครั้งโปรด
ฉันยังสนใจในการเลือกใช้เทคโนโลยีด้วย ตัวอย่างเช่น เราใช้หลายวิธีควบคู่กันไปด้วยเหตุผลใดเหตุผลหนึ่ง ทำไมต้อง ZFS? ทำไมคุณไม่ใช้ LVM คุณบอกว่ามีปัญหากับ LVM มีปัญหาอะไรบ้าง? ในความคิดของฉัน ตัวเลือกที่เหมาะสมที่สุดคือพื้นที่เก็บข้อมูลในแง่ของประสิทธิภาพ
ปัญหาหลักของ ZFS คืออะไร ความจริงที่ว่าคุณต้องทำงานบนโฮสต์เดียวกัน กล่าวคือ อินสแตนซ์ทั้งหมดจะอยู่ในระบบปฏิบัติการเดียวกัน และในกรณีของการจัดเก็บ คุณสามารถเชื่อมต่ออุปกรณ์ต่างๆ และคอขวดเป็นเพียงบล็อกที่อยู่ในระบบจัดเก็บข้อมูล และคำถามเกี่ยวกับการเลือกใช้เทคโนโลยีนั้นน่าสนใจ ทำไมไม่ LVM?
โดยเฉพาะอย่างยิ่ง เราสามารถพูดคุยเกี่ยวกับ LVM ได้ที่งานมีตติ้ง เกี่ยวกับการจัดเก็บ - มันแพง เราสามารถนำระบบ ZFS ไปใช้ได้ทุกที่ คุณสามารถปรับใช้กับเครื่องของคุณ คุณสามารถดาวน์โหลดที่เก็บและปรับใช้ได้ มีการติดตั้ง ZFS เกือบทุกที่หากเรากำลังพูดถึง Linux นั่นคือเราได้วิธีแก้ปัญหาที่ยืดหยุ่นมาก และ ZFS เองก็ให้อะไรมากมายนอกกรอบ คุณสามารถอัปโหลดข้อมูลได้มากเท่าที่คุณต้องการ เชื่อมต่อดิสก์จำนวนมาก มีสแนปช็อต และอย่างที่ฉันพูด มันง่ายที่จะจัดการ นั่นคือมันดูน่าใช้มาก เขาถูกทดสอบ เขาอายุหลายปีแล้ว เขามีชุมชนขนาดใหญ่ที่กำลังเติบโต ZFS เป็นโซลูชันที่น่าเชื่อถือมาก
Nikolai Samokhvalov: ฉันขอแสดงความคิดเห็นเพิ่มเติมได้ไหม ฉันชื่อ Nikolay เราทำงานร่วมกับ Anatoly ฉันยอมรับว่าที่เก็บข้อมูลนั้นยอดเยี่ยม และลูกค้าบางรายของเรามี Pure Storage เป็นต้น
Anatoly ตั้งข้อสังเกตอย่างถูกต้องว่าเรามุ่งเน้นไปที่โมดูลาร์ และในอนาคต คุณสามารถใช้อินเทอร์เฟซเดียว - ถ่ายภาพ สร้างโคลน ทำลายโคลน มันง่ายทั้งหมด และที่เก็บของก็เจ๋งถ้าเป็นเช่นนั้น
แต่ ZFS มีให้ทุกคน DelPhix เพียงพอแล้ว พวกเขามีลูกค้า 300 ราย ในจำนวนนี้ บริษัทฟอร์จูน 100 มีลูกค้า 50 ราย เช่น พวกเขามุ่งเป้าไปที่ NASA เป็นต้น ถึงเวลาแล้วที่ทุกคนจะต้องได้รับเทคโนโลยีนี้ และนั่นคือเหตุผลที่เรามีคอร์โอเพ่นซอร์ส เรามีส่วนต่อประสานที่ไม่ใช่โอเพ่นซอร์ส นี่คือแพลตฟอร์มที่เราจะแสดง แต่เราต้องการให้ทุกคนเข้าถึงได้ เราต้องการปฏิวัติเพื่อให้ผู้ทดสอบทุกคนหยุดคาดเดาเกี่ยวกับแล็ปท็อป เราต้องเขียน SELECT และดูทันทีว่ามันช้า หยุดรอให้ DBA บอกคุณเกี่ยวกับเรื่องนี้ นี่คือเป้าหมายหลัก และฉันคิดว่าเราทุกคนจะมาถึงสิ่งนี้ และเราทำสิ่งนี้ให้ทุกคนมี ดังนั้น ZFS เนื่องจากจะมีให้บริการทุกที่ ขอบคุณชุมชนสำหรับการแก้ปัญหาและการมีใบอนุญาตโอเพ่นซอร์ส ฯลฯ*
ทักทาย! ขอบคุณสำหรับรายงาน! ฉันชื่อแม็กซิม เราได้จัดการกับปัญหาเดียวกัน พวกเขาตัดสินใจด้วยตัวเอง คุณจะแบ่งปันทรัพยากรระหว่างโคลนเหล่านี้ได้อย่างไร? โคลนแต่ละตัวสามารถทำสิ่งต่าง ๆ ของตัวเองในเวลาใดก็ได้: คนหนึ่งทดสอบสิ่งหนึ่ง อีกสิ่งหนึ่ง อีกคนสร้างดัชนี บางคนมีงานหนัก และถ้าคุณยังสามารถแบ่งตาม CPU แล้วแบ่งตาม IO คุณจะแบ่งอย่างไร นี่เป็นคำถามแรก
และคำถามที่สองเกี่ยวกับความแตกต่างของอัฒจันทร์ สมมติว่าฉันมี ZFS ที่นี่และทุกอย่างก็ยอดเยี่ยม แต่ไคลเอนต์ใน prod ไม่มี ZFS แต่มี ext4 เป็นต้น ในกรณีนี้ได้อย่างไร?
คำถามเป็นสิ่งที่ดีมาก ฉันได้กล่าวถึงปัญหานี้เล็กน้อยเนื่องจากเราใช้ทรัพยากรร่วมกัน และทางออกคือสิ่งนี้ ลองนึกภาพว่าคุณกำลังทดสอบการแสดงละคร คุณยังสามารถมีสถานการณ์ดังกล่าวในเวลาเดียวกันที่มีคนให้ภาระหนึ่งคน และด้วยเหตุนี้ คุณจึงเห็นเมตริกที่เข้าใจยาก แม้แต่ปัญหาเดียวกันก็สามารถเกิดขึ้นกับผลิตภัณฑ์ได้ เมื่อคุณต้องการตรวจสอบคำขอบางอย่างและคุณเห็นว่ามีปัญหาบางอย่าง - มันทำงานช้า อันที่จริงแล้วปัญหาไม่ได้อยู่ในคำขอ แต่ในความเป็นจริงแล้วมีการโหลดแบบขนานบางประเภท
ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องเน้นว่าแผนจะเป็นอย่างไร ขั้นตอนใดที่เราจะดำเนินการในแผน และจำนวนข้อมูลที่เราจะรวบรวมสำหรับสิ่งนี้ ตัวอย่างเช่นความจริงที่ว่าดิสก์ของเราจะโหลดด้วยบางสิ่งมันจะส่งผลต่อเวลาโดยเฉพาะ แต่เราสามารถประเมินได้ว่าคำขอนี้ถูกโหลดมากน้อยเพียงใดด้วยจำนวนข้อมูล ไม่สำคัญว่าในเวลาเดียวกันจะมีการประหารชีวิต
ฉันมีสองคำถาม นี่เป็นสิ่งที่เจ๋งมาก เคยมีกรณีที่ข้อมูลการผลิตมีความสำคัญ เช่น หมายเลขบัตรเครดิตหรือไม่? มีของพร้อมแล้วหรือแยกงาน? และคำถามที่สอง - มีสิ่งนี้สำหรับ MySQL หรือไม่
เกี่ยวกับข้อมูล เราจะทำเรื่องยุ่งๆ จนกว่าเราจะทำ แต่ถ้าคุณปรับใช้ Joe ทุกประการ หากคุณไม่ให้สิทธิ์เข้าถึงแก่นักพัฒนา ก็จะไม่สามารถเข้าถึงข้อมูลได้ ทำไม เนื่องจากโจไม่แสดงข้อมูล แสดงเฉพาะเมตริก แผน และแค่นั้น สิ่งนี้ทำขึ้นโดยตั้งใจเพราะนี่คือหนึ่งในข้อกำหนดของลูกค้าของเรา พวกเขาต้องการเพิ่มประสิทธิภาพโดยไม่ให้ทุกคนเข้าถึงได้
เกี่ยวกับ MySQL ระบบนี้สามารถใช้สำหรับทุกสิ่งที่เก็บสถานะบนดิสก์ และเนื่องจากเรากำลังทำ Postgres เราจึงทำระบบอัตโนมัติทั้งหมดสำหรับ Postgres ก่อน เราต้องการรับข้อมูลจากการสำรองข้อมูลโดยอัตโนมัติ เรากำลังกำหนดค่า Postgres อย่างถูกต้อง เรารู้จักวางแผนให้ตรงกัน ฯลฯ
แต่เนื่องจากระบบสามารถขยายได้ จึงสามารถใช้กับ MySQL ได้เช่นกัน และมีตัวอย่างดังกล่าว ยานเดกซ์มีสิ่งที่คล้ายกัน แต่ไม่ได้เผยแพร่ที่ใดก็ได้ พวกเขาใช้มันใน Yandex.Metrica และมีเพียงเรื่องราวเกี่ยวกับ MySQL แต่เทคโนโลยีเหมือนกัน ZFS
ขอบคุณสำหรับรายงาน! ฉันยังมีคำถามสองสามข้อ คุณกล่าวว่าสามารถใช้การโคลนสำหรับการวิเคราะห์ได้ เช่น เพื่อสร้างดัชนีเพิ่มเติมที่นั่น คุณช่วยบอกเพิ่มเติมเกี่ยวกับวิธีการทำงานได้ไหม
และฉันจะถามคำถามที่สองทันทีเกี่ยวกับความคล้ายคลึงของอัฒจันทร์ ความคล้ายคลึงของแผน แผนยังขึ้นอยู่กับสถิติที่รวบรวมโดย Postgres คุณแก้ปัญหานี้อย่างไร?
จากการวิเคราะห์ไม่มีกรณีเฉพาะเพราะเรายังไม่ได้ใช้ แต่มีโอกาสเช่นนี้ หากเรากำลังพูดถึงดัชนี ลองนึกดูว่าคิวรีกำลังไล่ตามตารางที่มีระเบียนหลายร้อยล้านรายการและคอลัมน์ที่โดยปกติแล้วจะไม่จัดทำดัชนีในผลิตภัณฑ์ และเราต้องการคำนวณข้อมูลบางอย่างที่นั่น หากคำขอนี้ถูกส่งไปยัง prod มีความเป็นไปได้ที่คำขอนี้จะง่ายใน prod เนื่องจากคำขอจะได้รับการดำเนินการที่นั่นเป็นเวลาหนึ่งนาที
ตกลงมาสร้างโคลนบาง ๆ ที่ไม่น่ากลัวเพื่อหยุดสักสองสามนาที และเพื่อให้อ่านการวิเคราะห์ได้สะดวกยิ่งขึ้น เราจะเพิ่มดัชนีสำหรับคอลัมน์ที่เราสนใจในข้อมูล
ดัชนีจะถูกสร้างขึ้นในแต่ละครั้ง?
คุณสามารถทำเพื่อให้เราสัมผัสกับข้อมูล ทำสแน็ปช็อต จากนั้นเราจะกู้คืนจากสแน็ปช็อตนี้และขับเคลื่อนคำขอใหม่ นั่นคือคุณสามารถสร้างมันขึ้นมาเพื่อที่จะสร้างโคลนใหม่ด้วยดัชนีที่ติดอยู่
สำหรับคำถามเกี่ยวกับสถิติ ถ้าเรากู้คืนจากข้อมูลสำรอง ถ้าเราทำการจำลอง สถิติของเราก็จะเหมือนเดิมทุกประการ เนื่องจากเรามีโครงสร้างข้อมูลเชิงกายภาพทั้งหมด กล่าวคือ เราจะนำข้อมูลตามที่มีมาตรวัดสถิติทั้งหมดด้วย
นี่คือปัญหาอื่น หากคุณใช้โซลูชันระบบคลาวด์ จะมีเฉพาะโลจิคัลดัมพ์เท่านั้นเนื่องจาก Google, Amazon ไม่อนุญาตให้คุณทำสำเนาจริง จะมีปัญหา
ขอบคุณสำหรับรายงาน มีคำถามที่ดีสองข้อที่นี่เกี่ยวกับ MySQL และการแบ่งปันทรัพยากร แต่ในความเป็นจริง ทั้งหมดนี้มาจากข้อเท็จจริงที่ว่านี่ไม่ใช่หัวข้อของ DBMS เฉพาะ แต่เป็นเรื่องของระบบไฟล์โดยรวม และด้วยเหตุนี้ ปัญหาของการแบ่งปันทรัพยากรควรได้รับการแก้ไขจากจุดนั้นด้วย ไม่ใช่อยู่ที่ Postgres แต่อยู่ที่ระบบไฟล์ ในเซิร์ฟเวอร์ เป็นต้น
คำถามของฉันแตกต่างกันเล็กน้อย ใกล้กับฐานข้อมูลหลายชั้นซึ่งมีหลายชั้น ตัวอย่างเช่น เราตั้งค่าการอัปเดตอิมเมจขนาด 100 เทราไบต์ เรากำลังทำซ้ำ และเราใช้โซลูชันนี้สำหรับฐานข้อมูลโดยเฉพาะ กำลังจำลองข้อมูล กำลังปรับปรุงข้อมูล มีพนักงาน XNUMX คนที่ทำงานควบคู่กันที่นี่ ซึ่งคอยเปิดตัวช็อตต่างๆ เหล่านี้อย่างต่อเนื่อง จะทำอย่างไร? จะแน่ใจได้อย่างไรว่าไม่มีข้อขัดแย้ง พวกเขาเปิดตัวหนึ่ง จากนั้นระบบไฟล์ก็เปลี่ยนไป และรูปภาพเหล่านี้ทั้งหมดก็หายไป
พวกเขาจะไม่ไปเพราะนั่นคือวิธีการทำงานของ ZFS เราสามารถแยกการเปลี่ยนแปลงระบบไฟล์ที่เกิดจากการจำลองแบบในหนึ่งเธรด และเก็บโคลนที่นักพัฒนาใช้กับข้อมูลเวอร์ชันเก่า และมันใช้ได้กับเราทุกอย่างเป็นไปตามนี้
ปรากฎว่าการอัปเดตจะเกิดขึ้นเป็นเลเยอร์เพิ่มเติมและรูปภาพใหม่ทั้งหมดจะขึ้นอยู่กับเลเยอร์นี้ใช่ไหม
จากเลเยอร์ก่อนหน้าที่เกิดจากการจำลองแบบครั้งก่อน
เลเยอร์ก่อนหน้าจะหลุดออกไป แต่จะอ้างอิงถึงเลเยอร์เก่า และพวกเขาจะนำรูปภาพใหม่จากเลเยอร์ล่าสุดที่ได้รับในการอัปเดตหรือไม่
โดยทั่วไปใช่
ดังนั้นเราจะมีเลเยอร์มากถึงชั้น และเมื่อเวลาผ่านไปพวกเขาจะต้องถูกบีบอัด?
ใช่ ทุกอย่างถูกต้อง มีหน้าต่างบางส่วน เราเก็บภาพรายสัปดาห์ ขึ้นอยู่กับทรัพยากรที่คุณมี หากคุณมีความสามารถในการจัดเก็บข้อมูลจำนวนมาก คุณสามารถจัดเก็บสแน็ปช็อตได้นาน พวกเขาจะไม่หายไปเอง จะไม่มีข้อมูลเสียหาย หากสแนปชอตล้าสมัยตามที่เราเข้าใจ นั่นคือขึ้นอยู่กับนโยบายในบริษัท เราสามารถลบออกและเพิ่มพื้นที่ว่างได้
สวัสดี ขอบคุณสำหรับรายงาน! คำถามเกี่ยวกับโจ คุณบอกว่าลูกค้าไม่ต้องการให้ทุกคนเข้าถึงข้อมูล ถ้าพูดกันตามตรง ถ้าคนๆ หนึ่งมีผลของ Explain Analyse เขาก็สามารถแอบดูข้อมูลได้
ประมาณนั้นแหละ. ตัวอย่างเช่น เราสามารถเขียนว่า: "SELECT FROM WHERE email = to that" นั่นคือเราจะไม่เห็นข้อมูล แต่เราสามารถเห็นสัญญาณทางอ้อมบางอย่าง สิ่งนี้จะต้องเข้าใจ แต่ในอีกทางหนึ่ง มันทั้งหมดอยู่ที่นั่น เรามีการตรวจสอบบันทึก เรามีการควบคุมเพื่อนร่วมงานคนอื่นๆ ที่มองเห็นว่านักพัฒนากำลังทำอะไรอยู่ และถ้ามีคนพยายามทำเช่นนี้บริการรักษาความปลอดภัยจะมาหาพวกเขาและแก้ไขปัญหานี้
สวัสดีตอนบ่าย ขอบคุณสำหรับรายงาน! ฉันมีคำถามสั้นๆ หากบริษัทไม่ได้ใช้ Slack จะมีการผูกมัดใดๆ ในตอนนี้หรือไม่ หรือเป็นไปได้หรือไม่ที่นักพัฒนาจะปรับใช้อินสแตนซ์เพื่อเชื่อมต่อแอปพลิเคชันทดสอบกับฐานข้อมูล
ขณะนี้มีลิงก์ไปยัง Slack เช่น ไม่มีผู้ส่งสารรายอื่น แต่ฉันต้องการให้การสนับสนุนผู้ส่งสารรายอื่นด้วย คุณทำอะไรได้บ้าง? คุณสามารถปรับใช้ DB Lab ได้โดยไม่ต้องใช้ Joe ใช้ REST API หรือด้วยความช่วยเหลือของแพลตฟอร์มของเรา และสร้างโคลนและเชื่อมต่อกับ PSQL แต่สิ่งนี้สามารถทำได้หากคุณพร้อมที่จะให้นักพัฒนาของคุณเข้าถึงข้อมูล เพราะจะไม่มีหน้าจอใดๆ อีกต่อไป
ฉันไม่ต้องการเลเยอร์นี้ แต่ฉันต้องการโอกาสเช่นนี้
แล้วใช่มันสามารถทำได้
ที่มา: will.com