Loki is Grafana‑Labs’ log aggregation system that stores logs in compressed chunks accompanied by an index built from labels (key–value pairs). Queries are expressed in LogQL and rely heavily on label filters followed by line filtering.

What Is VictoriaLogs?

VictoriaLogs is a log database by the VictoriaMetrics team. It uses columnar LSM‑style storage with per‑field indices, SIMD‑accelerated search and SQL‑like LogSQL syntax.

What is the key difference betweeen Victorialogs and Loki?

The key difference in victorialogs vs loki is VictoriaLogs' advanced per-token indexing and columnar storage. This enables much faster query performance and significantly lower resource usage compared to Loki's label-only indexing, which often results in slower full-scan searches and higher operational overhead for log management.

Is VictoriaLogs faster than Loki?

Yes, in our rigorous benchmarking, VictoriaLogs demonstrated superior speed compared to Loki. For victorialogs vs loki comparisons, VictoriaLogs reduced query latencies by 94% and achieved 12x faster search times for complex queries. It also delivered 3x higher ingestion performance, making it significantly more efficient.

What is the default port for VictoriaLogs?

When evaluating victorialogs vs loki, knowing setup details is helpful. VictoriaLogs typically uses port 8428 for its default HTTP API and scraping endpoints. This port allows access and interaction with the log database. While our blog focuses on performance, understanding deployment basics, like the default port, is crucial for system configuration.

What are VictoriaLogs vs Loki benchmark results?

In benchmarks comparing victorialogs vs loki, VictoriaLogs delivered superior performance. It achieved a 94% reduction in query latencies, decreased storage usage by approximately 40%, and consumed less than 50% of allocated CPU and RAM. VictoriaLogs also showcased 3x higher ingestion throughput, making it highly efficient.

Which is better: VictoriaLogs or Loki?

In our benchmark of victorialogs vs loki, VictoriaLogs proved superior. It cut query latencies by 94%, reduced storage by 40%, and used over 50% less CPU/RAM. TrueFoundry in the US chose VictoriaLogs for its enhanced performance and efficiency managing ML workloads.

VictoriaLogs مقابل Loki - نتائج اختبارات الأداء

By هارشيت لوثرا

Published: July 4, 2026

Built for Speed: ~10ms Latency, Even Under Load

Blazingly fast way to build, track and deploy your models!

Handles 350+ RPS on just 1 vCPU — no tuning needed
Production-ready with full enterprise support

Get Started with Truefoundry Now Talk to the Expert

ملخص – بعد إجراء اختبارات مقارنة على عبء عمل بحجم 500 جيجابايت/7 أيام، قللت VictoriaLogs من زمن استجابة الاستعلامات بنسبة 94 %، وقلصت مساحة التخزين بنسبة ≈40 %، واستخدمت أقل من 50 % من وحدة المعالجة المركزية والذاكرة العشوائية التي خصصناها سابقًا لـ Loki. يشرح هذا المنشور لماذا انتقلنا.

الخلفية والمتطلبات

تساعد Truefoundry المطورين على تشغيل أعباء عمل التعلم الآلي متعددة المستأجرين على Kubernetes.
يحتاج المطورون إلى:

بحث سريع ومخصص
معدل استيعاب جيد
متابعة مباشرة للتصحيح.
أقل عبء تشغيلي – يُفضل النشر بملف ثنائي واحد.
كفاءة في استخدام الموارد التشغيل على 4 معالجات افتراضية / 16 جيجابايت ذاكرة وصول عشوائي عقدة
نسبة عالية ضغط على السجلات المخزنة
تخزين الكتل > يُفضل S3 لتقليل العبء التشغيلي. + زمن الاستجابة

لقد خدمنا Loki جيدًا في البداية، ولكن مع تزايد الحجم، لاحظنا زمن استجابة للبحث يتجاوز 30 ثانية وتضخيمًا عاليًا لعمليات الإدخال/الإخراج. وقد دفعنا هذا إلى تقييم VictoriaLogs.

Gartner Hype Cycle for Platform Engineering 2026

Access Full 2026 Report

ما هو Loki؟

Loki هو نظام تجميع السجلات من Grafana-Labs الذي يخزن السجلات في أجزاء مضغوطة مصحوبة بفهرس مبني على تسميات (أزواج المفتاح-القيمة). يتم التعبير عن الاستعلامات في LogQL وتعتمد بشكل كبير على مرشحات التسميات متبوعة بتصفية الأسطر.

نقاط القوة: تكامل قوي مع Grafana، فهرس منخفض التكلفة، قابل للتوسع أفقيًا.
محددات بالنسبة لنا: فهرس يعتمد على التسميات فقط يعني عمليات بحث مكلفة باستخدام التعبيرات النمطية بمسح كامل؛ عمليات إدخال/إخراج عالية لضغط الكتل؛ عبء إضافي على جامع القمامة (GC) في Go عند الاستيعاب العالي للبيانات.

ما هو VictoriaLogs؟

VictoriaLogs هي قاعدة بيانات سجلات من فريق VictoriaMetrics. تستخدم تخزينًا عموديًا على غرار LSM مع فهارس لكل حقل، وبحث مُسرّع بتقنية SIMD، و LogSQL شبيه بـ SQL في بناء الجملة.

نقاط القوة: فهرس نصي كامل على جميع الرموز؛ ملف تنفيذي واحد؛ استهلاك منخفض جدًا للذاكرة؛ عمليات مسح سريعة للذاكرة المؤقتة الباردة.
المفاضلات: نظام بيئي أصغر، عدد أقل من عمليات التكامل المضمنة (نقوم بتمرير البيانات عبر Vector).

منهجية الاختبار المعياري

Category	Details
Requests/Memory	(4 vCPU, 8 GiB RAM) – identical for both systems, QoS: Guaranteed
Log Generator	flog pushing 65 MB/s to Vector → Loki / Vector → VictoriaLogs
Data Set	~500 GB over 7 days; mixed duplicate & unique lines; 20 namespaces, 40 apps
Retention	7 days
Clients	Locust 2.27.1, 10 virtual users, sustained 43 RPS to /select/logsql/query Grafana
Queries Tested	Stats, Needle in a Haystack, Regex, Negative (details below)
Caching	Block-cache disabled for both systems to simulate cold reads; pods were restarted to ensure this.
Index Tweaks	Loki: defaults; VictoriaLogs: defaults

مجموعة الاستعلامات

الإحصائيات – إجمالي عدد الأسطر لمرشح في آخر 24 ساعة.
إبرة في كومة قش – 3-4 سطر ثابت [UNIQUE-STATIC-LOG] ID=abc123 XYZ في مساحة اسم مليئة بالسجلات الكثيفة على مدار 7 أيام.
سلبي – سلسلة نصية لا توجد (تفرض فحصًا كاملاً) على مدار 7 أيام.

🔍 أداء الاستعلام

1. استعلام الإحصائيات (عدد السجلات على مدار 24 ساعة)

الغرض: إجمالي سطور السجل من app="servicefoundry-server"

System	Query	Latency
Loki	sum(count_over_time({app="servicefoundry-server"}[24h]))	2.5s
VictoriaLogs	{app="servicefoundry-server"} \| stats count()	1.5s

2. استعلام إبرة في كومة قش (7 أيام، ~500 جيجابايت)

الغرض: البحث عن سطر سجل ثابت فريد في truefoundry مساحة الاسم

System	Query	Latency
Loki	{namespace="truefoundry", app!="grafana"} \|= "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"	12s
VictoriaLogs	{namespace="truefoundry", app!="grafana"} "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"	~900ms

3. مطابقة سجل إعادة تشغيل التطبيق (7 أيام) (استعلام إضافي للتحقق من الخطوة 2)

الغرض: البحث عن نمط إعادة تشغيل معروف :3000 في مجموعة فرعية صغيرة من السجلات (تستهدف جزءًا واحدًا)
تم التحقق من أن مجموعات النتائج متطابقة.

System	Query	Latency
Loki	{app="servicefoundry-server"} \|= ":3000"	~2.2 s
VictoriaLogs	{app="servicefoundry-server"} ":3000"	~2.2 s

4. مطابقة سجل غير موجود (7 أيام)

الغرض: البحث عن سجل غير موجود، مما يؤدي إلى تشغيل بحث كامل للبيانات
تم التحقق من أن مجموعات النتائج متطابقة.

عند معالجة بيانات بحجم 500 جيجابايت، تصرف Loki بغرابة. اختنقت الموارد وتوقفت استجابة الاستعلام.

System	Query	Latency
Loki (500 GB)	{namespace="truefoundry"} \|= "non-existent log line"	Timeout
VictoriaLogs (500 GB)	{namespace="truefoundry"} "non-existent log line"	2.2s
Loki (300 GB)	{namespace="truefoundry"} \|= "non-existent log line"	2.6s
VictoriaLogs (300 GB)	{namespace="truefoundry"} "non-existent log line"	266ms

Loki مقابل VictoriaLogs: النتائج في لمحة

ركز تقييمنا على ثلاثة أبعاد تهم مهندسي المنصات في عملهم اليومي:

ما مدى سرعة حصولنا على الإجابات؟
كم تكلف هذه السرعة من الموارد؟
ما مدى استقرار التجربة تحت الحمل الحقيقي؟

أداء الاستعلام

Workload	Loki	VictoriaLogs	Speed-up
Stats (24h)	2.5s	1.5s	40 % faster
Needle (500 GB)	12s	1s	12× faster
Pattern “:3000” (7d)	2.2s	2.2s	same result
Negative (7d)	2.6s	266ms	10× faster

‍

لماذا هذا الفارق؟ يحتفظ VictoriaLogs بفهرس لكل رمز، لذا حتى عمليات الفحص الشبيهة بالتعابير النمطية تكون مدعومة بالفهرس. على النقيض من ذلك، يقوم Loki بالتصفية سطرًا بسطر بعد استعلام التسمية، مما يتحول إلى فحص بالقوة الغاشمة عندما تكون مجموعة التسميات واسعة.

🌪️ · أداء الاستيعاب

كما اختبرنا أداء الاستيعاب تحت الضغط باستخدام 120 نسخة متماثلة من flog مولد.
كانت النتائج مذهلة:

Metric	Loki	VictoriaLogs	Outcome
Peak Ingestion	20 MB/s	66 MB/s	3× higher throughput
vCPU Usage	4 vCPUs (100 % throttled)	2 vCPUs peak	≥50 % reduction
Memory Usage	≈4 GiB	≈1.3 GiB	~3× lower

Loki:

يرتفع استهلاك Loki إلى 3-4 vCPU، ويقترب من حده الأقصى البالغ 8 جيجابايت، ويظهر تباطؤًا تحت نفس عبء العمل

VictoriaLogs:

👉 الخلاصة الرئيسية: قدمت VictoriaLogs سرعة استيعاب أعلى بثلاثة أضعاف بينما تستهلك أقل بنسبة 72% من وحدة المعالجة المركزية و أقل بنسبة 87% من الذاكرة مقارنة بـ Loki.

تبقى VictoriaLogs بأريحية دون حدودها البالغة 4 vCPU / 8 جيجابايت حتى أثناء فترات الاستيعاب المكثفة

2 · استهلاك الموارد (احتفاظ لمدة 7 أيام)

Loki

الذاكرة المستخدمة: تستخدم باستمرار 6-7 جيجابايت من ذاكرة الوصول العشوائي
ذروة استخدام المعالج: 3 vCPU

‍

VictoriaLogs

الذاكرة المستخدمة: 800 ميجابايت - 900 ميجابايت
ذروة استخدام وحدة المعالجة المركزية: 1.1 vCPU

	Loki	VictoriaLogs	Delta
Storage	501 GiB	318 GiB	37 %
Memory	6–7 GiB steady	0.6–2 GiB	33–80 %
CPU peak	4 vCPU (throttled)	1.1 vCPU	73 %

3 · حمل واقعي (تشغيل Locust لمدة دقيقتين بواسطة 10 مستخدمين و 2 تصاعد)

كانت الاستعلامات متشابهة، مع حدود عشوائية ونطاق زمني عشوائي، لضمان تدفقات ذاكرة التخزين المؤقت.

Victoria Logs

Loki

📌 على الرغم من معالجة معدل طلبات في الثانية أعلى بنسبة 36%، أظهر VictoriaLogs زمن استجابة أقل عند p95% وزمن استجابة ذيلي أقل — مما يثبت أن نموذج الفهرسة الخاص به يصمد تحت الضغط مع 3.6 ضعف أسرع p99%

‍عزز هذا الاختبار قرارنا: VictoriaLogs ليس أسرع نظريًا فحسب، بل يتوسع بشكل أفضل تحت الضغط في أعباء العمل الشبيهة بالإنتاج.

خلاصة الأرقام

أسرع بنسبة 70-94% عبر أنماط البحث الشائعة.
أصغر بنسبة 40% تقريبًا على القرص مع نفس فترة الاحتفاظ.
نصف موارد الحوسبة، مما يوفر وحدة معالجة مركزية افتراضية كاملة وحوالي 1-2 جيجابايت من ذاكرة الوصول العشوائي على أصغر العقد لدينا.

الخلاصة: بالنسبة لحالة استخدام كثيفة السجلات وتتمحور حول البحث، يتيح لنا VictoriaLogs الإجابة على الأسئلة في ثوانٍ بدلاً من دقائق مع خفض تكاليف البنية التحتية.

النتائج الرئيسية

أهمية فهرس النص الكامل – فهرس VictoriaLogs القائم على الرموز يلغي تصفية الأسطر بالقوة الغاشمة.
تخطيط التخزين – التخزين العمودي + LSM يقلل بشكل كبير من الحجم على القرص وعمليات البحث في القرص.
كفاءة الذاكرة – حررنا حوالي 2 جيجابايت من ذاكرة الوصول العشوائي لكل عقدة، مما يسمح بجدولة أكثر كثافة.
بساطة التشغيل – كلاهما يعمل بملف تنفيذي واحد، لكن VictoriaLogs لم يحتج أي ضبط مخصص لتحقيق هذه الأرقام.

الاستنتاج

بالنسبة لملفات تعريف أعباء العمل التي تعتمد بشكل كبير على البحث النصي المخصص، قدمت VictoriaLogs فارقًا كبيرًا في سرعة الاستعلامات وتوفيرًا ماديًا في التكاليف. يظل Loki خيارًا ممتازًا عندما تسود التكاملات المحكمة مع Grafana والاستعلامات القائمة على التسميات أولاً، لكن VictoriaLogs هو الآن خيارنا الافتراضي للمجموعات عالية الاستيعاب والتي تركز على المطورين.

المراجع

الأسئلة الشائعة

ما هو الفرق الرئيسي بين VictoriaLogs و Loki؟

الفرق الرئيسي بين VictoriaLogs و Loki يكمن في الفهرسة المتقدمة لكل رمز والتخزين العمودي في VictoriaLogs. يتيح ذلك أداء استعلامات أسرع بكثير واستخدامًا أقل للموارد بشكل ملحوظ مقارنة بفهرسة Loki المعتمدة على التسميات فقط، والتي غالبًا ما تؤدي إلى عمليات بحث أبطأ بمسح كامل ونفقات تشغيلية أعلى لإدارة السجلات.

هل VictoriaLogs أسرع من Loki؟

نعم، في اختبارات الأداء الصارمة التي أجريناها، أظهرت VictoriaLogs سرعة فائقة مقارنة بـ Loki. في مقارنات VictoriaLogs مقابل Loki، قللت VictoriaLogs من زمن استجابة الاستعلامات بنسبة 94% وحققت أوقات بحث أسرع بـ 12 مرة للاستعلامات المعقدة. كما قدمت أداء استيعاب أعلى بـ 3 مرات، مما يجعلها أكثر كفاءة بشكل ملحوظ.

ما هو المنفذ الافتراضي لـ VictoriaLogs؟

عند تقييم VictoriaLogs مقابل Loki، من المفيد معرفة تفاصيل الإعداد. تستخدم VictoriaLogs عادةً المنفذ 8428 لواجهة برمجة تطبيقات HTTP الافتراضية ونقاط نهاية التجميع. يتيح هذا المنفذ الوصول والتفاعل مع قاعدة بيانات السجلات. بينما تركز مدونتنا على الأداء، فإن فهم أساسيات النشر، مثل المنفذ الافتراضي، أمر بالغ الأهمية لتكوين النظام.

ما هي نتائج اختبارات الأداء لـ VictoriaLogs مقابل Loki؟

في اختبارات الأداء التي قارنت VictoriaLogs بـ Loki، قدمت VictoriaLogs أداءً فائقًا. فقد حققت انخفاضًا بنسبة 94% في زمن استجابة الاستعلامات، وقللت من استخدام التخزين بنسبة 40% تقريبًا، واستهلكت أقل من 50% من وحدة المعالجة المركزية والذاكرة العشوائية المخصصة. كما أظهرت VictoriaLogs إنتاجية استيعاب أعلى بـ 3 مرات، مما يجعلها عالية الكفاءة.

أيهما أفضل: VictoriaLogs أم Loki؟

في اختبارات الأداء التي أجريناها لـ VictoriaLogs مقابل Loki، أثبتت VictoriaLogs تفوقها. فقد خفضت زمن استجابة الاستعلامات بنسبة 94%، وقللت التخزين بنسبة 40%، واستخدمت أقل من 50% من وحدة المعالجة المركزية/الذاكرة العشوائية. اختارت TrueFoundry في الولايات المتحدة VictoriaLogs لأدائها وكفاءتها المحسّنة في إدارة أعباء عمل التعلم الآلي.

TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

Built for Speed: ~10ms Latency, Even Under Load

Schedule your Demo Now