دریافت کمک

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

نحوه اجرای متابیس در مقیاس

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

متابیس نرم‌افزار scalable، battle-hardened است که توسط ده‌ها هزار شرکت برای تحویل تحلیل‌های self-service با کیفیت بالا استفاده می‌شود. از در دسترس بودن بالا از طریق scale کردن افقی پشتیبانی می‌کند، و از جعبه کارآمد است: یک ماشین single-core با 4 گیگابایت RAM می‌تواند متابیس را به صدها کاربر scale کند.

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

عوامل تأثیرگذار بر عملکرد و در دسترس بودن متابیس

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

تعداد پایگاه‌های داده متصل به متابیس.
تعداد جداول در هر پایگاه داده.
کارایی data warehouse شما.
تعداد سؤال‌ها در داشبوردهای شما.

به عنوان مثال، مهم نیست چند instance متابیس اجرا می‌کنید اگر یک سؤال نیاز به اجرای یک پرس‌وجو دارد که پایگاه داده(های) شما 30 دقیقه طول می‌کشد تا کامل شود: این فقط 30 دقیقه طول می‌کشد. راه‌حل این است که نیاز خود به آن داده را دوباره ارزیابی کنید (آیا واقعاً هر بار به همه آن اطلاعات نیاز دارید؟) یا راه‌هایی برای بهبود عملکرد پایگاه داده خود پیدا کنید، مثل reorganize کردن، index کردن، یا cache کردن داده شما.

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

اکنون بیایید مطمئن شویم برنامه متابیس شما به خوبی tune شده است تا scale کند.

Scale کردن عمودی

Scale کردن عمودی رویکرد brute force است. به متابیس هسته‌ها و حافظه بیشتری بدهید، و منابع بیشتری برای انجام کار خود در دسترس خواهد داشت. اگر مشکلات عملکرد مرتبط با خود برنامه را تجربه می‌کنید (یعنی، نامرتبط با breadth و magnitude پایگاه‌های داده شما)، اجرای متابیس روی یک ماشین قدرتمندتر می‌تواند عملکرد را بهبود بخشد.

برای هر 20 کاربر همزمان، تقریباً به 1 هسته CPU و 1GB RAM نیاز است

متابیس از جعبه از قبل کارآمد است. برای شروع، یک ماشین single-core با 2 گیگابایت RAM باید برای کاربران solo یا تیم‌های کوچک بیش از حد کافی باشد.

چه زمانی حافظه و هسته بیشتری اضافه کنیم: اگر می‌بینید سرور شما به طور مداوم بیش از 80% منابع فعلی خود (حافظه یا compute) را استفاده می‌کند.

پایگاه داده برنامه متابیس باید در کمتر از یک ثانیه برای هر عملیاتی پاسخ دهد (شمارش زمان پاسخ برای data warehouse که متابیس شما به آن متصل است).

ماشین‌های با 4-8 گیگابایت باید صدها کاربر را handle کنند، و می‌توانید تعداد هسته‌ها و گیگابایت حافظه را در صورت نیاز bump کنید.

در حالی که افزودن هسته‌ها و حافظه بیشتر می‌تواند مؤثر باشد، به طور کلی بهتر است از scale کردن افقی برای پشتیبانی از کاربران بیشتر استفاده کنید. دلیل این است که محدودیت‌های اتصال پایگاه داده در هر instance متابیس ساخته شده است تا از overwhelming کردن data warehouse شما با درخواست‌ها توسط instance جلوگیری کند. می‌توانید تعداد اتصال‌ها را افزایش دهید در دسترس برای instance خود، اما هنوز چندین instance را توصیه می‌کنیم.

Scale کردن افقی (ترجیح داده شده)

به جای افزایش اندازه سرور در حال اجرای متابیس، scale کردن افقی شامل راه‌اندازی سرورهای بیشتر، هر کدام در حال اجرای متابیس، که به همان پایگاه داده برنامه متصل می‌کنید است. به این ترتیب می‌توانید چندین instance متابیس را در ترکیب با یک load balancer برای هدایت ترافیک به instanceها اجرا کنید. متابیس برای scale کردن افقی از جعبه تنظیم شده است، پس نیازی به پیکربندی خاص برای اجرای چندین instance متابیس ندارید. وقتی یک سرور متابیس به یک پایگاه داده برنامه موجود متصل می‌شود، خود را به عنوان بخشی از یک cluster تشخیص می‌دهد.

مورد استفاده اصلی برای scale کردن افقی بهبود قابلیت اطمینان (a.k.a. "در دسترس بودن بالا") است، اما scale کردن افقی همچنین می‌تواند عملکرد multi-user را بهبود بخشد. وقتی load متعادل است، یک instance متابیس high-traffic، CPU-bound عملکرد بهتری (سریع‌تر) خواهد داشت وقتی بخشی از ترافیک آن به instanceهای دیگر هدایت می‌شود، چون CPU load در چندین ماشین توزیع می‌شود.

متابیس با یک پایگاه داده محلی H2 برای ذخیره داده برنامه شما (همه سؤال‌ها، داشبوردها، logها، و سایر داده‌های متابیس) ship می‌شود، اما وقتی در production اجرا می‌کنید باید به یک پایگاه داده رابطه‌ای مثل PostgreSQL در حال اجرا روی یک سرور جداگانه upgrade کنید. در واقع، وقتی به صورت افقی scale می‌کنید، باید از یک پایگاه داده رابطه‌ای که روی یک سرور جداگانه اجرا می‌شود برای ذخیره داده برنامه خود استفاده کنید. به این ترتیب، همه instanceهای متابیس می‌توانند یک پایگاه داده مشترک را share کنند. ما یک پایگاه داده خارجی روی یک سرور جداگانه برای همه instanceهای production توصیه می‌کنیم، حتی اگر فقط یک instance متابیس اجرا می‌کنید، پس یک پایگاه داده خارجی هزینه اضافی برای scale کردن افقی نیست.

متابیس از پایگاه داده برنامه خارجی برای ذخیره داده session کاربر استفاده می‌کند، پس مشتریان نگران از دست دادن کار ذخیره شده نیستند اگر یک یا همه instanceهای متابیس down شوند، و مدیران مجبور نیستند با پیکربندی sticky sessionها برای اطمینان از اتصال مشتریان به instance متابیس درست deal کنند. load balancer مشتریان را به یک instance در دسترس route می‌کند تا بتوانند به کار خود ادامه دهند.

استفاده از scale کردن افقی مبتنی بر زمان

برخی مشتریان تعداد instanceهای متابیس را بر اساس زمان روز تنظیم می‌کنند. به عنوان مثال، برخی شرکت‌ها چندین instance متابیس را صبح راه‌اندازی می‌کنند تا burst ترافیک را وقتی مشتریان وارد می‌شوند و داشبوردهای صبحگاهی خود را اجرا می‌کنند handle کنند، سپس آن instanceها را بعدازظهر (یا شب، یا آخر هفته) spin down می‌کنند تا در هزینه کلود صرفه‌جویی کنند.

برای محیط‌هایی مثل Kubernetes یا Google Cloud Platform، نیاز دارید به مستندات مربوط به هر سیستم برای تنظیم قوانین autoscaling مشابه مراجعه کنید.

Load balancing ساده

Load balancerها ترافیک را به چندین instance متابیس هدایت می‌کنند تا اطمینان حاصل کنند هر درخواست سریع‌ترین پاسخ را دریافت می‌کند. اگر یک instance متابیس به طور موقت down شود، load balancer درخواست‌ها را به instance در دسترس دیگری route می‌کند.

تنظیم یک load balancer با متابیس ساده است. API متابیس یک endpoint health check، /api/health را expose می‌کند که load balancerها می‌توانند برای تعیین اینکه آیا یک instance متابیس up است و به درخواست‌ها پاسخ می‌دهد فراخوانی کنند. اگر instance سالم باشد، endpoint یک کد وضعیت HTTP 200 OK برمی‌گرداند. در غیر این صورت، load balancer می‌داند درخواست را به instance دیگری route کند.

tune کردن data warehouse

معماری یک data warehouse خارج از محدوده این مقاله است، اما باید بدانید پرس‌وجوهای شما در متابیس فقط به اندازه سرعت برگرداندن داده توسط پایگاه‌های داده شما سریع خواهند بود. اگر سؤال‌هایی دارید که مقدار زیادی داده می‌پرسند که پایگاه داده شما زمان زیادی برای retrieve کردن آن می‌برد، آن زمان‌های پرس‌وجو بر تجربه شما تأثیر می‌گذارند، صرف نظر از اینکه متابیس چقدر سریع است.

در اینجا برخی راه‌هایی که می‌توانید عملکرد data warehouse را بهبود بخشید:

داده خود را به روشی که سؤال‌هایی که مشتریان می‌پرسند را پیش‌بینی می‌کند ساختار دهید. الگوهای استفاده خود را شناسایی کنید و داده خود را به روشی ذخیره کنید که بازگشت نتایج برای سؤال‌های رایج در سازمان شما را آسان می‌کند. ETLها را compose کنید تا جداول جدیدی ایجاد کنید که داده مکرراً پرس‌وجو شده از چندین منبع را با هم می‌آورند.
پایگاه‌های داده خود را tune کنید. مستندات پایگاه‌های داده خود را بخوانید تا یاد بگیرید چگونه عملکرد آن‌ها را از طریق index کردن، cache کردن، و سایر بهینه‌سازی‌ها بهبود بخشید.
داده خود را فیلتر کنید. مشتریان را تشویق کنید داده را هنگام پرسیدن سؤال فیلتر کنند. آن‌ها همچنین باید از ابزارهای کاوش داده متابیس (از جمله previewهای رکورد) استفاده کنند تا فقط داده مرتبط با سؤالی که سعی در پاسخ دادن به آن دارند را پرس‌وجو کنند.
تصمیم بگیرید از یک پایگاه داده یا یک data warehouse استفاده کنید. مشتریان اغلب با استفاده از یک پایگاه داده تراکنشی مثل MySQL یا PostgreSQL شروع می‌کنند. در حالی که این پایگاه‌های داده به خوبی scale می‌شوند، اغلب برای نوع پرس‌وجوهای تحلیلی که متابیس استفاده می‌کند بهینه نشده‌اند. عملیات‌هایی مثل sum یا max می‌توانند کند شوند وقتی به یک مقیاس خاص می‌رسید. همانطور که adoption تحلیل رشد می‌کند، ممکن است نیاز به کاوش data warehouseهای اختصاصی مثل Amazon Redshift، Google BigQuery، یا Snowflake را پیدا کنید.

بهترین روش‌های برنامه متابیس

در اینجا برخی استراتژی‌ها برای بهره‌برداری حداکثری از برنامه متابیس:

فقط داده مورد نیاز خود را درخواست کنید.
از یک پایگاه داده رابطه‌ای مدیریت شده برای ذخیره داده برنامه متابیس خود استفاده کنید.
پرس‌وجوهای خود را cache کنید.
به دنبال bottlenecks بگردید.
حداکثر تعداد اتصال‌ها به پایگاه داده برنامه را افزایش دهید.
حداکثر تعداد اتصال به هر پایگاه داده را افزایش دهید.
با پایگاه‌های داده خود فقط وقتی نیاز دارید sync کنید.
به آخرین نسخه متابیس upgrade کنید.
مرورگر خود را به‌روز نگه دارید.

فقط داده مورد نیاز خود را درخواست کنید

اگر مشتریان پرس‌وجوهای زیادی اجرا می‌کنند که رکوردهای زیادی برمی‌گردانند، مهم نیست متابیس سریع است: کاربران داده خود را فقط به اندازه سرعت برگرداندن رکوردهای درخواست شده توسط data warehouse شما دریافت می‌کنند. و گاهی مشتریان با داشبوردها زیاده‌روی می‌کنند: وقتی یک داشبورد با (مثلاً) 50 سؤال load می‌شود، 50 درخواست همزمان برای داده ارسال می‌کند. بسته به اندازه آن پایگاه داده، می‌تواند زمان زیادی طول بکشد تا آن رکوردها برگردند.

اما این همه داستان نیست. متابیس به سادگی کند نمی‌شود چون سؤال‌های بیشتری در داشبورد خود قرار می‌دهید. اگر سؤال‌های شما مقدار زیادی داده pull نمی‌کنند، یا data warehouse شما می‌تواند نتایج را در کمتر از یک ثانیه برگرداند، 50 سؤال به سرعت load می‌شوند.

به طور کلی، با این حال، مشتریان را تشویق کنید داشبوردهای خود را متمرکز نگه دارند. داشبوردها برای گفتن یک داستان درباره داده شما هستند، و می‌توانید یک داستان خوب با فقط چند سؤال (یا حتی یک سؤال واحد) بگویید. از ابزارهای کاوش داده متابیس برای یادگیری درباره داده خود (مثل توانایی preview کردن رکوردها در جداول) استفاده کنید تا بتوانید فقط روی رکوردهایی که برای پاسخ دادن به سؤال‌های خود نیاز دارید dial in کنید.

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

استفاده از یک پایگاه داده رابطه‌ای مدیریت شده برای ذخیره داده برنامه متابیس خود

پایگاه داده برنامه همه سؤال‌ها، داشبوردها، مجموعه‌ها، مجوزها، و سایر داده‌های مرتبط با برنامه متابیس را ذخیره می‌کند. می‌توانید از یک پایگاه داده رابطه‌ای (مثل PostgreSQL یا MySQL) برای مدیریت پایگاه داده برنامه خود استفاده کنید، اما یک راه‌حل مدیریت شده مثل AWS RDS را توصیه می‌کنیم. RDS backupها را خودکار می‌کند و تنظیم storage و compute را همانطور که scale می‌کنید آسان می‌کند، یک چیز کمتر برای نگرانی به شما می‌دهد.

Cache کردن پرس‌وجوهای خود

می‌توانید caching را پیکربندی کنید تا نتایج سؤال‌های اخیراً پرسیده شده را ذخیره کنید تا نیازی به محاسبه مجدد نداشته باشند. متابیس timestamp برای نتایج را به مشتریان نشان می‌دهد، و آن‌ها می‌توانند نتایج سؤال را به صورت دستی refresh کنند اگر می‌خواهند پرس‌وجو را دوباره اجرا کنند. Cache کردن برای نتایجی که به طور مکرر به‌روزرسانی نمی‌شوند مناسب است.

جستجوی bottlenecks

طرح‌های Pro و Enterprise Usage Analytics را برای نظارت بر استفاده و عملکرد برنامه شما ارائه می‌دهند. می‌توانید، به عنوان مثال، ببینید چند سؤال پرسیده می‌شود، توسط چه کسی، و چقدر طول کشید سؤال‌ها اجرا شوند، که می‌تواند به شناسایی bottlenecks که نیاز به توجه دارند کمک کند.

افزایش حداکثر تعداد اتصال‌ها به پایگاه داده برنامه

تعداد پیش‌فرض اتصال‌ها به پایگاه داده برنامه متابیس توسط متغیر محیطی MB_APPLICATION_DB_MAX_CONNECTION_POOL_SIZE مشخص شده است، که در حال حاضر به طور پیش‌فرض روی 15 تنظیم شده است. اگر استفاده شما به طور منظم همه آن اتصال‌ها را مصرف می‌کند، می‌توانید عملکرد را با افزایش حداکثر تعداد اتصال‌ها بهبود بخشید. به طور جایگزین، می‌توانید تعداد اتصال‌ها را از طریق scale کردن افقی افزایش دهید (مثلاً، اگر یک instance متابیس اضافی اضافه کنید، به طور مؤثر 15 اتصال اضافی به پایگاه داده برنامه اضافه می‌کنید).

می‌توانید تعداد اتصال‌ها را با مشاهده logها، و بررسی خطوطی مثل ... App DB connections: 12/15 بررسی کنید. در آن مثال، متابیس از 12 از 15 اتصال پایگاه داده برنامه در دسترس استفاده می‌کند.

افزایش حداکثر تعداد اتصال‌ها به هر پایگاه داده

به طور مشابه، حداکثر تعداد پیش‌فرض اتصال‌ها برای یک instance متابیس واحد به هر پایگاه داده 15 است. این 15 برای هر پایگاه داده است، پس اگر متابیس را به دو پایگاه داده متصل کرده‌اید، حداکثر 30 اتصال خواهید داشت.

می‌توانید حداکثر تعداد اتصال‌ها به هر پایگاه داده را با تغییر متغیر محیطی MB_JDBC_DATA_WAREHOUSE_MAX_CONNECTION_POOL_SIZE افزایش دهید. همانطور که در بالا با اتصال‌های پایگاه داده برنامه، همچنین می‌توانید تعداد اتصال‌ها را از طریق scale کردن افقی افزایش دهید. هر instance متابیس اضافی حداکثر تعداد اتصال‌ها را 15 (یا هر حداکثری که تنظیم کرده‌اید) افزایش می‌دهد. برای یادگیری بیشتر، مستندات ما درباره متغیرهای محیطی را ببینید.

Sync با پایگاه‌های داده خود فقط وقتی نیاز دارید

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

می‌توانید زمان‌بندی و فرکانس این همگام‌سازی‌ها را تنظیم کنید. برای پایگاه‌های داده بزرگ، ممکن است محدود کردن تعداد دفعاتی که متابیس sync را انجام می‌دهد، و محدود کردن آن همگام‌سازی‌ها به ساعات off-peak را در نظر بگیرید، به خصوص اگر به طور مکرر جداول جدید به پایگاه داده خود اضافه نمی‌کنید.

ارتقا به آخرین نسخه متابیس

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

سرو کردن متابیس از طریق HTTPS روی HTTP/2

سرو کردن instance متابیس از طریق HTTPS روی HTTP/2 می‌تواند عملکرد را افزایش دهد، چون مرورگرها روی HTTP/1.1 می‌توانند اتصال‌ها را به تقریباً 6 اتصال همزمان در هر دامنه محدود کنند، در حالی که HTTP/2 روی یک اتصال واحد multiplex می‌شود. اتصال‌های بیشتر در دسترس یک پایگاه داده کند، یا یک instance متابیس overload شده که threadها تمام شده است را fix نمی‌کند، اما حداقل می‌دانید مرورگر شما اتصال‌های شما را throttle نمی‌کند.

مرورگر خود را به‌روز نگه دارید

متابیس یک برنامه وب است، و می‌تواند از آخرین و بهترین نسخه‌های مرورگرهایی مثل Firefox، Chrome، Edge، و Safari بهره ببرد.

deploymentهای پشتیبانی شده

راه‌های زیادی برای تنظیم متابیس وجود دارد؛ برخی از مورد علاقه‌های ما شامل:

AWS Elastic Beanstalk: راهنمای ما برای تنظیم متابیس روی Elastic Beanstalk را بررسی کنید. ما از Elastic Beanstalk برای میزبانی برنامه متابیس داخلی خود استفاده می‌کنیم.
Docker: اجرای متابیس روی Docker را ببینید.

Google Cloud Platform، Microsoft Azure، Digital Ocean، و سایر ارائه‌دهندگان کلود جایگزین‌های عالی دیگری برای میزبانی برنامه متابیس شما ارائه می‌دهند.

متابیس میزبانی شده

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