DELETE عزیز. نیکولای ساموخوالوف (Postgres.ai)

در آینده ای دور، حذف خودکار داده های غیر ضروری یکی از وظایف مهم DBMS خواهد بود [1]. در این بین، ما خودمان باید مراقب حذف یا انتقال داده های غیر ضروری به سیستم های ذخیره سازی ارزان قیمت باشیم. فرض کنید تصمیم دارید چند میلیون ردیف را حذف کنید. یک کار نسبتاً ساده، به خصوص اگر شرایط مشخص باشد و شاخص مناسبی وجود داشته باشد. "حذف از جدول 1 WHERE col1 = :value" - چه چیزی می تواند ساده تر باشد، درست است؟

ویدئو:

• من از سال اول یعنی از سال 2007 در کمیته برنامه هایلود بودم.

• و من از سال 2005 با Postgres بودم. از آن در بسیاری از پروژه ها استفاده کرد.

• همچنین از سال 2007 با RuPostges گروه کنید.

• ما در Meetup به بیش از 2100 شرکت‌کننده رسیده‌ایم. این کشور پس از نیویورک در رتبه دوم جهان قرار دارد و برای مدت طولانی توسط سانفرانسیسکو پیشی گرفته است.

• من چندین سال است که در کالیفرنیا زندگی می کنم. من بیشتر با شرکت های آمریکایی از جمله شرکت های بزرگ سروکار دارم. آنها کاربران فعال Postgres هستند. و انواع چیزهای جالب وجود دارد.

https://postgres.ai/ شرکت من است ما در کسب و کار اتوماسیون وظایفی هستیم که کندی توسعه را از بین می برند.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

من اخیراً در VLDB در لس آنجلس بودم. این بزرگترین کنفرانس در مورد پایگاه های داده است. و گزارشی وجود داشت که در آینده DBMS نه تنها داده ها را ذخیره می کند، بلکه به طور خودکار داده ها را حذف می کند. این یک موضوع جدید است.

در دنیای زتابایت ها داده های بیشتری وجود دارد - این رقم 1 پتابایت است. و اکنون تخمین زده می شود که بیش از 000 زتابایت داده در جهان ذخیره شده است. و تعداد آنها بیشتر و بیشتر می شود.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

و با آن چه باید کرد؟ بدیهی است که باید حذف شود. در اینجا لینک این گزارش جالب است. اما تاکنون این مورد در DBMS پیاده سازی نشده است.

آنهایی که می توانند پول بشمارند دو چیز می خواهند. آنها از ما می خواهند که حذف کنیم، بنابراین از نظر فنی باید بتوانیم این کار را انجام دهیم.

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

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

به طور کلی، وظیفه این است که حذف موارد خاص، خطوط خاص در برخی از جدول ها را به طور خودکار انجام دهیم.

و ما چنین درخواستی داریم که امروز در مورد آن صحبت خواهیم کرد، یعنی در مورد زباله برداری.

ما از یک توسعه دهنده با تجربه خواستیم که این کار را انجام دهد. او این درخواست را گرفت، آن را برای خودش بررسی کرد - همه چیز کار می کند. تست شده در مرحله - همه چیز خوب است. رول شد - همه چیز کار می کند. یک بار در روز آن را اجرا می کنیم - همه چیز خوب است.

پایگاه داده رشد می کند و رشد می کند. روزانه DELETE کمی کندتر شروع به کار می کند.

سپس متوجه می شویم که اکنون یک شرکت بازاریابی داریم و ترافیک چندین برابر بیشتر خواهد شد، بنابراین تصمیم می گیریم موارد غیر ضروری را موقتاً متوقف کنیم. و فراموش کن که برگردی

چند ماه بعد به یاد آوردند. و آن توسعه‌دهنده آن را ترک کرد یا با چیز دیگری مشغول است، به دیگری دستور داد آن را برگرداند.

او برنامه‌نویس، روی صحنه‌سازی را بررسی کرد - همه چیز درست است. به طور طبیعی، شما هنوز باید آنچه را که انباشته شده است تمیز کنید. او بررسی کرد که همه چیز کار می کند.

بعد چه اتفاقی می افتد؟ بعد همه چیز برای ما خراب می شود. افت می کند به طوری که در یک نقطه همه چیز سقوط می کند. همه در شوک هستند، هیچ کس نمی فهمد چه اتفاقی می افتد. و بعد معلوم می شود که موضوع در این DELETE بوده است.

مشکلی پیش آمده است؟ در اینجا لیستی از آنچه ممکن است اشتباه رخ داده باشد آورده شده است. کدام یک از اینها مهمترین است؟

• به عنوان مثال، هیچ بررسی وجود ندارد، یعنی کارشناس DBA به آن نگاه نکرده است. او بلافاصله با یک چشم باتجربه مشکل را پیدا می کرد و علاوه بر این، به پرود دسترسی دارد که چندین میلیون خط انباشته شده است.

• شاید آنها چیزی را اشتباه بررسی کرده اند.

• شاید سخت افزار قدیمی شده باشد و باید این پایه را ارتقا دهید.

• یا مشکلی در خود پایگاه داده وجود دارد و باید از Postgres به MySQL برویم.

• یا شاید مشکلی در عمل وجود داشته باشد.

• شاید اشتباهاتی در سازماندهی کار وجود داشته باشد و شما نیاز به اخراج شخصی و استخدام بهترین افراد داشته باشید؟

هیچ بررسی DBA وجود نداشت. اگر DBA بود این چند میلیون خط را می دید و حتی بدون هیچ آزمایشی می گفت: این کار را نمی کنند. فرض کنید اگر این کد در GitLab، GitHub بود و یک فرآیند بررسی کد وجود داشت و چنین چیزی وجود نداشت که بدون تأیید DBA این عملیات روی prod انجام شود، پس بدیهی است که DBA می‌گوید: «این کار انجام نمی‌شود. "

و او می گفت که شما با IO دیسک مشکل خواهید داشت و همه فرآیندها دیوانه می شوند، ممکن است قفل وجود داشته باشد و همچنین برای چند دقیقه اتو وکیوم را مسدود خواهید کرد، بنابراین این خوب نیست.

http://bit.ly/nancy-hl2018-2

اشتباه دوم - آنها در جای اشتباه بررسی کردند. بعد از این واقعیت دیدیم که داده‌های ناخواسته زیادی روی prod انباشته می‌شوند، اما توسعه‌دهنده داده‌های انباشته‌شده در این پایگاه داده نداشت و هیچ‌کس این ناخواسته را در طول مرحله‌بندی ایجاد نکرد. بر این اساس، 1 خط وجود داشت که به سرعت به نتیجه رسیدند.

ما می‌دانیم که تست‌های ما ضعیف هستند، یعنی فرآیندی که ساخته می‌شود مشکلی ایجاد نمی‌کند. آزمایش DB کافی انجام نشد.

یک آزمایش ایده آل ترجیحاً روی همان تجهیزات انجام می شود. همیشه نمی توان این کار را روی یک تجهیزات انجام داد، اما بسیار مهم است که یک کپی در اندازه کامل از پایگاه داده باشد. این همان چیزی است که من چندین سال است که موعظه می کنم. و یک سال پیش من در مورد این صحبت کردم، شما می توانید همه آن را در یوتیوب تماشا کنید.

شاید تجهیزات ما بد است؟ اگر نگاه کنید، پس تأخیر افزایش یافت. ما دیدیم که استفاده 100 درصد است. البته، اگر این ها درایوهای NVMe مدرن بودند، احتمالاً برای ما بسیار راحت تر بود. و شاید ما از آن دست نکشیم.

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

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

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

تنظیمات در Postgres عقب مانده است. آنها برای حجم داده ها و تراکنش های 10-15 ساله طراحی شده اند. و ایست بازرسی نیز از این قاعده مستثنی نیست.

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

چه مفهومی داره؟ اونجا دو تا تنظیمات هست ایست بازرسی می‌تواند با تایم اوت، برای مثال، در 10 دقیقه بیاید. یا ممکن است زمانی رخ دهد که داده های زیادی پر شده باشد.

و به طور پیش فرض max_wal_saze روی 1 گیگابایت تنظیم شده است. در واقع، این واقعا در Postgres بعد از 300-400 مگابایت اتفاق می افتد. شما داده های زیادی را تغییر داده اید و ایست بازرسی شما اتفاق می افتد.

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

و ما باید مطمئن شویم که کمتر می آید. یعنی ما می توانیم max_wal_size را افزایش دهیم. و کمتر خواهد آمد.

اما ما یک روش کامل برای نحوه انجام صحیح تر آن ایجاد کرده ایم، یعنی نحوه تصمیم گیری در مورد انتخاب تنظیمات، به وضوح بر اساس داده های خاص.

بر این اساس، ما در حال انجام دو سری آزمایش بر روی پایگاه های داده هستیم.

سری اول - max_wal_size را تغییر می دهیم. و ما در حال انجام یک عملیات عظیم هستیم. ابتدا این کار را با تنظیمات پیش فرض 1 گیگابایت انجام می دهیم. و ما یک DELETE عظیم از میلیون ها خط انجام می دهیم.

می بینید که چقدر برای ما سخت است. می بینیم که IO دیسک بسیار بد است. ما به تعداد WAL هایی که تولید کرده ایم نگاه می کنیم، زیرا این بسیار مهم است. ببینیم ایست بازرسی چند بار اتفاق افتاده است. و می بینیم که خوب نیست.

بعد max_wal_size را افزایش می دهیم. ما تکرار میکنیم. افزایش می دهیم، تکرار می کنیم. و بارها. در اصل 10 امتیاز خوب است که 1، 2، 4، 8 گیگابایت. و ما به رفتار یک سیستم خاص نگاه می کنیم. واضح است که در اینجا تجهیزات باید مانند روی prod باشد. شما باید دیسک های یکسان، همان مقدار حافظه و تنظیمات Postgres یکسان داشته باشید.

و به این ترتیب ما سیستم خود را مبادله خواهیم کرد و می دانیم که DBMS در صورت DELETE انبوه بد چگونه رفتار می کند، چگونه ایست بازرسی را انجام می دهد.

ایست بازرسی در روسی ایست بازرسی هستند.

مثال: چندین میلیون ردیف را بر اساس فهرست حذف کنید، ردیف‌ها در صفحات «پراکنده» هستند.

به عنوان مثال. این یک پایه است. و با تنظیم پیش فرض 1 گیگابایت برای max_wal_size، کاملاً واضح است که دیسک های ما برای ضبط به قفسه می روند. این تصویر یک علامت معمولی از یک بیمار بسیار بیمار است، یعنی او واقعاً احساس بدی داشته است. و یک عملیات واحد وجود داشت، فقط یک DELETE از چندین میلیون خط وجود داشت.

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

علاوه بر این، جایی که 16 گیگابایت است، مشخص است که دندان ها قبلاً رفته اند. دندان ها در حال حاضر بهتر شده اند، یعنی ما داریم به سقف می کوبیم، اما نه چندان بد. آنجا مقداری آزادی وجود داشت. در سمت راست رکورد است. و تعداد عملیات - نمودار دوم. و واضح است که ما در حال حاضر با 16 گیگابایت راحت تر نفس می کشیم.

و جایی که 64 گیگ دیده می شود که کاملا بهتر شده است. در حال حاضر دندان ها تلفظ می شوند، فرصت های بیشتری برای زنده ماندن از سایر عملیات ها و انجام کاری با دیسک وجود دارد.

چرا؟

من کمی به جزئیات می پردازم، اما این مبحث، نحوه انجام تنظیمات ایست بازرسی، می تواند به یک گزارش کامل منجر شود، بنابراین من زیاد بارگذاری نمی کنم، اما کمی مشکلات وجود دارد را شرح می دهم.

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

و ما ایست بازرسی را مجبور خواهیم کرد تا بارها آن را ذخیره کند. چگونه ممکن است عملیات اضافی برای او وجود داشته باشد.

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

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

در تغییرات بعدی فقط یک تاپل خاص وجود خواهد داشت، اما برای اولین بار همه چیز را یادداشت می کنیم.

و، بر این اساس، اگر ایست بازرسی دوباره اتفاق افتاد، پس باید همه چیز را دوباره از ابتدا شروع کنیم و کل صفحه را فشار دهیم. با چک پوینت‌های مکرر، وقتی از صفحات مشابه عبور می‌کنیم، full_page_writes = on بیشتر از آنچه می‌توانست باشد، یعنی WAL بیشتری تولید می‌کنیم. موارد بیشتر به کپی ها، به بایگانی، به دیسک ارسال می شود.

و بر این اساس، ما دو افزونگی داریم.

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

بیایید یک ترابایت بگذاریم و با آن زندگی کنیم. چه چیز بدی دارد؟ این بد است، زیرا در صورت شکست، ساعت ها صعود خواهیم کرد، زیرا ایست بازرسی خیلی وقت پیش بود و خیلی چیزها قبلاً تغییر کرده است. و ما باید همه این REDO را انجام دهیم. و بنابراین ما سری دوم آزمایش ها را انجام می دهیم.

ما یک عملیات انجام می دهیم و می بینیم که وقتی ایست بازرسی در شرف تکمیل است، -9 Postgres را عمدا می کشیم.

و بعد از آن دوباره آن را شروع می کنیم، و می بینیم که چقدر روی این تجهیزات بالا می رود، یعنی چقدر در این شرایط بد دوباره انجام می شود.

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

ما چنین وضعیتی را برای اندازه های مختلف max_wal_size اندازه گیری می کنیم و می فهمیم که اگر max_wal_size 64 گیگابایت باشد، در بدترین حالت دو برابر برای 10 دقیقه صعود خواهیم کرد. و ما فکر می کنیم که آیا برای ما مناسب است یا نه. این یک سوال تجاری است. ما باید این تصویر را به کسانی که مسئول تصمیمات تجاری هستند نشان دهیم و بپرسیم: «در صورت بروز مشکل حداکثر تا کی می‌توانیم دراز بکشیم؟ آیا می توانیم در بدترین شرایط 3-5 دقیقه دراز بکشیم؟ و تو تصمیم بگیر

و در اینجا یک نکته جالب وجود دارد. ما چند گزارش در مورد پاترونی در کنفرانس داریم. و شاید شما از آن استفاده می کنید. این یک خطای خودکار برای Postgres است. GitLab و Data Egret در این مورد صحبت کردند.

و اگر شما یک خودکاری دارید که در 30 ثانیه می آید، شاید بتوانیم 10 دقیقه دراز بکشیم؟ زیرا تا این مرحله به ماکت سوئیچ خواهیم کرد و همه چیز درست خواهد شد. این یک موضوع بحث برانگیز است. من جواب روشنی نمی دانم. من فقط احساس می کنم که این موضوع فقط در مورد بازیابی تصادف نیست.

اگر پس از یک شکست، بهبودی طولانی داشته باشیم، در بسیاری از موقعیت‌های دیگر ناراحت خواهیم بود. مثلا در همین آزمایش ها وقتی کاری را انجام می دهیم و گاهی باید 10 دقیقه منتظر بمانیم.

من هنوز خیلی دور نمی روم، حتی اگر یک خودکار فایلوور داشته باشیم. به عنوان یک قاعده، مقادیری مانند 64، 100 گیگابایت مقادیر خوبی هستند. گاهی حتی ارزش انتخاب کمتر را دارد. به طور کلی، این یک علم ظریف است.

برای انجام تکرارها، به عنوان مثال، max_wal_size = 1، 8، باید عملیات جرم را چندین بار تکرار کنید. تو موفق شدی. و بر روی همان پایه می خواهید دوباره این کار را انجام دهید، اما قبلاً همه چیز را حذف کرده اید. چه باید کرد؟

من بعداً در مورد راه حل خود صحبت خواهم کرد، چه کاری انجام می دهیم تا در چنین شرایطی تکرار کنیم. و این صحیح ترین رویکرد است.

اما در این مورد، ما خوش شانس بودیم. اگر همانطور که در اینجا می گوید "BEGIN, DELETE, ROLLBACK" می توانیم DELETE را تکرار کنیم. یعنی اگر خودمان لغوش کردیم، می توانیم آن را تکرار کنیم. و از نظر فیزیکی در شما داده ها در همان مکان قرار می گیرند. شما حتی نفخ هم نمی کنید می توانید روی چنین DELETE هایی تکرار کنید.

این DELETE با ROLLBACK برای تنظیم ایست بازرسی ایده آل است، حتی اگر آزمایشگاه های پایگاه داده به درستی مستقر نشده باشند.

یک بشقاب با یک ستون "i" درست کردیم. Postgres دارای ستون های کاربردی است. آنها نامرئی هستند مگر اینکه به طور خاص درخواست شود. اینها عبارتند از: ctid، xmid، xmax.

Ctid یک آدرس فیزیکی است. صفحه صفر، اولین تاپل در صفحه.

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

Xmax زمان مرگ تاپل است. مهر شده بود، اما Postgres می داند که تراکنش برگشت خورده است، بنابراین فرقی نمی کند که 0 باشد یا یک تراکنش برگشتی. این نشان می دهد که امکان تکرار روی DELETE و بررسی عملیات انبوه رفتار سیستم وجود دارد. شما می توانید آزمایشگاه های پایگاه داده برای فقرا ایجاد کنید.

این در مورد برنامه نویسان است. در مورد DBA نیز، آنها همیشه برنامه نویسان را به این دلیل سرزنش می کنند: "چرا اینقدر عملیات طولانی و دشوار انجام می دهید؟". این یک موضوع عمود کاملا متفاوت است. قبلاً مدیریت وجود داشت و اکنون توسعه خواهد بود.

بدیهی است که ما تکه تکه نشده ایم. واضح است. غیرممکن است که چنین DELETE را برای انبوهی از میلیون ها خط به قطعات تقسیم نکنید. به مدت 20 دقیقه انجام می شود و همه چیز دراز می کشد. اما، متاسفانه، حتی توسعه دهندگان با تجربه، حتی در شرکت های بسیار بزرگ، اشتباه می کنند.

چرا شکستن مهم است؟

• اگر دیدیم که دیسک سخت است، بیایید سرعت آن را کاهش دهیم. و اگر شکسته شدیم، می‌توانیم مکث اضافه کنیم، می‌توانیم گاز را کاهش دهیم.

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

https://postgres.ai/products/joe/

جالب است. من اغلب می بینم که توسعه دهندگان می پرسند: "چه اندازه بسته باید انتخاب کنم؟".

واضح است که هر چه اندازه بسته بزرگتر باشد، سربار تراکنش کوچکتر است، یعنی سربار اضافی تراکنش ها. اما در عین حال زمان این معامله افزایش می یابد.

من یک قانون بسیار ساده دارم: تا جایی که می‌توانید از آن استفاده کنید، اما از فایل‌های اجرایی در ثانیه غافل نشوید.

چرا یک ثانیه؟ توضیح بسیار ساده و قابل فهم برای همه حتی افراد غیر فنی است. ما شاهد واکنش هستیم. بیایید 50 میلی ثانیه در نظر بگیریم. اگر چیزی تغییر کرده باشد، چشم ما واکنش نشان می دهد. اگر کمتر، سخت تر است. اگر چیزی بعد از 100 میلی‌ثانیه پاسخ داد، مثلاً روی ماوس کلیک کردید و بعد از 100 میلی‌ثانیه به شما پاسخ داد، قبلاً این تأخیر جزئی را احساس می‌کنید. یک ثانیه در حال حاضر به عنوان ترمز درک می شود.

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

ما اندازه بسته را انتخاب می کنیم. در هر مورد، ما می توانیم آن را متفاوت انجام دهیم. می تواند خودکار باشد. و ما از کارایی پردازش یک بسته متقاعد شده ایم. یعنی ما یک بسته را DELETE یا UPDATE می کنیم.

به هر حال، هر چیزی که من در مورد آن صحبت می کنم فقط در مورد DELETE نیست. همانطور که حدس زدید، اینها هر گونه عملیات انبوه روی داده است.

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

استراتژی های پارتیشن بندی چیست؟ من 3 استراتژی پارتیشن بندی مختلف را می بینم که توسعه دهندگان روی بسته از آنها استفاده می کنند.

مورد اول بسیار ساده است. ما یک شناسه عددی داریم. و بیایید آن را به فواصل مختلف تقسیم کنیم و با آن کار کنیم. جنبه منفی مشخص است. در بخش اول، ممکن است 100 خط زباله واقعی داشته باشیم، در 5 خط دوم یا اصلاً نداشته باشیم، یا هر 1 خط زباله تبدیل شود. کار بسیار ناهموار است، اما شکستن آن آسان است. حداکثر شناسه را گرفتند و خرد کردند. این یک رویکرد ساده لوحانه است.

راهبرد دوم یک رویکرد متعادل است. در Gitlab استفاده می شود. میز را گرفتند و اسکن کردند. ما مرزهای بسته های ID را پیدا کردیم به طوری که هر بسته دقیقاً 10 رکورد داشت. و آنها را در یک صف قرار دهید. و سپس پردازش می کنیم. شما می توانید این کار را در چندین رشته انجام دهید.

اتفاقاً در استراتژی اول نیز می توانید این کار را در چندین رشته انجام دهید. سخت نیست.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

اما یک رویکرد سردتر و بهتر وجود دارد. این سومین استراتژی است. و در صورت امکان بهتر است آن را انتخاب کنید. ما این کار را بر اساس یک شاخص خاص انجام می دهیم. در این صورت به احتمال زیاد یک شاخص با توجه به شرایط زباله و شناسه ما خواهد بود. شناسه را اضافه می کنیم تا فقط اسکن شاخص باشد تا به پشته نرویم.

به طور کلی، اسکن فقط فهرست سریعتر از اسکن فهرست است.

و ما به سرعت شناسه های خود را که می خواهیم حذف کنیم پیدا می کنیم. BATCH_SIZE ما از قبل انتخاب می کنیم. و ما نه تنها آنها را دریافت می کنیم، بلکه آنها را به روشی خاص دریافت می کنیم و بلافاصله آنها را هک می کنیم. اما ما قفل می کنیم تا اگر از قبل قفل شده اند قفلشان نکنیم بلکه جلو برویم و بعدی ها را بگیریم. این برای به روز رسانی است که پرش قفل شده است. این ویژگی فوق العاده Postgres به ما این امکان را می دهد که در صورت تمایل در چندین رشته کار کنیم. در یک جریان امکان پذیر است. و در اینجا یک CTE وجود دارد - این یک درخواست است. و ما یک حذف واقعی در طبقه دوم این CTE داریم - returning *. شما می توانید id را برگردانید، اما بهتر است *اگر اطلاعات زیادی در هر خط ندارید.

چرا ما به اون احتیاج داریم؟ این چیزی است که باید گزارش کنیم. ما اکنون بسیاری از خطوط را در واقع حذف کرده ایم. و ما مرزهایی با شناسه یا توسط create_at مانند این داریم. شما می توانید حداقل، حداکثر انجام دهید. یه کار دیگه هم میشه کرد شما می توانید در اینجا چیزهای زیادی بپردازید. و برای نظارت بسیار راحت است.

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

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

اما این بهینه ترین استراتژی است، نحوه تقسیم به دسته ها و شلیک به دسته ها با یک درخواست، حذف کمی و غیره.

معاملات طولانی https://gitlab.com/snippets/1890447

جارو برقی مسدود شده - https://gitlab.com/snippets/1889668

مشکل مسدود کردن - https://gitlab.com/snippets/1890428

اشتباه شماره 5 یک اشتباه بزرگ است. نیکولای از Okmeter در مورد نظارت Postgres صحبت کرد. متأسفانه نظارت ایده آل Postgres وجود ندارد. برخی نزدیکترند، برخی دورتر. Okmeter به اندازه کافی به کامل بودن نزدیک است، اما چیزهای زیادی گم شده است و باید اضافه شود. شما باید برای این کار آماده باشید.

به عنوان مثال، تاپل های مرده به بهترین وجه تحت نظر هستند. اگر چیزهای مرده زیادی در جدول دارید، پس چیزی اشتباه است. بهتر است الان عکس العمل نشان دهیم وگرنه ممکن است انحطاط ایجاد شود و می توانیم دراز بکشیم. اتفاق می افتد.

اگر یک IO بزرگ وجود دارد، پس واضح است که این خوب نیست.

معاملات طولانی نیز. تراکنش های طولانی نباید در OLTP مجاز باشند. و در اینجا پیوندی به یک قطعه وجود دارد که به شما امکان می دهد این قطعه را بگیرید و از قبل تراکنش های طولانی را ردیابی کنید.

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

اگر میزهای زیادی داریم که جاروبرقی ندارند، باید یک هشدار داشته باشیم. در اینجا چنین وضعیتی امکان پذیر است. ما می توانیم به طور غیر مستقیم بر عملکرد اتو وکیوم تأثیر بگذاریم. این یک قطعه از Avito است که من کمی آن را بهبود بخشیم. و معلوم شد که ابزار جالبی برای دیدن آنچه ما با autovacuum داریم. به عنوان مثال، برخی از میزها در آنجا منتظر هستند و منتظر نوبت خود نخواهند بود. شما همچنین باید آن را در مانیتورینگ قرار دهید و یک هشدار داشته باشید.

و بلوک ها را صادر می کند. جنگل درختان بلوک. من دوست دارم چیزی را از کسی بگیرم و آن را بهبود بخشم. در اینجا من یک CTE بازگشتی جالب از Data Egret گرفتم که جنگلی از درختان قفل را نشان می دهد. این یک ابزار تشخیصی خوب است. و بر اساس آن، شما همچنین می توانید نظارت ایجاد کنید. اما این باید با دقت انجام شود. شما باید یک statement_timeout کوچک برای خود بسازید. و lock_timeout مطلوب است.

گاهی اوقات تمام این خطاها در مجموع رخ می دهد.

به نظر من اشتباه اصلی اینجا تشکیلاتی است. این سازمانی است، زیرا تکنیک نمی کشد. این شماره 2 است - آنها در جای اشتباه بررسی کردند.

ما در جای اشتباه بررسی کردیم، زیرا ما یک کلون تولید نداشتیم، که بررسی آن آسان است. یک توسعه دهنده ممکن است اصلاً به تولید دسترسی نداشته باشد.

و ما بررسی کردیم که آنجا نیست. اگر آنجا را چک کرده بودیم، خودمان می دیدیم. اگر توسعه دهنده آن را در یک محیط خوب بررسی کند، که در آن به همان میزان داده و یک مکان یکسان وجود دارد، همه را حتی بدون DBA دید. او این همه تنزل را می دید و خجالت می کشید.

اطلاعات بیشتر در مورد اتو وکیوم پس از انجام یک جاروی عظیم چند میلیون خطی، هنوز باید REPACK را انجام دهیم. این به ویژه برای شاخص ها مهم است. بعد از اینکه همه چیز را آنجا تمیز کردیم، احساس بدی خواهند کرد.

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

کاری که ما انجام می دهیم منبع باز است. در GitLab پست شده است. و ما آن را طوری می سازیم که مردم حتی بدون DBA هم بتوانند چک کنند. ما در حال انجام یک آزمایشگاه پایگاه داده هستیم، یعنی کامپوننت پایه ای را که جو در حال حاضر روی آن کار می کند، فراخوانی می کنیم. و شما می توانید یک نسخه از تولید را بگیرید. اکنون یک پیاده سازی Joe برای Slack وجود دارد، می توانید در آنجا بگویید: "فلان درخواست را توضیح دهید" و بلافاصله نتیجه را برای کپی پایگاه داده خود دریافت کنید. شما حتی می توانید آن را حذف کنید، و هیچ کس متوجه آن نخواهد شد.

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

به این می گویند تامین نازک. این تدارک ظریف است. این نوعی فانتزی است که تأخیر در توسعه، آزمایش را تا حد زیادی برطرف می کند و جهان را از این نظر به مکان بهتری تبدیل می کند. یعنی فقط به شما این امکان را می دهد که از مشکلات مربوط به عملیات انبوه جلوگیری کنید.

مثال: پایگاه داده 5 ترابایتی، دریافت یک کپی در کمتر از 30 ثانیه. و حتی به اندازه آن نیز بستگی ندارد، یعنی مهم نیست چند ترابایت.

امروز می توانید به postgres.ai و ابزارهای ما را حفاری کنید. می توانید ثبت نام کنید تا ببینید چه چیزی وجود دارد. شما می توانید این ربات را نصب کنید. رایگان است. نوشتن.

پرسش

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

این یک رویکرد بسیار خوب و یک کار بسیار خوب است. این بسیار شبیه به کاری است که pg_repack انجام می دهد، بسیار شبیه به کاری است که وقتی ID ها را 4 بایت می سازید، باید انجام دهید. بسیاری از فریمورک ها چند سال پیش این کار را انجام دادند و فقط صفحات بزرگ شده اند و باید به 8 بایت تبدیل شوند.

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

اگر به pg_repack در GitHub نگاه کنید، در آنجا، زمانی که وظیفه تبدیل ID از int 4 به int 8 وجود داشت، ایده ای وجود داشت که از خود pg_repack استفاده کنید. این نیز ممکن است، اما کمی هک است، اما برای این نیز کار خواهد کرد. می توانید در تریگری که pg_repack استفاده می کند مداخله کنید و در آنجا بگویید: "ما به این داده ها نیاز نداریم"، یعنی فقط آنچه را که نیاز داریم منتقل می کنیم. و سپس او فقط سوئیچ می کند و تمام.

با این رویکرد، ما هنوز یک کپی دوم از جدول را دریافت می کنیم، که در آن داده ها از قبل ایندکس شده و به طور یکنواخت با نمایه های زیبا روی هم قرار می گیرند.

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

من فقط کمی از دنیای MySQL فاصله دارم، بنابراین آمدم گوش کنم. و ما از این روش استفاده می کنیم.

اما فقط در صورتی است که 90 درصد داشته باشیم. اگر 5 درصد داشته باشیم، استفاده از آن خیلی خوب نیست.

با تشکر از گزارش! اگر هیچ منبعی برای کپی کامل پرود وجود نداشته باشد، آیا الگوریتم یا فرمولی برای محاسبه بار یا اندازه وجود دارد؟

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

با تشکر از گزارش! شما ابتدا در مورد این واقعیت شروع کردید که یک Postgres باحال وجود دارد که چنین و چنان محدودیت هایی دارد، اما در حال توسعه است. و این همه در کل یک عصا است. آیا همه اینها در تضاد با توسعه خود Postgres نیست، که در آن برخی از DELETE deferent ظاهر می شود یا چیز دیگری که باید آنچه را که ما در اینجا می خواهیم با برخی از ابزارهای عجیب و غریب خود لکه دار کنیم، در سطح پایین نگه دارد؟

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

با نمایه ها انجام شد.

من می توانم فرض کنم که همان تنظیم ایست بازرسی می تواند خودکار باشد. روزی ممکن است باشد. اما من واقعاً سؤال را درک نمی کنم.

سوال این است که آیا چنین بردار توسعه ای وجود دارد که به این طرف و آن طرف می رود و اینجا مال شما موازی می شود؟ آن ها هنوز به آن فکر نکرده اند؟

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

و برای تنظیم چک پوینت، می‌توانید این کار را انجام دهید: اگر هزاران خوشه و سخت‌افزار مختلف، ماشین‌های مجازی مختلف در فضای ابری دارید، می‌توانید از ربات ما استفاده کنید. نانسی اتوماسیون انجام دهید و max_wal_size با توجه به تنظیمات هدف شما به طور خودکار انتخاب می شود. اما متأسفانه تا کنون این حتی در هسته نزدیک نیست.

عصر بخیر شما در مورد خطرات معاملات طولانی صحبت کردید. شما گفتید که اتوواکیوم در صورت حذف مسدود می شود. دیگر چگونه به ما آسیب می رساند؟ زیرا ما بیشتر در مورد آزاد کردن فضا و امکان استفاده از آن صحبت می کنیم. چه چیز دیگری را از دست داده ایم؟

اتو وکیوم شاید بزرگترین مشکل در اینجا نباشد. و اینکه یک تراکنش طولانی می تواند سایر تراکنش ها را قفل کند، این احتمال خطرناک تر است. او ممکن است ملاقات کند یا نکند. اگر او ملاقات کرد، پس می تواند بسیار بد باشد. و با autovacuum - این نیز یک مشکل است. دو مشکل در تراکنش های طولانی در OLTP وجود دارد: قفل و خلاء خودکار. و اگر بازخورد آماده به کار داغ را روی ماکت فعال کرده باشید، باز هم یک قفل خلاء خودکار روی Master دریافت خواهید کرد، که از ماکت می‌رسد. اما حداقل هیچ قفلی وجود نخواهد داشت. و لوک وجود خواهد داشت. ما در مورد تغییرات داده ها صحبت می کنیم، بنابراین قفل ها یک نکته مهم در اینجا هستند. و اگر همه اینها برای مدت طولانی و طولانی باشد، تراکنش های بیشتر و بیشتری قفل می شوند. آنها می توانند دیگران را بدزدند. و درختان لوک ظاهر می شوند. لینک قطعه را گذاشتم. و این مشکل سریعتر از مشکل اتوواکیوم که فقط می تواند انباشته شود قابل توجه تر می شود.

با تشکر از گزارش! شما گزارش خود را با گفتن اینکه تست را اشتباه انجام داده اید شروع کردید. ما به ایده خود ادامه دادیم که باید همان تجهیزات را با پایه به همان روش برداریم. فرض کنید به توسعه دهنده یک پایگاه داده ایم. و خواسته را اجابت کرد. و به نظر می رسد او خوب است. ولی لایو چک نمیکنه ولی لایو مثلا 60-70 بار داریم. و حتی اگر از این تنظیم استفاده کنیم، خیلی خوب کار نمی کند.

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

زمانی که در حال انجام یک انتخاب زباله هستیم و مثلاً یک پرچم حذف شده داریم

این همان کاری است که autovacuum به طور خودکار در Postgres انجام می دهد.

اوه، او این کار را می کند؟

Autovacuum جمع کننده زباله است.

با تشکر از شما!

با تشکر از گزارش! آیا گزینه ای برای طراحی فوری یک پایگاه داده با پارتیشن بندی به گونه ای وجود دارد که همه زباله ها از میز اصلی جایی به سمت آن کثیف شوند؟

البته دارند.

اگر میزی را قفل کرده ایم که نباید از آن استفاده کنیم، آیا می توان از خود محافظت کرد؟

البته دارند. اما مثل یک سوال مرغ و تخم مرغ است. اگر همه ما بدانیم که در آینده چه اتفاقی خواهد افتاد، مطمئناً همه چیز را عالی انجام خواهیم داد. اما کسب و کار در حال تغییر است، ستون های جدید، درخواست های جدید وجود دارد. و سپس - اوه، ما می خواهیم آن را حذف کنیم. اما این وضعیت ایده آل، در زندگی اتفاق می افتد، اما نه همیشه. اما در کل ایده خوبی است. فقط کوتاه کن و تمام.

منبع: www.habr.com