ไม่ว่าคุณจะเพิ่งเริ่มใช้ Redis หรือเพียงแค่ต้องการทบทวนคุณลักษณะที่พร้อมใช้งาน คู่มือนี้สามารถช่วยให้คุณเข้าใจโครงสร้างข้อมูลทั้งหมดที่ Redis มีให้
เลือกโครงสร้างที่เหมาะสม
โครงสร้างข้อมูล Redis นั้นเรียบง่าย — ไม่มีโครงสร้างใดที่เหมาะกับปัญหาที่คุณพยายามแก้ไข แต่ถ้าคุณเลือกโครงสร้างเริ่มต้นที่เหมาะสมสำหรับข้อมูลของคุณ คำสั่ง Redis สามารถแนะนำวิธีที่มีประสิทธิภาพในการรับสิ่งที่คุณต้องการ คำสั่ง Redis จำนวนมากมีคำนำหน้าซึ่งระบุประเภทของโครงสร้างข้อมูลพื้นฐานที่ต้องการใช้งาน
โครงสร้างข้อมูลเอนกประสงค์
| คำนำหน้า | การใช้งาน | ข้อควรระวังและการใช้ในทางที่ผิด | |
|---|---|---|---|
| แฮช | H | การจัดเก็บอ็อบเจ็กต์; อะไรก็ได้ที่คุณจะใช้วัตถุพจนานุกรมสำหรับ | เช่นเดียวกับ Redis เอง หนึ่งในปัญหาที่ใหญ่ที่สุดที่ผู้ใช้พบเกี่ยวกับ Hashes คือการจัดทำบัญชีหลัก ตรวจสอบให้แน่ใจว่าคุณมีระบบเพื่อให้แน่ใจว่าคุณจะไม่เติมแฮชด้วยคีย์และค่าที่คุณไม่ต้องการ |
| รายการ | ล | คิว สแต็ค และรายการวัฏจักร | อย่าพยายามเข้าถึงโดยสุ่มในรายการขนาดใหญ่ และระวังเกี่ยวกับการสำรองข้อมูลคิว |
| ตั้งค่า | ส | ระบบการติดแท็ก ที่เก็บข้อมูลสำหรับข้อมูลอนุกรมเวลา | ทางแยกและสหภาพต้องใช้ด้วยความระมัดระวัง - ให้ชุดของคุณมีขนาดเล็ก ชุดไม่ใช่วิธีที่ดีที่สุดในการนับจำนวนเฉพาะ ใช้ HyperLogLog แทน! |
| ชุดเรียง | Z | ตารางคะแนน การค้นหาคำศัพท์ รายการเข้าถึงโดยสุ่ม | Zsets เป็นหนึ่งในโครงสร้างที่หลากหลายที่สุด และยังเป็นหนึ่งในโครงสร้างที่แพงที่สุดอีกด้วย จับตาดูบิ๊ก O ของคุณอย่างใกล้ชิด! หากคุณกำลังใช้ชุดการจัดเรียงสำหรับการเติมข้อความอัตโนมัติ คุณอาจตรวจสอบ ZRANGEBYLEX ซึ่งจัดการการค้นหาคำศัพท์ (แต่ต้องระวังด้วย UTF-8!) |
| สตรีม | X | อนุกรมเวลา คิว การกระจายข้อความ | ความล้มเหลวในการแคปสตรีมเป็นเรื่องปกติ บางครั้งพวกเขาก็สับสนกับความสามารถของระบบส่งข้อความแบบกระจาย (โดยเฉพาะ Apache Kafka) |
| สตริง | (ไม่มี) | แคช ตัวนับ การจัดการบิตอย่างง่าย | โปรดใช้ความระมัดระวังเกี่ยวกับค่าที่มีขนาดใหญ่มาก GETting หรือ SETting ซึ่งอาจทำให้เกิดความล้มเหลวที่หายากในบางเครือข่ายและไคลเอ็นต์ Redis ทำร้ายตัวเองได้ง่ายๆ โดยใช้ SETNX เพื่อสร้างระบบล็อค |
โครงสร้างข้อมูลเฉพาะทาง
Redis มีการดำเนินการจำนวนหนึ่งสำหรับการจัดการกรณีพิเศษเฉพาะบางประเภท ในขณะที่ประเภท "ภายใต้ประทุน" เป็นหนึ่งในประเภทข้อมูลวัตถุประสงค์ทั่วไปข้างต้น:
| คำนำหน้า | ประเภทอ้างอิง | การใช้งาน | ข้อควรระวังและการใช้ในทางที่ผิด | |
|---|---|---|---|---|
| บิตแมป | บิต | สตริง | แฟล็กประหยัดพื้นที่สำหรับการวิเคราะห์ | ความสับสนเกี่ยวกับความสามารถหรือการสูญเสียการติดตามความซับซ้อนของการบัญชีในระบบที่ใช้บิตแมป |
| เคาน์เตอร์ | INCR, DECR | สตริง | การวิเคราะห์ที่ประหยัดพื้นที่ | โอเวอร์โฟลว์ของช่วงที่ลงชื่อ 64 บิตจะส่งคืนข้อผิดพลาด |
| โกฮาช | จีโอ | ชุดเรียง | ตัวระบุตำแหน่งร้าน ค้นหาผู้ใช้ที่อยู่ใกล้เคียง | ต้องใช้การคำนวณทางไกล ทุกที่ที่ต้องการการคาดการณ์เฉพาะทางหรือฟังก์ชันทางภูมิศาสตร์ที่ซับซ้อน |
| HyperLogLog | PF | สตริง | การนับจำนวนเฉพาะสำหรับการวิเคราะห์ | การรวม HLL หลายรายการเข้าด้วยกันอาจมีค่าใช้จ่ายสูง อย่าลืมจำกัดจำนวนพารามิเตอร์ที่คุณระบุใน PFMERGE |
| ผับ/ย่อย | PUB, SUB, PSUB | (ไม่มี) | ส่งข้อความชั่วคราว | ง่าย ส่งข้อความรวดเร็วโดยไม่มีความทนทาน ประเภทสตรีมเป็นตัวเลือกที่ดีกว่าสำหรับกรณีการใช้งานส่วนใหญ่ |
ใช้บิ๊กโอของคุณ
การใช้รูปแบบการเข้าถึงของโครงสร้างข้อมูลในทางที่ผิดก็เหมือนกับการใช้พจนานุกรมในทางที่ผิด:อย่าพลิกผ่านทุกหน้าเพื่อค้นหาคำ! ความซับซ้อนของเวลาของคำสั่ง Redis ทุกคำสั่งได้รับการบันทึกไว้ใน redis.io
Big O เป็นวิธีการแสดง "พฤติกรรมที่ จำกัด " สำหรับสิ่งที่จะทำ วิธีคิดง่ายๆ คือ การดำเนินการจะดำเนินการอย่างไรเมื่อปริมาณข้อมูลในระบบเพิ่มขึ้น หากการดำเนินการเป็น O(1) จะใช้เวลาที่กำหนดในการดำเนินการให้เสร็จสิ้น ไม่ว่าข้อมูลจะเกี่ยวข้องมากเพียงใด Anoperation ซึ่งเป็น O(n) จะปรับขนาดเชิงเส้นตามข้อมูล และค่าที่ isO(n²) จะช้าลงแบบทวีคูณเมื่อปริมาณข้อมูลเพิ่มขึ้น
สำหรับการรักษาที่ละเอียดยิ่งขึ้น โปรดดูคำแนะนำง่ายๆ เกี่ยวกับ big O พร้อมโค้ดตัวอย่างและกราฟ
การออกแบบระบบที่ดีต้องใช้มากกว่าการวิเคราะห์อัลกอริธึมพื้นฐาน แต่ก็คุ้มค่าที่จะทบทวนพื้นฐานเป็นครั้งคราว และพิจารณาความซับซ้อนโดยรวมของการเข้าถึงข้อมูลในแอปของคุณ
Keep Operations Small
Redis เป็นแบบเธรดเดียว ซึ่งทำให้ง่ายต่อการให้เหตุผล แต่ยังสร้างความประหลาดใจให้กับผู้ที่คุ้นเคยกับการเข้าถึงข้อมูลแบบมัลติเธรดเท่านั้น การดำเนินการระยะยาวใน Redis นั้นอันตรายกว่าในฐานข้อมูลอื่นๆ เนื่องจาก Redis ทำสิ่งเดียวเท่านั้นที่ เวลา การดำเนินการที่ใช้เวลานานอาจทำให้เกิดการสำรองข้อมูลทั้งระบบ
การรักษาการเข้าถึงข้อมูลอย่างละเอียดเป็นกุญแจสำคัญสู่ประสิทธิภาพที่ดีกับ Redis การดำเนินการ 100,000 O(1) ใน Redis อาจดีกว่าการดำเนินการ 1 O(N) บนคอลเล็กชัน 100,000 องค์ประกอบ แม้ว่าคุณจะต้องจ่ายค่าปรับเนื่องจากการแยกวิเคราะห์เครือข่ายและโปรโตคอล
คุณจะทราบจุดปวดในระบบของคุณได้อย่างไร? ตรวจสอบ SLOWLOG เป็นประจำ (หรือหากคุณเป็นลูกค้า RedisGreen ให้ดูที่แท็บ "Slow Queries" บนแดชบอร์ดของคุณ) ยิ่งการดำเนินการครั้งเดียวทำงานนานเท่าใด การดำเนินการอื่นๆ ที่ระบบของคุณพยายามจะทำก็จะช้าลงมากเท่านั้น ดังนั้นให้ดำเนินการให้สั้นลง!
