ฉันมีกรณีการใช้งานที่จะมีกระแสข้อมูลไหลเข้ามาและฉันไม่สามารถใช้งานได้ในเวลาเดียวกันและต้องการบัฟเฟอร์ สิ่งนี้สามารถแก้ไขได้โดยใช้คิว SNS-SQS ฉันรู้ว่า Kinesis แก้จุดประสงค์เดียวกันดังนั้นอะไรคือความแตกต่าง? ทำไมฉันถึงชอบ Kinesis (หรือไม่ควร)
ฉันมีกรณีการใช้งานที่จะมีกระแสข้อมูลไหลเข้ามาและฉันไม่สามารถใช้งานได้ในเวลาเดียวกันและต้องการบัฟเฟอร์ สิ่งนี้สามารถแก้ไขได้โดยใช้คิว SNS-SQS ฉันรู้ว่า Kinesis แก้จุดประสงค์เดียวกันดังนั้นอะไรคือความแตกต่าง? ทำไมฉันถึงชอบ Kinesis (หรือไม่ควร)
คำตอบ:
บนพื้นผิวมันมีความคล้ายคลึงกันอย่างคลุมเครือ แต่กรณีการใช้งานของคุณจะกำหนดเครื่องมือที่เหมาะสม IMO ถ้าคุณได้รับจาก SQS คุณควร - ถ้ามันจะทำในสิ่งที่คุณต้องการมันจะง่ายและราคาถูกกว่า แต่นี่เป็นคำอธิบายที่ดีกว่าจากคำถามที่พบบ่อย AWS ซึ่งให้ตัวอย่างของการใช้งานที่เหมาะสมสำหรับเครื่องมือทั้งสอง ช่วยคุณตัดสินใจ:
โปรดทราบว่าคำตอบนี้ถูกต้องในเดือนมิถุนายน 2558
หลังจากศึกษาปัญหามาพักหนึ่งแล้วเมื่อมีคำถามเดียวกันฉันพบว่า SQS (พร้อม SNS) เป็นที่นิยมใช้ในกรณีส่วนใหญ่เว้นแต่ว่าลำดับของข้อความนั้นสำคัญสำหรับคุณ (SQS ไม่รับประกัน FIFO กับข้อความ)
มี 2 ข้อได้เปรียบหลักสำหรับ Kinesis:
ข้อดีทั้งสองนี้สามารถทำได้โดยการใช้ SNS เป็นแฟนตัวยงถึง SQS นั่นหมายความว่าผู้สร้างข้อความจะส่งข้อความเดียวไปยัง SNS เท่านั้นจากนั้น SNS จะกระจายข้อความไปยัง SQS หลายรายการหนึ่งรายการสำหรับแต่ละแอปพลิเคชันสำหรับผู้บริโภค ด้วยวิธีนี้คุณสามารถมีผู้บริโภคได้มากเท่าที่คุณต้องการโดยไม่ต้องคิดเกี่ยวกับความสามารถในการแบ่งส่วน
นอกจากนี้เราได้เพิ่ม SQS เพิ่มเติมอีกหนึ่งรายการที่สมัครรับข่าวสารจาก SNS ที่จะเก็บข้อความไว้เป็นเวลา 14 วัน ในกรณีปกติไม่มีใครอ่านจาก SQS นี้ แต่ในกรณีที่มีข้อผิดพลาดที่ทำให้เราต้องการย้อนกลับข้อมูลเราสามารถอ่านข้อความทั้งหมดจาก SQS นี้ได้อย่างง่ายดายและส่งไปยัง SNS อีกครั้ง ในขณะที่ Kinesis ให้การเก็บรักษา 7 วันเท่านั้น
โดยสรุป SNS + SQS ง่ายกว่าและให้ความสามารถมากที่สุด IMO คุณต้องมีเคสที่แข็งแกร่งมากในการเลือก Kinesis
splitในSNS split the message to multiple SQSsเพราะมันไม่ได้ทำลายลงข้อความเป็นชิ้น แต่สำเนาไปยังสถานที่ต่างๆ
Kinesis สนับสนุนความสามารถของผู้ใช้หลายคนซึ่งหมายถึงการบันทึกข้อมูลเดียวกันสามารถประมวลผลในเวลาเดียวกันหรือเวลาที่แตกต่างกันภายใน 24 ชั่วโมงที่ผู้บริโภคที่แตกต่างกันพฤติกรรมที่คล้ายกันใน SQS สามารถทำได้โดยการเขียนลงในหลาย ๆ คิว อย่างไรก็ตามการเขียนอีกครั้งในหลายคิวจะเพิ่มวินาทีย่อย {ไม่กี่มิลลิวินาที} เวลาแฝงในระบบ
ประการที่สอง Kinesis จัดเตรียมความสามารถในการเราต์เพื่อเลือกเรคคอร์ดข้อมูลเส้นทางไปยังส่วนต่าง ๆ โดยใช้พาร์ติชั่นคีย์ซึ่งสามารถประมวลผลได้โดยอินสแตนซ์ของ EC2 โดยเฉพาะและสามารถเปิดใช้งานการคำนวณแบบแบทช์ขนาดเล็ก
การทำงานกับซอฟต์แวร์ AWS เป็นเรื่องง่าย แต่ SQS นั้นง่ายที่สุด ด้วย Kinesis มีความจำเป็นที่จะต้องจัดเตรียมเศษพอล่วงหน้าเพิ่มจำนวนแบบไดนามิกในการจัดการโหลดสไปค์และลดลงเพื่อประหยัดค่าใช้จ่ายในการจัดการ มันเป็นความเจ็บปวดใน Kinesis ไม่จำเป็นต้องมี SQS SQS สามารถปรับขนาดได้อย่างไม่ จำกัด
ความหมายของเทคโนโลยีเหล่านี้มีความแตกต่างเพราะถูกออกแบบมาเพื่อรองรับสถานการณ์ต่าง ๆ :
ลองมาทำความเข้าใจความแตกต่างตามตัวอย่าง
เมื่อการประมวลผลของรายการหนึ่งไม่สามารถแยกออกจากการประมวลผลอีกรายการได้เราจะต้องมี Kinesis semantics เพื่อจัดการกรณีทั้งหมดอย่างปลอดภัย
ข้อความที่ตัดตอนมาจากเอกสาร AWS :
เราขอแนะนำ Amazon Kinesis Streams สำหรับเคสการใช้งานที่มีข้อกำหนดที่คล้ายกับต่อไปนี้:
การกำหนดเส้นทางระเบียนที่เกี่ยวข้องไปยังตัวประมวลผลระเบียนเดียวกัน (เช่นเดียวกับในสตรีมมิ่ง MapReduce) ตัวอย่างเช่นการนับและการรวมจะง่ายขึ้นเมื่อเร็กคอร์ดทั้งหมดสำหรับคีย์ที่กำหนดถูกส่งไปยังตัวประมวลผลเร็กคอร์ดเดียวกัน
การสั่งซื้อบันทึก ตัวอย่างเช่นคุณต้องการถ่ายโอนข้อมูลบันทึกจากโฮสต์แอพพลิเคชันไปยังโฮสต์ประมวลผล / เก็บถาวรในขณะที่รักษาลำดับของข้อความสั่งบันทึก
ความสามารถในการใช้งานหลายแอพพลิเคชั่นที่จะใช้สตรีมเดียวกันพร้อมกัน ตัวอย่างเช่นคุณมีแอปพลิเคชั่นหนึ่งที่อัปเดตแดชบอร์ดตามเวลาจริงและอีกแอปหนึ่งที่เก็บข้อมูลเป็น Amazon Redshift คุณต้องการให้ทั้งสองแอปพลิเคชันใช้ข้อมูลจากสตรีมเดียวกันพร้อมกันและเป็นอิสระ
ความสามารถในการใช้ระเบียนในลำดับเดียวกันไม่กี่ชั่วโมงต่อมา ตัวอย่างเช่นคุณมีแอปพลิเคชันสำหรับการเรียกเก็บเงินและแอปพลิเคชันตรวจสอบที่ใช้งานไม่กี่ชั่วโมงหลังแอปพลิเคชันการเรียกเก็บเงิน เนื่องจาก Amazon Kinesis Streams จัดเก็บข้อมูลนานถึง 7 วันคุณสามารถเรียกใช้แอปพลิเคชันการตรวจสอบภายใน 7 วันหลังใบสมัครการเรียกเก็บเงิน
เราขอแนะนำ Amazon SQS สำหรับกรณีการใช้งานที่มีข้อกำหนดที่คล้ายกับต่อไปนี้:
อรรถศาสตร์การส่งข้อความ (เช่นการรับ / ระดับข้อความและการหมดเวลาการมองเห็น) ตัวอย่างเช่นคุณมีคิวของรายการงานและต้องการติดตามความสำเร็จของแต่ละรายการอย่างเป็นอิสระ Amazon SQS ติดตามการรับ / ล้มเหลวดังนั้นแอปพลิเคชันไม่จำเป็นต้องรักษาจุดตรวจสอบ / เคอร์เซอร์ถาวร Amazon SQS จะลบข้อความที่รับและส่งข้อความล้มเหลวอีกครั้งหลังจากหมดเวลาการมองเห็นที่กำหนดค่าไว้
ข้อความล่าช้าส่วนบุคคล ตัวอย่างเช่นคุณมีคิวงานและจำเป็นต้องกำหนดเวลางานแต่ละงานด้วยความล่าช้า ด้วย Amazon SQS คุณสามารถกำหนดค่าข้อความส่วนตัวให้ล่าช้าได้ถึง 15 นาที
การเพิ่มพร้อมกัน / ปริมาณงานแบบไดนามิกในเวลาที่อ่าน ตัวอย่างเช่นคุณมีคิวงานและต้องการเพิ่มผู้อ่านมากขึ้นจนกว่าจะมีงานค้าง ด้วย Amazon Kinesis Streams คุณสามารถเพิ่มจำนวนเศษให้เพียงพอ (หมายเหตุอย่างไรก็ตามคุณจะต้องจัดเตรียมเศษชิ้นส่วนให้เพียงพอก่อนเวลา)
ยกระดับความสามารถของ Amazon SQS ในการขยายขนาดอย่างโปร่งใส ตัวอย่างเช่นคุณบัฟเฟอร์การร้องขอและการเปลี่ยนแปลงโหลดเป็นผลมาจากการโหลดเป็นครั้งคราวหรือการเติบโตตามธรรมชาติของธุรกิจของคุณ เนื่องจากคำขอแบบบัฟเฟอร์แต่ละรายการสามารถประมวลผลได้อย่างอิสระ Amazon SQS สามารถปรับขนาดได้อย่างโปร่งใสเพื่อจัดการกับโหลดโดยไม่ต้องมีคำแนะนำการเตรียม
ข้อได้เปรียบที่ใหญ่ที่สุดสำหรับฉันคือข้อเท็จจริงที่ว่า Kinesis เป็นคิวที่เล่นซ้ำได้และ SQS ไม่ใช่ ดังนั้นคุณสามารถมีผู้บริโภคหลายรายที่มีข้อความเดียวกันของ Kinesis (หรือผู้บริโภครายเดิมในเวลาที่ต่างกัน) โดยใช้ SQS เมื่อข้อความได้รับการตอบรับมันหายไปจากคิวนั้น SQS ดีกว่าสำหรับคิวของผู้ปฏิบัติงานเนื่องจากสิ่งนั้น
อีกอย่าง: Kinesis สามารถกระตุ้นแลมบ์ดาได้ในขณะที่ SQS ไม่สามารถทำได้ ดังนั้นด้วย SQS คุณต้องจัดเตรียมอินสแตนซ์ EC2 เพื่อประมวลผลข้อความ SQS (และจัดการกับมันหากล้มเหลว) หรือคุณต้องมีแลมบ์ดาตามกำหนดเวลา (ซึ่งไม่ได้ปรับเพิ่มหรือลดลง - คุณจะได้หนึ่งนาที .
แก้ไข: คำตอบนี้ไม่ถูกต้องอีกต่อไป SQS สามารถเรียกใช้แลมบ์ดาโดยตรง ณ เดือนมิถุนายน 2561
รูปแบบการกำหนดราคาจะแตกต่างกันดังนั้นขึ้นอยู่กับกรณีการใช้งานของคุณอย่างใดอย่างหนึ่งอาจจะถูกกว่า ใช้กรณีที่ง่ายที่สุด (ไม่รวม SNS):
เสียบราคาปัจจุบันและไม่คำนึงถึงระดับฟรีหากคุณส่งข้อความ 1 GB ต่อวันที่ขนาดข้อความสูงสุด Kinesis จะมีราคามากกว่า SQS ($ 10.82 / เดือนสำหรับ Kinesis เทียบกับ $ 0.20 / เดือนสำหรับ SQS) . แต่ถ้าคุณส่ง 1 TB ต่อวัน Kinesis จะค่อนข้างถูกกว่า ($ 158 / เดือนเทียบกับ $ 201 / เดือนสำหรับ SQS)
รายละเอียด: SQS เรียกเก็บเงิน $ 0.40 ต่อการร้องขอ (64 KB ต่อการร้องขอ) ดังนั้น $ 0.00655 ต่อ GB ที่ 1 GB ต่อวันนี่แค่ต่ำกว่า $ 0.20 ต่อเดือน ที่ 1 TB ต่อวันมันมาน้อยกว่า $ 201 ต่อเดือน
Kinesis คิดค่าบริการ $ 0.014 ต่อการร้องขอ (25 KB ต่อการร้องขอ) ดังนั้น $ 0.00059 ต่อ GB ที่ 1 GB ต่อวันนี้น้อยกว่า $ 0.02 ต่อเดือน ที่ 1 TB ต่อวันประมาณ $ 18 ต่อเดือน อย่างไรก็ตาม Kinesis คิดค่าธรรมเนียม $ 0.015 ต่อชาร์ดชั่วโมง คุณต้องมีอย่างน้อย 1 ชิ้นต่อ 1 MB ต่อวินาที ที่ 1 GB ต่อวันเศษ 1 ชิ้นจะมีมากมายดังนั้นจะเพิ่มอีก $ 0.36 ต่อวันสำหรับค่าใช้จ่ายทั้งหมด $ 10.82 ต่อเดือน ที่ 1 TB ต่อวันคุณจะต้องมีอย่างน้อย 13 เศษซึ่งเพิ่มอีก $ 4.68 ต่อวันสำหรับค่าใช้จ่ายทั้งหมด $ 158 ต่อเดือน
Kinesis แก้ปัญหาส่วนแผนที่ในสถานการณ์ลดแผนที่โดยทั่วไปสำหรับการสตรีมข้อมูล ในขณะที่ SQS ไม่แน่ใจในเรื่องนั้น หากคุณมีข้อมูลสตรีมมิ่งที่จำเป็นต้องรวมไว้ในคีย์ kinesis ทำให้แน่ใจว่าข้อมูลทั้งหมดสำหรับคีย์นั้นไปยังชาร์ดเฉพาะและสามารถใช้ชาร์ดบนโฮสต์เดี่ยวทำให้การรวมคีย์ทำได้ง่ายกว่า SQS
ฉันจะเพิ่มอีกหนึ่งสิ่งที่ไม่มีใครพูดถึง - SQS มีขนาดใหญ่กว่าคำสั่งหลายคำสั่ง
Kinesis ใช้เคส
SQS ใช้เคส