Redis และราคาที่ต้องจ่ายของความทะเยอทะยาน

 (charlesleifer.com)
4 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Redis กำลังพิจารณา PR สำหรับ array type ไปจนถึงปี 2026 ซึ่งสะท้อนว่ามันได้เปลี่ยนจากเซิร์ฟเวอร์โครงสร้างข้อมูลแบบเรียบง่าย ไปเป็นผลิตภัณฑ์ที่พยายามครอบคลุมหลายด้าน
  • Redis ในยุคแรกสมชื่อ Remote Dictionary Server ด้วยการเป็นดิกชันนารี in-memory ที่รวดเร็ว มีชุดคำสั่งแคบ โปรโตคอลเรียบง่าย และเข้าไปอยู่ในเว็บสแตกได้อย่างรวดเร็ว
  • ตลอด 10 ปีที่ผ่านมา Redis ได้ขยายไปสู่ Streams, JSON, search, graph, time-series, Redis-Raft, vector sets ฯลฯ จนมีแนวโน้มไปทาง database อย่างชัดเจน
  • การพองตัวของฟีเจอร์ทำให้จุดแข็งเดิมของ Redis อย่าง ความเรียบง่ายและความสม่ำเสมอ อ่อนลง และเพิ่มการรวมฟังก์ชันแบบยังไม่สุกงอมในพื้นที่ที่จริง ๆ ต้องใช้เครื่องมือเฉพาะทาง
  • Valkey เลือกโฟกัสที่ ประสิทธิภาพแบบมัลติเธรด, ประสิทธิภาพการใช้หน่วยความจำ และความน่าเชื่อถือของคลัสเตอร์ มากกว่าการไล่ตามฟีเจอร์หวือหวา โดยมุ่งจับฐานผู้ใช้ Redis แบบปี 2011

อัตลักษณ์ที่ Redis ทำหายไป

  • Redis เดินมาถึงจุดที่ในปี 2026 กำลังพิจารณา PR ขนาดใหญ่เพื่อเพิ่ม array type แล้ว และนี่เป็นสัญลักษณ์ว่ามันเปลี่ยนจาก data structure server แบบเรียบง่าย ไปเป็นผลิตภัณฑ์ที่พยายามครอบคลุมหลายขอบเขต
  • array type PR ของ antirez เริ่มต้นจากปัญหาที่ว่า Hash, List และ Stream ต่างก็มีจุดเด่นในเรื่องการเข้าถึงแบบสุ่ม, append/trim และอีเวนต์แบบ append-only ตามลำดับ แต่ไม่มีตัวไหนให้ทั้งการเข้าถึงตรงกลางแบบอาร์เรย์และการมองเห็นช่วงข้อมูลได้พร้อมกัน
  • ใน Redis มีความสามารถที่ใช้แทนอาร์เรย์ได้อยู่แล้ว เช่น JSON array, time-series และ sorted-set แต่การที่ยังมุ่งจะเพิ่ม type ใหม่เข้าไปอีก ก็ยิ่งแสดงให้เห็นธรรมชาติของการขยายฟีเจอร์นี้ชัดเจน
  • ปัญหาแกนกลางคือสิ่งที่เคยทำให้ Redis ประสบความสำเร็จในตอนแรกอย่าง ความเรียบง่าย, โปรโตคอลที่ชัดเจน, ชุดคำสั่งที่แคบและเป็น orthogonal และความสม่ำเสมอเชิงแนวคิด กำลังอ่อนแรงลง

การเปลี่ยนแปลงในช่วง 10 ปีที่ผ่านมา

  • ใบอนุญาตและทิศทางของบริษัท

    • Redis Inc ยุติ BSD license ในปี 2024 และถอยไปใช้ระบบใบอนุญาตแบบสามทางที่มี AGPLv3 เป็นตัวเลือกแบบ OSI เพียงตัวเดียว
    • ด้วย AGPLv3 ทำให้ Redis Inc ยังพูดได้ว่าเป็นโอเพนซอร์ส แต่ลักษณะของใบอนุญาตนี้ต่างจาก BSD อย่างมาก
    • บริษัทที่มีเงินทุน VC อยู่เบื้องหลัง Redis เดิมคือ Garantia Data ซึ่งเป็นบริการ cloud hosting สำหรับ NoSQL ก่อนจะย้ายมาทำ Redis hosting เปลี่ยนชื่อบริษัทให้เป็นสาย Redis และดึง antirez เข้ามาเพื่อสร้างความชอบธรรม
    • กระบวนการรับโอนสิทธิ์เครื่องหมายการค้าในอีกหลายปีต่อมา กลายเป็นฐานสำคัญของการเปลี่ยนใบอนุญาตภายหลัง และบทความกับคอมเมนต์เก่า ๆ ที่เกี่ยวข้องก็ ดูเก่าตามคาด

  • การพองตัวของฟีเจอร์และการวางตำแหน่งผลิตภัณฑ์

    • Redis เริ่มจาก data type ที่มีประโยชน์เพียงไม่กี่ชนิด แต่เมื่อเวลาผ่านไปกลับรองรับทั้งโครงสร้างข้อมูลแปลกใหม่ ระบบ stateful ที่ซับซ้อนอย่าง Streams รวมถึงโมดูลที่ในบางเวอร์ชันมีลักษณะกึ่งผูกขาด
    • ในปี 2026 ตำแหน่งทางการตลาดบนหน้า landing page ของ Redis เปลี่ยนเป็น “The Real-Time Context Engine for AI Apps”
    • บน landing page มีทั้งปุ่ม “Try Redis for Free” และ “Get a Demo” ซึ่งดูได้จากภาพหน้าจอ

  • มุ่งสู่ฐานข้อมูลระดับเว็บสเกล

    • ฟีเจอร์อย่าง Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® แสดงให้เห็นว่า Redis มุ่งไปสู่การเป็น “webscale database” มาโดยตลอด

  • การเปลี่ยนแปลงของโปรโตคอลและ client-side caching

    • RESP3 มีหลายจุดที่ทำลายสมมติฐานพื้นฐานของ RESP2 ซึ่งยึดโมเดล request/response และถูกมองว่าใกล้เคียงกับลักษณะความล้มเหลวของระบบที่สองตามที่ Brooks เคยพูดถึง
    • เดิม Redis ถูกใช้อย่างแพร่หลายเป็นแคช แต่ตอนนี้กลับอยู่ในสภาพที่ต้องมีโปรโตคอลใหม่เพื่อรองรับ client-side caching

เหตุผลที่ Redis ยุคแรกลงตัวได้ดี

  • บริบทยุคสมัย

    • ราวปี 2011 ในหมู่นักพัฒนาเว็บมีกระแส NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST และ JSON อย่างเข้มข้น
    • Redis เข้ากับบรรยากาศนี้ได้พอดี และแทบจะกลายเป็นเครื่องมือที่เข้าไปอยู่ในหลายสแตกชั่วข้ามคืน
    • คำแนะนำ Redis ช่วงปลายปี 2011 อธิบายตัวเองว่าเป็น advanced key-value store และ data structure server โดยยังไม่มีคำว่า “database”

  • ดิกชันนารีระยะไกลที่ดีกว่า Memcached

    • memcached เป็นโครงสร้างพื้นฐานสำคัญที่ทำงานเงียบ ๆ อยู่ในเว็บเซิร์ฟเวอร์จำนวนมาก และนอกจากแคชแล้วยังมักถูกใช้ชั่วคราวกับงานอย่าง lock, counter และ rate limit
    • ในเวลานั้น Redis ถูกมองว่าใกล้เคียงกับ “memcached but way better” และชื่อ Remote Dictionary Server ก็ย้ำตัวตนว่าเป็นดิกชันนารี in-memory ที่รวดเร็ว
    • Redis ไม่ได้รองรับแค่ byte blob แต่ยังมีโครงสร้างข้อมูลที่เลือกมาอย่างดีอย่าง linked-list, hash-table, set และ sorted-set จึงขยายกรณีใช้งานเชิงปฏิบัติแบบชั่วคราวได้มาก

  • โปรโตคอลที่เรียบง่ายแต่แสดงออกได้เพียงพอ

    • wire protocol ของ Redis เรียบง่ายพอจะเข้าใจและเขียน implement ได้ภายในหนึ่งชั่วโมง แต่ก็ทรงพลังพอสำหรับการแทนข้อมูลหลายชนิด
    • การทำ client library จึงเรียบง่ายและสะอาด และตัวโปรโตคอลเองก็ให้ความรู้สึกเป็นธรรมชาติ
    • บทความสอน write your own Redis ซึ่งให้สร้างทั้ง Redis protocol และเซิร์ฟเวอร์อย่างง่ายด้วยตัวเอง ยังคงเป็นบทความยอดนิยมที่เขียนไว้ราว 10 ปีก่อน

  • single-thread, event-driven, in-memory

    • การออกแบบแบบ single-thread ของ Redis รับประกันความเป็น atomic ของทุก operation ทำให้ลดความซับซ้อนและช่วยให้ให้เหตุผลกับระบบได้ง่ายขึ้นมาก
    • เพื่อให้ single-thread ใช้งานได้จริง เซิร์ฟเวอร์จึงต้องเขียนด้วย non-blocking I/O และการดำเนินการกับข้อมูลก็ต้องเร็วมากด้วย
    • การผสมกันนี้ทำให้ key/value store ที่รวดเร็วและรองรับ client จำนวนมากทำงานได้ด้วยเธรดเดียว

  • โครงสร้างข้อมูลที่เหมาะกับเว็บแอปพลิเคชัน

    • string และเวลาหมดอายุเหมาะกับแคช, list เหมาะกับคิว, ส่วน hash เหมาะกับข้อมูลที่มีโครงสร้าง
    • งานอย่าง lock, counter, rate limiting, liveness, monitoring และ leaderboard ก็ประกอบขึ้นได้ง่ายจาก data type ที่มีมาให้ในตัว

ความทะเยอทะยานที่จะเป็นฐานข้อมูล

  • การยอมรับ Redis เติบโตอย่างรวดเร็วและประสบความสำเร็จอย่างมาก แต่เมื่อถึงจุดหนึ่ง ความทะเยอทะยานของโปรเจกต์ก็เปลี่ยนไปในทิศทางที่จะเป็น database
  • บางฟีเจอร์มีประโยชน์จริง เช่น BZPOPMIN ที่เพิ่มใน Redis 5.0 ซึ่งทำให้ใช้ sorted-set เป็น priority queue พร้อม blocking pop ได้ จึงใช้งานได้จริงมากขึ้น
  • ในทางกลับกัน ฟีเจอร์อย่าง ACL ดูไม่ค่อยเป็น Redis นัก และภาพรวมก็ชัดว่ามีความต้องการจะทำให้ Redis เป็นทุกอย่างสำหรับทุกคน
  • การเพิ่มฟีเจอร์ของ Redis ยังสอดคล้องกับ “ของฮิตล่าสุด” ที่นักพัฒนาใน Hacker News พูดถึงกันตลอด 10 ปีที่ผ่านมา
    • เมื่อ MongoDB เก็บ JSON ได้ Redis ก็ต้องเป็น document database ด้วย
    • เมื่อ ElasticSearch ให้ full-text search ได้ Redis ก็ต้องเป็น search engine ด้วย
    • เมื่อ graph database ได้รับความสนใจ Redis ก็พยายามเป็น graph database เช่นกัน แต่สุดท้ายก็นำไปสู่ RedisGraph EOL
    • เมื่อ Kafka ได้รับความสนใจ Redis ก็พยายามเป็น event streaming platform
    • เมื่อ ZooKeeper และฐานข้อมูลแบบ strong consistency มีความสำคัญขึ้น ก็เกิด Redis-Raft ขึ้นมา โดย บทวิเคราะห์ Jepsen ของ Aphyr ถือเป็นงานที่แทบจะต้องอ่าน
    • เมื่อ InfluxDB ได้รับความสนใจ Redis ก็พยายามเป็น time series database
    • และเพื่อไม่ให้ตกขบวน AI ก็ต้องมีฟีเจอร์ฝั่ง AI อย่าง vector sets

ราคาที่ต้องจ่ายของการขยายฟีเจอร์

  • ปัญหาแรกคือ Redis กำลังบั่นทอนปัจจัยที่ทำให้มันกลายเป็นเครื่องมือจำเป็นในสแตกของทุกคนเสียเอง
    • Redis เคยเรียบง่าย, คำสั่งเป็น orthogonal และนิยามแคบ, โปรโตคอลสะอาด และเป็นเครื่องมือที่สม่ำเสมอเชิงแนวคิด
  • ปัญหาที่สองคือ ผู้ใช้ที่ต้องการรวม full-text search, event stream processing, strong-consistency key/value, time-series และ vector storage อย่างจริงจัง ย่อมต้องการ เครื่องมือเฉพาะทาง ไม่ใช่โมดูลแบบยังไม่สุกงอมที่สืบทอดข้อจำกัดของ Redis มา
  • ความพร้อมใช้งานสูงของ Redis มีความซับซ้อน ความคงทนของข้อมูลก็มี trade-off ที่ละเอียดอ่อน และภาระจากโปรโตคอลรวมถึงความกระจัดกระจายของ client ก็เป็นอุปสรรคจริง
  • มุมมองนี้ชี้ว่า Redis ไม่ใช่เครื่องมือที่จะมาแทน Postgres และระบบอย่าง ElasticSearch หรือ RabbitMQ ก็ควรยังคงเป็นเสาหลักของตัวเองต่อไป
  • บทวิเคราะห์ implementation แรก ๆ ของ Redis-Raft โดย Aphyr ระบุว่าพบปัญหาถึง 21 รายการ
    • ใช้งานไม่ได้เป็นเวลานานแม้ในคลัสเตอร์ที่ยังปกติ
    • crash 8 กรณี
    • stale read 3 กรณี
    • aborted read 1 กรณี
    • บั๊ก 5 กรณีที่นำไปสู่การสูญหายของ committed update
    • infinite loop 1 กรณี
    • ปัญหา 2 กรณีที่ทำให้ส่ง response ที่เสียหายเชิงตรรกะไปยัง client ได้
    • เวอร์ชันแรกที่ทดสอบคือ 1b3fbf6 ถูกประเมินว่าแทบใช้งานไม่ได้เลย
  • Redis ในฐานะแคชและ data structure server กับ Redis ที่มุ่งเป็น “Redis the etcd” หรือฐานข้อมูลเฉพาะทางอื่น ๆ นั้น เป็นข้อเสนอที่ต่างกันโดยพื้นฐาน และช่องว่างนี้เองคือปัญหาหลัก

Disque เผยให้เห็นรูปแบบเดียวกัน

  • antirez เปิดตัว Disque ในปี 2015 และยอมรับว่าไม่ได้เริ่มจาก use case จริง แต่เป็นการออกแบบในโหมด “astronaut mode” จากการเห็นคนใช้ Redis เป็น message queue และเห็น message queue ตัวอื่น ๆ
  • โปรเจกต์ที่ทำขึ้นจากความท้าทายส่วนตัวหรือเพื่อการเรียนรู้โดยไม่มี use case จริงก็อาจยอดเยี่ยมได้ แต่การจะตามแก้ปัญหายาก ๆ ระยะยาวที่โผล่มาหลังผู้ใช้เพิ่มขึ้นเรื่อย ๆ ได้หรือไม่นั้นเป็นอีกเรื่องหนึ่ง
  • การส่งข้อความแบบ high availability เป็นปัญหาที่ยากจะทำให้ดีจริง และไม่ว่าจะเลือก optimize ด้านไหนของ CAP theorem ก็หนี trade-off และปัญหายาก ๆ ไม่พ้น
  • ในปี 2015 ก็มี message broker ที่โตเต็มที่อยู่แล้วมากมาย และเหตุผลที่คนใช้ Redis เป็น message broker ก็เพราะพวกเขาใช้งาน Redis อยู่แล้ว และมันเรียบง่ายพอ
  • สิ่งที่ต้องการไม่ใช่ message broker ตัวใหม่ และไม่ใช่การทำให้ Redis กลายเป็น message broker ที่ซับซ้อนขึ้น
  • Disque แทบกลายเป็น abandonware ทันทีหลังเปิดตัว และแม้จะมี 8K stars บน GitHub ก็ยังถูกปล่อยทิ้งไว้
  • หลังจากนั้นมันถูกเขียนใหม่เป็น Redis module แต่โปรเจกต์นั้นก็ถูกปล่อยทิ้งมาแล้ว 7-8 ปีเช่นกัน

Valkey ชี้ให้เห็นอีกทิศทางหนึ่ง

  • แรงผลักที่ขับเคลื่อนเส้นทางของ Redis ผูกอยู่กับความทะเยอทะยานของนักพัฒนาที่อยากแก้ปัญหาซับซ้อน ความทะเยอทะยานที่จะเป็นทุกอย่างสำหรับทุกคน และความทะเยอทะยานของเจ้าของ Redis ที่ต้องการรีดรายได้สูงสุดก่อนพ่ายให้ AWS และ GCP
  • ความทะเยอทะยานเองไม่ใช่ปัญหา แต่จะกลายเป็นปัญหาเมื่อมันทำให้สูญเสียเหตุผลที่เคยประสบความสำเร็จ
  • การมีอยู่และการยอมรับของ Valkey ถูกเสนอให้เป็นคำตัดสินสุดท้ายของตลาดที่กว้างขึ้นต่อพลวัตนี้
  • แทนที่จะไล่ตามฟีเจอร์หรือ bullet point ในตารางเปรียบเทียบ Valkey กลับลงทุนกับงานที่ไม่หวือหวาอย่างประสิทธิภาพแบบมัลติเธรด, ประสิทธิภาพการใช้หน่วยความจำ, ความน่าเชื่อถือของคลัสเตอร์ และการปรับปรุง throughput
  • benchmark ด้านประสิทธิภาพของ Valkey น่าประทับใจ และมันกำลังเล็งเป้าแบบตรง ๆ ไปยังผู้ใช้ Redis 80% ที่ฟีเจอร์ระดับ Redis ปี 2011 ก็เพียงพอแล้ว
  • ในโลกของ Valkey บทสรุปคือไม่จำเป็นต้องมี array type ใหม่

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

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

 
GN⁺ 4 시간 전
ความเห็นจาก Lobste.rs

  • ในมุมของคนที่เคยขยายโอเพนซอร์สให้ใหญ่พอสมควร ตั้งบริษัท สร้างรายได้ระดับหลายร้อยล้านดอลลาร์ ผ่านทั้ง IPO และการขายกิจการระดับหลายพันล้านดอลลาร์มาแล้ว รวมถึงเคย เปลี่ยนไลเซนส์ออกจาก OSS ด้วย การวางตำแหน่งของ Redis ว่าเป็น “เอนจินบริบทแบบเรียลไทม์สำหรับแอป AI” ก็ดูเหมือนจะมาถูกทาง
    ในการซื้อซอฟต์แวร์นั้นมีทั้งผู้ใช้งานจริงและ ผู้มีอำนาจตัดสินใจด้านเทคนิค (TDM) และหน้า landing page ของ Redis ก็ดูเหมือนจะเล็งไปที่ TDM ที่ถือ งบ มากกว่านักพัฒนาผู้ใช้งานจริง หลายคนในกลุ่ม TDM ชอบการตัดสินใจแบบ “ไม่มีใครถูกไล่ออกเพราะเลือก IBM” คือเลือกสิ่งที่ปลอดภัยต่อหน้าที่การงาน และเมื่อ Gartner หรือ McKinsey เน้นเรื่องกลยุทธ์ AI กับการจัดการบริบท คำว่า “Context Engine สำหรับแอป AI” ก็กลายเป็นเหตุผลในการซื้อที่ป้องกันตัวเองได้
    ที่ HashiCorp ก็เคยพยายามแยก terraform.io สำหรับคนทำงานจริง กับ hashicorp.com สำหรับ TDM ซึ่งก็ได้ผลในระดับหนึ่งแต่ก็มีข้อจำกัด นี่เป็นปัญหาที่ยากสำหรับบริษัท OSS ที่ขับเคลื่อนโดยนักพัฒนา
    ปุ่ม “ใช้ Redis ฟรี” กับ “ขอเดโม” ก็ไม่ได้แปลกในมุมมองของ TDM เช่นกัน เพราะ TDM ไม่อยากรับภาระการตัดสินใจทางเทคนิคมากนัก และกลับอยากจ่ายเงินซื้อซอฟต์แวร์มากกว่า ดังนั้นคำว่าใช้ฟรีจึงถูกลดบทบาทให้เหมือนตัวทดลอง และเน้น call to action ที่พาไปคุยกับคนจริงแทน
    ดูเหมือนว่าผู้บริหาร Redis Inc. จะสรุปว่าการดึงดูด TDM สำคัญกว่าการดึงดูดนักพัฒนาหรือผู้ดูแลระบบ และถ้าไม่มีข้อมูลภายในก็ยากจะบอกว่าถูกหรือผิด แต่คงไม่ใช่กลยุทธ์ที่ทำไปแบบไม่มีเจตนา
    การเติมฟีเจอร์เข้าไปเรื่อย ๆ ก็เพราะต้นทุนในการขยายเครื่องมือเดิมต่ำกว่าต้นทุนในการนำเครื่องมือใหม่เข้ามามาก ต่อให้ไม่มีแรงจูงใจทางธุรกิจ ภาษาการเขียนโปรแกรมจำนวนมากก็มักลงเอยด้วยการกลายเป็นตัวหารร่วมต่ำสุดของทุกฟีเจอร์ มากกว่าจะรักษาอัตลักษณ์หลักของตัวเองไว้ และในบริษัทเชิงพาณิชย์แนวคิด “land and expand” ก็ทำงานแรงมาก คือปิดดีลแรกด้วยฟีเจอร์หลัก แล้วค่อยขายฟีเจอร์เสริมระดับกลาง ๆ เพิ่มเข้าไป เพราะฝ่ายจัดซื้อมักจัดการการขยายสัญญาเดิมได้ง่ายกว่าการทำสัญญาใหม่
    ข้ออ้างที่ว่า “ลูกค้าที่จริงจังจะอยากได้ผลิตภัณฑ์เฉพาะทางจริง ๆ สำหรับ semantic search / event stream / strong-consistency KV / time series / vector store” ก็เป็นประเด็นที่ถกเถียงได้มาก แม้ดูจากข้อมูลของบริษัทซอฟต์แวร์มหาชนเพียงอย่างเดียว ลูกค้าก็มักเลือกทางเลือกที่แย่กว่าด้วยเหตุผลที่ไม่ใช่เรื่องเทคนิคอยู่บ่อยครั้ง
    จะบอกว่า Valkey คือคำตัดสินสุดท้ายของตลาดก็ยังฟันธงยาก Valkey ทำได้ดีกว่า fork ทั่วไปมาก (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/) แต่บริษัท Redis เองก็ดูเหมือนยังยืนระยะได้ดีจากมุมคนนอก หากดูบริษัทอย่าง ElasticSearch หรือ MongoDB ที่เปลี่ยนไลเซนส์แล้วมี fork เกิดขึ้น แต่การประเมินมูลค่าในตลาดสาธารณะไม่ได้เสียหายหนัก ก็อาจสรุปได้อีกแบบ ในฟองสบู่นักพัฒนาอาจดูต่างออกไป แต่ถ้ารายได้คือดัชนีตามหลังสุดท้าย ก็อาจถามได้ว่า “มันสำคัญขนาดนั้นจริงหรือ?”
    ไม่ได้จะปกป้องผลประโยชน์เชิงพาณิชย์ เพียงแค่อยากแชร์มุมมองจากฝั่งนั้น คล้ายกับที่เมื่อมองพืชผลแบบเดียวกัน คนซื้อของเข้าบ้านกับชาวนา จะตั้งคำถามและมีเป้าหมายต่างกันโดยสิ้นเชิง

    • มุม “ทำไม” ทางธุรกิจถูกอธิบายไว้ดี และช่วยเติมบริบทว่า Redis ไม่ได้อยู่ในสุญญากาศของซอฟต์แวร์ ไม่ได้เล็งเป้าไปที่พวกคลั่ง OSS และผู้ตัดสินใจก็มีเกณฑ์ต่างจากวิศวกรระบบ
      แต่ตรรกะนี้ก็ดูเหมือนตั้งต้นจากสมมติฐานว่าทุกคนมีเป้าหมายคือเงิน ความทะเยอทะยานที่จะหาเงินมหาศาลจาก Redis ก็เป็นความทะเยอทะยานแบบหนึ่งเท่านั้น และจากท่าทีที่ antirez เขียนไว้ เขาไม่ได้ดูเหมือนคนที่ใส่ใจเรื่องเงินมากเป็นพิเศษ
      มีตัวอย่างโต้แย้งคือ SQLite ซึ่งไม่ได้พูดถึงรายได้หลายล้านหรือการขายกิจการระดับหลายพันล้าน แต่โฟกัสกับการส่งมอบสิ่งที่นิยามชัดเจนอย่างเงียบ ๆ SQLite ไม่ได้สูญเสียเหตุผลที่ทำให้มันกลายเป็น embedded database ที่ได้รับความนิยมสูงสุด และในฝั่งฐานข้อมูลขนาดใหญ่ Postgres ก็คล้ายกัน เราหยิบตัวอย่างโต้แย้งจากโลกแบบนี้ได้พอ ๆ กับจากโลกของเงินและผลประโยชน์เชิงพาณิชย์
      สำหรับ Redis นั้น สถานการณ์ดูเหมือนเป็นผลตามธรรมชาติของการขยายตัวในแนวนอนแบบ “เราใช้ AWS/GCP อยู่แล้ว งั้นก็ใช้ของที่คล้าย Redis จากเจ้านั้นไปเลย” เส้นทางที่เป็นแบบ IBM มากกว่าคือเลือกผู้ให้บริการคลาวด์ แล้วใช้ Redis ของเขา ซึ่งทุกวันนี้ก็คือ Valkey
      เรื่องที่คนมักเลือกตัวเลือกที่แย่กว่าไม่ใช่ประเด็นถกเถียง แต่เป็นข้อเท็จจริง และการที่ Redis ขยายตัวมาในโหมดแบบนั้นก็เป็นตัวอย่างหนึ่งของ ความทะเยอทะยานและการล่องลอย ที่อยากชี้ให้เห็นพอดี
    • ฉันเคยทำงานที่ Redis Labs จึงแทบจะอยู่ในบทบาท “นักพัฒนาฝ่ายปีศาจ” แบบตรงตัว ตอนลาออกก็ไม่ได้ใช้สิทธิ์ options ที่ vest แล้ว และเพราะอาศัยอยู่ไกลจาก Silicon Valley มาก เลยพูดได้โดยไม่ต้องกังวลว่าจะเผาสะพานมากเกินไป
      แต่ก่อน redis.com เป็นเว็บสำหรับ TDM ส่วน redis.io เป็นเว็บสำหรับนักพัฒนา แต่หลังจาก Redis Labs ได้ redis.io ที่ antirez ถืออยู่มา ก็ทำมันพังจนแทบหาลิงก์ดาวน์โหลดไม่เจอ และตอนนี้ทั้งสอง URL ก็พาไปเว็บสำหรับ TDM เหมือนกัน ทุกวันนี้ก็ยังหาลิงก์ดาวน์โหลด Redis ได้ไม่ง่าย ถึงขั้นอยากบอกให้ไปลองหาดูเอง
      ปัญหาหลักคือ Redis Labs เลือก ผู้นำด้านการตลาด ได้แย่มาตลอด CMO กับ VP เข้ามาแล้วก็เผาผลาญ goodwill ให้มากที่สุดในช่วงเวลาสั้น ๆ ก่อนจะจากไปสู่ “การผจญภัยครั้งถัดไป” ในอีก 6 เดือนต่อมา พอเห็นว่า traffic ของ redis.io สูงกว่า redis.com มาก ก็เลยทำลาย redis.io ด้วยความหวังว่าคนที่หาลิงก์ดาวน์โหลดไม่เจอจะกด “try free” ซึ่งดูเป็นตัวอย่างคลาสสิกของความโลภต่อคลิกระยะสั้น
      การขายฟีเจอร์เสริมยังช่วยสร้างความแตกต่างจากคู่แข่งในเชิง checklist ได้ด้วย โดยเฉพาะเวลาที่แข่งขันด้วยราคาได้ยาก และ AWS ก็สามารถมัดส่วนลดคลาวด์หนัก ๆ เข้ากับ ElastiCache ได้ ขณะที่คู่แข่งที่แย่ที่สุดก็คือ Redis โอเพนซอร์สแบบฟรี
      Valkey ได้รับเงินสนับสนุนมากกว่า fork ทั่วไปอย่างมาก ตัวอย่างเช่นอดีตหัวหน้าฝ่าย developer relations ของ Redis Labs ตอนนี้ก็มาทำ Valkey ที่ AWS
      แต่ก็เสียดายที่มีคนมองว่า Valkey ทำแค่งาน “ไม่หวือหวา” เพราะ Redis เองก็เป็น multi-threaded มานานแล้ว แม้ control plane จะยังเป็น single-threaded แต่ I/O เป็น multi-threaded อยู่แล้ว ดังนั้นงานของ Valkey จึงไม่ใหม่อย่างที่ผู้เขียนคิด
      Valkey เป็นปฏิบัติการแบบตรงไปตรงมาเพื่อให้บริษัทคลาวด์อย่าง AWS ขาย Redis ต่อไปได้โดยไม่ต้องจ่ายเงินให้ใคร ตรรกะอื่น ๆ ก็เป็นเพียงเครื่องมือทางการตลาดเพื่อโน้มน้าวให้คนยอมรับว่าพวกเขาจะได้ทำสิ่งที่อยากทำต่อไป และถ้าวันหนึ่งเห็นว่าการทำลายความเข้ากันได้กับ Redis คุ้มในเชิงธุรกิจ พวกเขาก็จะทำ อาจพนันได้พอประมาณว่าทั้งสองฝั่งน่าจะทำบางส่วนไปแล้ว แต่ฉันไม่ได้ตามละเอียดพอ
      ถ้าอยากได้ Redis fork ที่ตั้งใจทำงานไม่หวือหวาและรักษาความเรียบง่ายไว้จริง ๆ ก็มี redict
      ถึงอย่างนั้นก็ยังมองว่าเวลาของ Redis กำลังใกล้หมดลง ในภูมิทัศน์เชิงพาณิชย์อันประหลาดตอนนี้ แต่ละ fork ต่างก็มีจุดที่กะเผลกกันคนละแบบ แม้แต่ redict ซึ่งมีคุณธรรมที่สุด ก็ยังดูไม่สนใจจริงจังที่จะผลัก Redis ไปข้างหน้าแบบที่ antirez เคยขับเคลื่อนโปรเจ็กต์ต้นฉบับอย่างผู้นำเบ็ดเสร็จ นี่ไม่ได้หมายความว่าซอฟต์แวร์ที่ “เสร็จสมบูรณ์แล้ว” เป็นเรื่องไม่ดี แต่ฉันยังเชื่อว่า Redis ยังมีพื้นที่น่าสนใจที่ยังไม่ถูกค้นพบ และก็สงสัยว่า fork เชิงพาณิชย์จะสร้างระบบนิเวศแบบนั้นได้หรือไม่ แน่นอนว่าอาจกำลังประเมินค่าของ Arrays และการประยุกต์ใช้ AI ต่ำไปก็ได้ เลยพยายามเปิดใจฟังไว้
      มองย้อนกลับไปแล้วก็น่าทึ่งที่ Redis Labs ทำเรื่องทั้งหมดนี้พังได้หนักขนาดนั้น และก็ดีที่เวลาผ่านมาพอแล้วจนตอนนี้โกรธน้อยลง
    • ก็น่าจะเป็นเพราะบริษัทต่าง ๆ พยายามเอาไปใช้ให้มากที่สุดโดยไม่ยอมจ่ายเงินใช่ไหม เลยทำให้ Redis, MongoDB, HashiCorp สุดท้ายต้องเปลี่ยนไลเซนส์

  • ที่บริษัทกำลังใช้ Lua script สร้างระบบคิวงานที่ยุติธรรมขึ้น และ Redis ให้ความรู้สึกแปลกมาก โมเดลในหัวของฉันคือมันเป็น “key-value store แบบเรียบง่าย” มาโดยตลอด แต่กลับต้องมาเรียนรู้ฟีเจอร์สารพัดอย่าง เช่น การรัน Lua script ภายใต้ global lock
    แต่เอกสารกลับอยู่บนเว็บไซต์วิบวับ และไม่ได้อธิบายอย่างชัดเจน ค่า config ต่าง ๆ ก็เหมือนจะอธิบายไว้แค่ในตัวอย่าง config เท่านั้น
    ฉันรู้ว่า Redis ทำงานได้ดีและทุกคนก็พูดแบบนั้น แต่ประสบการณ์การเรียนรู้ฟีเจอร์ต่าง ๆ ของ Redis กลับค่อนข้างอึดอัด เหมือนมีใครสักคนสร้างโปรแกรมที่ดีมากขึ้นมา แต่ลืมทำเอกสารที่ดีซึ่งปกติแล้วโปรแกรมดี ๆ ก็ควรจะมี
    เป็นการบ่นที่แปลกอยู่เหมือนกัน Redis ดูเหมือนจะทำงานได้ยอดเยี่ยมมาก และฉันก็ชอบเอกสารแบบ Postgres ที่อธิบาย “ทุกอย่าง”

    • สงสัยเหมือนกันว่าเอกสารของผลิตภัณฑ์ที่มุ่ง TDM น้อยกว่าจะเข้าใจง่ายกว่าหรือไม่: https://valkey.io/topics/programmability/
      โปรเจ็กต์โอเพนซอร์สจำนวนมากก็รู้ดีว่าเอกสารของตัวเองอ่อนเหมือนกัน ดังนั้นในการทดลองนี้คงไม่ได้มีแค่ตัวแปรเรื่องหัวหน้าหัวแหลมเท่านั้น
    • เมื่อก่อน Redis มีเอกสารสารพัดอย่าง และโชคดีที่ Wayback Machine ช่วยย้อนความเสียหายที่ Redis Labs ทำไว้ได้ คุณอาจหาอะไรที่ต้องการเจอจากที่นี่: https://web.archive.org/web/20190725152042/…
      เอกสารของ redict ก็ดูดีเหมือนกัน: https://redict.io/docs/scripting/