ذاكرة التخزين المؤقت للاستعلامات

تتيح ذاكرة التخزين المؤقت للاستعلامات تنفيذ استعلامات SELECT مرة واحدة فقط، ثم تقديم عمليات التنفيذ اللاحقة للاستعلام نفسه مباشرةً من ذاكرة التخزين المؤقت. واعتمادًا على نوع الاستعلامات، يمكن أن يؤدي ذلك إلى تقليل زمن الوصول واستهلاك الموارد على ClickHouse server بشكل كبير.

الخلفية والتصميم والقيود

يمكن عمومًا النظر إلى ذاكرات التخزين المؤقت للاستعلامات على أنها متسقة أو غير متسقة من ناحية المعاملات.

في ذاكرات التخزين المؤقت المتسقة من ناحية المعاملات، تُبطِل قاعدة البيانات (تستبعد) نتائج الاستعلامات المخزنة مؤقتًا إذا تغيّرت نتيجة استعلام SELECT أو كان من المحتمل أن تتغيّر. في ClickHouse، تشمل العمليات التي تغيّر البيانات عمليات insert/update/delete في الجداول أو عمليات الدمج من نوع collapsing. ويُعدّ التخزين المؤقت المتسق من ناحية المعاملات مناسبًا بشكل خاص لقواعد بيانات OLTP، مثل MySQL (الذي أزال ذاكرة التخزين المؤقت للاستعلامات بعد v8.0) و Oracle.
في ذاكرات التخزين المؤقت غير المتسقة من ناحية المعاملات، يُقبل وجود فروق طفيفة في نتائج الاستعلامات على افتراض أن جميع عناصر cache تُمنح فترة صلاحية تنتهي بعدها (مثلًا دقيقة واحدة)، وأن البيانات الأساسية لا تتغير إلا بقدر محدود خلال هذه الفترة. ويُعد هذا النهج، عمومًا، أنسب لقواعد بيانات OLAP. وكمثال على حالة يكون فيها التخزين المؤقت غير المتسق من ناحية المعاملات كافيًا، تخيّل تقرير مبيعات بالساعة في أداة لإعداد التقارير يصل إليه عدة مستخدمين في الوقت نفسه. فعادةً ما تتغير بيانات المبيعات ببطء يكفي لأن تحتاج قاعدة البيانات إلى compute التقرير مرة واحدة فقط (ويمثل ذلك أول استعلام SELECT). وبعد ذلك يمكن تقديم الاستعلامات اللاحقة مباشرةً من ذاكرة التخزين المؤقت للاستعلامات. وفي هذا المثال، قد تكون فترة صلاحية معقولة 30 دقيقة.

يُوفَّر التخزين المؤقت غير المتسق من ناحية المعاملات تقليديًا عبر أدوات client أو حزم proxy (مثل chproxy) التي تتفاعل مع قاعدة البيانات. ونتيجةً لذلك، غالبًا ما يتكرر منطق التخزين المؤقت نفسه و الإعداد نفسه. ومع ذاكرة التخزين المؤقت للاستعلامات في ClickHouse، ينتقل منطق التخزين المؤقت إلى جهة server. وهذا يقلل جهد الصيانة ويجنب الازدواجية.

إعدادات التكوين والاستخدام

في ClickHouse Cloud، يجب استخدام إعدادات على مستوى الاستعلام لتعديل إعدادات ذاكرة التخزين المؤقت للاستعلامات. لا تتوفر حاليًا إمكانية تعديل إعدادات على مستوى config.

يشغّل clickhouse-local استعلامًا واحدًا فقط في كل مرة. ونظرًا إلى أن تخزين نتائج الاستعلامات مؤقتًا في الذاكرة لا جدوى منه في حالة عملية واحدة، فإن ذاكرة التخزين المؤقت للاستعلامات في الذاكرة تكون معطّلة في clickhouse-local. أما ذاكرة التخزين المؤقت للاستعلامات على القرص فمتاحة، إذ تُحفَظ عناصرها في ذاكرة التخزين المؤقت لنظام الملفات على القرص، ومن ثَمّ يمكن للعمليات اللاحقة من clickhouse-local التي تستخدم دليل ذاكرة التخزين المؤقت لنظام الملفات نفسه الاستفادة من النتائج التي خزّنتها عملية سابقة.

يمكن استخدام الإعداد use_query_cache للتحكم في ما إذا كان ينبغي لاستعلام معيّن أو لجميع استعلامات الجلسة الحالية استخدام ذاكرة التخزين المؤقت للاستعلامات. على سبيل المثال، أول تنفيذ للاستعلام

SELECT some_expensive_calculation(column_1, column_2)
FROM table
SETTINGS use_query_cache = true;

سيُخزِّن نتيجة الاستعلام في ذاكرة التخزين المؤقت للاستعلامات. وستقرأ عمليات التنفيذ اللاحقة للاستعلام نفسه (أيضًا مع المعلَمة use_query_cache = true) النتيجة المحسوبة من ذاكرة التخزين المؤقت وتُعيدها فورًا.

لا تسري use_query_cache وجميع الإعدادات الأخرى المرتبطة بذاكرة التخزين المؤقت للاستعلامات إلا على عبارات SELECT المستقلة. وعلى وجه الخصوص، لا تُخزَّن نتائج عبارات SELECT الموجَّهة إلى العروض المُنشأة باستخدام CREATE VIEW AS SELECT [...] SETTINGS use_query_cache = true في ذاكرة التخزين المؤقت ما لم تُنفَّذ عبارة SELECT مع SETTINGS use_query_cache = true.

يمكن ضبط طريقة استخدام ذاكرة التخزين المؤقت بمزيد من التفصيل باستخدام الإعدادين enable_writes_to_query_cache وenable_reads_from_query_cache (وكلاهما true افتراضيًا). يتحكم الإعداد الأول في ما إذا كانت نتائج الاستعلامات ستُخزَّن في ذاكرة التخزين المؤقت، بينما يحدد الإعداد الثاني ما إذا كان ينبغي على قاعدة البيانات محاولة استرجاع نتائج الاستعلامات من ذاكرة التخزين المؤقت. على سبيل المثال، سيستخدم الاستعلام التالي ذاكرة التخزين المؤقت بشكل سلبي فقط، أي سيحاول القراءة منها دون تخزين نتيجته فيها:

SELECT some_expensive_calculation(column_1, column_2)
FROM table
SETTINGS use_query_cache = true, enable_writes_to_query_cache = false;

لأقصى قدر من التحكم، يُوصى عمومًا بتوفير الإعدادات use_query_cache وenable_writes_to_query_cache و enable_reads_from_query_cache فقط مع استعلامات محددة. ويمكن أيضًا تمكين التخزين المؤقت على مستوى المستخدم أو ملف التعريف (مثلًا عبر SET use_query_cache = true)، لكن ينبغي الانتباه إلى أن جميع استعلامات SELECT قد تُرجع عندئذٍ نتائج مخزنة مؤقتًا. يمكن مسح ذاكرة التخزين المؤقت للاستعلامات باستخدام العبارة SYSTEM CLEAR QUERY CACHE. ويُعرض محتوى ذاكرة التخزين المؤقت للاستعلامات في جدول النظام system.query_cache. ويظهر عدد مرات الإصابة والإخفاق في ذاكرة التخزين المؤقت للاستعلامات منذ بدء تشغيل قاعدة البيانات كحدثين “QueryCacheHits” و”QueryCacheMisses” في جدول النظام system.events. ولا يُحدَّث هذان العدادان إلا من أجل استعلامات SELECT التي تعمل مع الإعداد use_query_cache = true، أما الاستعلامات الأخرى فلا تؤثر في “QueryCacheMisses”. ويصف هذان العدادان ذاكرة التخزين المؤقت للاستعلامات ككل: فعند تمكين ذاكرة التخزين المؤقت للاستعلامات على القرص (انظر أدناه)، يُحتسب الاستعلام الذي يُخفق في الذاكرة ثم يُخدَم من القرص إصابةً واحدة “QueryCacheHits”، بينما يُحتسب الاستعلام الذي يُخفق في كلتا الواجهتين الخلفيتين إخفاقًا واحدًا “QueryCacheMisses”. ويُظهر الحقل query_cache_usage في جدول النظام system.query_log لكل استعلام مُنفَّذ ما إذا كانت نتيجة الاستعلام قد كُتبت إلى ذاكرة التخزين المؤقت للاستعلامات أو قُرئت منها. وتُظهر المقاييس QueryCacheEntries وQueryCacheBytes في جدول النظام system.metrics عدد الإدخالات / البايتات التي تحتوي عليها ذاكرة التخزين المؤقت للاستعلامات في الذاكرة حاليًا. ولا تأخذ هذه المقاييس في الحسبان إدخالات ذاكرة التخزين المؤقت للاستعلامات على القرص، التي لا تتوفر لها حاليًا مقاييس لنسبة الإشغال. توجد ذاكرة التخزين المؤقت للاستعلامات مرة واحدة لكل عملية خادم ClickHouse. ومع ذلك، لا تكون النتائج المخزنة مؤقتًا مشتركة بين المستخدمين افتراضيًا. ويمكن تغيير ذلك (انظر أدناه)، لكن لا يُنصح به لأسباب أمنية. تُربَط نتائج الاستعلامات في ذاكرة التخزين المؤقت للاستعلامات بـشجرة البنية المجرّدة (AST) الخاصة باستعلاماتها. وهذا يعني أن التخزين المؤقت لا يتأثر بحالة الأحرف (كبيرة/صغيرة)؛ فعلى سبيل المثال، يُعامَل SELECT 1 وselect 1 على أنهما الاستعلام نفسه. ولجعل المطابقة أكثر طبيعية، تُزال من AST جميع الإعدادات على مستوى الاستعلام المتعلقة بذاكرة التخزين المؤقت للاستعلامات وتنسيق الإخراج) . إذا أُلغي الاستعلام بسبب استثناء أو إلغاء من المستخدم، فلن يُكتب أي إدخال في ذاكرة التخزين المؤقت للاستعلامات. يمكن تهيئة حجم ذاكرة التخزين المؤقت للاستعلامات بالبايت، والحد الأقصى لعدد إدخالات ذاكرة التخزين المؤقت، والحد الأقصى لحجم كل إدخال على حدة (بالبايت وبعدد السجلات) باستخدام خيارات تهيئة الخادم المختلفة.

<query_cache>
    <max_size_in_bytes>1073741824</max_size_in_bytes>
    <max_entries>1024</max_entries>
    <max_entry_size_in_bytes>1048576</max_entry_size_in_bytes>
    <max_entry_size_in_rows>30000000</max_entry_size_in_rows>
</query_cache>

يمكن أيضًا تقييد استخدام ذاكرة التخزين المؤقت للمستخدمين الفرديين باستخدام ملفات تعريف الإعدادات وقيود الإعدادات. وبشكل أكثر تحديدًا، يمكنك تقييد الحد الأقصى لذاكرة (بالبايت) التي يمكن للمستخدم تخصيصها في ذاكرة التخزين المؤقت للاستعلامات داخل الذاكرة، والحد الأقصى لعدد نتائج الاستعلام المخزّنة (لا تنطبق هذه الحدود على ذاكرة التخزين المؤقت للاستعلامات على القرص). ولتنفيذ ذلك، حدِّد أولًا الإعدادين query_cache_max_size_in_bytes و query_cache_max_entries في ملف تعريف مستخدم داخل users.xml، ثم اجعل كلا الإعدادين للقراءة فقط:

<profiles>
    <default>
        <!-- The maximum cache size in bytes for user/profile 'default' -->
        <query_cache_max_size_in_bytes>10000</query_cache_max_size_in_bytes>
        <!-- The maximum number of SELECT query results stored in the cache for user/profile 'default' -->
        <query_cache_max_entries>100</query_cache_max_entries>
        <!-- Make both settings read-only so the user cannot change them -->
        <constraints>
            <query_cache_max_size_in_bytes>
                <readonly/>
            </query_cache_max_size_in_bytes>
            <query_cache_max_entries>
                <readonly/>
            </query_cache_max_entries>
        </constraints>
    </default>
</profiles>

لتحديد الحد الأدنى لمدة تشغيل الاستعلام بحيث يمكن تخزين نتيجته مؤقتًا، يمكنك استخدام الإعداد query_cache_min_query_duration. على سبيل المثال، نتيجة الاستعلام

SELECT some_expensive_calculation(column_1, column_2)
FROM table
SETTINGS use_query_cache = true, query_cache_min_query_duration = 5000;

يُخزَّن مؤقتًا فقط إذا استغرق الاستعلام أكثر من 5 ثوانٍ. ويمكن أيضًا تحديد عدد المرات التي يجب أن يُنفَّذ فيها الاستعلام قبل أن تُخزَّن نتيجته مؤقتًا — ولهذا استخدم الإعداد query_cache_min_query_runs. تصبح إدخالات ذاكرة التخزين المؤقت للاستعلامات قديمة بعد فترة زمنية معينة (time-to-live). وتكون هذه الفترة افتراضيًا 60 ثانية، ولكن يمكن تحديد قيمة مختلفة على مستوى الجلسة أو ملف التعريف أو الاستعلام باستخدام الإعداد query_cache_ttl. وتُخرج ذاكرة التخزين المؤقت للاستعلامات إدخالات ذاكرة التخزين المؤقت بشكل “كسول”، أي عندما يصبح أحد العناصر قديمًا، لا يُزال فورًا من ذاكرة التخزين المؤقت. وبدلًا من ذلك، عندما يُراد إدراج عنصر جديد في ذاكرة التخزين المؤقت للاستعلامات، تتحقق قاعدة البيانات مما إذا كانت ذاكرة التخزين المؤقت تحتوي على مساحة خالية كافية للعنصر الجديد. وإذا لم تكن هذه هي الحالة، تحاول قاعدة البيانات إزالة جميع العناصر القديمة. وإذا ظلت ذاكرة التخزين المؤقت لا تحتوي على مساحة خالية كافية، فلن يُدرج العنصر الجديد. إذا جرى تنفيذ الاستعلام عبر HTTP، فإن ClickHouse يضبط ترويستَي Age وExpires مع عمر العنصر المخزَّن مؤقتًا (بالثواني) والطابع الزمني لانتهاء صلاحيته. تكون إدخالات ذاكرة التخزين المؤقت للاستعلامات مضغوطة افتراضيًا. وهذا يقلل إجمالي استهلاك الذاكرة على حساب بطء عمليات الكتابة إلى / والقراءة من ذاكرة التخزين المؤقت للاستعلامات. لتعطيل الضغط، استخدم الإعداد query_cache_compress_entries. أحيانًا يكون من المفيد الاحتفاظ بعدة نتائج مخزَّنة مؤقتًا للاستعلام نفسه. ويمكن تحقيق ذلك باستخدام الإعداد query_cache_tag الذي يعمل كتسمية (أو مساحة اسم) لإدخالات ذاكرة التخزين المؤقت. وتتعامل ذاكرة التخزين المؤقت للاستعلامات مع نتائج الاستعلام نفسه ذات الوسوم المختلفة على أنها مختلفة. مثال على إنشاء ثلاثة إدخالات ذاكرة التخزين المؤقت مختلفة للاستعلام نفسه:

SELECT 1 SETTINGS use_query_cache = true; -- query_cache_tag is implicitly '' (empty string)
SELECT 1 SETTINGS use_query_cache = true, query_cache_tag = 'tag 1';
SELECT 1 SETTINGS use_query_cache = true, query_cache_tag = 'tag 2';

لإزالة العناصر ذات الوسم tag فقط من ذاكرة التخزين المؤقت للاستعلامات، يمكنك استخدام العبارة SYSTEM CLEAR QUERY CACHE TAG 'tag'.

التخزين المؤقت للاستعلامات الفرعية

لا ينتقل use_query_cache في الاستعلام الخارجي، افتراضيًا، إلى الاستعلامات الفرعية. وهذا يعني أن على كل استعلام فرعي تفعيل التخزين المؤقت صراحةً:

SELECT *
FROM (SELECT number FROM system.numbers LIMIT 1000 SETTINGS use_query_cache = true)
WHERE number > 500;

في هذا المثال، لا تُخزَّن مؤقتًا إلا نتيجة الاستعلام الفرعي الداخلي. أما الاستعلام الخارجي فلا يُخزَّن مؤقتًا. لتمكين التخزين المؤقت لجميع الاستعلامات الفرعية دفعة واحدة، استخدم الإعداد query_cache_for_subqueries:

SELECT *
FROM (SELECT number FROM system.numbers LIMIT 1000)
WHERE number > 500
SETTINGS use_query_cache = true, query_cache_for_subqueries = true;

لتعطيل التخزين المؤقت صراحةً لاستعلام فرعي معيّن مع تفعيل النشر المجمّع، اضبط use_query_cache = false لهذا الاستعلام الفرعي:

SELECT *
FROM (SELECT number FROM system.numbers LIMIT 1000 SETTINGS use_query_cache = false)
WHERE number > 500
SETTINGS use_query_cache = true, query_cache_for_subqueries = true;

تظهر إدخالات ذاكرة التخزين المؤقت للاستعلامات الفرعية في ذاكرة التخزين المؤقت للاستعلامات داخل الذاكرة في system.query_cache مع is_subquery = 1. وتُخزَّن نتائج الاستعلامات الفرعية مؤقتًا على القرص أيضًا إذا كانت ذاكرة التخزين المؤقت للاستعلامات على القرص مفعّلة، لكن هذه الإدخالات لا تظهر في system.query_cache. وينطبق الإعداد query_cache_ttl أيضًا على إدخالات ذاكرة التخزين المؤقت الخاصة بالاستعلامات الفرعية، ويمكن ضبطه لكل استعلام فرعي على حدة. يقرأ ClickHouse بيانات الجدول في blocks من max_block_size rows. وبسبب التصفية وaggregation، وما إلى ذلك، تكون blocks النتائج عادةً أصغر بكثير من ‘max_block_size’، ولكن توجد أيضًا حالات تكون فيها أكبر بكثير. يتحكم الإعداد query_cache_squash_partial_results (ممكّن افتراضيًا) في ما إذا كانت blocks النتائج تُدمج (إذا كانت صغيرة جدًا) أو تُقسَّم (إذا كانت كبيرة) إلى blocks بحجم ‘max_block_size’ قبل إدراجها في ذاكرة التخزين المؤقت لنتيجة الاستعلام. ويؤدي ذلك إلى تقليل أداء عمليات الكتابة إلى ذاكرة التخزين المؤقت للاستعلامات، لكنه يحسّن معدل ضغط لإدخالات ذاكرة التخزين المؤقت ويوفر granularity أكثر طبيعية للـ block عند تقديم نتائج الاستعلام لاحقًا من ذاكرة التخزين المؤقت للاستعلامات. ونتيجة لذلك، يخزّن ذاكرة التخزين المؤقت للاستعلامات لكل استعلام عدة blocks نتائج (جزئية). ورغم أن هذا السلوك يُعد خيارًا افتراضيًا جيدًا، يمكن تعطيله باستخدام الإعداد query_cache_squash_partial_results. كذلك، لا تُخزَّن نتائج الاستعلامات التي تحتوي على دوال غير حتمية مؤقتًا افتراضيًا. وتشمل هذه الدوال:

الدوال الخاصة بالوصول إلى Dictionaries: dictGet() وغيرها.
الدوال المعرّفة من قبل المستخدم من دون الوسم <deterministic>true</deterministic> في تعريف XML الخاص بها،
الدوال التي تُرجع التاريخ أو الوقت الحاليين: now(), today(), yesterday() وغيرها،
الدوال التي تُرجع قيمًا عشوائية: randomString(), fuzzBits() وغيرها،
الدوال التي تعتمد نتيجتها على الحجم والترتيب أو على chunks الداخلية المستخدمة في معالجة الاستعلام: nowInBlock() وغيرها، rowNumberInBlock(), runningDifference(), blockSize() وغيرها،
الدوال التي تعتمد على البيئة: currentUser(), queryID(), getMacro() وغيرها.

لفرض تخزين نتائج الاستعلامات التي تحتوي على دوال غير حتمية مؤقتًا رغم ذلك، استخدم الإعداد query_cache_nondeterministic_function_handling. لا يتم، بشكل افتراضي، تخزين نتائج الاستعلامات التي تتضمن جداول النظام (مثل system.processes` أو information_schema.tables) في ذاكرة التخزين المؤقت. ولفرض تخزين نتائج الاستعلامات التي تتضمن جداول النظام في ذاكرة التخزين المؤقت رغم ذلك، استخدم الإعداد query_cache_system_table_handling. أخيرًا، لا تتم مشاركة إدخالات ذاكرة التخزين المؤقت للاستعلامات بين المستخدمين لأسباب أمنية. على سبيل المثال، يجب ألا يتمكن المستخدم A من تجاوز سياسة الصفوف على جدول من خلال تشغيل الاستعلام نفسه الذي يشغّله المستخدم B، والذي لا تنطبق عليه مثل هذه السياسة. ومع ذلك، إذا لزم الأمر، يمكن تمييز إدخالات ذاكرة التخزين المؤقت بحيث تصبح متاحة لمستخدمين آخرين (أي مشتركة) عبر توفير الإعداد query_cache_share_between_users.

ذاكرة التخزين المؤقت للاستعلامات على القرص

تحتفظ ذاكرة التخزين المؤقت للاستعلامات افتراضيًا بإدخالاتها في الذاكرة. ويمكن أيضًا تخزين نتائج الاستعلامات مؤقتًا على القرص بالاعتماد على ذاكرة التخزين المؤقت لنظام الملفات. ومقارنةً بذاكرة التخزين المؤقت للاستعلامات داخل الذاكرة، توفر ذاكرة التخزين المؤقت للاستعلامات على القرص مساحة أكبر، وتبقى محفوظة بعد إعادة تشغيل الخادم. ولا يُقدَّم الإدخال إلا من إصدار الخادم نفسه الذي كتبه، لذا فبعد الترقية أو الرجوع إلى إصدار أقدم، تُعدّ الإدخالات التي كتبها الإصدار السابق حالات إخفاق في ذاكرة التخزين المؤقت، وسيُكتب فوقها أو تُزال في نهاية المطاف. لاستخدام ذاكرة التخزين المؤقت للاستعلامات على القرص، قم أولًا بتهيئة ذاكرة تخزين مؤقت لنظام الملفات في القسم filesystem_caches من تهيئة الخادم:

<filesystem_caches>
    <query_results>
        <path>query_results_cache/</path>
        <max_size>10Gi</max_size>
    </query_results>
</filesystem_caches>

ثم حدِّد اسمه في الإعداد query_cache_on_disk_cache_name:

SELECT some_expensive_calculation(column_1, column_2)
FROM table
SETTINGS use_query_cache = true, query_cache_on_disk_cache_name = 'query_results';

تعمل ذاكرة التخزين المؤقت للاستعلامات على القرص بشكل مستقل عن ذاكرة التخزين المؤقت للاستعلامات في الذاكرة، ويمكن تفعيلها للقراءة و/أو الكتابة كلٌّ على حدة باستخدام الإعدادين enable_reads_from_query_cache_on_disk وenable_writes_to_query_cache_on_disk (وكلاهما true افتراضيًا). إذا كانت القراءة مفعّلة في كلتا الذاكرتين، فيُجرى البحث أولًا في الذاكرة، ولا يُلجأ إلى القرص إلا إذا لم يُعثر على النتيجة فيها. وإذا كانت الكتابة مفعّلة في كلتا الذاكرتين، فتُخزَّن النتيجة في كلتيهما. أما إذا تعذّر على أي ذاكرة تخزين مؤقت تخزين النتيجة (كما في clickhouse-local الذي لا يتضمن ذاكرة تخزين مؤقت للاستعلامات في الذاكرة، مع enable_writes_to_query_cache_on_disk = false)، فلن يُرفض الاستعلام بسبب الدوال غير الحتمية أو جداول النظام أو وضع تجاوز غير throw، لأن هذه الفحوصات لا تهدف إلا إلى منع تخزين نتائج خاطئة. تُضغط العناصر المخزنة على القرص باستخدام المرمِّز المحدد في الإعداد query_cache_on_disk_codec (ZSTD(3) افتراضيًا). ويقيّد إعدادا الخادم max_entry_size_in_bytes وmax_entry_size_in_rows الخاصان بـ ذاكرة التخزين المؤقت للاستعلامات حجمَ العناصر في كلتا الواجهتين الخلفيتين؛ إذ تقيس كل واجهة خلفية الإدخال وفق طريقة تخزينها له، ومن ثمّ يسري حد البايتات على القرص على الإدخال بعد تسلسله وضغطه. ويؤدي تعيين أيٍّ منهما إلى 0 إلى تعطيل الكتابة في كلتا الواجهتين الخلفيتين. أما سائر إعدادات ذاكرة التخزين المؤقت للاستعلامات (مثل query_cache_ttl وquery_cache_min_query_duration) فتسري على ذاكرة التخزين المؤقت للاستعلامات على القرص كما تسري على ذاكرة التخزين المؤقت للاستعلامات في الذاكرة، باستثناء الحالتين الموضحتين أدناه. يمثّل الإعدادان query_cache_max_size_in_bytes وquery_cache_max_entries حدّين لكل مستخدم يقتصران على ذاكرة التخزين المؤقت للاستعلامات في الذاكرة، ولا يُطبَّقان على ذاكرة التخزين المؤقت للاستعلامات على القرص؛ فالعناصر المخزنة على القرص يحدّها حجم ذاكرة التخزين المؤقت لنظام الملفات التي جرت تهيئتها، وتُزال وفق قواعدها (انظر أدناه). ولذلك يظل بإمكان مستخدم ذي ملف تعريف إعدادات مقيِّد أن يخزّن على القرص نتائج تفوق ما تسمح به هذه الإعدادات في الذاكرة. وهذا السلوك مقصود، إذ إن ذاكرة التخزين المؤقت لنظام الملفات مورد مشترك محدود الحجم، لا تحجز فيه ذاكرة التخزين المؤقت للاستعلامات على القرص مساحة خاصة بها. ويُعدّ الإعداد query_cache_share_between_users استثناءً آخر: فمعناه واحد في كلتا الواجهتين الخلفيتين، إذ يُقدَّم الإدخال المكتوب في ظله لجميع المستخدمين، غير أن طريقة عزل العناصر غير المشتركة تختلف بينهما. فذاكرة التخزين المؤقت للاستعلامات في الذاكرة تحتفظ بإدخال واحد لكل استعلام، وترفضه عند القراءة إذا كان يخص مستخدمًا آخر، ولذلك يحجب الإدخال غير المشترك للمستخدم A عمليات الكتابة للمستخدم B إلى أن تنتهي صلاحيته أو يُزال. أما ذاكرة التخزين المؤقت للاستعلامات على القرص فتجعل المستخدم ومجموعة أدواره الحالية جزءًا من مفتاح الإدخال غير المشترك، وبذلك لا يعثر المستخدم B على إدخال المستخدم A، فيخزّن نسخته الخاصة من النتيجة. والأمر نفسه ينطبق على المستخدم الواحد عند اختلاف مجموعات أدواره الحالية، كما بعد تنفيذ SET ROLE: فالأدوار تحمل امتيازات وسياسات صفوف، ولذلك تُخزَّن النتائج المحسوبة في ظل أدوار مختلفة كلٌّ على حدة. عناصر ذاكرة التخزين المؤقت للاستعلامات على القرص هي عناصر عادية في ذاكرة التخزين المؤقت لنظام الملفات، ولا يمكن تمييزها عن البيانات الأخرى المخزنة مؤقتًا في ذاكرة التخزين المؤقت لنظام الملفات نفسها: فهي غير محمية من الحذف، وتُزال وفق القواعد نفسها (مثل الأقل استخدامًا مؤخرًا) عندما تنفد المساحة في ذاكرة التخزين المؤقت لنظام الملفات. ولا توجد حدود منفصلة لحجمها الإجمالي أو عددها، إذ لا تُطبَّق سوى حدود ذاكرة التخزين المؤقت لنظام الملفات نفسها. تُزيل العبارة SYSTEM CLEAR QUERY CACHE (وSYSTEM CLEAR QUERY CACHE TAG 'tag') أيضًا عناصر (ذات الوسم المحدد؛ أما العناصر التالفة والعناصر ذات الصيغة غير المتوافقة فتُزال بغض النظر عن وسمها) ذاكرة التخزين المؤقت للاستعلامات على القرص من ذاكرة التخزين المؤقت لنظام الملفات المحددة بالإعداد query_cache_on_disk_cache_name الخاص بالـ session (مثلًا بعد SET query_cache_on_disk_cache_name = 'query_results')، مع الإبقاء على البيانات الأخرى في ذاكرة التخزين المؤقت لنظام الملفات كما هي. وللعثور على هذه العناصر، تمر العبارة على البيانات الوصفية لجميع مقاطع الملفات في ذاكرة التخزين المؤقت لنظام الملفات (في الذاكرة، دون القراءة من القرص) وتقرأ ترويسة كل مفتاح مُعلَّم بوصفه إدخالًا في ذاكرة التخزين المؤقت للاستعلامات. ويستغرق هذا المرور وقتًا يتناسب مع عدد مقاطع الملفات في ذاكرة التخزين المؤقت لنظام الملفات، لذا فإن تخصيص ذاكرة تخزين مؤقت لنظام الملفات لنتائج الاستعلامات وحدها يُبقي تنفيذ SYSTEM CLEAR QUERY CACHE منخفض التكلفة. وإذا كانت ذاكرة التخزين المؤقت لنظام الملفات قد أزالت بالفعل بداية إدخال ما، فإن ما تبقى منه يظل في مكانه إلى أن تُزيله ذاكرة التخزين المؤقت لنظام الملفات أو تُكتب نتيجة الاستعلام نفسها مجددًا، لكنه لا يُستخدم لتقديم النتائج أبدًا. وكذلك يبقى في مكانه أي إدخال لا تزال كتابته جارية. أما العبارة SYSTEM DROP FILESYSTEM CACHE '<name>' فتُزيل هذه العناصر مع كل ما عداها في ذاكرة التخزين المؤقت لنظام الملفات. لا يعرض جدول النظام system.query_cache والمقياسان QueryCacheEntries وQueryCacheBytes سوى عناصر ذاكرة التخزين المؤقت للاستعلامات في الذاكرة. ويظهر عدد مرات الإصابة والإخفاق في ذاكرة التخزين المؤقت للاستعلامات على القرص في الحدثين “QueryCacheOnDiskHits” و”QueryCacheOnDiskMisses” في جدول النظام system.events. يمثل هذان الحدثان تفصيلًا خاصًا بالواجهة الخلفية على القرص وحدها، في حين يظل “QueryCacheHits” و “QueryCacheMisses” عدّادَي ذاكرة التخزين المؤقت للاستعلامات ككل، ويحتسب “QueryCacheAgeSeconds” الإصابات في كلتا الواجهتين الخلفيتين. تُفحص ذاكرة التخزين المؤقت في الذاكرة أولًا، لذا فإن عدد الإصابات في الذاكرة يساوي “QueryCacheHits” مطروحًا منه “QueryCacheOnDiskHits”.

مدونة: مقدمة إلى ذاكرة التخزين المؤقت للاستعلامات في ClickHouse

الأساسيات

مفاهيم ClickHouse

أفضل الممارسات

ذاكرة التخزين المؤقت للاستعلامات

الخلفية والتصميم والقيود

إعدادات التكوين والاستخدام

التخزين المؤقت للاستعلامات الفرعية

ذاكرة التخزين المؤقت للاستعلامات على القرص

​الخلفية والتصميم والقيود

​إعدادات التكوين والاستخدام

​التخزين المؤقت للاستعلامات الفرعية

​ذاكرة التخزين المؤقت للاستعلامات على القرص

​محتوى مرتبط

الخلفية والتصميم والقيود

إعدادات التكوين والاستخدام

التخزين المؤقت للاستعلامات الفرعية

ذاكرة التخزين المؤقت للاستعلامات على القرص

محتوى مرتبط