TL; DR: สี่ปีที่แล้วฉันออกจาก Google พร้อมกับแนวคิดสำหรับเครื่องมือตรวจสอบเซิร์ฟเวอร์ตัวใหม่ แนวคิดคือการรวมฟังก์ชันที่มักจะแยกออกมาเป็นบริการเดียว และการวิเคราะห์บันทึก การรวบรวมตัวชี้วัด และแดชบอร์ด หลักการประการหนึ่งคือต้องให้บริการอย่างแท้จริง เร็วมอบประสบการณ์ที่ง่าย โต้ตอบ และสนุกสนานให้กับ Devops ต้องใช้การประมวลผลชุดข้อมูลหลายกิกะไบต์ในเวลาเสี้ยววินาทีโดยยังคงอยู่ภายในงบประมาณ เครื่องมือการจัดการบันทึกที่มีอยู่มักจะช้าและเทอะทะ ดังนั้นเราจึงเผชิญกับความท้าทายที่ดี นั่นคือการออกแบบเครื่องมืออย่างชาญฉลาดเพื่อให้ผู้ใช้ได้รับประสบการณ์ใหม่
บทความนี้จะอธิบายว่าพวกเราที่ Scalyr แก้ไขปัญหานี้ได้อย่างไรโดยการใช้วิธีการแบบเก่า วิธีการแบบเดรัจฉาน การกำจัดเลเยอร์ที่ไม่จำเป็น และหลีกเลี่ยงโครงสร้างข้อมูลที่ซับซ้อน คุณสามารถนำบทเรียนเหล่านี้ไปใช้กับปัญหาทางวิศวกรรมของคุณได้
พลังโรงเรียนเก่า
การวิเคราะห์บันทึกมักจะเริ่มต้นด้วยการค้นหา: ค้นหาข้อความทั้งหมดที่ตรงกับรูปแบบที่กำหนด ใน Scalyr บันทึกเหล่านี้เป็นสิบหรือหลายร้อยกิกะไบต์จากเซิร์ฟเวอร์หลายแห่ง ตามกฎแล้วแนวทางสมัยใหม่เกี่ยวข้องกับการสร้างโครงสร้างข้อมูลที่ซับซ้อนซึ่งปรับให้เหมาะสมสำหรับการค้นหา ฉันเคยเห็นสิ่งนี้บน Google อย่างแน่นอน ซึ่งพวกเขาค่อนข้างเก่งในเรื่องประเภทนี้ แต่เราตัดสินใจเลือกแนวทางที่หยาบกว่า: การสแกนบันทึกเชิงเส้น และมันก็ได้ผล - เรามีอินเทอร์เฟซที่สามารถค้นหาได้ซึ่งเร็วกว่าคู่แข่งของเรา (ดูภาพเคลื่อนไหวในตอนท้าย)
ข้อมูลเชิงลึกที่สำคัญคือโปรเซสเซอร์สมัยใหม่มีความรวดเร็วในการดำเนินงานที่เรียบง่ายและตรงไปตรงมา นี่เป็นเรื่องง่ายที่จะพลาดในระบบหลายเลเยอร์ที่ซับซ้อนซึ่งต้องอาศัยความเร็ว I/O และการทำงานของเครือข่าย และระบบดังกล่าวเป็นเรื่องธรรมดามากในปัจจุบัน ดังนั้นเราจึงพัฒนาการออกแบบที่ลดชั้นและเศษส่วนเกินให้เหลือน้อยที่สุด ด้วยโปรเซสเซอร์และเซิร์ฟเวอร์หลายตัวพร้อมกัน ความเร็วในการค้นหาจึงสูงถึง 1 TB ต่อวินาที
ประเด็นสำคัญจากบทความนี้:
- การค้นหาแบบเดรัจฉานเป็นแนวทางที่ใช้ได้จริงในการแก้ปัญหาในโลกแห่งความเป็นจริงและปัญหาขนาดใหญ่
- การใช้กำลังเดรัจฉานเป็นเทคนิคการออกแบบ ไม่ใช่วิธีแก้ปัญหาแบบไร้งาน เช่นเดียวกับเทคนิคใดๆ ก็ตาม เทคนิคนี้จะเหมาะสมกับปัญหาบางอย่างมากกว่าเทคนิคอื่นๆ และอาจนำไปใช้ได้ไม่ดีหรือดีก็ได้
- การใช้กำลังดุร้ายเป็นสิ่งที่ดีอย่างยิ่งในการบรรลุเป้าหมาย มั่นคง ประสิทธิภาพ.
- การใช้กำลังอย่างมีประสิทธิภาพจำเป็นต้องปรับโค้ดให้เหมาะสมและใช้ทรัพยากรที่เพียงพอในเวลาที่เหมาะสม เหมาะอย่างยิ่งหากเซิร์ฟเวอร์ของคุณมีภาระงานหนักโดยไม่ใช่ผู้ใช้และการดำเนินงานของผู้ใช้ยังคงมีความสำคัญ
- ประสิทธิภาพขึ้นอยู่กับการออกแบบของทั้งระบบ ไม่ใช่แค่อัลกอริธึมวงในเท่านั้น
(บทความนี้อธิบายการค้นหาข้อมูลในหน่วยความจำ ในกรณีส่วนใหญ่ เมื่อผู้ใช้ทำการค้นหาบันทึก เซิร์ฟเวอร์ Scalyr ได้แคชไว้แล้ว บทความถัดไปจะกล่าวถึงการค้นหาบันทึกที่ไม่แคช หลักการเดียวกันนี้ใช้: รหัสที่มีประสิทธิภาพ, กำลังเดรัจฉาน ด้วยทรัพยากรการคำนวณขนาดใหญ่)
วิธีใช้กำลังดุร้าย
โดยปกติแล้ว ชุดข้อมูลขนาดใหญ่จะถูกค้นหาโดยใช้ดัชนีคำสำคัญ เมื่อนำไปใช้กับบันทึกของเซิร์ฟเวอร์ หมายถึงการค้นหาคำที่ไม่ซ้ำกันทุกคำในบันทึก สำหรับแต่ละคำ คุณจะต้องสร้างรายการการรวมทั้งหมด ซึ่งทำให้ง่ายต่อการค้นหาข้อความทั้งหมดที่มีคำนี้ เช่น 'error', 'firefox' หรือ "transaction_16851951" เพียงดูในดัชนี
ฉันใช้แนวทางนี้ที่ Google และได้ผลดี แต่ใน Scalyr เราค้นหาบันทึกแบบไบต์ต่อไบต์
ทำไม จากมุมมองของอัลกอริธึมเชิงนามธรรม ดัชนีคำหลักจะมีประสิทธิภาพมากกว่าการค้นหาแบบ Brute Force มาก อย่างไรก็ตาม เราไม่ขายอัลกอริธึม แต่เราขายประสิทธิภาพ และประสิทธิภาพไม่ได้เกี่ยวกับอัลกอริธึมเท่านั้น แต่ยังเกี่ยวกับวิศวกรรมระบบด้วย เราต้องพิจารณาทุกอย่าง: ปริมาณข้อมูล ประเภทการค้นหา บริบทของฮาร์ดแวร์และซอฟต์แวร์ที่มีอยู่ เราตัดสินใจว่าสำหรับปัญหาเฉพาะของเรา บางอย่างเช่น 'grep' นั้นเหมาะสมกว่าดัชนี
ดัชนีนั้นดี แต่ก็มีข้อจำกัด บอกได้คำเดียวว่าหาง่าย แต่การค้นหาข้อความที่มีคำหลายคำ เช่น 'googlebot' และ '404' นั้นยากกว่ามาก การค้นหาวลีเช่น 'uncaught ข้อยกเว้น' ต้องใช้ดัชนีที่ยุ่งยากมากขึ้น ซึ่งไม่เพียงแต่บันทึกข้อความทั้งหมดที่มีคำนั้นเท่านั้น แต่ยังรวมถึงตำแหน่งเฉพาะของคำนั้นด้วย
ความยากลำบากที่แท้จริงเกิดขึ้นเมื่อคุณไม่มองหาคำศัพท์ สมมติว่าคุณต้องการดูว่าปริมาณการเข้าชมมาจากบอทมากน้อยเพียงใด ความคิดแรกคือการค้นหาบันทึกเพื่อหาคำว่า 'บอท' นี่คือวิธีที่คุณจะพบบอทบางตัว: Googlebot, Bingbot และอื่นๆ อีกมากมาย แต่ที่นี่ 'บอท' ไม่ใช่คำ แต่เป็นส่วนหนึ่งของคำนั้น หากเราค้นหา "bot" ในดัชนี เราจะไม่พบโพสต์ที่มีคำว่า "Googlebot" หากคุณตรวจสอบทุกคำในดัชนีแล้วสแกนดัชนีเพื่อหาคำหลักที่พบ การค้นหาจะช้าลงอย่างมาก เป็นผลให้บางโปรแกรมบันทึกไม่อนุญาตให้มีการค้นหาคำที่เป็นส่วนหนึ่งหรือ (อย่างดีที่สุด) อนุญาตให้ใช้ไวยากรณ์พิเศษที่มีประสิทธิภาพต่ำกว่า เราต้องการหลีกเลี่ยงสิ่งนี้
ปัญหาอีกประการหนึ่งคือเครื่องหมายวรรคตอน คุณต้องการค้นหาคำขอทั้งหมดจาก 50.168.29.7? แล้วบันทึกการดีบักที่มี [error]? ตัวห้อยมักจะข้ามเครื่องหมายวรรคตอน
สุดท้ายนี้ วิศวกรชอบเครื่องมือที่มีประสิทธิภาพ และบางครั้งปัญหาสามารถแก้ไขได้ด้วยนิพจน์ทั่วไปเท่านั้น ดัชนีคำหลักไม่เหมาะกับสิ่งนี้มากนัก
นอกจากนี้ดัชนี ซับซ้อน. แต่ละข้อความจะต้องเพิ่มลงในรายการคำหลักหลายรายการ รายการเหล่านี้ควรเก็บไว้ในรูปแบบที่ค้นหาได้ง่ายตลอดเวลา ข้อความค้นหาที่มีวลี ส่วนของคำ หรือนิพจน์ทั่วไปจำเป็นต้องแปลเป็นการดำเนินการหลายรายการ และสแกนผลลัพธ์และรวมเข้าด้วยกันเพื่อสร้างชุดผลลัพธ์ ในบริบทของบริการขนาดใหญ่ที่มีผู้เช่าหลายราย ความซับซ้อนนี้สร้างปัญหาด้านประสิทธิภาพที่ไม่สามารถมองเห็นได้เมื่อวิเคราะห์อัลกอริทึม
ดัชนีคำสำคัญยังใช้พื้นที่มาก และพื้นที่จัดเก็บถือเป็นต้นทุนหลักในระบบการจัดการบันทึก
ในทางกลับกัน การค้นหาแต่ละครั้งอาจใช้พลังงานในการประมวลผลเป็นจำนวนมาก ผู้ใช้ของเราชื่นชอบการค้นหาด้วยความเร็วสูงสำหรับข้อความค้นหาที่ไม่ซ้ำใคร แต่ข้อความค้นหาดังกล่าวเกิดขึ้นค่อนข้างน้อย สำหรับคำค้นหาทั่วไป เช่น สำหรับแดชบอร์ด เราใช้เทคนิคพิเศษ (เราจะอธิบายในบทความถัดไป) คำขออื่นๆ นั้นไม่บ่อยนักจนคุณแทบไม่ต้องดำเนินการมากกว่าหนึ่งรายการในแต่ละครั้ง แต่นี่ไม่ได้หมายความว่าเซิร์ฟเวอร์ของเราไม่ยุ่ง: พวกเขายุ่งกับงานรับ วิเคราะห์และบีบอัดข้อความใหม่ ประเมินการแจ้งเตือน บีบอัดข้อมูลเก่า และอื่นๆ ดังนั้นเราจึงมีโปรเซสเซอร์จำนวนมากพอสมควรที่สามารถใช้เพื่อดำเนินการสืบค้นได้
การใช้กำลังแบบเดรัจฉานจะใช้ได้ผลหากคุณมีปัญหาแบบเดรัจฉาน (และใช้กำลังมาก)
การใช้กำลังเดรัจฉานทำงานได้ดีที่สุดกับปัญหาง่ายๆ ที่มีลูปภายในขนาดเล็ก บ่อยครั้งที่คุณสามารถปรับลูปภายในให้ทำงานด้วยความเร็วสูงได้ หากโค้ดมีความซับซ้อน การเพิ่มประสิทธิภาพก็จะยากขึ้นมาก
โค้ดการค้นหาของเราแต่เดิมมีวงในที่ค่อนข้างใหญ่ เราจัดเก็บข้อความบนเพจที่ 4K; แต่ละหน้าประกอบด้วยข้อความบางส่วน (ในรูปแบบ UTF-8) และข้อมูลเมตาสำหรับแต่ละข้อความ ข้อมูลเมตาคือโครงสร้างที่เข้ารหัสความยาวของค่า รหัสข้อความภายใน และช่องอื่นๆ วงจรการค้นหามีลักษณะดังนี้:
นี่เป็นโค้ดจริงเวอร์ชันที่เรียบง่าย แต่ถึงแม้ที่นี่ ตำแหน่งของวัตถุ สำเนาข้อมูล และการเรียกใช้ฟังก์ชันหลายรายการก็สามารถมองเห็นได้ JVM ค่อนข้างดีในการปรับการเรียกใช้ฟังก์ชันให้เหมาะสมและการจัดสรรออบเจ็กต์ชั่วคราว ดังนั้นโค้ดนี้จึงทำงานได้ดีกว่าที่เราสมควรได้รับ ระหว่างการทดสอบ ลูกค้าใช้ค่อนข้างประสบความสำเร็จ แต่ในที่สุดเราก็ก้าวไปสู่อีกระดับหนึ่ง
(คุณอาจถามว่าทำไมเราจึงจัดเก็บข้อความในรูปแบบนี้ด้วยหน้า 4K ข้อความ และข้อมูลเมตา แทนที่จะทำงานกับบันทึกโดยตรง มีเหตุผลหลายประการที่สรุปได้ว่ากลไกภายใน Scalyr เป็นเหมือนฐานข้อมูลแบบกระจายมากกว่า ระบบไฟล์ การค้นหาข้อความมักจะรวมกับตัวกรองสไตล์ DBMS ในระยะขอบหลังจากการแยกวิเคราะห์บันทึก เราสามารถค้นหาบันทึกได้หลายพันรายการพร้อมกันและไฟล์ข้อความธรรมดาไม่เหมาะสำหรับการจัดการข้อมูลเชิงธุรกรรม จำลองแบบ และกระจายของเรา)
ในตอนแรก ดูเหมือนว่าโค้ดดังกล่าวไม่เหมาะสำหรับการเพิ่มประสิทธิภาพเดรัจฉานฟอร์ซมากนัก “งานจริง” ค่ะ String.indexOf() ไม่ได้ครอบงำโปรไฟล์ CPU ด้วยซ้ำ นั่นคือการปรับวิธีนี้ให้เหมาะสมเพียงอย่างเดียวจะไม่ส่งผลกระทบที่สำคัญ
บังเอิญเราจัดเก็บข้อมูลเมตาไว้ที่ตอนต้นของแต่ละหน้า และข้อความของข้อความทั้งหมดใน UTF-8 จะถูกรวมไว้ที่ปลายอีกด้านหนึ่ง เราใช้ประโยชน์จากสิ่งนี้ โดยเขียนลูปใหม่เพื่อค้นหาทั้งหน้าในคราวเดียว:
เวอร์ชันนี้ใช้งานได้โดยตรงบนมุมมอง raw byte[] และค้นหาข้อความทั้งหมดพร้อมกันทั่วทั้งหน้า 4K
วิธีนี้ง่ายกว่ามากในการเพิ่มประสิทธิภาพสำหรับวิธีกำลังดุร้าย ลูปการค้นหาภายในจะถูกเรียกพร้อมกันสำหรับทั้งหน้า 4K แทนที่จะแยกกันในแต่ละโพสต์ ไม่มีการคัดลอกข้อมูล ไม่มีการจัดสรรออบเจ็กต์ และการดำเนินการเมตาดาต้าที่ซับซ้อนมากขึ้นจะถูกเรียกเมื่อผลลัพธ์เป็นค่าบวกเท่านั้น และไม่ใช่ในทุกข้อความ ด้วยวิธีนี้เราได้กำจัดค่าใช้จ่ายจำนวนมาก และโหลดส่วนที่เหลือจะรวมอยู่ในลูปการค้นหาภายในขนาดเล็ก ซึ่งเหมาะอย่างยิ่งสำหรับการปรับให้เหมาะสมต่อไป
อัลกอริธึมการค้นหาจริงของเรานั้นขึ้นอยู่กับ . คล้ายกับอัลกอริทึม Boyer-Moore โดยข้ามความยาวของสตริงค้นหาในแต่ละขั้นตอนโดยประมาณ ข้อแตกต่างที่สำคัญคือจะตรวจสอบครั้งละสองไบต์เพื่อลดการจับคู่ที่ผิดพลาดให้เหลือน้อยที่สุด
การใช้งานของเราจำเป็นต้องสร้างตารางการค้นหา 64K สำหรับการค้นหาแต่ละครั้ง แต่ก็เทียบไม่ได้กับข้อมูลกิกะไบต์ที่เราใช้ค้นหา วงในจะประมวลผลหลายกิกะไบต์ต่อวินาทีบนคอร์เดียว ในทางปฏิบัติ ประสิทธิภาพที่เสถียรอยู่ที่ประมาณ 1,25 GB ต่อวินาทีในแต่ละคอร์ และยังมีช่องว่างที่ต้องปรับปรุง มีความเป็นไปได้ที่จะกำจัดโอเวอร์เฮดบางส่วนที่อยู่นอกลูปด้านใน และเราวางแผนที่จะทดลองกับลูปด้านในในภาษา C แทน Java
เราใช้กำลัง
เราได้พูดคุยกันว่าการค้นหาบันทึกสามารถทำได้ "โดยประมาณ" แต่เรามี "พลัง" มากแค่ไหน? ค่อนข้างมาก.
1 ปี: เมื่อใช้อย่างถูกต้อง คอร์เดียวของโปรเซสเซอร์สมัยใหม่จะค่อนข้างทรงพลังในตัวมันเอง
8 คอร์: ขณะนี้เรากำลังใช้งานบนเซิร์ฟเวอร์ Amazon hi1.4xlarge และ i2.4xlarge SSD โดยแต่ละตัวมี 8 คอร์ (16 เธรด) ตามที่กล่าวไว้ข้างต้น แกนเหล่านี้มักจะยุ่งอยู่กับการดำเนินการในเบื้องหลัง เมื่อผู้ใช้ทำการค้นหา การดำเนินการในเบื้องหลังจะถูกระงับ ทำให้มีคอร์ทั้ง 8 ว่างสำหรับการค้นหา โดยปกติการค้นหาจะเสร็จสิ้นภายในเสี้ยววินาที หลังจากนั้นงานในพื้นหลังจะกลับมาทำงานต่อ (โปรแกรมควบคุมปริมาณทำให้มั่นใจได้ว่าคำค้นหาจะไม่รบกวนงานในพื้นหลังที่สำคัญ)
16 คอร์: เพื่อความน่าเชื่อถือ เราจัดเซิร์ฟเวอร์เป็นกลุ่มหลัก/รอง ต้นแบบแต่ละคนมีหนึ่ง SSD และหนึ่งเซิร์ฟเวอร์ EBS ภายใต้คำสั่งของเขา หากเซิร์ฟเวอร์หลักล่ม เซิร์ฟเวอร์ SSD จะเข้ามาแทนที่ทันที เกือบตลอดเวลา มาสเตอร์และทาสทำงานได้ดี ดังนั้นแต่ละบล็อกข้อมูลจึงสามารถค้นหาได้บนเซิร์ฟเวอร์ที่แตกต่างกันสองเครื่อง (เซิร์ฟเวอร์ทาส EBS มีตัวประมวลผลที่อ่อนแอ ดังนั้นเราจึงไม่พิจารณาเรื่องนี้) เราแบ่งงานระหว่างพวกเขาเพื่อให้เรามีทั้งหมด 16 คอร์ที่พร้อมใช้งาน
หลายคอร์: ในอนาคตอันใกล้นี้ เราจะแจกจ่ายข้อมูลข้ามเซิร์ฟเวอร์ในลักษณะที่พวกเขาทั้งหมดมีส่วนร่วมในการประมวลผลทุกคำขอที่ไม่สำคัญ ทุกคอร์จะทำงาน [บันทึก: เราดำเนินการตามแผนและเพิ่มความเร็วในการค้นหาเป็น 1 TB/s ดูหมายเหตุท้ายบทความ].
ความเรียบง่ายทำให้มั่นใจได้ถึงความน่าเชื่อถือ
ข้อดีอีกประการหนึ่งของวิธีกำลังเดรัจฉานก็คือประสิทธิภาพที่ค่อนข้างสม่ำเสมอ โดยทั่วไปแล้ว การค้นหาไม่ได้มีความอ่อนไหวต่อรายละเอียดของปัญหาและชุดข้อมูลมากนัก (ฉันเดาว่าทำไมจึงเรียกว่า "หยาบ")
บางครั้งดัชนีคำหลักก็ให้ผลลัพธ์ที่รวดเร็วอย่างไม่น่าเชื่อ และในบางครั้งก็ไม่ได้ให้ผลลัพธ์เช่นนั้น สมมติว่าคุณมีบันทึกขนาด 50 GB ซึ่งมีคำว่า 'customer_5987235982' ปรากฏขึ้นสามครั้งพอดี การค้นหาคำนี้จะนับสามตำแหน่งโดยตรงจากดัชนี และจะเสร็จสิ้นทันที แต่การค้นหาไวด์การ์ดที่ซับซ้อนสามารถสแกนคำหลักได้หลายพันคำและใช้เวลานาน
ในทางกลับกัน การค้นหาแบบ Brute Force จะดำเนินการด้วยความเร็วเท่ากันสำหรับข้อความค้นหาใดๆ การค้นหาคำที่ยาวจะดีกว่า แต่การค้นหาอักขระเพียงตัวเดียวก็ยังค่อนข้างรวดเร็ว
ความเรียบง่ายของวิธีกำลังเดรัจฉานหมายความว่าประสิทธิภาพใกล้เคียงกับค่าสูงสุดทางทฤษฎี มีตัวเลือกน้อยลงสำหรับการโอเวอร์โหลดดิสก์โดยไม่คาดคิด การแย่งชิงการล็อก การไล่ตามพอยน์เตอร์ และสาเหตุอื่นๆ อีกหลายพันรายการที่ทำให้เกิดปัญหา ฉันเพิ่งดูคำขอที่ทำโดยผู้ใช้ Scalyr เมื่อสัปดาห์ที่แล้วบนเซิร์ฟเวอร์ที่ยุ่งที่สุดของเรา มีคำขอ 14 รายการ แปดคนใช้เวลามากกว่าหนึ่งวินาทีพอดี เสร็จสิ้น 000% ภายใน 99 มิลลิวินาที (หากคุณไม่ได้ใช้เครื่องมือวิเคราะห์บันทึก เชื่อฉันสิ: มันเร็ว).
ประสิทธิภาพที่เสถียรและเชื่อถือได้เป็นสิ่งสำคัญสำหรับการใช้บริการที่ง่ายดาย หากล่าช้าเป็นระยะ ผู้ใช้จะมองว่าไม่น่าเชื่อถือและไม่เต็มใจที่จะใช้
บันทึกการค้นหาในการดำเนินการ
นี่คือภาพเคลื่อนไหวสั้นๆ ที่แสดงการค้นหาของ Scalyr เรามีบัญชีทดลองที่เรานำเข้าทุกกิจกรรมในพื้นที่เก็บข้อมูล Github สาธารณะทุกแห่ง ในการสาธิตนี้ ฉันตรวจสอบข้อมูลในหนึ่งสัปดาห์: บันทึกดิบประมาณ 600 MB
วิดีโอนี้บันทึกสดบนเดสก์ท็อปของฉันโดยไม่ต้องเตรียมการเป็นพิเศษ (ห่างจากเซิร์ฟเวอร์ประมาณ 5000 กิโลเมตร) ประสิทธิภาพที่คุณจะเห็นส่วนใหญ่เนื่องมาจาก รวมถึงแบ็กเอนด์ที่รวดเร็วและเชื่อถือได้ เมื่อใดก็ตามที่มีการหยุดชั่วคราวโดยไม่มีสัญลักษณ์ 'กำลังโหลด' ฉันจะหยุดชั่วคราวเพื่อให้คุณอ่านสิ่งที่ฉันกำลังจะกดได้
ในข้อสรุป
เมื่อประมวลผลข้อมูลจำนวนมาก สิ่งสำคัญคือต้องเลือกอัลกอริทึมที่ดี แต่ "ดี" ไม่ได้หมายความว่า "สวยงาม" ลองคิดดูว่าโค้ดของคุณจะทำงานอย่างไรในทางปฏิบัติ การวิเคราะห์ทางทฤษฎีของอัลกอริธึมขจัดปัจจัยบางอย่างที่อาจมีความสำคัญอย่างยิ่งในโลกแห่งความเป็นจริงออกไป อัลกอริธึมที่เรียบง่ายกว่าจะปรับให้เหมาะสมได้ง่ายกว่าและมีเสถียรภาพมากขึ้นในสถานการณ์ Edge
คิดถึงบริบทที่โค้ดจะถูกเรียกใช้งานด้วย ในกรณีของเรา เราต้องการเซิร์ฟเวอร์ที่ทรงพลังเพียงพอที่จะจัดการงานเบื้องหลัง ผู้ใช้เริ่มการค้นหาไม่บ่อยนัก ดังนั้นเราจึงสามารถยืมเซิร์ฟเวอร์ทั้งกลุ่มในช่วงเวลาสั้นๆ ที่จำเป็นในการค้นหาแต่ละครั้งให้เสร็จสิ้น
ด้วยการใช้วิธีการบังคับแบบดุร้าย เราได้ดำเนินการค้นหาที่รวดเร็ว เชื่อถือได้ และยืดหยุ่นในชุดบันทึกต่างๆ เราหวังว่าแนวคิดเหล่านี้จะเป็นประโยชน์สำหรับโครงการของคุณ
แก้ไข: ชื่อเรื่องและข้อความเปลี่ยนจาก "ค้นหาที่ 20 GB ต่อวินาที" เป็น "ค้นหาที่ 1 TB ต่อวินาที" เพื่อสะท้อนถึงประสิทธิภาพที่เพิ่มขึ้นในช่วงไม่กี่ปีที่ผ่านมา ความเร็วที่เพิ่มขึ้นนี้มีสาเหตุหลักมาจากการเปลี่ยนแปลงประเภทและจำนวนเซิร์ฟเวอร์ EC2 ที่เราจัดทำขึ้นในปัจจุบันเพื่อรองรับฐานลูกค้าที่เพิ่มขึ้นของเรา มีการเปลี่ยนแปลงในเร็วๆ นี้ ซึ่งจะช่วยเพิ่มประสิทธิภาพการดำเนินงานอย่างมาก และเราแทบจะรอไม่ไหวที่จะแชร์การเปลี่ยนแปลงดังกล่าว
ที่มา: will.com