คุณอาจไม่จำเป็นต้องใช้ Redis

 (viblo.se)
9 คะแนน โดย GN⁺ 2025-03-10 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • Redis เป็นหนึ่งในเทคโนโลยีที่มีชื่อเสียงเชิงบวกมากที่สุดในอุตสาหกรรมเทคโนโลยี
    • เป็นเทคโนโลยีที่ยอดเยี่ยม ออกแบบมาอย่างดีมาก และไม่ได้มีข้อบกพร่องในตัวเอง แต่ อาจไม่ได้จำเป็นเสมอไป
  • ตลอด 10+ ปีที่ผ่านมา ผู้เขียนเห็นแพตเทิร์นเดียวกันใน 3 บริษัท:
    • มีปัญหาเกิดขึ้นและ Redis ดูเหมือนจะเหมาะสม แต่ในความเป็นจริงกลับไม่ได้ช่วยให้สถานการณ์ดีขึ้น หรือไม่ได้แก้ปัญหาที่ต้นตอ
    • มันเป็นเพียงการ เพิ่มความซับซ้อนเพื่อความซับซ้อนเท่านั้น

กรณีแรก: ประสบการณ์ที่ Tantan

  • Tantan เป็นแอปหาคู่ที่ใหญ่เป็นอันดับ 2 ของจีน และใช้งานเซิร์ฟเวอร์ฐานข้อมูลประสิทธิภาพสูง 50~100 เครื่องบน PostgreSQL
  • แต่ละเซิร์ฟเวอร์ถูกชาร์ดตาม user ID ดังนั้นข้อมูลของผู้ใช้แต่ละคนจะถูกเก็บไว้บนเซิร์ฟเวอร์เพียงเครื่องเดียว
  • สถานการณ์ปัญหา
    • มีความต้องการให้บันทึกจำนวนครั้งของการ "ปัด" และอัปเดตได้อย่างรวดเร็ว
    • ในตอนแรกตัดสินใจว่าการเก็บไว้ใน Redis น่าจะเหมาะสม
    • คิดว่าเพียงมีเซิร์ฟเวอร์ Redis ประสิทธิภาพสูงไม่กี่เครื่องก็น่าจะเพียงพอ จึงเริ่มตั้งค่า
  • ทบทวนและแนวทางแก้ไข
    • ภายในทีมมีการพูดคุยถึงแนวทางเก็บข้อมูลลง PostgreSQL โดยตรงแทน Redis
    • เนื่องจากโหลดของเซิร์ฟเวอร์ PostgreSQL สูงอยู่แล้ว จึงคาดว่าโหลดที่เพิ่มขึ้นจะมีน้อยมาก
    • หลังจากเก็บข้อมูลลง PostgreSQL ก็ไม่พบการลดลงของประสิทธิภาพ ทำให้การนำ Redis มาใช้ไม่จำเป็น

กรณีที่สอง: ประสบการณ์ที่ Bannerflow

  • เบื้องหลัง
    • Bannerflow เป็นแพลตฟอร์มสำหรับสร้างและเผยแพร่โฆษณา
    • มีการตัดสินใจนำ Redis มาใช้ในไมโครเซอร์วิสใหม่ เพื่อรองรับการเผยแพร่โฆษณาไปยังโซเชียลเน็ตเวิร์กอย่าง Facebook
  • สถานการณ์ปัญหา
    • เมื่อเทียบกับ Tantan แล้ว โหลดต่ำกว่ามาก จึงไม่ชัดเจนว่าจำเป็นต้องใช้ Redis หรือไม่
    • หลังจากนักพัฒนาเริ่มต้นออกจากทีมไป ก็ไม่มีใครอธิบายเหตุผลของการนำ Redis มาใช้ได้อย่างชัดเจน
  • ผลลัพธ์
    • Redis ไม่ได้จำเป็นจริง ๆ เพราะโหลดต่ำ
    • ในระยะยาวจึงสรุปว่าทางเลือกที่ดีที่สุดคือการถอด Redis ออก

กรณีที่สาม: ประสบการณ์ที่ MAJORITY

  • เบื้องหลัง
    • MAJORITY เป็นบริษัทฟินเทคที่นำ Redis มาใช้เพื่อแคชผลลัพธ์จากการเรียก external API
    • Redis ถูกนำมาใช้เพื่อแคชข้อมูลการค้นหาตำแหน่ง ช่วยให้ประมวลผลเร็วขึ้นและลดต้นทุน
  • สถานการณ์ปัญหา
    • ข้อมูลเดียวกันนี้ถูกเก็บอยู่ใน DB (Azure SQL) ด้วย
    • คาดว่าแม้จะเปลี่ยนจากการเรียก Redis ไปเป็นการเรียก DB ก็แทบจะไม่เพิ่มโหลด
    • เดิมต้องการใช้ Redis ต่อเพราะจำเป็นต้องมีการจัดการ lock แต่พบว่า Azure SQL ก็รองรับได้เพียงพอ
  • ผลลัพธ์
    • สรุปว่าการนำ Redis มาใช้ไม่จำเป็น
    • จัดทำแผนเปลี่ยนไปใช้ Azure SQL แทน Redis

บทสรุป

  • ทั้งสามกรณีเกิดขึ้นในโดเมน เทคโนโลยีสแต็ก และเงื่อนไขโหลดที่แตกต่างกัน
  • จุดร่วมคือมีการนำ Redis มาใช้โดยไม่จำเป็น
  • ก่อนนำ Redis มาใช้ ควรพิจารณาความจำเป็นจริงและประโยชน์ด้านประสิทธิภาพให้รอบคอบ
  • แนะนำให้ดูบรรยาย 'Choose Boring Technology' ของ Dan McKinley

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
iolothebard 2025-03-10

ไม่ว่าคุณจะใช้ Redis หรือไม่ การแทรกชั้นแคชไว้ระหว่างโดเมนกับ persistence (โดยให้การทำงานพื้นฐานเป็นแบบ bypass) ไม่ใช่การ overengineering เลยแม้แต่น้อย ใช้ได้กับการทำ logging, ข้อมูลปลอม, debugging, profiling และอาจรวมถึงการแคชจริง ๆ ด้วย…
 
nodelay 2025-03-10

+1 ผมก็เห็นด้วยครับ แค่เพิ่มอีกหนึ่งเลเยอร์ก็สร้าง ช่องว่าง ขึ้นมาได้ และทำให้มีพื้นที่สำหรับแก้ปัญหาสารพัดอย่างได้ด้วย
 
galadbran 2025-03-10

ดูเหมือนว่าแทนที่จะมองว่า Redis มีปัญหา ประเด็นคือถ้าแค่ DB อย่างเดียวก็เพียงพอแล้ว ทำไมต้องเพิ่มองค์ประกอบเข้าไปอีกจนภาระในการดูแลจัดการสูงขึ้น
บทความนี้อธิบายค่อนข้างย่อ ๆ ดังนั้นน่าจะรับไว้ในแง่ว่าเป็นอีกมุมมองหนึ่งที่ควรลองคิดดู
ทั้งนี้ก็มีสถานการณ์ที่การนำ Redis cache มาใช้พร้อมกับคงตรรกะของแอปพลิเคชันให้เรียบง่าย อาจเป็นทางเลือกที่ดีกว่าได้เช่นกัน
สุดท้ายก็ควรเลือกให้เหมาะกับสถานการณ์ครับ
 
zinisuni 2025-03-24

โดนพาดหัวหลอกเลยนะครับ 555 เห็นด้วยครับ~~
 
GN⁺ 2025-03-10
ความคิดเห็นจาก Hacker News

  • ตอนทำงานที่ Uber ในปี 2015 มีความพยายามเปลี่ยนการแบ่งพื้นที่เชิงภูมิศาสตร์ตามรหัสไปรษณีย์ไปเป็นวิธีที่อิงกับหกเหลี่ยม

    • แทนที่จะแบ่งเมืองออกเป็นรหัสไปรษณีย์ไม่กี่สิบส่วน ก็เปลี่ยนเป็นแบ่งด้วยหกเหลี่ยมหลายแสนช่องและสร้างขอบเขตแบบไดนามิก
    • เปิดตัวครั้งแรกที่ฟีนิกซ์ และทีมก็โต้รุ่งเพื่อขยายระบบ surge pricing
    • การเปิดตัวทั่วโลกล่าช้าออกไป
    • มีวิศวกรจำนวนมากที่ชอบ Redis
    • บริการด้านราคาทำงานบน Redis และรองรับคำขอได้หลายล้านครั้ง
    • มีค่าใช้จ่ายสูงและมีปัญหาเรื่องการขยายระบบ
    • ปรับปรุงอัลกอริทึมจนสามารถคำนวณขอบเขตแบบไดนามิกของหลายเมืองได้บนเครื่องเดียว
    • วิศวกรคนหนึ่งชื่อ Isaac ลงมือทำและนำขึ้นใช้งานภายในช่วงสุดสัปดาห์

  • มีการถกเถียงกันเรื่องการใช้ Redis มากเกินไป

    • Redis เจ๋งก็จริง แต่เมื่อใช้งานจะมี network latency และ serialization overhead
    • ถ้าข้อมูลถูกแบ่งพาร์ทิชันไว้อยู่แล้ว hash map ทั่วไปอาจดีกว่า
    • ใน Java มีทั้ง ConcurrentHashMap, Guava Caches และ Caffeine Caches
    • การทำ local cache มักจะเร็วกว่าใช้เครือข่ายแทบทุกครั้ง
    • Redis มีแนวโน้มถูกใช้งานมากเกินไป

  • วัฒนธรรมการใช้งาน Redis ยังพัฒนาไม่ทันความนิยมของมัน

    • Redis รองรับโครงสร้างข้อมูลหลากหลาย และเมื่อวัฒนธรรมในองค์กรพัฒนามากขึ้น ก็จะเรียนรู้แพตเทิร์นเพิ่มขึ้นได้
    • น่าเสียดายที่ยังไม่มีชุดรวมแพตเทิร์นของ Redis

  • ประเด็นไม่ได้อยู่ที่ Redis หรือไม่ใช่ Redis แต่เป็นปัญหาของการทำงานกับข้อมูลที่ serialize ได้ไม่ดี

    • ข้อมูลอย่างตัวนับ ฟีดข่าว และข้อความแชต อาจใช้ Redis ได้มีประสิทธิภาพกว่า
    • แต่ในกรณีส่วนใหญ่ MySQL ก็รับมือได้เพียงพอ

  • การพัฒนาซอฟต์แวร์มักมีแนวโน้มทำซ้ำวิธีของคนอื่น

    • เริ่มจาก Memcached แล้วค่อยพัฒนาไปเป็น Redis
    • มีแนวโน้มใช้แคชเพื่อหลีกเลี่ยงความซับซ้อนของฐานข้อมูล
    • แต่ฐานข้อมูลก็ยังซับซ้อนและยากอยู่ดี

  • Redis คือ "data structure server" เพียงตัวเดียวที่พร้อมใช้ในโปรดักชัน

    • มีประโยชน์เมื่อหลายอินสแตนซ์ต้องเข้าถึงบริการเดียวกัน

  • คุณอาจไม่จำเป็นต้องมีแคช

    • มีประสบการณ์ที่โฟกัสกับการปรับปรุงสถาปัตยกรรมโดยไม่เพิ่มแคชเข้ามา

  • API ของ Redis ยอดเยี่ยม แต่มีความเสี่ยงด้านการปฏิบัติการ

    • เหมาะเป็นแคช แต่เชื่อถือไม่ได้ในฐานะที่เก็บข้อมูลโปรดักชัน

  • น่าประหลาดใจกับแนวโน้มที่ไม่ค่อยแนะนำให้ใช้ Redis

    • Redis ยังมอบทั้งโครงสร้างข้อมูลที่ยอดเยี่ยมและประสิทธิภาพที่ดีอยู่เสมอ

  • Redis ใช้เป็นแคชชั่วคราวได้ดี แต่ยังไม่พอสำหรับทรานแซกชันหรือระบบจัดเก็บแบบกระจายศูนย์

    • จำเป็นต้องเรียนรู้ปัญหาเรื่อง distributed lock