डेटाबेस स्केलिंग रणनीतियाँ: प्रतिकृतियाँ, साझाकरण और उससे आगे पढ़ें

डेटाबेस प्रदर्शन 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: लंबवत स्केलिंग ($)

अपने मौजूदा डेटाबेस सर्वर पर सीपीयू, रैम और स्टोरेज बढ़ाएँ। इससे समय बर्बाद होता है और एप्लिकेशन में शून्य परिवर्तन की आवश्यकता होती है।

अधिकांश एप्लिकेशन 64 जीबी रैम और 8 वीसीपीयू पर अपनी सीमा तक पहुंचते हैं। इसके अलावा, ऊर्ध्वाधर स्केलिंग लागत-निषेधात्मक हो जाती है।

चरण 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

एप्लिकेशन-स्तरीय रूटिंग (ड्रिज़ल ओआरएम उदाहरण):

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];
}

कैश अमान्यकरण रणनीति: लिखने पर अमान्य करें। जब कोई उत्पाद अपडेट किया जाता है, तो कैश कुंजी हटा दें। राइट-थ्रू (डेटाबेस कैश को प्रबंधित करता है) के बजाय कैश-असाइड पैटर्न (एप्लिकेशन कैश को प्रबंधित करता है) का उपयोग करें।

Step 6: Horizontal Sharding ($$$)

शेयरिंग एक शार्ड कुंजी के आधार पर कई डेटाबेस इंस्टेंसेस में डेटा वितरित करता है।

कब शार्ड करें:

• एकल डेटाबेस 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% पर अलर्ट)। यदि आप नियमित रूप से इन सीमाओं को पार कर रहे हैं, तो स्केलिंग सीढ़ी पर अगले चरण पर जाएँ। जब डेटा आपसे कहे तो --- स्केल को पूर्व-अनुकूलित न करें।

प्रतिकृतियां या कैशिंग पढ़ें --- पहले कौन सा?

कैशिंग से प्रारंभ करें. रेडिस कैशिंग को लागू करना आसान है, अधिक लोड को समाप्त करता है (कैश हिट डेटाबेस को पूरी तरह से छोड़ देता है), और लागत कम होती है। जब आपकी कैश हिट दर पहले से ही 80% से ऊपर हो, लेकिन प्राथमिक डेटाबेस अभी भी कैश मिस और राइट ऑपरेशंस के दबाव में है, तो रीड प्रतिकृतियां जोड़ें।

ओडू के साथ डेटाबेस स्केलिंग कैसे काम करती है?

Odoo विशेष रूप से PostgreSQL का उपयोग करता है। क्वेरी अनुकूलन से प्रारंभ करें (Odoo रिपोर्टिंग के लिए जटिल क्वेरी उत्पन्न करता है)। जब आपके समवर्ती उपयोगकर्ता 50 से अधिक हो जाएं तो कनेक्शन पूलिंग के लिए PgBouncer जोड़ें। रिपोर्टिंग प्रश्नों के लिए पढ़ी गई प्रतिकृतियों का उपयोग करें (ओडू के --db-replica विकल्प को कॉन्फ़िगर करें)। ECOSIRE डेटाबेस ट्यूनिंग सहित Odoo प्रदर्शन अनुकूलन प्रदान करता है।

क्या प्रबंधित डेटाबेस (आरडीएस/क्लाउड एसक्यूएल) प्रीमियम के लायक है?

हाँ, अधिकांश व्यवसायों के लिए। प्रबंधित डेटाबेस स्वचालित बैकअप, पैचिंग, फ़ेलओवर और मॉनिटरिंग को संभालते हैं। स्व-प्रबंधित PostgreSQL पर 30-40% लागत प्रीमियम की भरपाई आपके द्वारा बचाए गए इंजीनियरिंग समय से होती है। अपवाद बड़े पैमाने पर तैनाती है जहां बड़े उदाहरण पर लागत प्रीमियम अंशकालिक डीबीए की लागत से अधिक है।

---

आगे क्या आता है

डेटाबेस स्केलिंग व्यापक बुनियादी ढांचे स्केलिंग रणनीति का एक घटक है। इसे स्थिर परिसंपत्तियों के लिए सीडीएन अनुकूलन, एप्लिकेशन पॉड्स के लिए कुबेरनेट्स ऑटो-स्केलिंग और यथार्थवादी परिस्थितियों में अपने स्केलिंग निर्णयों को मान्य करने के लिए लोड परीक्षण के साथ संयोजित करें।

डेटाबेस अनुकूलन परामर्श के लिए ECOSIRE से संपर्क करें, या संपूर्ण बुनियादी ढांचे रोडमैप के लिए हमारा DevOps गाइड देखें।

---

ECOSIRE द्वारा प्रकाशित - व्यवसायों को आत्मविश्वास के साथ डेटा अवसंरचना बढ़ाने में मदद करना।