بازطراحی اسکیمای SQL Server روی پایگاه داده‌ی زنده

اسکیمای زیر پلتفرم وفاداری باید تغییر می‌کرد: بازطراحی‌های بزرگ و ساختاری روی جدول‌هایی با ۸۰۰ میلیون رکورد فاکتور، در پایگاه داده‌ای که نمی‌شد به اندازه‌ی زمانی که راه‌حل بدیهی لازم داشت آفلاین کرد.

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

بخش عمده‌ی کار نوشتن DDL نبود؛ پیدا کردن راهی برای اعمال کردن آن بود.

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

آنچه این کار در عمل شامل شد:

• خواندن اینکه پایگاه داده حین مهاجرت واقعاً چه می‌کند، از دل system tableها، نه حدس زدن از بیرون.
• شکستن تغییرات به گام‌هایی که هر کدام قفلشان را کوتاه نگه می‌دارند، به‌جای یک دستور که یک قفل را طولانی نگه می‌دارد.
• جدا کردن backfill از switchover، تا بخش طولانی کار هیچ‌وقت سر راه یک درخواست کاربر نباشد.
• پذیرفتن مهاجرت کندتر در ازای پنجره‌ی blocking کوتاه‌تر — همان معامله‌ای که تقریباً هر نسخه‌ای از این مسئله به آن ختم می‌شود.

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