Boost SQL Performance: Upstash Redis Caching สำหรับ Drizzle ORM Queries

พักหนึ่งเรามีโอกาส collab กับ Drizzle ORM

เห็นว่า TypeScript ORM นี้ถูกชื่นชอบโดย community ยิ่งใหญ่ การตัดสินใจพูด "yes 😳" เป็น no-brainer:

ในบทความนี้ เราจะเห็นว่า Upstash Redis x Drizzle caching integration ปรับปรุง SQL performance อย่างไร และเราใช้ Lua scripts และ hash data structure เพื่อ optimize integration

The Challenge: SQL Performance ใน Modern Applications

Traditional SQL databases เก่งที่ consistency และ modeling complex relationships แตอาจ struggle กับ:

• High latency ใน distributed environments
• Connection pooling limitations ใน serverless functions
• Repetitive query overhead สำหรับ frequently accessed data
• Scaling bottlenecks ภายใต้ heavy read loads

The solution? Caching layer ที่เข้าใจ data relationships ของคุณและ automatically manages cache invalidation

How the Upstash x Drizzle Caching Works (Upstash x Drizzle Caching ทำงานอย่างไร)

Improving Read Performance: Cache-First with Fallback

ตอนคุณ execute query ด้วย Drizzle caching enabled integration ของเราตรวจสอบ Redis สำหรับ cached result ก่อน:

• Cache Miss: ถ้าไม่เจอ query อ่านจาก database ผลลัพธ์เก็บใน Redis พร้อม metadata เกี่ยวกับ dependent tables
• Cache Hit: Subsequent identical queries คืนค่าทันทีจาก Redis โดยไม่ต้องอ่านจาก relational database

// Query นี้เช็ค Redis ก่อน และอ่านจาก database เฉพาะถ้าจำเป็น const users = await db.select().from(usersTable) .where(eq(usersTable.status, 'active')) .$withCache();

Smart Invalidation สำหรับ Write Operations

The magic เกิดขึ้นระหว่าง write operations ตอนคุณ modify data ใน relational database integration ของเราอัตโนมัติ:

1. Identifies Dependencies: กำหนดว่ cached queries ไหน depend on modified tables
2. Batch Invalidation: ลบ affected cache entries ทั้งหมด

// Insert นี้ automatically invalidates ทุก cached queries ที่ depend on usersTable await db.insert(usersTable).values({ email: 'new@user.com', status: 'active' });

Building a Simple Cache: The "Naive" Approach (การสร้าง Simple Cache: "Naive" Approach)

เริ่มจาก simplest possible implementation เพื่อเข้าใจ problems ที่ caching integration ของเราแก้ ตอน cache query result เราต้อง:

1. Store cached value
2. Track tables ที่ query นี้ depend on สำหรับ invalidation

Simple Cache Storage

// ตอนเพิ่ม item เข้า cache await redis.set(itemHash, cachedValue); await Promise.all( dependentTables.map((table) => redis.sadd(table, itemHash)) );

Approach นี้ store cached result เป็น key-value pair และ track dependencies โดยเพิ่ม item hash เข้า sets ที่ชื่อจากแต่ละ dependent table

Simple Cache Invalidation

// ตอน invalidate ตาม table changes const hashesToInvalidate = await redis.sunion(dependentTables); await redis.del(...hashesToInvalidate);

นี่ทำงานโดยหา cached items ทั้งหมดที่ depend on modified tables แล้วลบพวกมัน

The Problems with this "Naive" Approach (ปัญหาของ "Naive" Approach)

แม้ technically works naive implementation นี้มี performance issues 2 ข้อ

Problem 1: Multiple Round Trips

Invalidation process ต้องการ สอง Redis operations แยกกัน:

1. ก่อน เราเรียก SUNION เพื่อได้ list of keys to delete
2. จากนั้น เราเรียก DEL ด้วย result จาก step 1

นี่สร้าง round-trip dependency ที่ operation ที่สองต้องรอ operation แรกเสร็จ

Problem 2: Slow Mass Deletion

Command DEL อาจเป็น bottleneck ตอน invalidate หลาย keys:

// นี่อาจ delete thousands of keys await redis.del(...hashesToInvalidate);

ตอนคุณมี popular table อย่าง users ที่ referenced by hundreds of cached queries single update อาจ trigger deletion ของ hundreds of individual Redis keys ด้วย hundreds หรือ thousands of keys นี่อาจช้ามาก

Solution 1: Lua Scripts (Lua Scripts)

Upstash Redis มี full support สำหรับ Lua script evaluation

Lua scripts แก้ round-trip problem โดย execute multiple Redis commands server-side:

-- Invalidation script that combines SUNION and DEL local tables = KEYS -- table names passed as keys local keysToDelete = {} if #tables > 0 then -- Get all hashes that depend on these tables local hashesToInvalidate = redis.call('SUNION', unpack(tables)) -- Prepare for deletion for _, hash in ipairs(hashesToInvalidate) do keysToDelete[#keysToDelete + 1] = hash end -- Add table sets themselves to deletion list for _, table in ipairs(tables) do keysToDelete[#keysToDelete + 1] = table end -- Single atomic deletion if #keysToDelete > 0 then redis.call('DEL', unpack(keysToDelete)) end end

Benefits of Lua scripts:

• Single round trip: ทุก operations เกิดขึ้น server-side
• Reduced latency: ไม่มี network overhead ระหว่าง operations
• Consistency: ไม่มี risk ของ partial updates เนื่องจาก network issues

Solution 2: Hash-Based Storage for Efficient Deletion (Hash-Based Storage สำหรับ Deletion ที่มีประสิทธิภาพ)

แม้ Lua scripts การลบ hundreds of individual keys อาจช้ากว่าที่เราอยากได้ Redis hashes ให้โซลูชัน efficient มากกว่า:

The Hash-Based Approach

แทนที่จะ store แต่ละ cached query เป็นแยก Redis key เรา group queries ที่ depend on same tables เข้า hashes:

// Old approach: แต่ละ query ได้ own key await redis.set('query_hash_1', result1); await redis.set('query_hash_2', result2); await redis.set('query_hash_3', result3); // New approach: Group queries by table dependencies const compositeKey = 'users,posts'; // hash key สำหรับ users และ posts tables await redis.hset(compositeKey, { 'query_hash_1': result1, 'query_hash_2': result2, 'query_hash_3': result3 });

Why Hashes Are Much Faster (ทำไม Hashes เร็วกว่ามาก)

ตอน invalidate queries ที่ depend on users table:

// Old way: Delete many individual keys (slow) await redis.del('query_hash_1', 'query_hash_2', /* ...hundreds more... */); // New way: Delete entire hash table (fast) await redis.del('__CT__users,posts');

Performance advantages:

• Single deletion operation: One DEL command ลบ hundreds of cached queries
• Memory efficiency: Redis can free entire hash tables ใน one operation
• Atomic cleanup: ทุก related queries invalidated together

เพื่อดู Lua scripts ตอนจบ long อย่างไร เช็ค implementation ใน Drizzle repository

Cache Tags สำหรับ Granular Control

นอกจาก table-based invalidation Drizzle รองรับ custom tags สำหรับ fine-grained cache control:

// Cache ด้วย custom tag const premiumUsers = await db.select().from(usersTable) .where(eq(usersTable.plan, 'premium')) .$withCache({ tag: 'premium_users' }); // ต่อมา invalidate just this specific query await db.$cache?.invalidate({ tags: 'premium_users' });

Auto vs Manual Invalidation

Automatic Invalidation (default): Queries invalidated เมื่อ dependent tables เปลี่ยน ให้ data consistency แตด้วย more aggressive cache clearing

Manual Invalidation: สำหรับ scenarios ที่ eventual consistency acceptable คุณ disable auto-invalidation และ manually control ตอน clear cache:

// ไม่ถูก auto-invalidate - ดีสำหรับ analytics data const monthlyStats = await db.select() .from(analyticsTable) .$withCache({ autoInvalidate: false }); // Manually invalidate เมื่อต้องการ (เช่น daily batch job) await db.$cache?.invalidate({ tables: ['analyticsTable'] });

Real-World Use Cases (Real-World Use Cases)

ตอนนี้เรา cover technical side ของ integration มาเห็นว่า concepts นี้ translate เป็น practical applications อย่างไร

E-commerce Product Catalog

// Cache product listings with automatic invalidation const products = await db.select() .from(productsTable) .where(eq(productsTable.active, true)) .$withCache({ tag: 'active_products' }); // ตอน inventory changes cache auto-invalidated await db.update(productsTable) .set({ stock: newStock }) .where(eq(productsTable.id, productId));

Content Management

// Cache published articles with manual invalidation const articles = await db.select() .from(articlesTable) .where(eq(articlesTable.status, 'published')) .$withCache({ autoInvalidate: false, tag: 'published_articles' }); // Manually invalidate เมื่อ content updated await db.$cache?.invalidate({ tags: 'published_articles' });

Conclusion (สรุป)

Upstash Redis & Drizzle caching integration สามารถ drastically improve SQL query performance และ reduce database load ด้วย (pretty) minimal code changes

ตอนคุณ enable cache คุณคาดหวังได้:

• Dramatically faster query response times สำหรับ cached data
• Reduced database load และ improved scalability

Upstash Redis's global distribution และ serverless-first architecture พร้อม pay-as-you-go pricing เป็น foundation ที่ดีสำหรับ modern applications

Perfect สำหรับ e-commerce platforms, analytics dashboards, content management systems และมากกว่า

Further Reading (อ่านเพิ่มเติม)

อยากลึกขึ้นไป? นี่คือ resources ที่แนะนำ:

• Upstash Redis & Drizzle Integration Guide
• Drizzle Caching Documentation
• Getting Started with Upstash Redis
• Upstash Rate Limit SDK (TypeScript) - SDK powerful อีกตัวที่ใช้ Lua scripts สำหรับ optimal performance
• Upstash Rate Limit SDK (Python) - Python implementation ของ Rate Limit SDK