معرفی وب سایت dbdesigner

یکی از بهترین وب سایت ها برای طراحی دیاگرام دیتابیستون هستش.
حتی میتونید بعد از طراحی خروجی postgres و mysql و چند تا دیتابیس معروف دیگه رو هم بگیرید تا با یه دستور ساده توی دیتابیس, هر چیزی که طراحی کردید ساخته شه.

پیشنهاد میکنم حتما حتما یکی از اولین اقدام های استارت پروژتون طراحی دیاگرام دیتابیستون باشه.

https://app.dbdesigner.net/

#database

@Syntax_fa

📢 معرفی CONN_MAX_AGE در Django

متغیر CONN_MAX_AGE یکی از تنظیمات مهم Django است که برای مدیریت اتصالات پایدار (Persistent Connections) به پایگاه داده استفاده می‌شود. این تنظیم مشخص می‌کند که یک اتصال به پایگاه داده برای چه مدت زمان زنده بماند و پس از آن بسته شود.

🔍 CONN_MAX_AGE چیست و چگونه عمل می‌کند؟

- مقدار CONN_MAX_AGE نشان‌دهنده مدت زمان (بر حسب ثانیه) است که یک اتصال به پایگاه داده در حالت باز باقی می‌ماند.
- اگر مقدار آن روی ۰ تنظیم شود، اتصال به پایگاه داده پس از هر درخواست بسته می‌شود (رفتار پیش‌فرض).
- اگر مقدار CONN_MAX_AGE روی `None` تنظیم شود، اتصال به پایگاه داده هرگز بسته نمی‌شود و دائماً زنده می‌ماند (تا زمانی که فرآیند Worker یا برنامه بسته شود).

⚙️ مقدار پیش‌فرض CONN_MAX_AGE

به صورت پیش‌فرض، مقدار CONN_MAX_AGE برابر با ۰ است. یعنی Django پس از پایان هر درخواست، اتصال به پایگاه داده را می‌بندد و برای درخواست جدید، اتصال دیگری باز می‌کند. این رفتار برای پروژه‌های کوچک یا آزمایشی مناسب است ولی در محیط تولید (Production) ممکن است باعث کاهش عملکرد شود.

✏️ نحوه تنظیم CONN_MAX_AGE

مقدار CONN_MAX_AGE در تنظیمات پایگاه داده تعریف می‌شود. مثال زیر نحوه استفاده از آن را نشان می‌دهد:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'your_database',
        'USER': 'your_user',
        'PASSWORD': 'your_password',
        'HOST': 'your_host',
        'PORT': 'your_port',
        'CONN_MAX_AGE': 600,  # 600 seconds
    }
}

✅ چند سناریو برای تنظیم CONN_MAX_AGE

1. پروژه کوچک یا محیط توسعه
- سناریو: اگر پروژه شما تعداد کمی از درخواست‌ها را مدیریت می‌کند یا در حال توسعه هستید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 0
     

- توضیح: اتصال پس از هر درخواست بسته می‌شود. این کار به شما کمک می‌کند که رفتار واقعی برنامه را در محیط توسعه مشاهده کنید.

2. پروژه با بار متوسط
- سناریو: اگر برنامه شما درخواست‌های متوسطی (نه کم، نه زیاد) دارد و پایگاه داده شما برای تعداد اتصالات زیاد محدودیت خاصی ندارد.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 300  # 5 minutes
     

- توضیح: این تنظیم باعث می‌شود که اتصالات برای چندین درخواست استفاده شوند و هزینه باز و بسته کردن اتصال کاهش یابد.

3. پروژه با بار زیاد (High Traffic)
- سناریو: اگر برنامه شما تعداد زیادی درخواست دارد و می‌خواهید عملکرد را بهینه کنید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 600  # 10 minutes
     

- توضیح: این مقدار کمک می‌کند که هزینه باز و بسته کردن مکرر اتصالات کاهش یابد، اما همچنان اتصالات پس از مدتی بسته می‌شوند تا از مشکلات احتمالی جلوگیری شود.

4. پروژه‌های با درخواست‌های خیلی کم
- سناریو: اگر برنامه شما به ندرت به پایگاه داده متصل می‌شود (مثلاً به دلیل استفاده از کش یا تعامل کم با پایگاه داده).
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 0  # each http request
     

- توضیح: نگه‌داشتن اتصال در این موارد منطقی نیست و بهتر است اتصال پس از هر درخواست بسته شود.

5. استفاده از Connection Pooling خارجی
- سناریو: اگر از ابزارهای خارجی مدیریت اتصال مانند pgbouncer (برای PostgreSQL) یا ProxySQL (برای MySQL) استفاده می‌کنید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': None
     

- توضیح: در این حالت، مدیریت اتصالات به ابزارهای خارجی سپرده شده است و Django نیازی به بستن اتصالات ندارد.

⚠️ نکات مهم:

1. مراقب تعداد اتصالات باشید:
اگر مقدار CONN_MAX_AGE را روی مقدار زیاد یا None تنظیم کنید، مطمئن شوید که سرور پایگاه داده شما می‌تواند تعداد زیادی اتصال همزمان را مدیریت کند. در غیر این صورت ممکن است با خطای "too many connections" مواجه شوید.

2. محیط production:
در محیط تولید، معمولاً مقدار CONN_MAX_AGE روی چند دقیقه (مثلاً ۵ تا ۱۰ دقیقه) تنظیم می‌شود تا عملکرد بهینه باشد و اتصالات مکرر ایجاد نشوند.

3. ابزارهای خارجی مدیریت اتصال:
اگر از Connection Pooling خارجی استفاده می‌کنید، مقدار CONN_MAX_AGE را روی None تنظیم کنید تا Django اتصال را مدیریت نکند.

conn_max_age

#database #django

@Syntax_fa

مقاله زیر به ما آموزش میده چطور 1,000,000 رکورد دیتا رو در 4 ثانیه در PostgreSQL ذخیره کنیم!

https://www.timescale.com/learn/testing-postgres-ingest-insert-vs-batch-insert-vs-copy?ref=timescale.com

#postgresql
#database

source

@Syntax_fa

💻 ناهمگونی خوندن داده‌ها یا Read Phenomena در دیتابیس‌ها
وقتی تراکنش‌ها همزمان دارن با داده‌ها کار می‌کنن، بعضی وقت‌ها نتیجه‌ای که می‌بینی، اون چیزی نیست که انتظار داری! به این وضعیت میگن Read Phenomena.

🔹 سه حالت اصلی:

1️⃣ خواندن داده کثیف (Dirty Read)
تراکنش A یه رکوردو تغییر میده ولی هنوز commit نکرده، تراکنش B میاد می‌خونه.
اگه بعداً A رولبک بشه، B یه داده‌ای خونده که واقعیت نداشته!

2️⃣ خواندن غیرتکراری (Non-Repeatable Read)
تراکنش A یه رکوردو می‌خونه، تراکنش B همون رکوردو تغییر میده و commit می‌کنه.
وقتی A دوباره می‌خونه، می‌بینه تغییر کرده!

3️⃣ خواندن شبح (Phantom Read)
تراکنش A یه مجموعه رکورد می‌خونه، تراکنش B بین دو بار خوندن یه رکورد اضافه یا حذف می‌کنه.
وقتی A دوباره می‌خونه، نتیجه فرق می‌کنه!

🔹 راه حل:
با سطوح Isolation در SQL میشه کنترلشون کرد:

Read Uncommitted

Read Committed

Repeatable Read

Serializable

هر سطح یه ترکیب متفاوت از سرعت و دقت داده‌ها میده.

📌 جمع‌بندی:
فهمیدن Read Phenomena کمک می‌کنه سطح Isolation مناسب انتخاب بشه و از مشکلاتی مثل محاسبات نادرست، داده‌های ناقص یا تداخل تراکنش‌ها جلوگیری بشه.
در پست‌های بعدی با جزئیات بیشتری به هر سطح Isolation می‌پردازم.

#database

@Syntax_fa