چگونه OpenAI پایگاه داده PostgreSQL را برای ۸۰۰ میلیون کاربر مقیاس‌پذیر کرده است

OpenAI در یک پست وبلاگی که روز پنج‌شنبه منتشر شد، جزئیات استفاده خود از پایگاه داده متن‌باز PostgreSQL را تشریح کرد.

OpenAI، که ChatGPT و پلتفرم API خود را برای حدود ۸۰۰ میلیون کاربر اجرا می‌کند، این بار کاری عظیم را روی یک نمونه PostgreSQL با یک Primary واحد اجرا می‌کند؛ نه یک پایگاه داده توزیع‌شده و نه یک کلاستر شارد (تکه تکه) شده. تمام عملیات نوشتن توسط یک Azure PostgreSQL Flexible Server انجام می‌شود و نزدیک به ۵۰ Replica خواندنی (Read Replica) در چندین منطقه جغرافیایی، بار خواندن را مدیریت می‌کنند. این سامانه میلیون‌ها کوئری در ثانیه را با تأخیر p99 در حد چند ده میلی‌ثانیه و سطح دسترس‌پذیری پنج نُه (99.999%) پردازش می‌کند.

این معماری با بسیاری از باورهای رایج درباره مقیاس‌پذیری در تضاد است و به معماران سازمانی نشان می‌دهد که در عمل، چه رویکردهایی در مقیاس بسیار بزرگ واقعاً جواب می‌دهند.

درس اصلی این معماری، کپی‌کردن دقیق پشته OpenAI نیست؛ بلکه این است که تصمیم‌های معماری باید بر اساس الگوی بار کاری (Workload Pattern) و محدودیت‌های عملیاتی گرفته شوند، نه بر پایه وحشت از مقیاس یا انتخاب‌های مد روز زیرساختی. تجربه PostgreSQL در OpenAI نشان می‌دهد که سیستم‌های اثبات‌شده، در صورت بهینه‌سازی آگاهانه، تا چه حد می‌توانند ادامه پیدا کنند؛ بدون آنکه نیاز به بازطراحی زودهنگام وجود داشته باشد.

بوهان ژانگ، مهندس OpenAI، در این افشای فنی نوشته است:
«برای سال‌ها، PostgreSQL یکی از حیاتی‌ترین سیستم‌های داده پنهان اما کلیدی بوده که محصولات اصلی مانند ChatGPT و APIهای OpenAI را تغذیه می‌کند. طی یک سال گذشته، بار کاری PostgreSQL ما بیش از ۱۰ برابر رشد کرده و همچنان با سرعت بالا در حال افزایش است.»

OpenAI این مقیاس را از طریق بهینه‌سازی‌های هدفمند به دست آورده است؛ از جمله استفاده از Connection Pooling که زمان برقراری اتصال را از ۵۰ میلی‌ثانیه به ۵ میلی‌ثانیه کاهش داده و همچنین قفل‌گذاری کش (Cache Locking) برای جلوگیری از مشکل «Thundering Herd»؛ وضعیتی که در آن، خطاهای هم‌زمان کش باعث هجوم درخواست‌ها به پایگاه داده و ایجاد بار بیش از حد می‌شوند.

چرا PostgreSQL برای سازمان‌ها اهمیت دارد

PostgreSQL داده‌های عملیاتی ChatGPT و پلتفرم API OpenAI را مدیریت می‌کند. این بار کاری به‌شدت خواندنی (Read-heavy) است و همین موضوع PostgreSQL را به گزینه‌ای مناسب تبدیل می‌کند. با این حال، سازوکار کنترل هم‌زمانی چندنسخه‌ای (MVCC) در PostgreSQL، تحت بارهای نوشتن سنگین چالش‌هایی ایجاد می‌کند.

در زمان به‌روزرسانی داده، PostgreSQL کل سطر را کپی می‌کند تا نسخه جدیدی بسازد. این موضوع باعث افزایش حجم نوشتن (Write Amplification) شده و کوئری‌ها را مجبور می‌کند چندین نسخه از داده را اسکن کنند تا به نسخه فعلی برسند.

OpenAI به‌جای مقابله مستقیم با این محدودیت، استراتژی خود را بر اساس آن طراحی کرده است. در مقیاس OpenAI، این ملاحظات صرفاً نظری نیستند؛ بلکه تعیین می‌کنند کدام بارهای کاری می‌توانند روی PostgreSQL باقی بمانند و کدام باید به سامانه‌های دیگر منتقل شوند.

OpenAI چگونه PostgreSQL را بهینه‌سازی می‌کند

در مقیاس‌های بزرگ، منطق متداول پایگاه داده معمولاً به یکی از دو مسیر اشاره می‌کند: شارد کردن PostgreSQL روی چندین Primary برای توزیع نوشتن‌ها، یا مهاجرت به یک پایگاه داده SQL توزیع‌شده مانند CockroachDB یا YugabyteDB که از ابتدا برای مقیاس عظیم طراحی شده‌اند. بسیاری از سازمان‌ها بسیار زودتر از رسیدن به ۸۰۰ میلیون کاربر، یکی از این مسیرها را انتخاب می‌کنند.

هر دو رویکرد، گلوگاه نویسنده واحد (Single-writer Bottleneck) را برطرف می‌کنند، اما بهای آن پیچیدگی بالاست: کد اپلیکیشن باید کوئری‌ها را به شارد درست هدایت کند، تراکنش‌های توزیع‌شده دشوارتر می‌شوند و سربار عملیاتی به‌شدت افزایش می‌یابد.

OpenAI به‌جای شارد کردن PostgreSQL، یک استراتژی ترکیبی اتخاذ کرده است:
هیچ جدول جدیدی به PostgreSQL اضافه نمی‌شود. بارهای کاری جدید به‌صورت پیش‌فرض به سامانه‌های شاردشده‌ای مانند Azure Cosmos DB می‌روند. بارهای نوشتنی سنگین موجود که امکان پارتیشن‌بندی افقی دارند، از PostgreSQL خارج می‌شوند و سایر بارها با بهینه‌سازی‌های تهاجمی روی PostgreSQL باقی می‌مانند.

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

چرا این موضوع مهم است؟

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

نخست، ایجاد لایه‌های دفاعی عملیاتی در سطوح مختلف. OpenAI از ترکیبی از قفل‌گذاری کش، Connection Pooling و Rate Limiting در سطح اپلیکیشن، پراکسی و کوئری استفاده می‌کند. ایزوله‌سازی بار کاری باعث می‌شود ترافیک کم‌اولویت و پراهمیت به نمونه‌های جداگانه هدایت شوند و یک قابلیت جدیدِ بهینه‌نشده، سرویس‌های حیاتی را مختل نکند.

دوم، بازبینی و پایش کوئری‌های تولیدشده توسط ORM در محیط عملیاتی. فریم‌ورک‌هایی مانند Django، SQLAlchemy و Hibernate کوئری‌ها را به‌صورت خودکار تولید می‌کنند. OpenAI گزارش داده که یک کوئری ORM با Join روی ۱۲ جدول، در زمان افزایش ترافیک، چندین حادثه بحرانی ایجاد کرده است. این ریسک‌های پنهان معمولاً فقط در بار واقعی تولید (Production) نمایان می‌شوند.

سوم، اعمال انضباط عملیاتی سخت‌گیرانه. OpenAI تنها تغییرات سبک در Schema را مجاز می‌داند؛ هر تغییری که باعث بازنویسی کامل جدول شود، ممنوع است. تغییرات Schema محدودیت زمانی ۵ ثانیه‌ای دارند، کوئری‌های طولانی به‌طور خودکار متوقف می‌شوند و عملیات Backfill با Rate Limitهایی انجام می‌شود که ممکن است بیش از یک هفته طول بکشد.

در نهایت، تجربه OpenAI نشان می‌دهد که بارهای کاری عمدتاً خواندنی با نوشتن‌های انفجاری (Burst Writes) می‌توانند بسیار طولانی‌تر از تصور رایج روی PostgreSQL با یک Primary واحد اجرا شوند. تصمیم برای شارد کردن باید بر اساس الگوی بار کاری باشد، نه صرفاً تعداد کاربران.

این الگو به‌ویژه برای اپلیکیشن‌های هوش مصنوعی اهمیت دارد؛ جایی که بار خواندن بالاست و جهش‌های ترافیکی غیرقابل‌پیش‌بینی هستند. ویژگی‌هایی که با توان مقیاس‌پذیری PostgreSQL در مدل Single-primary هم‌خوانی دارند.

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