چرا هر اپ Mythex پایگاه‌داده‌ی مخصوص خودش را دارد

وقتی اپی که روی Mythex می‌سازید به ذخیره‌ی داده نیاز دارد — ثبت‌نام، رزرو، سفارش — آن پروژه پایگاه‌داده‌ی Postgres مخصوص خودش را می‌گیرد. نه یک جدول در یک پایگاه‌داده‌ی مشترک، نه یک schema کنار schema دیگری: یک پایگاه‌داده‌ی جدا که به‌محض نیاز ساخته می‌شود و وقتی کسی از آن استفاده نمی‌کند می‌خوابد. دلیل ساختنش به این شکل را و آنچه هزینه دارد اینجا می‌گوییم.

چه چیزی به دست می‌آورید

وقتی داده می‌خواهید («ایمیل‌های لیست انتظار را ذخیره کن»، «رزروها را نگه دار») یا از دستور /database استفاده می‌کنید، Mythex:

• یک پایگاه‌داده‌ی Postgres اختصاصی برای پروژه می‌سازد (فعلاً Postgres 17)،
• جزئیات اتصال را به‌عنوان متغیرهای محیطی به فضای کاری و اپ منتشرشده‌ی شما تزریق می‌کند، تا هرگز در کدتان ظاهر نشوند، و
• به عامل اجازه می‌دهد جدول بسازد و داده را برای شما بخواند و بنویسد.

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

چرا یک پایگاه‌داده‌ی بزرگ مشترک نه؟

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

۱. جداسازی که مجبور نیستید به آن اعتماد کنید

کدی که هوش مصنوعی می‌نویسد اشتباه می‌کند. در یک پایگاه‌داده‌ی مشترک، یک WHERE app_id = … که در کوئری یک اپ جا افتاده باشد، داده‌ی مشتری دیگری را می‌خواند یا بازنویسی می‌کند. با یک پایگاه‌داده برای هر اپ، داده‌ی هیچ مشتری دیگری در دسترس نیست — یک باگ در همان اپ خودش می‌ماند.

۲. یک Postgres واقعی است، نه یک لایه‌ی اختصاصی

اپ شما با Postgres استاندارد و یک رشته‌ی اتصال معمولی حرف می‌زند. هر کتابخانه، ORM یا ابزاری که با Postgres کار می‌کند اینجا هم کار می‌کند. اگر پروژه‌تان را صادر کنید تا جای دیگری اجرا شود، انتظار دارد یک پایگاه‌داده‌ی Postgres داشته باشد — چیزی که هر میزبانی ارائه می‌دهد — نه یک API مخصوص Mythex.

۳. هر اپ می‌تواند به شکلی که نیاز دارد باشد

یک اپ یک جدول bookings با یک محدودیت یکتا روی بازه‌های زمانی می‌خواهد؛ اپ دیگری جستجوی تمام‌متن روی محصولات. با پایگاه‌داده‌ی مخصوص خودش، schema و مهاجرت‌های هر اپ مال خودش است. هیچ چیزی مجبور نیست با طراحی حداقل مشترک جور باشد.

۴. هزینه از استفاده تبعیت می‌کند

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

معامله‌ها

این طراحی رایگان نیست:

• راه‌اندازی سرد. یک پایگاه‌داده‌ی خوابیده بعد از یک دوره‌ی آرام، برای اولین کوئری کمی زمان می‌برد تا بیدار شود. برای بیشتر اپ‌ها این به‌سختی محسوس است؛ برای اپی که باید هر ساعتی فوری جواب دهد، یک ملاحظه است.
• هزینه‌ی بیدار بودن. یک پایگاه‌داده تا وقتی چیزی به آن کوئری می‌زند بیدار می‌ماند. اپی که هر چند ثانیه پایگاه‌داده‌اش را پرس‌وجو می‌کند، همیشه بیدار نگهش می‌دارد و بیشتر از اپی هزینه دارد که بر حسب تقاضا کوئری می‌زند. اگر مصرفتان بیشتر از انتظارتان است، معمولاً به همین خاطر است — از هوش مصنوعی بخواهید پرس‌وجوی مکرر را متوقف کند و داده را وقتی لازم است بار کند.
• اجزای متحرک بیشتر برای ما. ساختن، ردیابی و پاک‌سازی هزاران پایگاه‌داده بیشتر از یکی کار دارد. این بار ما هستیم، نه شما.

اگر تازه با پایگاه‌داده‌ها آشنا هستید

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