ربات DBA جو. آناتولی استنسلر (Postgres.ai)

چگونه یک توسعه دهنده باطن می فهمد که یک پرس و جوی SQL روی یک "prod" به خوبی کار می کند؟ در شرکت های بزرگ یا به سرعت در حال رشد، همه به «محصول» دسترسی ندارند. و با دسترسی، نمی توان همه درخواست ها را بدون دردسر بررسی کرد و ایجاد یک کپی از پایگاه داده اغلب ساعت ها طول می کشد. برای حل این مشکلات، ما یک DBA مصنوعی - Joe ایجاد کردیم. قبلاً با موفقیت در چندین شرکت پیاده سازی شده است و به بیش از ده ها توسعه دهنده کمک می کند.

ویدئو:

سلام به همه! نام من آناتولی استنسلر است. من برای یک شرکت کار می کنم postgres.ai. ما متعهد به تسریع روند توسعه با حذف تاخیرهای مرتبط با کار Postgres از توسعه دهندگان، DBAها و QAها هستیم.

ما مشتریان بزرگی داریم و امروز بخشی از گزارش به مواردی اختصاص می‌یابد که در حین کار با آنها ملاقات کردیم. من در مورد چگونگی کمک به آنها برای حل مشکلات کاملاً جدی صحبت خواهم کرد.

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

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

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

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

درد دارد، گران است. احتمالاً بهتر است این کار را نکنید.

و بهترین راه برای انجام آن چیست؟

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

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

مشکلات چیست؟

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

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

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

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

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

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

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

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

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

اینجا چه کار می توانیم بکنیم؟ بیایید نیمکت‌های تست را ارزان کنیم و به هر توسعه‌دهنده‌ای میز تست خود را بدهیم.

و این امکان پذیر است.

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

مثال واقعی:

• DB - 4,5 ترابایت.

• ما می توانیم در 30 ثانیه کپی های مستقل دریافت کنیم.

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

این عالی است. در اینجا ما در مورد جادو و یک جهان موازی صحبت می کنیم.

در مورد ما، این با استفاده از سیستم OpenZFS کار می کند.

OpenZFS یک سیستم فایل کپی روی نوشتن است که از عکس های فوری و کلون های خارج از جعبه پشتیبانی می کند. قابل اعتماد و مقیاس پذیر است. مدیریت او بسیار آسان است. این به معنای واقعی کلمه می تواند در دو تیم مستقر شود.

گزینه های دیگری نیز وجود دارد:

• LVM ،

• ذخیره سازی (به عنوان مثال، ذخیره سازی خالص).

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

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

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

و این کاربر با چنین مجموعه داده ای کار خواهد کرد. او به تدریج آنها را تغییر می دهد، عکس های فوری خود را می سازد.

و منشعب خواهیم شد. هر توسعه دهنده در مورد ما این فرصت را خواهد داشت که کلون خود را داشته باشد که ویرایش می کند و داده هایی که به اشتراک گذاشته می شود بین همه به اشتراک گذاشته می شود.

برای استقرار چنین سیستمی در خانه، باید دو مشکل را حل کنید:

• اولین مورد منبع داده است، جایی که آن را از آن دریافت خواهید کرد. شما می توانید همانند سازی را با تولید تنظیم کنید. امیدوارم از قبل می توانید از نسخه های پشتیبان که پیکربندی کرده اید استفاده کنید. WAL-E، WAL-G یا Barman. و حتی اگر از نوعی راه حل Cloud مانند RDS یا Cloud SQL استفاده می کنید، می توانید از dump های منطقی استفاده کنید. اما ما همچنان به شما توصیه می‌کنیم از پشتیبان‌گیری استفاده کنید، زیرا با این رویکرد ساختار فیزیکی فایل‌ها را نیز حفظ خواهید کرد، که به شما امکان می‌دهد حتی به معیارهایی که در تولید می‌بینید نزدیک‌تر باشید تا مشکلات موجود را برطرف کنید.

• مورد دوم جایی است که می خواهید آزمایشگاه پایگاه داده را میزبانی کنید. می تواند Cloud باشد، می تواند On-premise باشد. در اینجا مهم است که بگوییم ZFS از فشرده سازی داده ها پشتیبانی می کند. و آن را به خوبی انجام می دهد.

تصور کنید که برای هر یک از این کلون ها، بسته به عملیاتی که با پایگاه انجام می دهیم، نوعی توسعه دهنده رشد می کند. برای این، توسعه دهنده به فضا نیز نیاز دارد. اما با توجه به اینکه ما یک پایه 4,5 ترابایتی گرفتیم، ZFS آن را به 3,5 ترابایت فشرده می کند. این می تواند بسته به تنظیمات متفاوت باشد. و ما هنوز جا برای توسعه دهنده داریم.

چنین سیستمی برای موارد مختلف قابل استفاده است.

• اینها توسعه دهندگان، DBA برای اعتبارسنجی پرس و جو، برای بهینه سازی هستند.

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

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

با این رویکرد:

1. احتمال کم خطا در "prod"، زیرا ما تمام تغییرات را روی داده های اندازه کامل آزمایش کردیم.

2. ما فرهنگ تست زدن را داریم، زیرا اکنون مجبور نیستید ساعت ها منتظر غرفه خود باشید.

3. و هیچ مانعی وجود ندارد، هیچ انتظاری بین آزمون ها وجود ندارد. در واقع می توانید بروید و بررسی کنید. و با سرعت بخشیدن به توسعه، به این ترتیب بهتر خواهد شد.

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

• ما می توانیم تغییرات برگشت ناپذیر را معکوس کنیم. این رویکرد استاندارد نیست.

1. این مفید است زیرا ما منابع نیمکت های آزمون را به اشتراک می گذاریم.

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

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

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

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

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

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

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

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

اما برای اینکه این آزمایشات قابل قبول باشند، باید به نحوی این مشکل را حل کنید.

واضح است که نکته مهم همین داده است. اما ما قبلا آن را داریم. و ما می خواهیم به همان پیکربندی برسیم. و ما می توانیم چنین پیکربندی تقریباً یکسانی ارائه دهیم.

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

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

توجه به این نکته مهم است که حافظه پنهان بافر مشترک با شروع Postgres، بسته به اندازه ای که در پیکربندی مشخص می کنید، اختصاص می یابد.

و کش دوم از تمام فضای موجود استفاده می کند.

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

و معلوم می شود که اگر این پارامتر را تغییر ندهیم، می توانیم تنها 4 نمونه را روی یک ماشین اجرا کنیم، یعنی 4 مورد از این کلون های نازک. و این، البته، بد است، زیرا ما می خواهیم تعداد بیشتری از آنها داشته باشیم.

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

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

اما در اینجا به این نتیجه می رسیم که در واقع پلن در Postgres به اندازه خاصی که در Shared Buffer در پلن مشخص شده است بستگی ندارد، به effect_cache_size بستگی دارد.

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

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

اما این می تواند بر زمان بندی تأثیر بگذارد. و ما پرس و جوها را با زمان بندی بهینه می کنیم، اما مهم است که زمان بندی به عوامل زیادی بستگی دارد:

• این بستگی به باری دارد که در حال حاضر روی پرود است.

• این به ویژگی های خود دستگاه بستگی دارد.

و این یک پارامتر غیرمستقیم است، اما در واقع می‌توانیم دقیقاً با مقدار داده‌ای که این کوئری می‌خواند، بهینه‌سازی کنیم تا به نتیجه برسیم.

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

بیایید نگاهی به نحوه بهینه سازی خاص جو بیندازیم.

بیایید یک درخواست از یک سیستم واقعی بگیریم. در این حالت دیتابیس 1 ترابایت است. و می‌خواهیم تعداد پست‌های تازه‌ای که بیش از 10 لایک داشتند را بشماریم.

ما در حال نوشتن پیام به کانال هستیم، یک کلون برای ما مستقر شده است. و خواهیم دید که چنین درخواستی در 2,5 دقیقه تکمیل می شود. این اولین چیزی است که متوجه می شویم.

B Joe توصیه های خودکار را بر اساس طرح و معیارها به شما نشان می دهد.

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

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

و، به نظر می رسد، ما در اینجا یک اسکن شاخص داریم و باید به سرعت کار می کردیم، اما از آنجایی که خطوط زیادی را فیلتر کردیم (باید آنها را بشماریم)، ​​درخواست به آرامی انجام شد.

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

بیایید سعی کنیم ایندکس را دقیق تر کنیم و ببینیم که اجرای کوئری پس از آن چگونه تغییر می کند.

ایجاد ایندکس خیلی طول کشید، اما اکنون پرس و جو را بررسی می کنیم و می بینیم که زمان به جای 2,5 دقیقه فقط 156 میلی ثانیه است که به اندازه کافی خوب است. و ما فقط 6 مگابایت داده را می خوانیم.

و اکنون از اسکن فقط شاخص استفاده می کنیم.

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

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

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

البته، همه می دانند توضیح.depesz.com. ویژگی خوب این تجسم این است که ما طرح متن را ذخیره می کنیم و همچنین برخی از پارامترهای اساسی را در جدول قرار می دهیم تا بتوانیم مرتب کنیم.

و توسعه‌دهندگانی که هنوز به این موضوع نپرداخته‌اند نیز از توضیح.depesz.com استفاده می‌کنند، زیرا تشخیص اینکه کدام معیارها مهم هستند و کدام‌ها نیستند برایشان آسان‌تر است.

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

همکاری

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

به نظر ما این است که آزمایش روی داده های اندازه کامل مهم است. برای این کار ابزار Update Database Lab را ساختیم که به صورت متن باز موجود است. می توانید از ربات جو نیز استفاده کنید. می توانید همین الان آن را بگیرید و در محل خود پیاده سازی کنید. همه راهنماها در آنجا موجود هستند.

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

این همان جایی است که من به پایان می رسم. متشکرم!

پرسش

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

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

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

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

برای هر کلون مقداری ttl وجود دارد. اساسا ما یک ttl ثابت داریم.

اگر راز نباشد چه؟

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

من به انتخاب فناوری ها نیز علاقه مند هستم، زیرا به عنوان مثال، به دلایلی از چندین روش به صورت موازی استفاده می کنیم. چرا ZFS؟ چرا از LVM استفاده نکردید؟ شما اشاره کردید که LVM مشکلاتی داشت. مشکلات چه بود؟ به نظر من بهینه ترین گزینه با ذخیره سازی از نظر کارایی است.

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

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

نیکولای ساموخوالوف: ممکن است بیشتر نظر بدهم؟ اسم من نیکولای است، ما با آناتولی کار می کنیم. موافقم که ذخیره سازی عالی است. و برخی از مشتریان ما دارای Pure Storage و غیره هستند.

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

اما ZFS برای همه در دسترس است. DelPhix از قبل کافی است، آنها 300 مشتری دارند. از این تعداد، فورچون 100 50 مشتری دارد، یعنی ناسا و غیره را هدف گرفته اند. وقت آن رسیده که همه این فناوری را دریافت کنند. و به همین دلیل است که ما یک Core منبع باز داریم. ما یک بخش رابط داریم که منبع باز نیست. این پلتفرمی است که نشان خواهیم داد. اما ما می خواهیم که برای همه قابل دسترسی باشد. ما می خواهیم انقلابی ایجاد کنیم تا همه آزمایش کننده ها از حدس زدن روی لپ تاپ ها دست بردارند. باید SELECT بنویسیم و بلافاصله ببینیم کند است. منتظر نمانید تا DBA در مورد آن به شما بگوید. هدف اصلی اینجاست. و من فکر می کنم که همه ما به این موضوع خواهیم رسید. و ما این چیز را برای همه می سازیم. بنابراین ZFS، زیرا در همه جا در دسترس خواهد بود. با تشکر از جامعه برای حل مشکلات و داشتن مجوز منبع باز و غیره*

با درود! با تشکر از گزارش! اسم من ماکسیم است. ما با همین مسائل برخورد کرده ایم. خودشان تصمیم گرفتند. چگونه منابع را بین این کلون ها به اشتراک می گذارید؟ هر کلون می‌تواند کار خودش را در هر زمان انجام دهد: یکی یک چیز را آزمایش می‌کند، دیگری چیز دیگر، کسی یک شاخص می‌سازد، کسی کار سنگینی دارد. و اگر هنوز بتوانید بر اساس CPU تقسیم کنید، پس بر اساس IO، چگونه تقسیم می کنید؟ این اولین سوال است.

و سوال دوم در مورد عدم تشابه جایگاه هاست. فرض کنید من اینجا ZFS دارم و همه چیز باحال است، اما کلاینت روی prod ZFS ندارد، مثلا ext4 دارد. در این مورد چگونه؟

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

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

دو تا سوال دارم این چیز خیلی باحالی است آیا مواردی وجود داشته است که داده های تولید مانند شماره کارت اعتباری حیاتی باشد؟ آیا از قبل چیزی آماده است یا یک کار جداگانه است؟ و سوال دوم - آیا چیزی شبیه به این برای MySQL وجود دارد؟

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

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

اما از آنجایی که سیستم قابل توسعه است، می توان از آن برای MySQL نیز استفاده کرد. و نمونه هایی از این دست وجود دارد. Yandex چیزی مشابه دارد، اما آنها آن را در جایی منتشر نمی کنند. آنها از آن در داخل Yandex.Metrica استفاده می کنند. و فقط یک داستان در مورد MySQL وجود دارد. اما تکنولوژی ها یکسان هستند، ZFS.

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

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

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

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

شاخص هر بار ایجاد می شود؟

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

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

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

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

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

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

معلوم می شود که به روز رسانی به عنوان یک لایه اضافی انجام می شود و همه تصاویر جدید از قبل بر اساس این لایه می روند، درست است؟

از لایه های قبلی که از تکرارهای قبلی بودند.

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

به طور کلی، بله.

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

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

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

مثل اونه. به عنوان مثال، می توانیم بنویسیم: "SELECT FROM WHERE email = to that". یعنی ما خود داده را نخواهیم دید، اما می توانیم برخی از نشانه های غیر مستقیم را ببینیم. این را باید فهمید. اما از سوی دیگر، همه چیز وجود دارد. ما یک حسابرسی گزارش داریم، ما کنترل سایر همکاران را داریم که همچنین می بینند توسعه دهندگان چه کار می کنند. و اگر کسی سعی کند این کار را انجام دهد، سرویس امنیتی به سراغ آنها می آید و روی این موضوع کار می کند.

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

اکنون یک پیوند به Slack وجود دارد، یعنی هیچ پیام رسان دیگری وجود ندارد، اما من واقعاً می خواهم از پیام رسان های دیگر نیز پشتیبانی کنم. چه کاری می توانی انجام بدهی؟ شما می توانید DB Lab را بدون جو مستقر کنید، به کمک REST API یا با کمک پلتفرم ما بروید و کلون ایجاد کنید و با PSQL متصل شوید. اما اگر آماده باشید به توسعه دهندگان خود دسترسی به داده ها را بدهید، می توان این کار را انجام داد، زیرا دیگر هیچ صفحه ای وجود نخواهد داشت.

من به این لایه نیاز ندارم، اما به چنین فرصتی نیاز دارم.

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

منبع: www.habr.com