کمک Yandex به پایگاه های داده زیر بررسی خواهد شد.
- کلیک هاوس
- ادیسه
- بازیابی تا یک نقطه در زمان (WAL-G)
- PostgreSQL (از جمله logerrors، Amcheck، heapcheck)
- سبز آلو
ویدئو:
سلام دنیا! نام من آندری بورودین است. و کاری که من در Yandex.Cloud انجام می‌دهم توسعه پایگاه‌های داده رابطه‌ای باز در راستای منافع مشتریان Yandex.Cloud و Yandex.Cloud است.
در این گفتگو، ما در مورد چالش های پیش روی پایگاه های داده باز در مقیاس صحبت خواهیم کرد. چرا مهم است؟ زیرا مشکلات کوچک و کوچکی که مانند پشه ها بعداً فیل می شوند. وقتی خوشه های زیادی دارید بزرگ می شوند.
اما این چیز اصلی نیست. اتفاقات باورنکردنی رخ می دهد. اتفاقاتی که در یک میلیون مورد اتفاق می افتد. و در یک محیط ابری، باید برای آن آماده باشید، زیرا وقتی چیزی در مقیاس وجود داشته باشد، چیزهای باورنکردنی بسیار محتمل می‌شوند.
ولی! مزیت پایگاه داده باز چیست؟ واقعیت این است که شما یک فرصت نظری برای مقابله با هر مشکلی دارید. شما کد منبع را دارید، دانش برنامه نویسی دارید. ما آن را ترکیب می کنیم و کار می کند.
چه رویکردهایی در کار بر روی نرم افزار منبع باز وجود دارد؟
- ساده ترین روش استفاده از نرم افزار است. اگر از پروتکل‌ها استفاده می‌کنید، اگر از استانداردها استفاده می‌کنید، اگر از فرمت‌ها استفاده می‌کنید، اگر درخواست‌هایی را در نرم‌افزار منبع باز می‌نویسید، از قبل از آن پشتیبانی می‌کنید.
- شما اکوسیستم آن را بزرگتر می کنید. شما احتمال تشخیص زودهنگام یک باگ را بیشتر می کنید. شما قابلیت اطمینان این سیستم را افزایش می دهید. شما در دسترس بودن توسعه دهندگان را در بازار افزایش می دهید. شما این نرم افزار را بهبود بخشید. شما در حال حاضر یک مشارکت کننده هستید، اگر سبک خود را به پایان رسانده اید و چیزی را در آنجا سرهم کرده اید.
- یکی دیگر از رویکردهای قابل درک حمایت از نرم افزار منبع باز است. به عنوان مثال، برنامه معروف Google Summer of Code، زمانی که Google به تعداد زیادی از دانش‌آموزان از سراسر جهان پول قابل درک پرداخت می‌کند تا پروژه‌های نرم‌افزاری باز را توسعه دهند که الزامات مجوز خاصی را برآورده می‌کنند.
- این یک رویکرد بسیار جالب است زیرا به نرم افزار اجازه می دهد بدون تغییر تمرکز از جامعه تکامل یابد. گوگل به‌عنوان یک غول فناوری نمی‌گوید که ما این ویژگی را می‌خواهیم، ما می‌خواهیم این باگ را برطرف کنیم و اینجاست که باید جستجو کنیم. گوگل می گوید: «کاری را که انجام می دهید انجام دهید. فقط به همان روشی که کار می کردید ادامه دهید و همه چیز درست خواهد شد."
- رویکرد بعدی برای مشارکت در متن باز مشارکت است. وقتی در نرم افزار متن باز مشکلی دارید و توسعه دهندگان وجود دارند، توسعه دهندگان شما شروع به حل مشکلات می کنند. آنها شروع به کارآمدتر کردن زیرساخت های شما، سریع تر و قابل اطمینان تر کردن برنامه های شما می کنند.
یکی از معروف ترین پروژه های Yandex در زمینه نرم افزارهای متن باز، ClickHouse است. این پایگاه داده ای است که به عنوان پاسخی به چالش های پیش روی Yandex.Metrica متولد شده است.
و به عنوان یک پایگاه داده، به منظور ایجاد یک اکوسیستم و توسعه آن به همراه سایر توسعه دهندگان (نه تنها در Yandex) به صورت متن باز ساخته شد. و اکنون این یک پروژه بزرگ است که بسیاری از شرکت های مختلف در آن مشارکت دارند.
در Yandex.Cloud، ما ClickHouse را در بالای Yandex Object Storage، یعنی بالای فضای ذخیره سازی ابری ایجاد کردیم.
چرا این در ابر مهم است؟ زیرا هر پایگاه داده ای در این مثلث، در این هرم، در این سلسله مراتب انواع حافظه کار می کند. شما دارای رجیسترهای سریع اما کوچک و SSDهای بزرگ اما کند ارزان، هارد دیسک و برخی دستگاه های بلوک دیگر هستید. و اگر در راس هرم کارآمد هستید، یک پایگاه داده سریع دارید. اگر در انتهای این هرم کارآمد هستید، یک پایگاه داده مقیاس‌پذیر دارید. و در این راستا افزودن یک لایه دیگر از زیر یک رویکرد منطقی برای افزایش مقیاس پذیری پایگاه داده است.
چگونه می توان آن را انجام داد؟ این یک نکته مهم در این گزارش است.
- ما می‌توانیم ClickHouse را روی MDS پیاده‌سازی کنیم. MDS یک رابط ذخیره سازی ابری داخلی Yandex است. این پیچیده تر از پروتکل رایج S3 است، اما برای یک دستگاه بلوک مناسب تر است. برای ثبت اطلاعات بهتر است. نیاز به برنامه نویسی بیشتری دارد. برنامه نویسان برنامه ریزی خواهند کرد، حتی خوب است، جالب است.
- S3 رویکرد متداول تری است که رابط را ساده تر می کند به قیمت انطباق کمتر با انواع خاصی از بارهای کاری.
به طور طبیعی، مایل به ارائه عملکرد به کل اکوسیستم ClickHouse و انجام وظایف مورد نیاز در Yandex.Cloud، تصمیم گرفتیم مطمئن شویم که کل جامعه ClickHouse از آن سود می برند. ما ClickHouse را روی S3 پیاده سازی کردیم، نه ClickHouse را روی MDS. و این خیلی کار است.
لینک ها:
"لایه انتزاعی سیستم فایل"
"ادغام AWS SDK S3"
پیاده سازی پایه رابط IDisk برای S3
"ادغام موتورهای ذخیره سازی گزارش با رابط IDisk"
"پشتیبانی موتور لاگ برای S3 و SeekableReadBuffer"
"پشتیبانی از Storage Stripe Log S3"
"پشتیبانی اولیه Storage MergeTree برای S3"
"پشتیبانی کامل MergeTree برای S3"
"Support ReplicateMergeTree over S3"
"افزودن اعتبار پیش فرض و هدرهای سفارشی برای ذخیره سازی s3"
"S3 با پیکربندی پروکسی پویا"
"S3 با حل کننده پروکسی"
این یک لیست درخواست کششی برای پیاده سازی یک فایل سیستم مجازی در ClickHouse است. این تعداد زیادی درخواست کشش است.
لینک ها:
"پیاده سازی بهینه پیوندهای سخت DiskS3"
"کلینت HTTP S3 - از کپی کردن جریان پاسخ در حافظه خودداری کنید"
از کپی کردن کل جریان پاسخ در حافظه در S3 HTTP خودداری کنید
مشتری"
“قابلیت کش علامت گذاری و فهرست بندی فایل ها برای دیسک S3”
"انتقال قطعات از DiskLocal به DiskS3 به صورت موازی"
اما کار به همین جا ختم نشد. پس از ساخته شدن این ویژگی، برای بهینه سازی این قابلیت، به کار بیشتری نیاز بود.
لینک ها:
"افزودن رویدادهای SelectedRows و SelectedBytes"
"افزودن رویدادهای پروفایل از درخواست S3 به system.events"
"Add QueryTimeMicroseconds، SelectQueryTimeMicroseconds و InsertQueryTimeMicroseconds"
و پس از آن لازم بود که آن را قابل تشخیص، راه اندازی نظارت و قابل مدیریت کردن.
و همه این کارها انجام شد تا کل جامعه، کل اکوسیستم ClickHouse، نتیجه این کار را دریافت کند.
بیایید به پایگاه‌های داده تراکنشی، به پایگاه‌های داده OLTP که شخصاً به من نزدیک‌تر هستند، برویم.
این بخش توسعه DBMS منبع باز است. این افراد در حال انجام جادوی خیابانی برای بهبود پایگاه داده های باز تراکنش هستند.
یکی از پروژه هایی که با استفاده از مثالی از آن می توانیم در مورد چگونگی و کارهایی که انجام می دهیم صحبت کنیم، Connection Pooler در Postgres است.
Postgres یک پایگاه داده فرآیند است. این به این معنی است که پایگاه داده باید تا حد امکان اتصالات شبکه ای کمتری داشته باشد که تراکنش ها را مدیریت کند.
از سوی دیگر، در یک محیط ابری، یک وضعیت معمولی زمانی است که هزاران اتصال به یک خوشه به یکباره می آیند. و وظیفه ی کانکشن این است که هزاران اتصال را در تعداد کمی از اتصالات سرور قرار دهد.
می‌توان گفت که Pooler اتصال، اپراتور تلفن است که بایت‌ها را به گونه‌ای مرتب می‌کند که به طور مؤثر به پایگاه داده برسند.
متأسفانه، کلمه روسی خوبی برای اتصال pooler وجود ندارد. گاهی اوقات به آن اتصالات مالتی پلکسر می گویند. اگر می‌دانید چه نامی را به مخزن اتصال بدهید، پس حتماً به من بگویید، من بسیار خوشحال خواهم شد که به زبان فنی صحیح روسی صحبت کنم.
ما جمع‌کننده‌های اتصال را بررسی کردیم که برای یک خوشه postgres مدیریت شده مناسب بودند. و PgBouncer بهترین انتخاب برای ما بود. اما ما با یک سری مشکلات با PgBouncer مواجه شدیم. سال ها پیش، Volodya Borodin گزارش هایی ارائه کرد که ما از PgBouncer استفاده می کنیم، همه چیز را دوست داریم، اما تفاوت های ظریف وجود دارد، چیزی برای کار وجود دارد.
و ما کار کردیم. ما مشکلاتی را که با آن مواجه شدیم برطرف کردیم، Bouncer را وصله کردیم و سعی کردیم درخواست‌های pull را به سمت بالا هدایت کنیم. اما کار با تک رشته ای اساسی دشوار بود.
ما مجبور بودیم آبشارها را از Bouncer های وصله شده جمع آوری کنیم. زمانی که تعداد زیادی Bouncer تک رشته ای داریم، اتصالات لایه بالایی به لایه داخلی Bouncer ها منتقل می شود. این سیستمی است که مدیریت ضعیفی دارد و ساخت و توسعه آن دشوار است.
ما به این نتیجه رسیدیم که Pooler اتصال خودمان را ایجاد کردیم که به آن Odyssey می‌گویند. ما آن را از ابتدا نوشتیم.
در سال 2019، در کنفرانس PgCon، من این pooler را به جامعه توسعه دهندگان ارائه کردم. اکنون کمی کمتر از 2 ستاره در GitHub داریم، یعنی پروژه زنده است، پروژه محبوب است.
و اگر یک خوشه Postgres را در Yandex.Cloud ایجاد کنید، آنگاه خوشه‌ای با Odyssey داخلی خواهد بود که هنگام تغییر مقیاس خوشه به جلو یا عقب پیکربندی مجدد می‌شود.
ما از این پروژه چه آموختیم؟ راه اندازی یک پروژه رقیب همیشه یک گام تهاجمی است، زمانی که می گوییم مشکلاتی وجود دارد که به اندازه کافی سریع حل نمی شوند، در بازه های زمانی مناسب ما حل نمی شوند، یک اقدام افراطی است. اما این یک اقدام موثر است.
PgBouncer سریعتر شروع به توسعه کرد.
و اکنون پروژه های دیگری ظاهر شده اند. به عنوان مثال، pgagroal که توسط توسعه دهندگان Red Hat توسعه داده شده است. آنها اهداف مشابهی را دنبال می کنند و ایده های مشابهی را اجرا می کنند، اما، البته، با ویژگی های خاص خود، که به توسعه دهندگان pgagroal نزدیک تر است.
مورد دیگر کار با جامعه postgres بازگرداندن به یک نقطه از زمان است. این بازیابی پس از یک شکست است، این بازیابی از یک نسخه پشتیبان است.
پشتیبان های زیادی وجود دارد و همه آنها متفاوت هستند. تقریباً هر فروشنده Postgres راه حل پشتیبان خود را دارد.
اگر تمام سیستم های پشتیبان را بگیرید، یک ماتریس ویژگی ایجاد کنید و به شوخی تعیین کننده در این ماتریس را محاسبه کنید، صفر می شود. این یعنی چی؟ اگر یک فایل پشتیبان خاص را بگیرید، نمی‌توانید آن را از تکه‌هایی از سایر فایل‌ها جمع آوری کنید. در اجرایش بی نظیر است، در هدفش بی نظیر است، در ایده هایی که در آن نهفته است بی نظیر است. و همه آنها خاص هستند.
در حالی که ما روی این موضوع کار می کردیم، CitusData پروژه WAL-G را راه اندازی کرد. این یک سیستم پشتیبان است که با توجه به محیط ابری ساخته شده است. اکنون CitusData در حال حاضر بخشی از مایکروسافت است. و در آن لحظه، ایده‌هایی را که در نسخه‌های اولیه WAL-G مطرح شد، بسیار دوست داشتیم. و ما شروع به مشارکت در این پروژه کردیم.
اکنون ده‌ها توسعه‌دهنده در این پروژه وجود دارد، اما 10 مشارکت‌کننده برتر WAL-G شامل 6 Yandexoid است. ما خیلی از ایده هایمان را آنجا آوردیم. و البته، ما خودمان آنها را پیاده سازی کردیم، خود آنها را آزمایش کردیم، خودمان آنها را در تولید قرار دادیم، خودمان از آنها استفاده می کنیم، خودمان متوجه می شویم که کجا باید حرکت کنیم، در حالی که با جامعه بزرگ WAL-G تعامل داریم.
و از دیدگاه ما، اکنون این سیستم پشتیبان، از جمله با در نظر گرفتن تلاش های ما، برای یک محیط ابری بهینه شده است. این بهترین هزینه برای پشتیبان گیری از Postgres در فضای ابری است.
چه مفهومی داره؟ ما یک ایده نسبتاً بزرگ را ترویج می‌کردیم: پشتیبان‌گیری باید امن باشد، کارکرد آن ارزان باشد و با حداکثر سرعت ممکن بازیابی شود.
چرا باید کارکرد آن ارزان باشد؟ وقتی هیچ چیز خراب نیست، نباید بدانید که پشتیبان دارید. همه چیز به خوبی کار می کند، شما تا حد امکان CPU کمتری را هدر می دهید، تا حد امکان از منابع دیسک خود استفاده می کنید و تا حد امکان بایت های کمتری را به شبکه ارسال می کنید تا در بارگذاری سرویس های ارزشمند خود تداخل نداشته باشید.
و وقتی همه چیز خراب شد، برای مثال، ادمین داده ها را رها کرد، مشکلی پیش آمد، و شما باید فوراً به گذشته برگردید، با تمام پول بازیابی می کنید، زیرا می خواهید اطلاعات خود را سریع و دست نخورده برگردانید.
و ما این ایده ساده را ترویج کردیم. و به نظر ما، ما موفق به اجرای آن شدیم.
اما این همه ماجرا نیست. ما یک چیز کوچک دیگر می خواستیم. ما پایگاه های اطلاعاتی مختلفی می خواستیم. همه مشتریان ما از Postgres استفاده نمی کنند. برخی از افراد از MySQL، MongoDB استفاده می کنند. در جامعه، توسعه دهندگان دیگر FoundationDB را پشتیبانی کرده اند. و این لیست دائما در حال گسترش است.
جامعه این ایده را دوست دارد که پایگاه داده در یک محیط مدیریت شده در فضای ابری اجرا شود. و توسعه دهندگان پایگاه داده خود را حفظ می کنند، که می تواند به طور یکنواخت همراه با Postgres با سیستم پشتیبان ما پشتیبان گیری شود.
ما از این داستان چه آموختیم؟ محصول ما، به عنوان یک بخش توسعه، خطوط کد نیست، عبارت نیست، فایل نیست. محصول ما درخواست کشش نیست. اینها ایده هایی است که ما به جامعه منتقل می کنیم. این تخصص فناوری و حرکت فناوری به سمت یک محیط ابری است.
پایگاه داده ای به نام Postgres وجود دارد. من هسته Postgres را بیشتر دوست دارم. من زمان زیادی را صرف توسعه هسته Postgres با جامعه می کنم.
اما در اینجا باید گفت که Yandex.Cloud دارای نصب داخلی پایگاه های داده مدیریت شده است. و مدتها پیش در Yandex.Mail شروع شد. مهارتی که اکنون به Postgres مدیریت شده منجر شده است، زمانی جمع شد که نامه می خواست به Postgres منتقل شود.
Mail الزامات بسیار مشابهی با ابر دارد. به شما نیاز دارد که بتوانید در هر نقطه از داده‌های خود به رشد نمایی غیرمنتظره برسید. و نامه قبلاً با صدها میلیون صندوق پستی تعداد زیادی از کاربرانی که دائماً درخواست‌های زیادی می‌کنند، بارگیری شده بود.
و این یک چالش کاملا جدی برای تیمی بود که در حال توسعه Postgres بود. در آن زمان، هر مشکلی که با آن مواجه می شدیم به جامعه گزارش می شد. و این مشکلات در برخی جاها حتی در سطح پشتیبانی پولی برای برخی دیگر از پایگاه های داده و حتی بهتر از آن، اصلاح و توسط جامعه اصلاح شد. یعنی می توانید برای هکر PgSQL نامه بفرستید و در عرض 40 دقیقه پاسخ دریافت کنید. پشتیبانی پولی در برخی از پایگاه‌های داده ممکن است فکر کند که موارد اولویت بیشتری نسبت به اشکال شما وجود دارد.
اکنون نصب داخلی Postgres چند پتابایت داده است. اینها چند میلیون درخواست در ثانیه هستند. اینها هزاران خوشه هستند. بسیار در مقیاس بزرگ است.
اما یک تفاوت ظریف وجود دارد. این نه بر روی درایوهای شبکه فانتزی، بلکه بر روی سخت افزار نسبتاً ساده زندگی می کند. و یک محیط آزمایشی به طور خاص برای چیزهای جدید جالب وجود دارد.
و در یک لحظه خاص در محیط آزمایش، پیامی دریافت کردیم که نشان می‌دهد متغیرهای داخلی شاخص‌های پایگاه داده نقض شده است.
تغییر ناپذیر نوعی رابطه است که ما انتظار داریم همیشه آن را حفظ کنیم.
شرایط بسیار بحرانی برای ما. این نشان می دهد که ممکن است برخی از داده ها از بین رفته باشد. و از دست دادن داده ها چیزی کاملاً فاجعه بار است.
ایده کلی که ما در پایگاه های داده مدیریت شده دنبال می کنیم این است که حتی با تلاش، از دست دادن داده ها دشوار خواهد بود. حتی اگر عمداً آنها را حذف کنید، باز هم باید غیبت آنها را برای مدت طولانی نادیده بگیرید. امنیت داده ها دینی است که ما با جدیت از آن پیروی می کنیم.
و در اینجا وضعیتی پیش می آید که نشان می دهد ممکن است موقعیتی وجود داشته باشد که ما برای آن آماده نباشیم. و ما شروع به آماده شدن برای این وضعیت کردیم.
اولین کاری که انجام دادیم این بود که سیاهههای مربوط به این هزاران خوشه را دفن کردیم. متوجه شدیم کدام یک از خوشه‌ها روی دیسک‌هایی با سیستم‌افزار مشکل‌ساز قرار دارند که به‌روزرسانی‌های صفحه داده‌ها را از دست می‌دهند. تمام کدهای داده Postgres علامت گذاری شده است. و پیام‌هایی را که نشان‌دهنده نقض متغیرهای داخلی هستند با کدی که برای شناسایی خرابی داده‌ها طراحی شده است علامت‌گذاری کردیم.
این پچ عملاً بدون بحث زیاد توسط جامعه پذیرفته شد، زیرا در هر مورد خاص مشخص بود که اتفاق بدی رخ داده است و باید به گزارش گزارش شود.
بعد از این به این نقطه رسیدیم که نظارتی داریم که لاگ ها را اسکن می کند. و در صورت دریافت پیام های مشکوک، افسر وظیفه را بیدار می کند و افسر وظیفه آن را تعمیر می کند.
ولی! اسکن سیاههها یک عملیات ارزان در یک خوشه و به طرز فاجعه باری برای هزاران خوشه گران است.
یک پسوند نوشتیم به نام . نمایی از پایگاه داده ایجاد می کند که در آن می توانید آمار خطاهای گذشته را به صورت ارزان و سریع انتخاب کنید. و اگر لازم باشد افسر وظیفه را بیدار کنیم، بدون اسکن فایل های گیگابایت، اما با استخراج چند بایت از جدول هش، متوجه این موضوع خواهیم شد.
این پسوند، به عنوان مثال، در مخزن برای استفاده شده است . اگر می خواهید از آن استفاده کنید، می توانید خودتان آن را نصب کنید. البته منبع باز است.
اما این همه ماجرا نیست. ما شروع به استفاده از Amcheck کردیم، یک افزونه ساخته شده در جامعه، برای یافتن تخلفات ثابت در فهرست ها.
و ما متوجه شدیم که اگر آن را در مقیاس اجرا کنید، اشکالاتی وجود دارد. ما شروع به تعمیر آنها کردیم. اصلاحات ما پذیرفته شده است.
ما متوجه شدیم که این برنامه افزودنی نمی تواند شاخص های GiST و GIT را تجزیه و تحلیل کند. ما آنها را مجبور به حمایت کردیم. اما این پشتیبانی هنوز توسط جامعه مورد بحث است، زیرا این یک عملکرد نسبتاً جدید است و جزئیات زیادی در آن وجود دارد.
و همچنین متوجه شدیم که هنگام بررسی ایندکس ها برای نقض در رهبر تکرار، در مستر، همه چیز به خوبی کار می کند، اما در کپی ها، در فالوور، جستجوی فساد چندان موثر نیست. همه ثابت ها بررسی نمی شوند. و یک تغییر ناپذیر ما را بسیار آزار داد. و ما یک سال و نیم را صرف ارتباط با جامعه کردیم تا بتوانیم این بررسی را روی ماکت ها فعال کنیم.
ما کدی نوشتیم که باید از همه پروتکل ها پیروی کند. ما این پچ را مدتی با پیتر گاگان از Crunchy Data بحث کردیم. او مجبور شد درخت B موجود در Postgres را کمی تغییر دهد تا بتواند این پچ را بپذیرد. او پذیرفته شد. و اکنون بررسی نمایه‌ها روی ماکت‌ها نیز به اندازه کافی برای شناسایی تخلفاتی که با آن مواجه شده‌ایم مؤثر شده است. یعنی اینها موارد نقضی است که می تواند ناشی از خطا در سیستم عامل دیسک، باگ در Postgres، باگ در هسته لینوکس و مشکلات سخت افزاری باشد. فهرست بسیار گسترده ای از منابع مشکلاتی که ما برای آنها آماده می شدیم.
اما علاوه بر ایندکس ها، بخشی به عنوان پشته وجود دارد، یعنی مکانی که داده ها در آن ذخیره می شوند. و متغیرهای ثابت زیادی وجود ندارد که بتوان آنها را بررسی کرد.
ما یک افزونه به نام Heapcheck داریم. ما شروع به توسعه آن کردیم. و به موازات آن، همراه با ما، شرکت EnterpriseDB نیز شروع به نوشتن یک ماژول کرد که به همین ترتیب آن را Heapcheck نامیدند. فقط ما آن را PgHeapcheck نامیدیم و آنها فقط آن را Heapcheck نامیدند. آنها آن را با عملکردهای مشابه، امضای کمی متفاوت، اما با ایده های یکسان دارند. بعضی جاها کمی بهتر اجرا کردند. و قبلاً آن را در متن باز ارسال کرده بودند.
و اکنون ما در حال توسعه آنها هستیم، زیرا این دیگر گسترش آنها نیست، بلکه گسترش جامعه است. و در آینده، این بخشی از هسته است که برای همه عرضه می شود تا از قبل از مشکلات آینده مطلع شوند.
حتی در برخی جاها به این نتیجه رسیدیم که در سیستم های مانیتورینگ خود، مثبت کاذب داریم. به عنوان مثال، سیستم 1C. هنگام استفاده از پایگاه داده، Postgres گاهی اوقات داده هایی را در آن می نویسد که بتواند بخواند، اما pg_dump نمی تواند بخواند.
این وضعیت برای سیستم تشخیص مشکل ما مانند فساد به نظر می رسید. افسر وظیفه از خواب بیدار شد. افسر وظیفه نگاه کرد که چه اتفاقی می افتد. بعد از مدتی مشتری آمد و گفت مشکل دارم. مهماندار توضیح داد که مشکل چیست. اما مشکل در هسته Postgres است.
من یک بحث در مورد این ویژگی پیدا کردم. و نوشت که ما با این ویژگی مواجه شدیم و ناخوشایند بود، شخصی شب از خواب بیدار شد تا بفهمد چیست.
جامعه پاسخ داد، "اوه، ما واقعا باید آن را اصلاح کنیم."
من یک تشبیه ساده دارم. اگر با کفشی راه می روید که یک دانه شن در آن است، در اصل، می توانید ادامه دهید - مشکلی نیست. اگر به هزاران نفر چکمه می فروشید، پس بیایید اصلا چکمه بدون شن بسازیم. و اگر یکی از کاربران کفش شما قرار است یک ماراتن بدود، پس می‌خواهید کفش‌های بسیار خوبی بسازید و سپس آنها را به همه کاربران خود تقسیم کنید. و چنین کاربران غیرمنتظره ای همیشه در محیط ابری هستند. همیشه کاربرانی هستند که از خوشه به روشی اصلی بهره برداری می کنند. شما باید همیشه برای این کار آماده شوید.
ما اینجا چه آموختیم؟ ما یک چیز ساده یاد گرفتیم: مهمترین چیز این است که به جامعه توضیح دهیم که یک مشکل وجود دارد. اگر جامعه مشکل را تشخیص داده باشد، رقابت طبیعی برای حل مشکل به وجود می آید. زیرا همه می خواهند یک مشکل مهم را حل کنند. همه فروشندگان، همه هکرها می دانند که خودشان می توانند روی این چنگک پا بگذارند، بنابراین می خواهند آنها را از بین ببرند.
اگر روی مشکلی کار می‌کنید، اما هیچ‌کس را به جز شما آزار نمی‌دهد، اما به صورت سیستماتیک روی آن کار می‌کنید و در نهایت مشکل محسوب می‌شود، قطعاً درخواست کشش شما پذیرفته می‌شود. پچ شما پذیرفته می شود، بهبودها یا حتی درخواست های شما برای بهبود توسط انجمن بررسی می شود. در پایان روز، ما پایگاه داده را برای یکدیگر بهتر می کنیم.
یک پایگاه داده جالب Greenplum است. این یک پایگاه داده بسیار موازی مبتنی بر پایگاه کد Postgres است که من با آن بسیار آشنا هستم.
و Greenplum عملکرد جالبی دارد - جداول بهینه شده را اضافه کنید. اینها جدول هایی هستند که می توانید به سرعت به آنها اضافه کنید. آنها می توانند ستونی یا ردیفی باشند.
اما هیچ خوشه‌بندی وجود نداشت، یعنی هیچ عملکردی وجود نداشت که بتوانید داده‌های موجود در جدول را مطابق با ترتیبی که در یکی از ایندکس‌ها قرار دارد مرتب کنید.
بچه‌های تاکسی به سمت من آمدند و گفتند: «آندری، تو پستگرس را می‌شناسی. و اینجا هم تقریباً یکسان است. به 20 دقیقه تغییر دهید. شما آن را بگیرید و انجامش دهید.» من فکر کردم که بله، من Postgres را می شناسم، به مدت 20 دقیقه تغییر می کند - باید این کار را انجام دهم.
اما نه، 20 دقیقه نبود، من آن را در طول ماه ها نوشتم. در کنفرانس PgConf.Russia، من از Pivotal به Heikki Linakangas رفتم و پرسیدم: «آیا مشکلی در این مورد وجود دارد؟ چرا هیچ دسته بندی جدولی بهینه سازی شده ای وجود ندارد؟ او می گوید: «شما داده ها را می گیرید. شما مرتب می کنید، دوباره مرتب می کنید. این فقط یک شغل است." من: "اوه، بله، شما فقط باید آن را بگیرید و انجامش دهید." او می‌گوید: «بله، برای این کار به دست‌های آزاد نیاز داریم». فکر کردم حتما باید این کار را بکنم.
و چند ماه بعد من یک درخواست کشش ارسال کردم که این قابلیت را اجرا کرد. این درخواست کشش توسط Pivotal همراه با انجمن بررسی شد. البته اشکالاتی هم داشت.
اما جالب ترین چیز این است که وقتی این درخواست کشش ادغام شد، باگ هایی در خود Greenplum پیدا شد. ما دریافته‌ایم که جداول پشته گاهی اوقات وقتی خوشه‌بندی می‌شوند، تراکنشی را از بین می‌برند. و این چیزی است که باید اصلاح شود. و او در جایی است که من فقط آن را لمس کردم. و واکنش طبیعی من این بود - باشه، اجازه دهید من هم این کار را انجام دهم.
من این باگ را رفع کردم. یک درخواست کشش به فیکس کننده ها ارسال شد. او کشته شد.
پس از آن مشخص شد که این قابلیت باید در نسخه Greenplum برای PostgreSQL 12 به دست آید. یعنی ماجراجویی 20 دقیقه ای با ماجراهای جالب جدید ادامه می یابد. جالب بود که توسعه فعلی را لمس کنیم، جایی که جامعه در حال برش ویژگی های جدید و مهم است. یخ زده است.
اما به همین جا ختم نشد. بعد از همه چیز معلوم شد که برای همه اینها باید مستندات بنویسیم.
شروع به نوشتن مستندات کردم. خوشبختانه مستندسازان پیوتال آمدند. انگلیسی زبان مادری آنهاست. آنها در زمینه مستندات به من کمک کردند. در واقع، آنها خودشان چیزی را که من پیشنهاد کردم به انگلیسی واقعی بازنویسی کردند.
و در اینجا، به نظر می رسد، ماجراجویی به پایان رسید. و میدونی بعدش چی شد؟ بچه های تاکسی به سمت من آمدند و گفتند: "هنوز دو ماجرا وجود دارد، هر کدام 10 دقیقه." و به آنها چه بگویم؟ گفتم حالا یک گزارش در مقیاس ارائه می کنم، سپس ماجراهای شما را خواهیم دید، زیرا این کار جالبی است.
ما از این پرونده چه آموختیم؟ از آنجایی که کار با منبع باز همیشه کار با یک فرد خاص است، همیشه کار با جامعه است. زیرا در هر مرحله با یک توسعه دهنده، یک آزمایشگر، یک هکر، یک مستندساز، و یک معمار کار کردم. من با Greenplum کار نکردم، من با افراد اطراف Greenplum کار کردم.
ولی! نکته مهم دیگری وجود دارد - این فقط کار است. یعنی شما بیایید قهوه بنوشید کد بنویسید. همه انواع ثابت های ساده کار می کنند. این کار را به طور معمول انجام دهید - خوب خواهد شد! و کار بسیار جالبی است. درخواستی برای این کار از مشتریان Yandex.Cloud، کاربران خوشه های ما در داخل یا خارج از Yandex وجود دارد. و من فکر می کنم که تعداد پروژه هایی که در آنها مشارکت می کنیم افزایش می یابد و عمق مشارکت ما نیز افزایش می یابد.
همین. بریم سراغ سوالات.
جلسه سوالات
سلام! یک جلسه پرسش و پاسخ دیگر داریم. و در استودیو آندری بورودین. این شخصی است که به تازگی در مورد مشارکت Yandex.Cloud و Yandex در منبع باز به شما گفته است. گزارش ما در حال حاضر به طور کامل در مورد Cloud نیست، اما در عین حال ما مبتنی بر چنین فناوری هایی هستیم. بدون کاری که شما در داخل Yandex انجام دادید، هیچ سرویسی در Yandex.Cloud وجود نخواهد داشت، بنابراین شخصاً از من متشکرم. و اولین سوال از پخش: هر یک از پروژه هایی که نام بردید روی چه نوشته شده است؟
سیستم پشتیبان در WAL-G در Go نوشته شده است. این یکی از پروژه های جدیدتری است که روی آن کار کرده ایم. او به معنای واقعی کلمه فقط 3 سال سن دارد. و یک پایگاه داده اغلب در مورد قابلیت اطمینان است. و این بدان معنی است که پایگاه های داده کاملا قدیمی هستند و معمولاً به زبان C نوشته می شوند. پروژه Postgres حدود 30 سال پیش آغاز شد. سپس C89 انتخاب درستی بود. و Postgres روی آن نوشته شده است. پایگاه داده های مدرن تری مانند ClickHouse معمولاً در C++ نوشته می شوند. تمام توسعه سیستم بر اساس C و C ++ است.
یک سوال از مدیر مالی ما که مسئول هزینه‌های Cloud است: "چرا Cloud برای پشتیبانی از منبع باز پول خرج می کند؟"
در اینجا یک پاسخ ساده برای مدیر مالی وجود دارد. ما این کار را انجام می دهیم تا خدمات خود را بهتر کنیم. از چه راه هایی می توانیم بهتر عمل کنیم؟ ما می‌توانیم کارها را کارآمدتر، سریعتر انجام دهیم و کارها را مقیاس‌پذیرتر کنیم. اما برای ما، این داستان در درجه اول در مورد قابلیت اطمینان است. به عنوان مثال، در یک سیستم پشتیبان، ما 100٪ از وصله های اعمال شده برای آن را بررسی می کنیم. ما می دانیم که کد چیست. و ما راحت تر نسخه های جدید را برای تولید عرضه می کنیم. یعنی اول از همه، این در مورد اعتماد، در مورد آمادگی برای توسعه و در مورد قابلیت اطمینان است
سوال دیگر: "آیا الزامات کاربران خارجی که در Yandex.Cloud زندگی می کنند با کاربران داخلی که در Cloud داخلی زندگی می کنند متفاوت است؟"
مشخصات بار، البته، متفاوت است. اما از نظر دپارتمان من، تمام موارد خاص و جالب روی یک بار غیر استاندارد ایجاد می شود. توسعه دهندگان با تخیل، توسعه دهندگانی که کارهای غیرمنتظره را انجام می دهند، به احتمال زیاد هم در داخل و هم در خارج یافت می شوند. در این زمینه، همه ما تقریباً یکسان هستیم. و احتمالاً تنها ویژگی مهم در عملیات Yandex پایگاه داده این خواهد بود که در داخل Yandex ما یک آموزش داشته باشیم. در برخی موارد، برخی از مناطق در دسترس به طور کامل در سایه قرار می گیرند و همه سرویس های Yandex باید به نحوی به کار خود ادامه دهند. این یک تفاوت کوچک است. اما توسعه تحقیقات زیادی را در رابط پایگاه داده و پشته شبکه ایجاد می کند. در غیر این صورت، نصب های خارجی و داخلی همان درخواست ها را برای ویژگی ها و درخواست های مشابه برای بهبود قابلیت اطمینان و عملکرد ایجاد می کنند.
سوال بعدی: "شما شخصاً در مورد این واقعیت که بیشتر کارهایی که انجام می دهید توسط ابرهای دیگر استفاده می شود، چه احساسی دارید؟" ما موارد خاصی را نام نمی‌بریم، اما بسیاری از پروژه‌هایی که در Yandex.Cloud انجام شده‌اند در ابرهای افراد دیگر استفاده می‌شوند.
این باحاله اولاً این نشانه این است که ما کاری را درست انجام داده ایم. و نفس را خراش می دهد. و ما بیشتر مطمئن هستیم که تصمیم درستی گرفته ایم. از سوی دیگر، این امیدواری است که در آینده ایده های جدید، درخواست های جدید از کاربران شخص ثالث برای ما به ارمغان بیاورد. اکثر مسائل در GitHub توسط مدیران سیستم، DBA های فردی، معماران فردی، مهندسان منفرد ایجاد می شود، اما گاهی اوقات افرادی با تجربه سیستماتیک می آیند و می گویند که در 30٪ موارد خاص ما این مشکل را داریم و بیایید در مورد چگونگی حل آن فکر کنیم. این چیزی است که ما بیشتر منتظر آن هستیم. ما مشتاق به اشتراک گذاری تجربیات با دیگر پلتفرم های ابری هستیم.
شما در مورد ماراتن زیاد صحبت کردید. می دانم که در مسکو یک ماراتن دویدی. در نتیجه؟ از بچه های PostgreSQL سبقت گرفتید؟
نه، اولگ بارتونوف خیلی سریع می دود. یک ساعت جلوتر از من کارش را تمام کرد. در مجموع، از اینکه چقدر به آن رسیده ام راضی هستم. برای من، تمام کردن یک دستاورد بود. به طور کلی، تعجب آور است که تعداد دوندگان زیادی در جامعه postgres وجود دارد. به نظر من نوعی رابطه بین ورزش های هوازی و تمایل به برنامه نویسی سیستمی وجود دارد.
آیا می گویید هیچ دونده ای در ClickHouse وجود ندارد؟
من مطمئن هستم که آنها آنجا هستند. ClickHouse نیز یک پایگاه داده است. به هر حال، اولگ اکنون برای من می نویسد: "آیا پس از گزارش برای دویدن برویم؟" این یک ایده عالی است.
یک سوال دیگر از پخش از نیکیتا: "چرا خودت اشکال را در Greenplum برطرف کردی و آن را به جوانان ندهی؟" درست است، خیلی مشخص نیست که باگ چیست و در کدام سرویس است، اما احتمالاً به معنای همان چیزی است که شما در مورد آن صحبت کردید.
بله، اصولاً می شد به کسی داد. فقط کدی بود که من تغییر دادم. و طبیعی بود که بلافاصله این کار را ادامه دهیم. در اصل، ایده به اشتراک گذاری تخصص با تیم ایده خوبی است. ما قطعاً وظایف Greenplum را بین همه اعضای بخش خود به اشتراک خواهیم گذاشت.
از آنجایی که ما در مورد جوانان صحبت می کنیم، در اینجا یک سوال وجود دارد. آن شخص تصمیم گرفت اولین کامیت را در Postgres ایجاد کند. برای انجام اولین تعهد چه کاری باید انجام دهد؟
این یک سوال جالب است: "از کجا شروع کنیم؟" معمولاً شروع با چیزی در هسته بسیار دشوار است. به عنوان مثال، در Postgres، یک لیست برای انجام وجود دارد. اما در واقع این برگه ای از کاری است که آنها سعی کردند انجام دهند اما موفق نشدند. اینها چیزهای پیچیده ای هستند. و معمولاً می‌توانید برخی از ابزارهای کاربردی را در اکوسیستم پیدا کنید، برخی برنامه‌های افزودنی که می‌توانند بهبود یابند، که توجه کمتری را از سوی توسعه‌دهندگان هسته جلب می‌کنند. و بر این اساس، نقاط بیشتری برای رشد در آنجا وجود دارد. در برنامه تابستانی کد گوگل، هر ساله انجمن postgres موضوعات مختلفی را مطرح می کند که می توان به آنها پرداخت. امسال فکر کنم سه شاگرد داشتیم. یکی حتی در WAL-G در مورد موضوعات مهم برای Yandex نوشت. در Greenplum، همه چیز ساده تر از جامعه Postgres است، زیرا هکرهای Greenplum به خوبی با درخواست های کششی برخورد می کنند و بلافاصله شروع به بررسی می کنند. ارسال یک وصله به Postgres چند ماه است، اما Greenplum یک روز دیگر می‌آید و می‌بیند که شما چه کرده‌اید. نکته دیگر این است که گرین پلام باید مشکلات فعلی را حل کند. Greenplum به طور گسترده مورد استفاده قرار نمی گیرد، بنابراین یافتن مشکل شما بسیار دشوار است. و اول از همه، ما نیاز به حل مشکلات، البته.
منبع: www.habr.com