تحسين الأداء باستخدام ذاكرة التخزين المؤقت مع خادم مرن قاعدة بيانات Azure لـ PostgreSQL

عند إنشاء تطبيق على خادم مرن قاعدة بيانات Azure لـ PostgreSQL، تعد إضافة طبقة التخزين المؤقت إحدى الطرق الأكثر فعالية لتحسين أوقات الاستجابة وتقليل الحمل على قاعدة البيانات وزيادة المرونة. من خلال تقديم البيانات المقروءة بشكل متكرر من ذاكرة التخزين المؤقت في الذاكرة، يرسل التطبيق الخاص بك استعلامات أقل إلى PostgreSQL. وهذا يعني انخفاض استهلاك وحدة المعالجة المركزية وIOS، بحيث يمكنك التشغيل على طبقة حساب أصغر، وتوسيع نطاق القراءات دون توسيع نطاق الخادم، واستيعاب ارتفاعات نسبة استخدام الشبكة. يمكن أن تضيف ذاكرة التخزين المؤقت أيضا المرونة. إذا كان PostgreSQL لديه انقطاع قصير، يمكن أن تستمر الطلبات التي تصل إلى البيانات الموجودة بالفعل في ذاكرة التخزين المؤقت في النجاح، لذلك تظل مسارات القراءة متوفرة أثناء استرداد قاعدة البيانات.

تساعدك هذه المقالة على تحديد متى يساعد التخزين المؤقت والنمط الذي يناسب تطبيقك. ثم ينفذ أربعة أنماط تخزين مؤقت في Python (ذاكرة التخزين المؤقت المصاحبة، والإحضار المسبق للبيانات المرجعية، والكتابة من خلال، والأحداث) باستخدام Azure Managed Redisredispsycopg والمكتبات و، والمصادقة Microsoft Entra ID.

متى يتم إضافة ذاكرة تخزين مؤقت

يقوم PostgreSQL بالفعل بتخزين صفحات البيانات التي يتم الوصول إليها بشكل متكرر في ذاكرة التخزين المؤقت للمخزن المؤقت الخاص به، كما يستفيد من ذاكرة التخزين المؤقت للملفات في نظام التشغيل. تجعل ذاكرة التخزين المؤقت هذه الوصول المتكرر أسرع، ولكنها تشارك الذاكرة المخصصة لخادم قاعدة البيانات مع تنفيذ الاستعلام والعمليات الأخرى. تحتاج محتوياتها أيضا إلى التسخين مرة أخرى بعد بعض عمليات الصيانة وتجاوز الفشل.

يمكنك الحصول على المزيد من سعة ذاكرة التخزين المؤقت لقاعدة البيانات عن طريق التحجيم إلى خيار حساب بمزيد من الذاكرة. يمكنك أيضا ضبط إعدادات ذاكرة PostgreSQL، ولكن تخصيص المزيد من الذاكرة لذاكرة التخزين المؤقت للمخزن المؤقت يترك أقل لتنفيذ الاستعلام ونظام التشغيل. اختبر تغييرات الذاكرة بعناية لتجنب حالات نفاد الذاكرة.

يكمل Azure Managed Redis هذه ذاكرة التخزين المؤقت الأصلية. يقوم بتخزين بيانات التطبيق المحددة ونتائج الاستعلام خارج خادم قاعدة البيانات، ويوفر وصولا أقل لزمن انتقال لمسارات القراءة الحساسة للوقت، ويمكنه الاحتفاظ بقراءة مخزنة مؤقتا متوفرة أثناء استرداد PostgreSQL أو تجهيز ذاكرة التخزين المؤقت الخاصة به. استخدمه عندما تبرر هذه الفوائد منطق التطبيق المضاف وخدمة أخرى للعمل. لا يحل محل PostgreSQL كمصدر للحقيقة.

تساعد إضافة ذاكرة تخزين مؤقت خارجية مثل Azure Redis المدارة بشكل أكبر عندما يكون لحمل العمل الخاص بك هذه الخصائص:

• أنماط الوصول الثقيلة للقراءة. تتم قراءة الصفوف نفسها في كثير من الأحيان أكثر مما تتغير، مثل كتالوجات المنتجات أو ملفات تعريف المستخدمين أو بيانات التكوين أو الجداول المرجعية.
• استعلامات مكلفة أو متكررة. التجميعات أو الصلات أو النتائج المحسوبة المكلفة لإنتاجها ولكنها مستقرة على مدى نوافذ زمنية قصيرة.
• نقاط النهاية الحساسة لزمن الانتقال. العمليات التي تواجه المستخدم حيث تكون القراءة في الذاكرة (أقل من مللي ثانية) مفضلة على رحلة ذهابا وإيابا لقاعدة البيانات.
• طفرات يمكن التنبؤ بها. نسبة استخدام الشبكة الموسمية أو المستندة إلى الحدث حيث يمتص التخزين المؤقت الحمل الذي سيجبرك على تغيير حجم الحساب.
• الصيانة وحساسية تجاوز الفشل. قراءة المسارات التي تحتاج إلى أوقات استجابة ثابتة بينما يسترد مثيل PostgreSQL ذاكرة التخزين المؤقت الخاصة به أو يسخنها بعد عملية الصيانة أو تجاوز الفشل.

يساعد التخزين المؤقت أقل لأحمال العمل كثيفة الكتابة، أو البيانات التي يجب أن تكون دائما متسقة من الناحية العملية، أو الاستعلامات سريعة بالفعل ونادرا ما تتكرر.

أنماط التخزين المؤقت

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

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

المتطلبات المسبقه

• حساب Azure مع اشتراك نشط. إنشاء حساب مجانا.
• مثيل خادم مرن قاعدة بيانات Azure لـ PostgreSQL مع تمكين مصادقة Microsoft Entra. لإنشاء خادم، راجع إنشاء خادم مرن قاعدة بيانات Azure لـ PostgreSQL.
• نسخة Redis مدارة من Azure. لإنشاء واحد، راجع إنشاء مثيل redis مدار Azure. قم بإنشائه في نفس المنطقة مثل خادم PostgreSQL (وللإنتاج، نفس الشبكة الظاهرية) لتقليل زمن الانتقال.
• الوصول إلى البيانات لمطورك أو هوية التطبيق على كلتا الخدمتين: مسؤول Microsoft Entra أو دور على خادم PostgreSQL، وتعيين نهج وصول Redis على ذاكرة التخزين المؤقت. راجع مصادقة Microsoft Entra قاعدة بيانات Azure لـ PostgreSQLواستخدام Microsoft Entra ID للمصادقة مع Azure Managed Redis.
• Python 3.10 أو أحدث.
• واجهة سطر الأوامر Azure CLI. لتثبيته، راجع كيفية تثبيت Azure CLI.

نصيحة

للحصول على الإصدار الكامل القابل للنشر من هذا النموذج، بما في ذلك البنية الأساسية كتعليمية وجميع الأنماط الأربعة، راجع مستودع amr-caching-pattern-samples على GitHub.

الخطوة 1: تثبيت مكتبات العميل

قم بتثبيت مكتبات عميل Redis وPostgreSQL، جنبا إلى جنب مع مكتبة الهوية Azure للمصادقة Microsoft Entra.

pip install "redis>=5.0,<6.0" "psycopg[binary]>=3.1,<4.0" "azure-identity>=1.17,<2.0"

الخطوة 2: الاتصال مع Microsoft Entra ID

استخدم مصادقة Microsoft Entra ID بدلا من مفاتيح الوصول. Microsoft Entra ID يزيل الحاجة إلى تخزين الأسرار في التطبيق الخاص بك ويسمح لك بإدارة الوصول مركزيا.

تنشئ التعليمات البرمجية التالية عميل Redis واتصال PostgreSQL، وكلاهما تمت مصادقته بهوية مدارة أو بيانات اعتماد المطور من خلال DefaultAzureCredential. يستخدم المثال العميل المدرك RedisCluster لنظام المجموعة، والذي يطابق نهج تجميع OSS الذي يستخدمه هذا النموذج. إذا كانت ذاكرة التخزين المؤقت تستخدم نهج تجميع المؤسسات، فاستخدم العميل القياسي redis.Redis بدلا من ذلك.

import os
import json
import redis
from redis.cluster import RedisCluster
import psycopg
from azure.identity import DefaultAzureCredential

REDIS_HOST = os.environ["REDIS_HOST"]  # for example, mycache.eastus.redis.azure.net
REDIS_PORT = 10000
PG_HOST = os.environ["PG_HOST"]        # for example, myserver.postgres.database.azure.com
PG_DATABASE = os.environ["PG_DATABASE"]

credential = DefaultAzureCredential()

# Acquire a token for Azure Managed Redis and use it as the password.
redis_token = credential.get_token("https://redis.azure.com/.default")

# The username is the object ID of the Microsoft Entra identity.
redis_client = RedisCluster(
    host=REDIS_HOST,
    port=REDIS_PORT,
    ssl=True,
    ssl_check_hostname=False,  # cluster nodes are reached by IP; the certificate chain is still validated
    username=os.environ["REDIS_USER_OBJECT_ID"],
    password=redis_token.token,
    decode_responses=True,
)

# Acquire a token for Azure Database for PostgreSQL and use it as the password.
pg_token = credential.get_token("https://ossrdbms-aad.database.windows.net/.default")

pg_conn = psycopg.connect(
    host=PG_HOST,
    dbname=PG_DATABASE,
    user=os.environ["PG_USER"],
    password=pg_token.token,
    sslmode="require",
)

ملاحظة

تنتهي صلاحية Microsoft Entra الرموز المميزة للوصول، عادة بعد حوالي ساعة واحدة. بالنسبة للتطبيقات طويلة الأمد، قم بتحديث الرمز المميز قبل انتهاء صلاحيته وإعادة الاتصال لكل من Azure Managed Redis قاعدة بيانات Azure لـ PostgreSQL، أو استخدم مساعدا يعيد طلب الرموز المميزة بشفافية. للحصول على التفاصيل، راجع استخدام Microsoft Entra ID للمصادقة مع Azure Redis المدارة.

الخطوة 3: ذاكرة التخزين المؤقت جانبا

ذاكرة التخزين المؤقت المصاحبة هي النمط الأكثر شيوعا وتستخدم لقراءة المنتج في هذا النموذج. يتحقق التطبيق من Redis أولا، وفي حالة عدم وجوده، يستعلم PostgreSQL ويملأ ذاكرة التخزين المؤقت بوقت البقاء (TTL). تدفع بعض المنتجات الشائعة معظم القراءات، لذلك فإن معدل الوصول مرتفع.

نظرا لأن معظم القراءات يتم تقديمها من الذاكرة، فإن ذاكرة التخزين المؤقت جانبا تأخذ حمل القراءة المستمر من PostgreSQL. يعني هذا التخفيض عددا أقل من الاتصالات، وتناقصا أقل في ذاكرة التخزين المؤقت، وخفض وحدة المعالجة المركزية (CPU) وIOOPS. يمكنك استيعاب طفرات القراءة دون توسيع نطاق الخادم أو إضافة نسخ متماثلة للقراءة. يمكنك الاستعلام عن PostgreSQL فقط عند فقدان (الوصول الأول، أو بعد انتهاء صلاحية TTL). راجع البحث عن ما يجب تخزينه مؤقتا لتحديد الاستعلامات التي تستحق التخزين المؤقت.

CACHE_TTL_SECONDS = 300  # 5 minutes

def get_product(product_id: int) -> dict | None:
    cache_key = f"product:{product_id}"

    # 1. Try the cache first.
    cached = redis_client.get(cache_key)
    if cached is not None:
        return json.loads(cached)

    # 2. On a miss, read from PostgreSQL.
    with pg_conn.cursor() as cursor:
        cursor.execute("SELECT id, name, price FROM products WHERE id = %s", (product_id,))
        row = cursor.fetchone()
    if row is None:
        return None

    product = {"id": row[0], "name": row[1], "price": float(row[2])}

    # 3. Populate the cache with a TTL, then return.
    redis_client.set(cache_key, json.dumps(product), ex=CACHE_TTL_SECONDS)
    return product

الخطوة 4: الإحضار المسبق للبيانات المرجعية

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

def prefetch_categories() -> None:
    with pg_conn.cursor() as cursor:
        cursor.execute("SELECT id, name FROM categories ORDER BY name")
        categories = [{"id": r[0], "name": r[1]} for r in cursor.fetchall()]
    redis_client.set("ref:categories", json.dumps(categories))  # no TTL; refreshed on change

def get_categories() -> list[dict]:
    cached = redis_client.get("ref:categories")
    return json.loads(cached) if cached else []

الخطوة 5: الكتابة من خلال

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

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

def update_price(product_id: int, new_price: float) -> None:
    # 1. Write to PostgreSQL, the source of truth.
    with pg_conn.cursor() as cursor:
        cursor.execute("UPDATE products SET price = %s WHERE id = %s", (new_price, product_id))
    pg_conn.commit()

    # 2. Refresh the cached entry so reads see the new price right away.
    with pg_conn.cursor() as cursor:
        cursor.execute("SELECT id, name, price FROM products WHERE id = %s", (product_id,))
        row = cursor.fetchone()
    if row is not None:
        product = {"id": row[0], "name": row[1], "price": float(row[2])}
        redis_client.set(f"product:{product_id}", json.dumps(product), ex=CACHE_TTL_SECONDS)

الخطوة 6: الإبطال المستند إلى الحدث

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

استخدم هذا النمط عندما يتم اشتقاق قيمة مخزنة مؤقتا من البيانات التي تتغير في مكان آخر (حالة أو إسقاط أو تجميع)، حيث قد يخدم TTL بيانات قديمة أو يفرض إعادة حساب ثابتة. في واجهة المتجر، يدفع هذا النمط حالة الطلب من خلال التنفيذ. يقوم وضع طلب بكتابة الطلب إلى PostgreSQL، وتخزين حالته الأولية مؤقتا، وإلحاق placed حدث بالدفق:

ORDER_STREAM = "orders:events"

def place_order(product_id: int, quantity: int) -> int:
    with pg_conn.cursor() as cursor:
        cursor.execute(
            "INSERT INTO orders (product_id, quantity, status) VALUES (%s, %s, 'placed') RETURNING id",
            (product_id, quantity),
        )
        order_id = cursor.fetchone()[0]
    pg_conn.commit()

    redis_client.set(f"order:{order_id}:status", "placed", ex=86400)
    redis_client.xadd(ORDER_STREAM, {"order_id": order_id, "status": "placed"}, maxlen=10000, approximate=True)
    return order_id

يدير عامل التنفيذ مجموعة مستهلكين: يقرأ أحداثا جديدة، ويتقدم بكل طلب في PostgreSQL، ويحدث الإسقاط المخزن order:{id}:status مؤقتا، ويقر بالحدث. تقرأ صفحة الطلب هذا الإسقاط، لذا تظل عمليات التحقق من الحالة سريعة ولا تلمس قاعدة البيانات أبدا. تظل القيمة صحيحة لأن الأحداث تبقيها محدثة.

GROUP = "fulfillment"

def process_orders() -> None:
    try:
        redis_client.xgroup_create(ORDER_STREAM, GROUP, id="0", mkstream=True)
    except redis.exceptions.ResponseError:
        pass  # group already exists

    while True:
        events = redis_client.xreadgroup(GROUP, "worker-1", {ORDER_STREAM: ">"}, count=10, block=5000)
        for _stream, entries in events or []:
            for event_id, fields in entries:
                order_id = int(fields["order_id"])
                with pg_conn.cursor() as cursor:
                    cursor.execute("UPDATE orders SET status = 'shipped' WHERE id = %s", (order_id,))
                pg_conn.commit()
                redis_client.set(f"order:{order_id}:status", "shipped", ex=86400)
                redis_client.xack(ORDER_STREAM, GROUP, event_id)

مصدر الحدث في هذا النموذج هو التطبيق، الذي يكتب PostgreSQL ويلحق الحدث في نفس المسار. يمكن ل PostgreSQL أيضا إصدار تغييرات نفسها: LISTEN/NOTIFY للإعلامات الخفيفة، أو فك الترميز المنطقي (التقاط تغيير البيانات) لدفق تغيير دائم على مستوى الصف. يعني قيادة ذاكرة التخزين المؤقت من دفق التغيير الخاص ب PostgreSQL أنه يتفاعل مع كل تغيير ملتزم به، حتى أنه يكتب الذي يتجاوز التطبيق.

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

اتبع هذه الممارسات للحفاظ على ذاكرة التخزين المؤقت الخاصة بك صحيحة وفعالة وفعالة من حيث التكلفة.

• قم بتعيين TTL حيثما كان الثبات خطرا. يحد TTL من الثبات في حالة فشل الإبطال. مطابقة TTL مع الحد الأقصى من الثبات الذي يمكن للتطبيق قبوله. استخدم TTL طويل أو بدون TTL للبيانات المرجعية فقط عند وجود عمليات إبطال وتحديث موثوقة.
• استخدم نظام تسمية مفتاح متناسق. مفاتيح مساحة الاسم حسب الخدمة والكيان والمعرف، مثل product:42 أو user:1001:profile. أضف إصدارا عندما يمكن تغيير تنسيق المفتاح أو مخطط القيمة.
• قم بذاكرة التخزين المؤقت للنقاوة الصحيحة. تخزين الكيانات الفردية أو مجموعات النتائج الصغيرة مؤقتا عند إعادة استخدامها في كثير من الأحيان ويسهل إبطالها. لا تقم بالتخزين المؤقت للبيانات التي لا تحتوي على إعادة استخدام تذكر. التخزين المؤقت المفرط يضيع الذاكرة ويمكن أن يقلل من معدل الوصول.
• التعامل مع حالات فقدان ذاكرة التخزين المؤقت وانقطاعها بأمان. تعامل مع ذاكرة التخزين المؤقت على أنها تحسين، وليس مصدرا للحقيقة. إذا لم يكن Redis متوفرا، فاستخدم احتياطيا محددا إلى PostgreSQL. أضف المهلات وفواصل الدوائر والتراجع وحدود الطلب لحماية PostgreSQL. إذا كان PostgreSQL لديه انقطاع قصير، يمكنك الاستمرار في تقديم القراءات للبيانات الموجودة بالفعل في ذاكرة التخزين المؤقت بينما ينتظر الكتابة حتى يتم استرداد قاعدة البيانات.
• منع طوابع ذاكرة التخزين المؤقت. عند انتهاء صلاحية مفتاح شائع، يمكن أن تصل العديد من الطلبات إلى قاعدة البيانات في وقت واحد. استخدم TTL jitter أو طلب الاندماج أو إعادة التحقق من القيمة القديمة أو تأمين موزع قصير للسماح لطلب واحد بإعادة ملء الإدخال.
• الحجم الصحيح لذاكرة التخزين المؤقت. مراقبة معدل الوصول، واستخدام الذاكرة، ومعدل الإخلاء، ومعدل انتهاء الصلاحية، وزمن الانتقال، والمفاتيح الساخنة، والعلاقة الأساسية للمفتاح. يمكن أن يشير معدل الضرب المنخفض إلى ذاكرة تخزين مؤقت صغيرة جدا، أو عمليات إخلاء مفرطة، أو اختيار مفتاح رديء، أو نمط وصول ضعيف. للحصول على إرشادات تغيير الحجم، راجع Azure إرشادات تحديد مستوى Redis المدار.
• اختر نهج إخلاء يناسب مفاتيحك. بالنسبة لقاعدة بيانات ذاكرة التخزين المؤقت فقط، ابدأ ب allkeys-lru أو allkeys-lfu. استخدم نهج متقلب* فقط عندما تحتوي نفس قاعدة البيانات على مفاتيح ذاكرة التخزين المؤقت منتهية الصلاحية ومفاتيح محمية غير منتهية الصلاحية. يمكن أن يتوقف النهج المتقلب عن الإخلاء عندما لا تحتوي أي مفاتيح على TTL. فصل بيانات ذاكرة التخزين المؤقت عن البيانات المحمية عندما يكون ذلك ممكنا.
• تسلسل بكفاءة. JSON قابل للقراءة والمحمولة. بالنسبة إلى المسارات عالية الإنتاجية، اختبر تنسيقا ثنائيا مضغوطا لتقليل الذاكرة والنفقات العامة للشبكة. الذاكرة القياسية، وحدة المعالجة المركزية، زمن الانتقال، تطور المخطط، وتأثير تصحيح الأخطاء قبل تغيير التنسيق.

البحث عن ما يجب تخزينه مؤقتا

أهداف ذاكرة التخزين المؤقت الأكثر فعالية هي الاستعلامات التي يعمل بها تطبيقك في معظم الأحيان مقابل البيانات التي تتغير على الأقل. بدلا من تخمين الاستعلامات التي تناسب هذا الوصف، قارن طرق العرض التاريخية والحالية في بيانات تتبع الاستخدام للاستعلام التي قاعدة بيانات Azure لـ PostgreSQL يمكن جمعها عند تمكين الميزات ذات الصلة:

• يستمر Query Store في إحصائيات تنفيذ الاستعلام للتحليل التاريخي. استخدم عدد الاستدعاءات وإجمالي متوسط وقت التنفيذ للعثور على الاستعلامات التي تهيمن باستمرار على تحميل قاعدة البيانات على مدى فترات أطول. راجع مراقبة الأداء باستخدام Query Store.
• تصور Query Performance Insight بيانات Query Store في مدخل Azure، بحيث يمكنك اكتشاف الاستعلامات المتكررة والمكثفة للموارد ومقارنة سلوكها بمرور الوقت. راجع Query Performance Insight.
• pg_stat_statements يعرض الإحصائيات التراكمية لكل بيان داخل قاعدة البيانات لعرض مباشر لنافذة المراقبة الحالية. يمكن إعادة تعيين إحصائياته، لذا استخدم Query Store عندما تحتاج إلى محفوظات محتفظ بها عبر نوافذ المراقبة.

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

المحتوى ذو الصلة

• ما هو Azure Managed Redis؟
• إرشادات التخزين المؤقت
• التخطيط قاعدة بيانات Azure لـ PostgreSQL عمليات نشر الخادم المرنة للأداء التشغيلي