ڈیٹا بیس اسکیلنگ کی حکمت عملی: نقلیں، شارڈنگ، اور اس سے آگے پڑھیں

ڈیٹا بیس کی کارکردگی 78% ویب ایپلیکیشن اسکیلنگ کے مسائل میں رکاوٹ ہے۔ ایپلی کیشنز کم سے کم کوشش کے ساتھ افقی طور پر اسکیل کرسکتی ہیں، لیکن ڈیٹا بیس افقی اسکیلنگ کے خلاف مزاحمت کرتے ہیں۔ ڈیٹا بیس اسکیلنگ کے لیے آپ جو حکمت عملی منتخب کرتے ہیں اس سے یہ طے ہوتا ہے کہ آیا آپ کی ایپلیکیشن 100 صارفین کو پیش کرتی ہے یا قابل قبول کارکردگی کے ساتھ 100,000 صارفین کو۔

اس گائیڈ میں ڈیٹا بیس اسکیلنگ کی حکمت عملیوں کے مکمل اسپیکٹرم کا احاطہ کیا گیا ہے، سادہ اصلاح سے جو اسکیلنگ کی ضرورت میں تاخیر کرتی ہے جیسے افقی شارڈنگ جیسی جدید تکنیکوں تک۔

اہم ٹیک ویز

• بنیادی ڈھانچے کو شامل کرنے سے پہلے سوالات کو بہتر بنائیں اور اشاریہ جات شامل کریں --- یہ ڈیٹا بیس کی کارکردگی کے 60 فیصد مسائل کو حل کرتا ہے۔
• پڑھنے کی نقلیں سب سے کم خطرے والی اسکیلنگ کی حکمت عملی ہیں اور 80% پڑھنے والے بھاری کام کے بوجھ کو ہینڈل کرتی ہیں
• جب آپ کی درخواست 10 سے زیادہ مثالیں چلتی ہے تو کنکشن پولنگ لازمی ہے۔
• افقی شارڈنگ ایک آخری حربہ ہے جو درخواست کی اہم پیچیدگی کو متعارف کرواتا ہے۔

---

سکیلنگ سیڑھی

اس ترتیب میں پیمانہ۔ ہر قدم اگلے سے سستا اور کم خطرناک ہے:

مرحلہ 1: استفسار کی اصلاح (مفت)

بنیادی ڈھانچہ شامل کرنے سے پہلے، یقینی بنائیں کہ آپ کا موجودہ ڈیٹا بیس بہترین کارکردگی کا مظاہرہ کر رہا ہے۔

-- Find slow queries in PostgreSQL
SELECT
  calls,
  mean_exec_time::numeric(10,2) AS avg_ms,
  total_exec_time::numeric(10,2) AS total_ms,
  query
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

عام اصلاح:

• کثرت سے فلٹر کیے گئے کالموں کے لیے گمشدہ اشاریہ جات شامل کریں۔
• SELECT * کو مخصوص کالم فہرستوں سے تبدیل کریں۔
• بڑی میزوں پر ترتیب وار اسکینوں کی شناخت کے لیے EXPLAIN ANALYZE استعمال کریں۔
• کثیر کالم WHERE شقوں کے لیے جامع اشاریہ جات شامل کریں۔
• OFFSET کی بجائے کی سیٹ صفحہ بندی کے ساتھ صفحہ بندی لاگو کریں

-- Bad: OFFSET pagination (scans all skipped rows)
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 10000;

-- Good: Keyset pagination (index-only scan)
SELECT * FROM orders
WHERE created_at < '2026-03-15T10:00:00Z'
ORDER BY created_at DESC
LIMIT 20;

مرحلہ 2: عمودی اسکیلنگ ($)

اپنے موجودہ ڈیٹا بیس سرور پر CPU، RAM، اور اسٹوریج میں اضافہ کریں۔ یہ وقت خریدتا ہے اور درخواست میں صفر تبدیلیوں کی ضرورت ہوتی ہے۔

| مثال کا سائز | vCPU | رام | کنکشنز | ماہانہ لاگت (RDS) | |---------------|------|------|---------------| | db.t3.medium | 2 | 4 جی بی | 100 | $65 | | db.r6g.large | 2 | 16 جی بی | 200 | $175 | | db.r6g.xlarge | 4 | 32 جی بی | 400 | $350 | | db.r6g.2xlarge | 8 | 64 جی بی | 800 | $700 |

زیادہ تر ایپلیکیشنز 64 GB RAM اور 8 vCPUs پر اپنی حد تک پہنچ جاتی ہیں۔ اس سے آگے، عمودی پیمانہ لاگت ممنوع ہو جاتا ہے۔

مرحلہ 3: کنکشن پولنگ ($)

Application (50 pods x 20 connections = 1,000 connections)
    |
    v
PgBouncer (25 database connections, transaction pooling)
    |
    v
PostgreSQL (25 active connections, manageable)

پی جی باؤنسر کنفیگریشن:

[databases]
app = host=db.example.com port=5432 dbname=production

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
pool_mode = transaction
default_pool_size = 25
max_client_conn = 1000
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

مرحلہ 4: نقلیں پڑھیں ($$)

پرائمری سے ڈیٹا بیس کے 60-90% لوڈ کو آف لوڈ کرتے ہوئے، SELECT سوالات کو ہینڈل کرنے والی نقلیں پڑھیں۔

فن تعمیر:

Write queries --> Primary database
                      |
              Replication (async)
                      |
                 +----+----+
                 |         |
Read queries --> Replica 1  Replica 2

ایپلیکیشن لیول روٹنگ (بوندا باندی ORM مثال):

import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';

const primaryPool = new Pool({ connectionString: process.env.DATABASE_URL });
const replicaPool = new Pool({ connectionString: process.env.DATABASE_REPLICA_URL });

export const primaryDb = drizzle(primaryPool);
export const replicaDb = drizzle(replicaPool);

// In service code:
// Write operations use primaryDb
async createOrder(data: OrderInput) {
  return primaryDb.insert(orders).values(data).returning();
}

// Read operations use replicaDb
async getOrders(organizationId: string) {
  return replicaDb.select().from(orders)
    .where(eq(orders.organizationId, organizationId))
    .orderBy(desc(orders.createdAt));
}

ریپلیکیشن لیگ پر غور کرنا: Async ریپلیکیشن میں تاخیر ہوتی ہے (عام طور پر 10-100ms)۔ تحریر کے فوراً بعد، نقل سے پڑھنے سے باسی ڈیٹا واپس آ سکتا ہے۔ پڑھنے کے لیے پرائمری کا استعمال کریں جو ایک ہی صارف کے بہاؤ میں لکھتے ہیں۔

مرحلہ 5: کیشنگ ($$)

ریڈیس کیشنگ بار بار ڈیٹا بیس کے سوالات کو مکمل طور پر ختم کر دیتی ہے۔

async getProduct(id: string): Promise<Product> {
  const cacheKey = `product:${id}`;

  // Check cache first
  const cached = await this.redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Cache miss: query database
  const product = await this.db.select().from(products)
    .where(eq(products.id, id))
    .limit(1);

  // Cache for 5 minutes
  await this.redis.setex(cacheKey, 300, JSON.stringify(product[0]));

  return product[0];
}

کیشے کو باطل کرنے کی حکمت عملی: لکھنے پر باطل کریں۔ جب کوئی پروڈکٹ اپ ڈیٹ ہو جائے تو کیش کلید کو حذف کر دیں۔ رائٹ تھرو (ڈیٹا بیس کیشے کا انتظام کرتا ہے) کے بجائے کیشے سے الگ پیٹرن (ایپلی کیشن کیشے کا انتظام کرتی ہے) استعمال کریں۔

مرحلہ 6: افقی شارڈنگ ($$$)

شارڈنگ ایک شارڈ کلید کی بنیاد پر ڈیٹا کو متعدد ڈیٹا بیس مثالوں میں تقسیم کرتی ہے۔

کب شارڈ کرنا ہے:

• سنگل ڈیٹا بیس 1 ٹی بی سے زیادہ ہے اور بڑھ رہا ہے۔
• تھرو پٹ اس سے زیادہ لکھیں جو ایک پرائمری کو سنبھال سکتا ہے۔
• عمودی اسکیلنگ کے اخراجات $2,000/ماہ سے زیادہ ہیں بغیر ہیڈ روم کے

جب شارڈ نہ کریں:

• آپ نے 1-5 مراحل کو ختم نہیں کیا ہے۔
• آپ کا ڈیٹا ایک ہی 500 جی بی ڈیٹا بیس میں فٹ بیٹھتا ہے۔
• آپ کی درخواست میں کراس شارڈ سوالات عام ہیں۔

---

PostgreSQL- مخصوص اصلاح

تقسیم کرنا (شیئر کرنے سے پہلے)

PostgreSQL ٹیبل پارٹیشننگ ایک ہی منطقی جدول کو برقرار رکھتے ہوئے بڑی میزوں کو چھوٹے فزیکل ٹیبلز میں تقسیم کرتی ہے۔

-- Partition orders by month
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    organization_id UUID NOT NULL,
    created_at TIMESTAMP NOT NULL,
    total DECIMAL(10,2)
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2026_01 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE orders_2026_02 PARTITION OF orders
    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

CREATE TABLE orders_2026_03 PARTITION OF orders
    FOR VALUES FROM ('2026-03-01') TO ('2026-04-01');

پارٹیشننگ بڑی میزوں پر ٹائم رینج کے سوالات کے لیے استفسار کی کارکردگی کو 10-100x تک بہتر بناتی ہے کیونکہ PostgreSQL صرف متعلقہ پارٹیشنز کو اسکین کرتا ہے۔

ویکیومنگ اور دیکھ بھال

-- Check table bloat
SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  round(n_dead_tup::numeric / greatest(n_live_tup, 1) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

ہائی رائٹ ٹیبلز کے لیے آٹو ویکیوم کو جارحانہ انداز میں ترتیب دیں:

ALTER TABLE orders SET (
  autovacuum_vacuum_threshold = 100,
  autovacuum_vacuum_scale_factor = 0.05,
  autovacuum_analyze_threshold = 50,
  autovacuum_analyze_scale_factor = 0.02
);

---

ڈیٹا بیس کی کارکردگی کی نگرانی

کب اور کیسے پیمانہ کرنا ہے یہ سمجھنے کے لیے ان میٹرکس کو ٹریک کریں:

95% سے نیچے کیش ہٹ کا تناسب سب سے مضبوط اشارہ ہے کہ آپ کو زیادہ میموری کی ضرورت ہے۔ shared_buffers اور effective_cache_size کو بڑھانا اکثر پڑھی ہوئی نقلیں شامل کرنے سے سستا اور تیز ہوتا ہے۔

استفسار پرفارمنس ٹریکنگ

-- Enable pg_stat_statements (postgresql.conf)
-- shared_preload_libraries = 'pg_stat_statements'

-- Find the top 10 most time-consuming queries
SELECT
  queryid,
  calls,
  mean_exec_time::numeric(10,2) AS avg_ms,
  total_exec_time::numeric(10,2) AS total_ms,
  rows,
  query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

ہفتہ وار ٹاپ 10 سوالات کا جائزہ لیں۔ کثرت سے عمل میں آنے والے ایک سوال کو بھی بہتر بنانے سے ڈیٹا بیس کے مجموعی بوجھ کو 10-30% تک کم کیا جا سکتا ہے۔

---

اکثر پوچھے گئے سوالات

ہمیں کیسے پتہ چلے گا کہ کب پیمانے کا وقت ہے؟

تین میٹرکس کی نگرانی کریں: استفسار میں تاخیر P95 (500ms پر الرٹ)، کنکشن کا استعمال (80% پر الرٹ)، اور CPU کا استعمال (70% پر الرٹ برقرار)۔ اگر آپ ان حدوں کو باقاعدگی سے مار رہے ہیں، تو اسکیلنگ سیڑھی کے اگلے مرحلے پر جائیں۔ جب ڈیٹا آپ کو بتائے تو پہلے سے بہتر نہ بنائیں --- اسکیل کریں۔

نقل یا کیشنگ پڑھیں --- کون سا پہلے؟

کیشنگ کے ساتھ شروع کریں۔ Redis کیشنگ کو لاگو کرنا آسان ہے، زیادہ بوجھ کو ختم کرتا ہے (کیشے ہٹنے سے ڈیٹا بیس کو مکمل طور پر چھوڑ دیا جاتا ہے)، اور اس کی قیمت کم ہوتی ہے۔ جب آپ کی کیش ہٹ ریٹ پہلے سے ہی 80% سے اوپر ہو تو پڑھنے کی نقلیں شامل کریں لیکن بنیادی ڈیٹا بیس ابھی بھی کیش مسز اور رائٹ آپریشنز کے دباؤ میں ہے۔

Odoo کے ساتھ ڈیٹا بیس اسکیلنگ کیسے کام کرتی ہے؟

Odoo خصوصی طور پر PostgreSQL استعمال کرتا ہے۔ استفسار کی اصلاح کے ساتھ شروع کریں (Odoo رپورٹنگ کے لیے پیچیدہ سوالات پیدا کرتا ہے)۔ کنکشن پولنگ کے لیے PgBouncer شامل کریں جب آپ 50 ایک ساتھ استعمال کنندگان سے تجاوز کر جائیں۔ استفسارات کی اطلاع دینے کے لیے پڑھی ہوئی نقلیں استعمال کریں (اوڈو کے --db-replica اختیار کو ترتیب دیں)۔ ECOSIRE ڈیٹا بیس ٹیوننگ سمیت Odoo کارکردگی کی اصلاح فراہم کرتا ہے۔

کیا مینیجڈ ڈیٹا بیس (RDS/Cloud SQL) پریمیم کے قابل ہے؟

ہاں، زیادہ تر کاروباروں کے لیے۔ منظم ڈیٹا بیس خودکار بیک اپ، پیچنگ، فیل اوور اور نگرانی کو سنبھالتے ہیں۔ خود نظم کردہ PostgreSQL پر 30-40% لاگت کا پریمیم آپ کے بچائے ہوئے انجینئرنگ وقت سے پورا ہوتا ہے۔ استثناء بڑے پیمانے پر تعیناتی ہے جہاں ایک بڑی مثال پر لاگت کا پریمیم جز وقتی DBA کی لاگت سے زیادہ ہے۔

---

آگے کیا آتا ہے۔

ڈیٹا بیس اسکیلنگ وسیع تر انفراسٹرکچر اسکیلنگ حکمت عملی کا ایک جزو ہے۔ اسے جامد اثاثوں کے لیے CDN آپٹیمائزیشن، ایپلیکیشن پوڈز کے لیے Kubernetes آٹو اسکیلنگ، اور لوڈ ٹیسٹنگ کے ساتھ جوڑیں تاکہ حقیقت پسندانہ حالات میں اپنے اسکیلنگ کے فیصلوں کی توثیق کی جاسکے۔

ڈیٹا بیس کی اصلاح سے متعلق مشاورت کے لیے ECOSIRE سے رابطہ کریں، یا مکمل انفراسٹرکچر روڈ میپ کے لیے ہماری DevOps گائیڈ دیکھیں۔

---

ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو اعتماد کے ساتھ ڈیٹا کے بنیادی ڈھانچے کی پیمائش کرنے میں مدد کرنا۔