داستان یک مهاجرت: از الستیک سرچ به آپاچی دوریس و صرفه‌جویی ۸۰ درصدی در هزینه‌های عملیاتی
در یکی از سرویس‌های Tencent Music (TME)، روزانه بیش از ۶۹۰ گیگابایت داده وارد Elasticsearch می‌شد. این سیستم جستجو با وجود قدرت بالا در Full-Text Search، در مقیاس‌های بزرگ دچار مشکلات جدی شد:
منبع : https://doris.apache.org/blog/tencent-music-migrate-elasticsearch-to-doris
مشکلات کلیدی Elasticsearch:
هزینه ذخیره‌سازی بسیار بالا
ساختار فهرست‌گذاری سنگین (indexing روی همه فیلدها) و نگهداری نسخه‌های متنوع داده باعث مصرف فضای عظیمی می‌شد. تنها برای یک جدول، روزانه نزدیک به ۷۰۰ گیگابایت فضا اشغال می‌شد!
سرعت پایین در نوشتن داده‌ها
فرآیند ingest با افزایش داده‌ها بسیار کند شده بود — نوشتن داده‌ی کامل به بیش از ۱۰ ساعت زمان نیاز داشت. این تأخیر برای سرویس‌های زنده قابل‌قبول نبود.
ضعف در تحلیل‌های پیچیده
الستیک‌سرچ اساساً برای جستجو ساخته شده، نه تحلیل OLAP. انجام عملیات پیچیده مثل JOIN، گروه‌بندی سنگین و کوئری‌های ترکیبی باعث افت محسوس عملکرد می‌شد.
خطا در کوئری‌های بزرگ و ترکیبی
کوئری‌هایی با شرط‌های تو در تو (AND، OR، فیلترهای عددی/تاریخی) گاهی با خطاهایی مثل too_long_query یا timeouts مواجه می‌شدند.
پیچیدگی در معماری داده‌ها
برای تحلیل، داده‌ها باید هم در Elasticsearch و هم در سیستم‌های OLAP (مثل Doris) نگهداری می‌شدند؛ این یعنی دو نسخه از داده، پیچیدگی بیشتر و ریسک ناسازگاری.
راه‌حل TME: مهاجرت به Apache Doris 2.0
در سال ۲۰۲۳، تیم TME برای تحلیل‌های اصلی خود از ClickHouse به Apache Doris مهاجرت کرد. (https://doris.apache.org/blog/Tencent-Data-Engineers-Why-We-Went-from-ClickHouse-to-Apache-Doris)در این معماری جدید، تحلیل‌های OLAP روی Doris انجام می‌شد، اما برای تحلیل‌های متنی همچنان از Elasticsearch استفاده می‌کردند. با معرفی Inverted Index بومی در Doris 2.0، حالا می‌توان Full-Text Search را نیز مستقیماً در همین پلتفرم انجام داد — بدون نیاز به Elasticsearch و بدون معماری‌های چندلایه.
ویژگی‌های جدید Doris:
جستجوی تمام‌متن (Full-Text Search)
حالا Doris از طریق inverted index بومی، امکان جستجو در داده‌های متنی با سرعت بسیار بالا و با قابلیت ترکیب با سایر فیلترهای SQL را فراهم می‌کند.
جستجوی مبتنی بر تگ (Tag-Based Filtering)
برای اپلیکیشن‌هایی مثل فروشگاه‌های آنلاین یا شبکه‌های اجتماعی، فیلترگذاری سریع بر اساس تگ‌ها اهمیت بالایی دارد. Doris با ساختار جدید، می‌تواند میلیون‌ها رکورد را در زمان بسیار کوتاه segment و فیلتر کند.
تحلیل پیچیده با SQL یکپارچه
امکان JOIN بین چند جدول
برخلاف Elasticsearch که برای هر تحلیل نیاز به دستورات DSL خاص دارد، Doris تمام قدرت SQL استاندارد را در اختیار شما می‌گذارد:
امکان Aggregation تو در تو
امکان Window functions و حتی sub-queryها
همه این عملیات با پرفورمنس بالا، روی داده‌های با حجم بزرگ و حتی real-time قابل اجرا هستند.
نتیجه‌گیری: Elastic در نقش جستجوگر، Doris در نقش تحلیل‌گر – یا هر دو در یک سیستم؟
برای بسیاری از شرکت‌ها، Elastic هنوز برای سناریوهای خاص مانند log analysis یا سرچ‌های مبتنی بر متن، انتخاب مناسبی است. اما زمانی که نیاز به ingestion سنگین، تحلیل‌های real-time، کوئری‌های ترکیبی و مصرف بهینه منابع دارید، بهتر است به ابزارهایی مانند Apache Doris 2.0 نگاه جدی‌تری داشته باشید — ابزاری که ترکیب جستجو و تحلیل را بدون پیچیدگی معماری و با زبان SQL در یک سیستم ارائه می‌دهد.
مقاله اخیر علیرضا صادقی در خصوص بررسی وضعیت دیتابیس‌های تحلیلی، تایید کننده همین محبوبیت رو به گسترش آپاچی دوریس و فرزند جداشده آن یعنی استارراکز است . بخصوص پشتیبانی از آپدیت روی داده‌های حجیم تحلیلی، یکی از مزایای اصلی این دیتابیس است که یکی از دلایل اصلی مهاجرت از کلیک هوس به دوریس برای شرکت فوق هم همین موضوع بود :
https://www.pracdata.io/p/state-of-open-source-read-time-olap-2025
اگر احیانا شما هم برای تحلیل‌های بلادرنگ یا تحلیل‌های پیچیده از الستیک سرچ استفاده می‌کنید شاید این مقاله به شما دید مناسبی در خصوص مزایا و معایب مهاجرت به دوریس به شما بدهد :
https://doris.apache.org/blog/why-apache-doris-is-best-alternatives-for-real-time-analytics
