بینش ها

تنظیم پایگاه داده پیش از rewrite: اول چه چیزی را اصلاح کنیم

وقتی پایگاه داده به گلوگاه آشکار تبدیل می شود، تیم ها اغلب مستقیم سراغ مهاجرت یا rewrite می روند. گاهی این درست است، اما اغلب نیاز اول تنظیم پایگاه داده و بازبینی ساختار آن است. پرسش اول این است که کارایی دقیقا کجا از دست می رود و چه چیزی را می توان با امنیت بهتر کرد.

بهترین تناسب

  • اپلیکیشن هایی که queryهای کند روی رفتار واقعی کاربران اثر گذاشته اند
  • تیم هایی که تحت فشارند کارایی را بهتر کنند بدون اینکه تحویل ناپایدار شود
  • سامانه هایی که مدل داده در آن ها با هر انتشار آشفته تر شده است

از مسیر query شروع کنید

با پیدا کردن جایی شروع کنید که واقعا زمان در آن مصرف می شود. مسیرهای query سنگین، indexها، الگوهای join، بار گزارش گیری، و جاهایی را بررسی کنید که کد برنامه دارد ضعف دسترسی به داده را جبران می کند.

  • کندترین و پرهزینه ترین مسیرهای query تکرارشونده را شناسایی کنید
  • ناکارآمدی برنامه را از گلوگاه های واقعی پایگاه داده جدا کنید
  • indexing، فرضیات cardinality، و ناهماهنگی های آشکار ساختاری را بازبینی کنید

مسائل ساختاری ای را پیدا کنید که تنظیم نمی تواند پنهان کند

بعضی مشکلات کارایی در اصل مشکلات schema هستند. جدول های بیش از حد سنگین، کلیدهای ناهماهنگ، shortcutهای تاریخی، و مالکیت مبهم داده اصطکاکی ایجاد می کنند که فقط با دستکاری query حل نمی شود.

  • جدول ها یا رابطه هایی را پیدا کنید که بیش از حد بار روی دوش خود دارند
  • انتخاب های schema را که گزارش گیری یا مسیرهای یکپارچه سازی را پیچیده می کنند شناسایی کنید
  • تنظیم تاکتیکی را از نیازهای بازطراحی ساختاری جدا کنید

چرا شروع با تنظیم اغلب امن تر است

یک گذر measured و مبتنی بر تنظیم، کارایی فعلی را بهتر می کند، روشن می کند کدام بدهی schema مهم است، و برای هر مهاجرت یا بازطراحی بعدی پایه تمیزتری فراهم می آورد.

  • دستاوردهای فوری بدون وانمود به اینکه کل سامانه باید جایگزین شود
  • شواهد بهتر برای هر تصمیم بعدی درباره بازطراحی یا مهاجرت
  • اختلال کمتر در تحویل در حالی که مسائل اصلی روشن می شوند

گام بعدی

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

یک یادداشت کوتاه درباره سامانه، ریسک تحویل، یا مسئله عملیاتی برای شروع بحث کافی است.