چگونه دیتابیس یک فروشگاه اینترنتی را برای میلیون‌ها رکورد آماده کنیم؟

چگونه دیتابیس یک فروشگاه اینترنتی را برای میلیون‌ها رکورد آماده کنیم؟

مقدمه

در مراحل اولیه توسعه یک فروشگاه اینترنتی، ممکن است دیتابیس با چند هزار محصول، تعدادی سفارش و تعداد محدودی کاربر به‌خوبی کار کند. Queryها سریع اجرا می‌شوند، فهرست محصولات به‌سرعت نمایش داده می‌شود و ثبت سفارش نیز بدون مشکل انجام می‌گیرد.

اما با رشد کسب‌وکار، شرایط تغییر می‌کند.

تعداد محصولات افزایش می‌یابد، سفارش‌های بیشتری ثبت می‌شوند، کاربران به‌صورت هم‌زمان جست‌وجو می‌کنند و گزارش‌های مدیریتی حجم زیادی از داده‌ها را پردازش می‌کنند. در چنین شرایطی، ساختاری که در ابتدا مناسب بوده است، ممکن است به گلوگاه عملکردی تبدیل شود.

برای مثال، یک فروشگاه ممکن است با چند میلیون رکورد محصول و ده‌ها میلیون رکورد مرتبط با سفارش‌ها مواجه شود. در این مقیاس، اجرای یک Query نامناسب، ایندکس‌گذاری غیراصولی یا مدیریت ضعیف تراکنش‌ها می‌تواند زمان پاسخ‌گویی سیستم را افزایش دهد.

نکته اصلی این است که آماده‌سازی دیتابیس برای میلیون‌ها رکورد، صرفاً به معنای افزایش منابع سرور نیست؛ بلکه به طراحی صحیح داده‌ها، الگوی دسترسی، مدیریت هم‌زمانی و اندازه‌گیری عملکرد وابسته است.

در این مقاله، با تمرکز بر PostgreSQL بررسی می‌کنیم که چگونه می‌توان دیتابیس یک فروشگاه اینترنتی را برای رشد بلندمدت آماده کرد.

۱. طراحی Schema متناسب با نیازهای واقعی فروشگاه

اولین قدم، طراحی ساختار منطقی دیتابیس است. اگر روابط داده‌ها از ابتدا به‌درستی تعریف نشوند، افزایش منابع سخت‌افزاری نیز نمی‌تواند تمام مشکلات معماری را برطرف کند.

یک فروشگاه اینترنتی معمولاً با موجودیت‌های زیر سروکار دارد:

• محصولات و دسته‌بندی‌ها

• کاربران و آدرس‌ها

• سفارش‌ها و اقلام سفارش

• پرداخت‌ها

• موجودی انبار

• تخفیف‌ها و قیمت‌گذاری

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

نمونه‌ای از ساختار جداول

جدول محصولات:

CREATE TABLE products (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name VARCHAR(250) NOT NULL,
    sku VARCHAR(100) NOT NULL UNIQUE,
    price NUMERIC(14, 2) NOT NULL,
    category_id BIGINT,
    is_active BOOLEAN NOT NULL DEFAULT TRUE,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

جدول سفارش‌ها:

CREATE TABLE orders (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    user_id BIGINT NOT NULL,
    status VARCHAR(30) NOT NULL,
    total_amount NUMERIC(14, 2) NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

جدول اقلام سفارش:

CREATE TABLE order_items (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    order_id BIGINT NOT NULL REFERENCES orders(id),
    product_id BIGINT NOT NULL REFERENCES products(id),
    quantity INTEGER NOT NULL CHECK (quantity > 0),
    unit_price NUMERIC(14, 2) NOT NULL
);

در این طراحی، اطلاعات سفارش از اقلام آن جدا شده‌اند. بنابراین، یک سفارش می‌تواند چندین محصول داشته باشد و هر قلم سفارش نیز قیمت ثبت‌شده خود را نگه دارد.

چرا قیمت محصول باید در اقلام سفارش ذخیره شود؟

فرض کنید قیمت یک محصول امروز ۵۰۰ هزار تومان است، اما مشتری هفته گذشته آن را با قیمت ۴۵۰ هزار تومان خریده است.

اگر مبلغ سفارش فقط از قیمت فعلی جدول محصولات محاسبه شود، تاریخچه مالی سفارش ممکن است نادرست شود. ذخیره unit_price در جدول order_items باعث می‌شود قیمت اعمال‌شده هنگام خرید حفظ شود.

این مثال نشان می‌دهد که طراحی دیتابیس فقط مسئله سرعت نیست؛ صحت داده‌ها و حفظ تاریخچه کسب‌وکار نیز اهمیت دارد.

۲. ایندکس‌گذاری بر اساس Queryهای واقعی

ایندکس یکی از ابزارهای اصلی بهینه‌سازی دیتابیس است، اما ایجاد تعداد زیادی ایندکس بدون شناخت الگوی درخواست‌ها می‌تواند هزینه ذخیره‌سازی و عملیات نوشتن را افزایش دهد.

فرض کنید کاربران معمولاً سفارش‌های خود را از جدیدترین به قدیمی‌ترین مشاهده می‌کنند.

Query موردنیاز می‌تواند چنین باشد:

SELECT id, status, total_amount, created_at
FROM orders
WHERE user_id = 125
ORDER BY created_at DESC, id DESC
LIMIT 20;

برای پشتیبانی از این الگوی دسترسی، می‌توان ایندکس زیر را بررسی کرد:

CREATE INDEX idx_orders_user_created_id
ON orders (user_id, created_at DESC, id DESC);

این ایندکس ابتدا سفارش‌های کاربر مشخص را هدف قرار می‌دهد و سپس ترتیب زمانی موردنیاز را در نظر می‌گیرد.

در ایندکس‌های چندستونی، ترتیب ستون‌ها مهم است. معمولاً ستون‌های مورد استفاده در شرط‌های برابری در ابتدای ایندکس قرار می‌گیرند و پس از آن، ستون‌های مورد استفاده در بازه‌ها یا مرتب‌سازی بررسی می‌شوند؛ با این حال، انتخاب نهایی باید بر اساس Queryهای واقعی انجام شود.

آیا هر ستون باید ایندکس داشته باشد؟

خیر. ایندکس‌گذاری باید هدفمند باشد.

ایندکس برای ستون‌هایی که در فیلترها، اتصال جدول‌ها یا مرتب‌سازی‌های پرتکرار استفاده می‌شوند، ممکن است مفید باشد؛ اما هر ایندکس اضافه، هزینه نگهداری دارد.

برای انتخاب درست، سه مورد را بررسی کنید:

۱. Queryهای پرتکرار سیستم کدام‌اند؟

۲. هر Query چه تعداد رکورد را می‌خواند؟

۳. ایجاد ایندکس چه تغییری در زمان اجرا و هزینه عملیات نوشتن ایجاد می‌کند؟

برای اطلاعات بیشتر، می‌توان به مستندات رسمی PostgreSQL درباره Performance Tips مراجعه کرد.

۳. بهینه‌سازی Queryها و تحلیل Execution Plan

حتی با طراحی مناسب Schema و ایندکس‌ها، Queryهای غیربهینه می‌توانند عملکرد سیستم را کاهش دهند.

برای نمونه، دستور زیر تمام ستون‌ها و محصولات را دریافت می‌کند:

SELECT *
FROM products;

اگر هدف نمایش فهرست محصولات باشد، بهتر است فقط ستون‌های لازم دریافت شوند و تعداد نتایج نیز محدود شود:

SELECT id, name, price
FROM products
WHERE is_active = TRUE
ORDER BY created_at DESC, id DESC
LIMIT 20;

این تغییر می‌تواند حجم داده‌های خوانده‌شده یا منتقل‌شده را کاهش دهد؛ اما میزان تأثیر آن به ساختار جدول، ایندکس‌ها و برنامه اجرای Query بستگی دارد.

استفاده از EXPLAIN ANALYZE

در PostgreSQL، ابزار EXPLAIN ANALYZE برای بررسی برنامه اجرای واقعی Query کاربرد دارد.

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, name, price
FROM products
WHERE is_active = TRUE
ORDER BY created_at DESC, id DESC
LIMIT 20;

در خروجی، می‌توان زمان اجرا، تعداد ردیف‌های واقعی، عملیات مرتب‌سازی و اطلاعات مربوط به بافرها را بررسی کرد.

برای مثال، مشاهده Seq Scan لزوماً به معنای وجود مشکل نیست. اگر جدول کوچک باشد یا Query بخش بزرگی از آن را بخواند، اسکن ترتیبی ممکن است از استفاده از ایندکس مناسب‌تر باشد.

همچنین باید میان زمان اجرای خود Query و زمان کامل پاسخ API تفاوت قائل شد؛ زمان شبکه، انتظار برای اتصال و پردازش سمت برنامه نیز در عملکرد نهایی نقش دارند.

۴. مدیریت Pagination در جدول‌های بزرگ

با افزایش تعداد محصولات یا سفارش‌ها، صفحه‌بندی ساده با OFFSET ممکن است برای صفحات عمیق پرهزینه شود.

برای مثال:

SELECT id, name, price
FROM products
ORDER BY id
LIMIT 20 OFFSET 500000;

در این حالت، دیتابیس ممکن است ناچار باشد رکوردهای زیادی را طی کند و کنار بگذارد تا به نتایج موردنیاز برسد.

یکی از راهکارها، استفاده از Cursor-based Pagination است.

SELECT id, name, price
FROM products
WHERE id > 500000
ORDER BY id
LIMIT 20;

این نمونه برای حرکت رو به جلو بر اساس شناسه مناسب است. در یک فروشگاه واقعی، اگر ترتیب نمایش بر اساس تاریخ یا قیمت باشد، نشانگر باید با همان ترتیب سازگار باشد و معمولاً به یک ستون دوم برای رفع ابهام نیاز دارد.

برای مثال، در مرتب‌سازی بر اساس تاریخ ایجاد و شناسه:

SELECT id, name, price, created_at
FROM products
WHERE (created_at, id) < ($1, $2)
ORDER BY created_at DESC, id DESC
LIMIT 20;

در این مثال، $1 و $2 پارامترهای Query هستند و باید با مقادیر آخرین رکورد صفحه قبلی جایگزین شوند.

برای این الگو، ایندکس متناسب با (created_at DESC, id DESC) را نیز باید بررسی کرد.

Cursor-based Pagination برای پیمایش ترتیبی مجموعه‌های بزرگ اغلب مناسب‌تر است، اما برای رفتن مستقیم به شماره صفحه دلخواه، همیشه جایگزین کامل OFFSET نیست.

۵. آیا باید جدول‌ها را Partition کنیم؟

Partitioning به معنای تقسیم یک جدول منطقی به چند بخش فیزیکی کوچک‌تر است. PostgreSQL از پارتیشن‌بندی مبتنی بر بازه، فهرست و هش پشتیبانی می‌کند.

این قابلیت می‌تواند برای جدول‌های بسیار بزرگ، به‌خصوص زمانی که Queryها فقط به بخشی از داده‌ها نیاز دارند، مفید باشد. با این حال، صرف داشتن میلیون‌ها رکورد به معنای ضرورت Partitioning نیست. https://www.postgresql.org/docs/current/ddl-partitioning.html

مثال: پارتیشن‌بندی جدول سفارش‌ها بر اساس تاریخ

در فروشگاهی که سفارش‌ها بر اساس بازه زمانی جست‌وجو و نگهداری می‌شوند، می‌توان پارتیشن‌بندی ماهانه را بررسی کرد.

CREATE TABLE order_events (
    id BIGINT GENERATED ALWAYS AS IDENTITY,
    order_id BIGINT NOT NULL,
    event_type VARCHAR(50) NOT NULL,
    created_at TIMESTAMPTZ NOT NULL
) PARTITION BY RANGE (created_at);

سپس یک پارتیشن برای ژانویه ۲۰۲۶ ایجاد می‌کنیم:

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

در این طراحی، رکوردها بر اساس مقدار created_at به پارتیشن مناسب هدایت می‌شوند.

اگر Queryها بازه زمانی مشخصی داشته باشند، PostgreSQL ممکن است پارتیشن‌های نامرتبط را حذف کند و فقط بخش‌های موردنیاز را بررسی کند؛ قابلیتی که Partition Pruning نام دارد.

چه زمانی Partitioning ارزشمند است؟

• جدول بسیار بزرگ شده و نگهداری آن دشوار است.

• Queryهای پرتکرار بر اساس ستون پارتیشن‌بندی فیلتر می‌شوند.

• حذف یا آرشیو داده‌های قدیمی باید کارآمد باشد.

• بار کاری و اندازه جدول، پیچیدگی اضافه را توجیه می‌کنند.

Partitioning می‌تواند هزینه نگهداری را کاهش دهد یا عملکرد بعضی Queryها را بهبود بخشد، اما جایگزین طراحی صحیح ایندکس‌ها و Queryها نیست. تعداد زیاد پارتیشن‌ها نیز می‌تواند هزینه برنامه‌ریزی Query و مصرف حافظه را افزایش دهد.

۶. مدیریت تراکنش‌ها و جلوگیری از رقابت بر سر موجودی

در فروشگاه اینترنتی، یکی از حساس‌ترین بخش‌ها ثبت سفارش و مدیریت موجودی است.

فرض کنید تنها یک واحد از محصول باقی مانده و دو کاربر تقریباً هم‌زمان سفارش ثبت می‌کنند. اگر موجودی بدون کنترل هم‌زمانی کاهش یابد، احتمال فروش بیش از موجودی وجود دارد.

یک راهکار، کاهش شرطی موجودی در یک دستور اتمیک است:

UPDATE inventory
SET quantity = quantity - 1
WHERE product_id = 1001
  AND quantity >= 1
RETURNING quantity;

اگر این دستور یک ردیف برگرداند، موجودی با موفقیت کاهش یافته است. اگر هیچ ردیفی برنگرداند، ممکن است محصول موجود نباشد یا شناسه آن معتبر نباشد؛ برنامه باید این حالت را به‌درستی مدیریت کند.

در یک فرایند واقعی ثبت سفارش، کاهش موجودی و ایجاد سفارش باید در یک تراکنش هماهنگ شوند تا در صورت شکست بخشی از عملیات، داده‌ها ناسازگار باقی نمانند.

BEGIN;

-- کاهش شرطی موجودی
-- بررسی نتیجه عملیات در برنامه
-- ثبت سفارش و اقلام آن

COMMIT;

این قطعه صرفاً الگوی کلی است؛ منطق برنامه باید در صورت ناموفق بودن کاهش موجودی، تراکنش را لغو کند. همچنین نباید تراکنش را هنگام انتظار برای سرویس‌های خارجی یا عملیات غیرضروری باز نگه داشت.

تراکنش‌های کوتاه‌تر معمولاً به کاهش زمان نگهداری قفل‌ها و بهبود هم‌زمانی کمک می‌کنند.

۷. Connection Pooling و مدیریت اتصال‌های هم‌زمان

افزایش تعداد کاربران الزاماً به معنای نیاز به همان تعداد اتصال فعال به دیتابیس نیست.

هر اتصال PostgreSQL منابعی مصرف می‌کند. اگر تعداد اتصال‌ها بیش از ظرفیت مؤثر سرور افزایش یابد، رقابت بر سر CPU، حافظه و سایر منابع می‌تواند بیشتر شود و زمان پاسخ‌گویی را افزایش دهد.

Connection Pooling با استفاده مجدد از اتصال‌های مدیریت‌شده، به کنترل این وضعیت کمک می‌کند. ابزارهایی مانند PgBouncer در معماری‌های مناسب برای این هدف استفاده می‌شوند.

در طراحی Pool باید موارد زیر در نظر گرفته شوند:

• ظرفیت منابع سرور دیتابیس

• تعداد نمونه‌های هم‌زمان برنامه

• مدت اجرای Queryها و تراکنش‌ها

• تعداد اتصال‌های موردنیاز برای وظایف پس‌زمینه

• نحوه مدیریت Timeout و صف درخواست‌ها

افزایش بی‌رویه ظرفیت Pool راه‌حل مناسبی نیست؛ زیرا تعداد اتصال‌های فعال بیشتر لزوماً به توان عملیاتی بالاتر منجر نمی‌شود.

۸. کش؛ کاهش فشار روی دیتابیس

در فروشگاه‌های اینترنتی، اطلاعاتی مانند دسته‌بندی‌ها، تنظیمات عمومی و برخی داده‌های پرتکرار ممکن است بارها درخواست شوند.

کش می‌تواند پاسخ این درخواست‌ها را برای مدت مشخصی نگه دارد و نیاز به اجرای Query تکراری را کاهش دهد.

برای مثال، در معماری مناسب می‌توان از Redis برای نگهداری بعضی داده‌های پرتکرار استفاده کرد.

با این حال، کش نیازمند سیاست روشن برای تازگی داده‌ها است. اگر قیمت یا موجودی محصول تغییر کند، اطلاعات قدیمی نباید برای مدت نامناسب به کاربران نمایش داده شوند.

به همین دلیل، باید مشخص شود:

• کدام داده‌ها قابلیت کش شدن دارند؟

• مدت اعتبار هر داده چقدر است؟

• تغییر داده چگونه کش را بی‌اعتبار می‌کند؟

• اگر کش در دسترس نباشد، سیستم چگونه رفتار می‌کند؟

کش می‌تواند فشار روی دیتابیس را کاهش دهد، اما نباید جایگزین رفع Queryهای پرهزینه شود.

۹. پایش مداوم و نگهداری دیتابیس

بهینه‌سازی دیتابیس یک کار یک‌باره نیست. با افزایش حجم داده‌ها، تغییر الگوی درخواست‌ها و رشد تعداد کاربران، رفتار Queryها نیز تغییر می‌کند.

در PostgreSQL، جمع‌آوری آمار مناسب برای انتخاب برنامه اجرای Query اهمیت دارد. دستور ANALYZE آمار جدول‌ها را به‌روزرسانی می‌کند و Query Planner از آن برای تخمین تعداد ردیف‌ها و انتخاب روش اجرای Query استفاده می‌کند. در پیکربندی پیش‌فرض، Autovacuum معمولاً به مدیریت خودکار این فرایند کمک می‌کند. https://www.postgresql.org/docs/current/sql-analyze.html

برای نگهداری بهتر سیستم، موارد زیر را پایش کنید:

• Queryهای کند و پرتکرار

• زمان پاسخ در صدک‌های بالاتر، مانند p95

• مصرف CPU، حافظه و Disk I/O

• تعداد اتصال‌ها و زمان انتظار برای اتصال

• قفل‌ها و تراکنش‌های طولانی

• رشد حجم جدول‌ها و ایندکس‌ها

• وضعیت Autovacuum و آمار جدول‌ها

• خطاهای ثبت سفارش و عملیات حساس

علاوه بر این، نسخه پشتیبان باید به‌صورت دوره‌ای تهیه و فرایند بازیابی آن آزمایش شود. داشتن Backup بدون اطمینان از امکان Restore، برای حفظ پایداری کسب‌وکار کافی نیست.

۱۰. چه زمانی باید به Replication یا Sharding فکر کنیم؟

وقتی یک دیتابیس به محدودیت‌های منابع یا نیازهای دسترس‌پذیری می‌رسد، ممکن است راهکارهای معماری پیشرفته‌تری لازم باشند.

Replication به نگهداری نسخه‌های همگام یا نزدیک به همگام داده‌ها در سرورهای دیگر کمک می‌کند. برای مثال، در معماری مناسب می‌توان بخشی از بار خواندن را به Replicaها منتقل کرد؛ اما تأخیر همگام‌سازی باید در نظر گرفته شود و خواندن از Replica همیشه آخرین تغییر را تضمین نمی‌کند.

Sharding داده‌ها را میان چند بخش یا سرور مستقل تقسیم می‌کند. این رویکرد می‌تواند ظرفیت ذخیره‌سازی و پردازش را افزایش دهد، اما پیچیدگی قابل توجهی در توزیع داده‌ها، تراکنش‌ها، یکتایی شناسه‌ها و اجرای Queryهای بین‌بخشی ایجاد می‌کند.

بنابراین، پیش از انتخاب این معماری‌ها باید مطمئن شد که طراحی Schema، ایندکس‌ها، Queryها، مدیریت اتصال‌ها و منابع سرور به‌درستی بررسی شده‌اند.

۱۱. نقشه راه آماده‌سازی دیتابیس برای رشد

برای آماده‌سازی یک فروشگاه اینترنتی، می‌توان اقدامات را به ترتیب زیر انجام داد:

مرحله اول: طراحی صحیح

• تعریف روابط و محدودیت‌های داده

• انتخاب نوع داده مناسب

• حفظ صحت مالی و موجودی

• طراحی Queryهای اصلی کسب‌وکار

مرحله دوم: بهینه‌سازی عملکرد

• شناسایی Queryهای پرهزینه

• طراحی ایندکس‌های هدفمند

• استفاده از صفحه‌بندی مناسب

• حذف الگوهای N+1 Query

مرحله سوم: آماده‌سازی برای بار بیشتر

• مدیریت اتصال‌ها با Pooling

• کنترل زمان اجرای تراکنش‌ها

• استفاده آگاهانه از کش

• اجرای آزمون بار با داده‌های واقع‌گرایانه

مرحله چهارم: مدیریت داده‌های بزرگ

• بررسی نیاز به Partitioning

• برنامه‌ریزی برای آرشیو داده‌ها

• پایش رشد جدول‌ها و ایندکس‌ها

• آزمایش Backup و Restore

مرحله پنجم: توسعه معماری

• ارزیابی نیاز به Read Replica

• بررسی محدودیت‌های منابع

• در نظر گرفتن Sharding فقط در صورت وجود نیاز واقعی

• تعریف شاخص‌های عملکرد و دسترس‌پذیری

نتیجه‌گیری

آماده‌سازی دیتابیس برای میلیون‌ها رکورد، از انتخاب ابزارهای پیچیده یا تقسیم زودهنگام داده‌ها آغاز نمی‌شود؛ بلکه از طراحی صحیح Schema، شناخت الگوی دسترسی و اندازه‌گیری عملکرد شروع می‌شود.

در PostgreSQL، ایندکس‌گذاری هدفمند، تحلیل Execution Plan، صفحه‌بندی مناسب، تراکنش‌های کوتاه، مدیریت اتصال‌ها و نگهداری منظم می‌توانند پایه محکمی برای رشد یک فروشگاه اینترنتی فراهم کنند.

Partitioning، Replication و Sharding نیز ابزارهای ارزشمندی هستند، اما باید زمانی استفاده شوند که نیاز واقعی سیستم و اندازه‌گیری‌ها، مزایای آن‌ها را توجیه کنند.

اصل نهایی: دیتابیس مقیاس‌پذیر دیتابیسی نیست که صرفاً میلیون‌ها رکورد را ذخیره کند؛ دیتابیسی است که با حفظ صحت داده‌ها، عملکرد قابل پیش‌بینی و هزینه عملیاتی قابل مدیریت، بتواند بار واقعی کسب‌وکار را پاسخ دهد.

پرسش‌های متداول

آیا PostgreSQL می‌تواند میلیون‌ها رکورد را مدیریت کند؟

بله. PostgreSQL برای مدیریت مجموعه‌های بزرگ داده مناسب است؛ اما عملکرد واقعی به طراحی Schema، ایندکس‌ها، Queryها، منابع سخت‌افزاری و الگوی بار کاری بستگی دارد.

آیا با رسیدن جدول به یک میلیون رکورد باید Partitioning انجام دهیم؟

خیر. تعداد رکورد به‌تنهایی معیار کافی نیست. باید اندازه واقعی جدول و ایندکس‌ها، الگوی Queryها، نیازهای نگهداری و نتایج آزمون عملکرد بررسی شوند.

آیا ایندکس‌گذاری می‌تواند جایگزین افزایش منابع سرور شود؟

در برخی شرایط، ایندکس مناسب می‌تواند هزینه اجرای Query را به‌طور قابل توجهی کاهش دهد؛ اما مشکلات ناشی از کمبود منابع، قفل‌ها یا بار کاری نامناسب ممکن است به راهکارهای دیگری نیاز داشته باشند.

برای شروع مقیاس‌پذیری دیتابیس چه اقدامی مهم‌تر است؟

اندازه‌گیری عملکرد، شناسایی Queryهای پرهزینه و طراحی ایندکس‌های متناسب با الگوی دسترسی، معمولاً نقطه شروع مناسبی هستند.