دیتابیسهای درونحافظهای (In-Memory) به ستون اصلی زیرساخت هر سیستم مدرن تبدیل شدهاند؛ اما تقریباً همهٔ آنها — از Redis تا Memcached — به یک معماری تکریسمانی متکیاند. در دنیایی که سرورها دهها و صدها هستهٔ CPU دارند، اینکه یک دیتابیس فقط از یک هسته استفاده کند، یعنی هدر دادن بخش بزرگی از قدرتی که برایش هزینه میکنید.
DragonflyDB پاسخی مدرن به همین مشکل است. دراگونفلی توسط شرکت DragonflyDB Inc. به رهبری رومن گرشمان (مهندس سابق گوگل) توسعه یافته و نسخهٔ ۱.۳۹.۰ آن به صورت متنباز منتشر شده است. این دیتابیس با معماری چندنخی (Multi-Threaded) و کاملاً سازگار با APIهای Redis و Memcached طراحی شده تا بدون تغییر کد، جایگزین هر دوی آنها شود. در این مقاله معماری، امکانات و مقایسهٔ آن با رقبا را بررسی میکنیم.
دراگونفلی چیست؟
DragonflyDB یک دیتااستور درونحافظهای مدرن است که به عنوان جایگزین دراپ-این (Drop-in) برای Redis و Memcached ساخته شده. یعنی کدهای شما بدون تغییر کار میکنند — فقط آدرس سرویس را عوض میکنید. دراگونفلی پروتکل RESP ردیس و پروتکل متن مموکش را همزمان پشتیبانی میکند و هدفش این است که در سختافزارهای امروزی، توان عملیاتی بسیار بالاتری از ردیس ارائه دهد.
تفاوت بنیادی دراگونفلی با ردیس در معماری است: ردیس برای اطمینان از سازگاری، همهٔ درخواستها را روی یک ریسمان (Thread) پردازش میکند، اما دراگونفلی برای استفادهٔ کامل از همهٔ هستههای CPU از ابتدا طراحی شده. نتیجه این است که در بنچمارکهای چند هستهای، توان عملیاتی آن تا ۲۵ برابر ردیس اعلام شده است.
معماری چندنخی (Multi-Threaded)
در ردیس، حتی اگر سرور شما ۶۴ هسته داشته باشد، فقط یک هسته کار میکند و بقیه بیکار میمانند. دراگونفلی از الگوی Thread-Per-Core استفاده میکند: برای هر هستهٔ CPU یک ریسمان با حلقهٔ رویداد (Event Loop) اختصاصی ساخته میشود و هر ریسمان به صورت مستقل درخواستها را پردازش میکند.
این یعنی با اضافهشدن هسته، توان عملیاتی هم تقریباً به صورت خطی افزایش مییابد. یک نمونهٔ دراگونفلی روی ماشین ۳۲ هستهای میتواند باری را مدیریت کند که برای آن به یک کلاستر کامل از چند نمونهٔ ردیس نیاز دارید — با این مزیت که همهٔ دادهها هنوز در یک سرویس واحد و بدون پیچیدگی شاردینگ نگهداری میشوند.
معماری Shared-Nothing
نکتهٔ ظریف معماری دراگونفلی این است که چندنخی بودن به سادگی «چند قفل» نیست. دراگونفلی از معماری Shared-Nothing پیروی میکند: هر ریسمان مالک بخشی از حافظه است و ریسمان دیگر به دادههای او دسترسی مستقیم ندارد.
ارتباط بین ریسمانها فقط از طریق پیامرسانی اتفاق میافتد، نه از طریق اشتراکگذاری حافظهٔ مشترک. به این ترتیب نیازی به قفل سراسری (Global Lock) نیست، نزاع بین ریسمانها (Contention) به حداقل میرسد و تاخیر در بارهای بالا پایدار میماند — در حالی که ردیس در بارهای سنگین، تاخیرش به دلیل صف شدن درخواستها در یک ریسمان، بهشدت رشد میکند.
سازگاری کامل با API ردیس و مموکش
برای مهاجرت نیازی به بازنویسی کد ندارید: دراگونفلی دستورات پرکاربرد ردیس (String، Hash، List، Set، Sorted Set، Stream و حتی Pub/Sub) و پروتکل مموکش را همزمان روی یک پورت پشتیبانی میکند. حتی میتوانید از کلاینتهای ردیس و مموکش به صورت همزمان به یک نمونهٔ دراگونفلی وصل شوید:
docker run -p 6379:6379 --cpus=8 --memory=16g docker.dragonflydb.io/dragonfly/dragonflyدستورات رایج مثل SET، GET، LPUSH، ZADD و XADD بدون تغییر رفتار میکنند و ابزارهای اکوسیستم ردیس مثل redis-cli به راحتی با آن کار میکنند.
اسنپشات بدون fork
یکی از دردسرهای قدیمی ردیس، نحوهٔ اسنپشاتگیری است: ردیس برای نوشتن RDB از fork() استفاده میکند که در حافظههای بزرگ، هم باعث مکث (Pause) در پردازش درخواستها میشود و هم به دلیل Copy-on-Write مصرف حافظه را بهطور موقت افزایش میدهد.
دراگونفلی این مشکل را از ریشه حل کرده: اسنپشاتگیری بدون fork و به صورت افزایشی (Incremental) انجام میشود. یعنی در حین بکاپ، نه مکثی در پاسخگویی رخ میدهد و نه پیک حافظه. همین ویژگی به تنهایی دراگونفلی را برای نمونههایی با صدها گیگابایت داده به گزینهٔ بسیار مطمئنتری تبدیل میکند.
مصرف بهینهٔ حافظه
دراگونفلی از ساختارهای دادهٔ فشرده استفاده میکند و در سناریوهای ذخیرهٔ کلیدهای کوچک و متعدد — رایجترین الگوی کش — حافظهٔ کمتری نسبت به ردیس مصرف میکند. این یعنی روی یک سرور با حافظهٔ مشخص، میتوانید دیتای بیشتری کش کنید یا سرور کوچکتری (و ارزانتری) بخرید.
در نسخههای اخیر، قابلیت های حذف هوشمند (Cache Eviction) هم بهینه شده و الگوریتمهای اخراج کش مثل LRU و LFU با دقت بیشتری در بارهای بالا اجرا میشوند.
توان عملیاتی ۲۵ برابر
ادعای «تا ۲۵ برابر ردیس» از بنچمارکهای رسمی شرکت دراگونفلی روی ماشینهای پر هسته گرفته شده و باید با دقت تفسیر شود: این عدد به workload بستگی دارد و معمولاً در بارهای خواندنی و سنگین (Cache-Heavy) که ردیس به سقف تکریسمان میرسد، بیشترین فاصله دیده میشود. در سناریوهای ساده با هستههای کم، اختلاف کمتر است.
نکتهٔ مهم برای تصمیمگیری، همین است: هرچه تعداد هستههای سرور شما بیشتر باشد و بارتان سنگینتر، مزیت دراگونفلی بیشتر نمایان میشود.
مقایسه با رقبا
مقایسهٔ منصفانهٔ دراگونفلی باید با Redis (استاندارد بازار)، Valkey (فورک متنباز ردیس) و Memcached (کش کلاسیک) انجام شود:
| ویژگی | DragonflyDB | Redis | Valkey | Memcached |
|---|---|---|---|---|
| معماری | چندنخی Shared-Nothing | تکریسمان | تکریسمان | تکریسمان |
| پروتکلها | API ردیس + مموکش | بومی (RESP) | سازگار با ردیس | بومی (Text/Binary) |
| توان عملیاتی | تا ۲۵ برابر در بنچمارکها | مرجع | نزدیک به ردیس | بالا برای get/set ساده |
| اسنپشات | بدون fork، بدون مکث | fork + Copy-on-Write | fork + Copy-on-Write | ندارد |
| ساختار داده | بیشتر دستورات ردیس | کامل (String تا Stream) | کامل | فقط String |
| بازار و پشتیبانی | جوان ولی رو به رشد | اکوسیستم بزرگ و قدیمی | لینوکس فانودیشن | قدیمی و بالغ |
| مناسب برای | بارهای سنگین چند هستهای | استاندارد بازار و اکوسیستم کامل | جایگزین متنباز ردیس | کش ساده و سبک |
موارد استفاده (Use Cases)
- جایگزینی ردیس در محیطهای پر هسته — وقتی ردیس به سقف تکریسمان رسیده و کلاسترینگ برایتان پیچیده است
- مدیریت نشست (Session) میلیونها کاربر — با توان عملیاتی چندنخی و حافظهٔ بهینه
- لایهٔ کش پلتفرمهای بزرگ — cache-aside در مقیاس با یک نمونهٔ واحد به جای کلاستر ردیس
- مهاجرت از مموکش بدون تغییر کد — سازگاری کامل با پروتکل مموکش
- صف پیام و rate limiting — با همان دستورات ردیس و تاخیر کمتر در بارهای سنگین
- حافظههای بسیار بزرگ (صدها گیگابایت) — جایی که fork در ردیس مشکلساز است
چه زمانی دراگونفلی انتخاب مناسبی است؟
- سرور شما چند هستهٔ قوی دارد اما ردیس فقط از یک هسته استفاده میکند
- به توان عملیاتی بالاتر و تاخیر پایدارتر در بارهای سنگین نیاز دارید
- میخواهید ردیس و مموکش را به یک سرویس واحد ادغام کنید
- حافظهٔ نمونهٔ شما بزرگ است و مکث اسنپشات ردیس برایتان غیرقابل قبول است
- از پیچیدگی کلاستر ردیس خسته شدهاید و راهحل تکنمونهای میخواهید
- هزینهٔ حافظه برایتان مهم است و به دنبال مصرف بهینهتر هستید
دراگونفلی برای چه چیزهایی مناسب نیست؟
- اکوسیستم ماژولهای ردیس — اگر به ماژولهایی مثل RediSearch یا RedisJSON وابستهاید، دراگونفلی پوشش کامل آنها را ندارد
- نسخههای خیلی جدید دستورات ردیس — اگر به دستورات تازهٔ نسخهٔ ۸ ردیس نیاز دارید، ممکن است جاهای خالی ببینید
- بارهای سبک روی ماشینهای تکهستهای — اگر هستهٔ اضافه ندارید، مزیت چندنخی به کارتان نمیآید و ردیس کافی است
- پروژههای حساس به ریسک با تیم کمتجربه — ردیس و والکی منابع آموزشی و تجربهٔ عملیاتی بسیار بیشتری دارند
- کلاسترینگ توزیعشده در مقیاس بزرگ — اگر به شاردینگ بین چند دیتاسنتر نیاز دارید، هنوز ردیس کلاستر جایگاه خودش را دارد
دراگونفلی در لکسویا
دراگونفلی انتخاب هوشمندانهای برای پروژههایی است که به حداکثر توان از سختافزار خود نیاز دارند. اما نگهداری آن، مثل هر دیتابیس دیگری، به مانیتورینگ، بکاپ و آپدیتهای امنیتی نیاز دارد که لکسویا بر عهده میگیرد.
لکسویا این دیتابیس را به عنوان سرویس دیتابیس ابری (DBaaS) ارائه میدهد — با چند کلیک نمونهٔ تکنمونهای یا کلاستر با دسترسپذیری بالا راه بیندازید.
نتیجهگیری
DragonflyDB نشان میدهد که معماری تکریسمانی دیتابیسهای درونحافظهای اجتنابناپذیر نبوده است. با استفادهٔ کامل از هستههای CPU، اسنپشات بدون fork و سازگاری کامل با ردیس و مموکش، دراگونفلی گزینهای مدرن برای بارهای سنگین و حافظههای بزرگ است.
با این حال، ردیس و والکی به دلیل اکوسیستم بزرگ، ماژولهای غنی و تجربهٔ عملیاتی انباشته، هنوز انتخاب اول بسیاری از تیمها هستند. اگر ردیس به سقف خود رسیده و کلاستر کردن آن پیچیده شده، وقت آن است که دراگونفلی را امتحان کنید — شاید دیگر به کلاستر نیازی نداشته باشید.