AWS ElastiCache / SimpleQueue vs DynamoDB

ฉันสงสัยเกี่ยวกับเหตุผลในการใช้ ElastiCache / SimpleQueue vs เพิ่งมีตาราง "Cache" และ "Queue" ใน DynamoDB ตามลำดับ

ดูเหมือนว่าเวลาแฝงของเครือข่ายไปยังบริการ Cache / Queue จะดีกว่าประสิทธิภาพที่เพิ่มขึ้นและการที่ EC2 ปฏิบัติกับเครื่องปั่นไฟเนื่องจากบริการแคช / คิวจะให้บริการเวลาแฝงและปริมาณงานที่เท่ากัน (เนื่องจากเครื่องปั่นไฟอนุญาตให้แฝงต่ำ โหลด)

มันเกี่ยวกับราคาของไดนาโมเทียบกับบริการอื่น ๆ เป็นหลักหรือไม่?

ไม่มีใครมีหมายเลขแฝงที่หยาบเปรียบเทียบไดนาโมกับ ElastiCache / SQS หรือไม่?

มีการพิจารณาที่สำคัญอื่น ๆ อีกหรือไม่ที่ฉันคิดถึงซึ่งทำให้ความซับซ้อนเพิ่มขึ้น?

ขอบคุณ

เราใช้ DynamoDB และ ElastiCache Redis ด้วยเหตุผลที่แตกต่างกัน

DynamoDB:

• มีภาษาแบบสอบถามซึ่งสามารถทำสิ่งที่ซับซ้อนมากขึ้น (มากกว่าระหว่าง ฯลฯ )
• สามารถเข้าถึงได้ผ่าน API ภายนอกที่เชื่อมต่อกับอินเทอร์เน็ต (ภูมิภาคต่างๆสามารถเข้าถึงได้โดยไม่มีการเปลี่ยนแปลงหรือโครงสร้างพื้นฐานของตัวเอง)
• สิทธิ์ตามตารางหรือแถวเป็นไปได้
• ปรับขนาดในแง่ของขนาดข้อมูลเป็นไม่ จำกัด
• คุณจ่ายตามคำขอ -> หมายเลขคำขอต่ำหมายถึงใบเรียกเก็บเงินที่เล็กลงหมายเลขคำขอสูงหมายถึงใบเรียกเก็บเงินที่สูงขึ้น
• การอ่านและการเขียนมีค่าใช้จ่ายต่างกัน
• ข้อมูลถูกบันทึกซ้ำซ้อนโดย AWS ในศูนย์บริการหลายแห่ง
• DynamoDB มีวางจำหน่ายแล้ว
• การหาสัญญาณอัตโนมัติมีอยู่ในบริการ

ElastiCache Redis:

• ภาษาของแบบสอบถามอย่างง่าย - ไม่มีคุณสมบัติที่ซับซ้อน
• Is (นอกกรอบ) ไม่สามารถเข้าถึงได้จากภูมิภาคอื่น
• คุณถูก จำกัด จำนวนหน่วยความจำเสมอ (หรือผลรวมของอินสแตนซ์หลักทั้งหมดในคลัสเตอร์)
• การใช้ Sharding ผ่านหลายอินสแตนซ์ทำได้เฉพาะในแอปพลิเคชันของคุณ - Redis ไม่ได้ทำอะไรที่นี่ (Redis cluster ช่วยได้ที่นี่ แต่ตรรกะ Sharding ยังคงอยู่ในไดรเวอร์ / sdk ที่คุณใช้ในแอปพลิเคชันของคุณ) เป็นไปไม่ได้หากไม่มีเวลาหยุดทำงาน
• คุณจ่ายตามอินสแตนซ์ไม่ว่าการโหลดหรือจำนวนการร้องขอจะเป็นอย่างไร
• หากคุณต้องการความซ้ำซ้อนของข้อมูลคุณจำเป็นต้องตั้งค่าการจำลองแบบ (เป็นไปไม่ได้ระหว่างภูมิภาคต่าง ๆ )
• คุณต้องใช้แบบจำลองเพื่อความพร้อมใช้งานสูง
• ไม่มีการปรับค่าอัตโนมัติ (ดูส่วนที่เกี่ยวกับการปรับขนาดที่ด้านบน)

ดังนั้นการตั้งค่าของเราส่วนใหญ่เวลา: แคชง่าย ๆ ที่มีการร้องขอจำนวนมากใน Redis ที่ได้รับการสนับสนุนโดย DynamoDB เป็นที่เก็บถาวรและทนทาน ด้วยสิ่งนี้เรา จำกัด ค่าใช้จ่ายเมื่อเราได้รับส่วนลดโดยนัยสำหรับการอ่านของเราโดยรุ่นจ่ายต่ออินสแตนซ์ของ Redis แต่ยังได้รับประโยชน์จากความซ้ำซ้อนของ DynamoDB และสามารถใช้ภาษาแบบสอบถาม DynamoDB สำหรับสิ่งที่ซับซ้อนมากขึ้น ( ถ้าเราต้องการมัน)

หวังว่าจะช่วย!

อัปเดต: ด้วยการประกาศของ Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ) เรากำลังเปลี่ยนไปใช้ DAX เหมือนเดิม (ในที่สุด) สิ่งที่เราทำกับ การรวมกันของ DynamoDB และ Redis เนื่องจาก DAX นั้นจัดการโดย AWS อย่างเต็มที่และให้โอกาสเราในการใช้ภาษา DynamoDB ในแอปพลิเคชันของเราเสมอ แต่ยังได้รับประโยชน์จากแคชการเขียนผ่านเช่น Redis

เหตุผลหลักที่เราใช้ Elasticache แทน DynamoDB คือความเร็ว - คุณจะได้รับเวลาแฝงในการเดินทางไปกลับ 1 มิลลิวินาทีสำหรับวัตถุขนาดเล็ก กล่องนั้นใกล้กับเครื่อง EC2 ของคุณและหน่วยความจำนั้นเร็วกว่าดิสก์มากแม้แต่ SSD

อาจมีความได้เปรียบด้านต้นทุนด้วยโมเดลการกำหนดราคาที่แตกต่างกันถึงแม้ว่าฉันจะไม่ได้ลงรายละเอียดมากขนาดนั้น

Redis / memcached เป็นร้านค้าในหน่วยความจำและโดยทั่วไปควรจะเร็วกว่า DynamoDB สำหรับแคช / ข้อมูลประเภทคิว พวกเขายังมีรายการเพิ่มเติมที่สะดวกเช่นกุญแจหมดอายุ Pub / Sub ใน Redis ฯลฯ ที่ Dynamo อาจไม่มี