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

از اینکه در مورد سفر ما به یک ذخیره‌سازی انتزاعی و با ارزش کلیدی در Pinterest مطالعه کردید متشکریم. می‌خواهم از همه افرادی که در این پروژه مهم و چالش‌برانگیز مشارکت داشتند قدردانی کنم: راجات پراساد، کانگنان لی، ایندی پرنتیس، هارولد کابالیک، مادلین نگوین، جیا ژان، نیل انریکز، رامش کالوری، تیم جونز، گوپال راجپوروهیت، گوئودونگ Han، Prem Thangamani، Lianghong Xu، Alberto Ordonez Pereira، Kevin Lin، همه شرکای ما در SRE، امنیت، و بهره‌وری Eng، و همه مشتریان مهندسی ما در Pinterest که تیم‌هایی از تبلیغات تا homefeed، یادگیری ماشین تا پلتفرم سیگنال را در بر می‌گیرند. هیچ یک از اینها بدون کار تیمی و همکاری همه در اینجا امکان پذیر نخواهد بود.

اگر شما یا هرکسی که می شناسید به مشکلات سیستم های توزیع شده در مقیاس سیاره مانند این علاقه دارید و می خواهید با یک تیم شگفت انگیز کار کنید، فرصت های شغلی برای تیم Key Value Systems را ببینید!

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

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

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

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

فاز 1: انتقال داده فقط خواندنی (کاملاً بدون درز)

مرحله فقط خواندنی ابتدا به این دلیل بود که ساده‌تر بود (اطلاعات غیرقابل تغییر آسان‌تر از دریافت نوشته‌های زنده داده‌های قابل تغییر است) و به این دلیل که اکثر مشتریان را هدف قرار می‌داد (حدود 70 درصد از Terrapin استفاده می‌کردند). از آنجایی که Terrapin بسیار پرکار بود و در پایگاه کد ما مستقر بود، اگر همه API های خود را برای دسترسی به KVStore مهاجرت کنند، زمان و تلاش زیادی را با ارزش افزایشی بسیار کمی می طلبید.

ما تصمیم گرفتیم در عوض اکثر مشتریان Terrapin را به طور یکپارچه مهاجرت کنیم: برای کاربرانی که با Terrapin API تماس می‌گیرند هیچ تغییری لازم نیست، اما بدون اطلاع تماس‌گیرندگان، سرویس Terrapin API با یک کتابخانه KVStore API تعبیه‌شده برای بازیابی داده‌ها از Rockstore افزوده شد. و از آنجایی که Terrapin یک سیستم بارگذاری دسته‌ای است، ما همچنین یک کلاس پایه مرکزی پیدا کردیم و گردش‌های کاری را تغییر مسیر دادیم تا داده‌ها را به جای Terrapin در Rockstore دوبار بارگذاری کنیم (و سپس در نهایت Terrapin را قطع کردیم).

نموداری که زیربخشی از نمودار قبلی را نشان می‌دهد که چهار سیستم ارزش کلیدی را نشان می‌دهد. در این نمودار، روی مشتریانی که با Rockstore و Terrapin API تماس می‌گیرند بزرگنمایی می‌کنیم و نشان می‌دهیم که با معرفی لایه‌ای بین Terrapin API و Terrapin leaf Storage که مشتریان را هدایت می‌کند تا به جای ذخیره برگ Rockstore تماس بگیرند، می‌توانیم بدون نیاز به مشتریان به انتقال داده دست یابیم. هر اقدامی

شکل 3: با معرفی یک لایه مسیریابی بین APIهای Terrapin و ذخیره‌سازی برگ Terrapin، می‌توانیم به انتقال داده دست یابیم و سیستم ذخیره‌سازی پرهزینه و کم‌پایدار Terrapin را برای تأثیر فوری کسب‌وکار حذف کنیم، بدون اینکه از مشتریان بخواهیم اقدامی انجام دهند. مبادله در اینجا بدهی فناوری و لایه غیرمستقیم است: ما اکنون از مشتریان می‌خواهیم که استفاده خود از Terrapin API را پاک کنند تا مستقیماً KVStore API را فراخوانی کنند.

از آنجایی که Rockstore نسبت به Terrapin عملکرد و مقرون به صرفه‌تر بود، کاربران شاهد کاهش 30 تا 90 درصدی تاخیر بودند. هنگامی که زیرساخت ذخیره سازی Terrapin را از کار انداختیم، شرکت همچنین شاهد صرفه جویی سالانه 7 میلیون دلاری بود، همه بدون نیاز کاربران به برداشتن انگشت (به استثنای چند مورد). معاوضه این است که ما اکنون مقداری بدهی فنی داریم تا اطمینان حاصل کنیم که کاربران با حذف APIهای Terrapin منسوخ شده و روی KVStore API کد خود را پاک می کنند تا دیگر لایه ای غیرمستقیم نداشته باشیم.

فاز 2: انتقال داده خواندن و نوشتن (تا حدی بدون درز)

سمت خواندن و نوشتن تصویر متفاوتی ارائه کرد: کمتر از 200 مورد استفاده برای مقابله وجود داشت، و تعداد سایت‌های تماس کمتر افراطی بود، اما ایجاد برابری ویژگی‌ها برای یک سیستم خواندن-نوشتن در مقابل فقط خواندن شامل توسعه‌های جدی بود. . Rockstore برای اینکه بتواند با UserMetaStore (در اصل HBase) همتراز باشد، به یک قالب جدید با ستون گسترده، حالت‌های سازگاری بیشتر، پشتیبانی از عکس فوری آفلاین و تضمین‌های دوام بالاتر نیاز داشت.

در حالی که تیم برای توسعه این ویژگی‌ها وقت گذاشت، ما تصمیم گرفتیم "گلوله را گاز بگیریم" و از همه کاربران بخواهیم از همان ابتدا از UserMetaStore's API به KVStore API مهاجرت کنند. مزیت انجام این کار این است که یک حرکت کم خطر و کم تلاش است. به لطف قدرت انتزاع، ما یک پروکسی معکوس را پیاده سازی کردیم به طوری که مشتریانی که به KVStore API حرکت می کنند در واقع هنوز UserMetaStore زیر سرپوش را فراخوانی می کنند. ( طراحی سایت سفارش طراحی سایت ) با ایجاد این تغییر کوچک در حال حاضر، مشتریان قراردادی ماندگار می‌خریدند که برای آینده قابل پیش‌بینی مجدداً به چنین تغییراتی نیاز نخواهد داشت.

نموداری که Rockstore و UserMetastore را در کنار یکدیگر نشان می‌دهد که هر دو توسط لایه KVStore API در بالا انتزاع شده‌اند. به مشتریان نشان داده می‌شود که از تماس مستقیم UMS API به تماس با KVStore API، که می‌تواند درخواست‌ها را به UMS و Rockstore پراکسی کند، حرکت می‌کند و امکان مهاجرت زیر سر خود را فراهم می‌کند.

شکل 4: به جای اتخاذ همان رویکردی که با Terrapin در شکل 3 انجام دادیم، تصمیم گرفتیم که از مشتریان بخواهیم API های خود را از قبل منتقل کنند، برای یکسان سازی سیستم های ذخیره سازی خواندن-نوشتن منطقی تر است. هنگامی که مشتریان به لایه انتزاعی KVStore API ما رفتند، ما آزاد بودیم که داده‌های آنها را از UserMetaStore به Rockstore منتقل کنیم.

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

جسیکا چان | مدیر مهندسی، MySQL و ذخیره‌سازی کلید ارزش

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

پس چرا تیم سیستم‌های ارزش کلیدی در پینترست انتقال دو ساله بی‌درنگ تمام داده‌های ارائه‌دهنده کلید-مقدار آنلاین ما به یک سیستم ذخیره‌سازی واحد را آغاز کرد؟ چون هزینه مهاجرت نکردن خیلی زیاد بود. در سال 2019، Pinterest چهار سیستم ارزش کلیدی جداگانه داشت که متعلق به تیم های مختلف با API ها و ویژگی های مختلف بود.( انجام پروژه متلب انجام پروژه های متلب ) این منجر به تلاش‌های توسعه‌ای تکراری، تعداد بالای سربار عملیاتی و تعداد حوادث و سردرگمی در بین مشتریان مهندسی شد.

در یکپارچه سازی تمام موارد استفاده از بیش از 500 مورد ارزش کلیدی Pinterest (بیش از 4PB داده منحصر به فرد با 100Ms QPS) در یک رابط واحد، نه تنها دستاوردهای بزرگی در کاهش پیچیدگی سیستم و کاهش سربار عملیاتی به دست آوردیم، بلکه به 40-90 رسیدیم. درصد بهبود عملکرد با انتقال به کارآمدترین موتور ذخیره‌سازی، و با حرکت به سمت بهینه‌ترین معماری تکرار و نسخه‌سازی، میزان قابل توجهی در هزینه‌های شرکت در سال صرفه‌جویی کردیم.

در این پست وبلاگ، ما سه نوآوری (از میان بسیاری دیگر) را انتخاب کردیم که به ما کمک کرد تا همه این پیروزی ها را بدست آوریم.

اما ابتدا مقداری پیشینه

قبل از این تلاش، پینترست چهار سیستم ذخیره سازی با ارزش کلید داشت:

    Terrapin: ذخیره‌سازی فقط خواندنی، دسته‌ای و با ارزش کلیدی که در Pinterest ساخته شده و در طراحی برنامه‌های فشرده داده مبتنی بر HDFS ارائه شده است.

    Rockstore: یک ذخیره‌سازی با ارزش کلید چند حالته (فقط خواندن، خواندن، نوشتن، پخش-نوشتن) همچنین در Pinterest ساخته شده است، بر اساس چارچوب متن‌باز Rocksplicator، نوشته شده در C++، و با استفاده از RocksDB به عنوان یک موتور ذخیره‌سازی.

    UserMetaStore: یک ذخیره‌سازی با ارزش کلید خواندن و نوشتن با یک API ساده‌شده در بالای HBase

    Rocksandra: یک ذخیره‌سازی خواندنی-نوشتنی با ارزش کلیدی مبتنی بر نسخه‌ای از Cassandra که از RocksDB در زیر کاپوت استفاده می‌کرد.

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

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

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

نوآوری 1: انتزاعات API به ما این امکان را می دهد که داده های مشتری را به طور یکپارچه منتقل کنیم

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

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

نموداری که 4 مجموعه از مشتریان را نشان می دهد که هر مجموعه API هر یک از 4 سیستم ارزش کلیدی را در Pinterest فراخوانی می کند: Rockstore، Terrapin، UMS و Rocksandra. هر سیستمی در سطح بالایی نشان داده می‌شود که دارای معماری‌های زیربنایی متفاوتی است، که نشان می‌دهد حتی تصمیم‌گیری به‌عنوان مشتری در مورد استفاده از کدام یک پیچیده است.

شکل 1: چهار سیستم ارزش کلیدی مجزا در پینترست، هر کدام دارای API های خاص خود، مجموعه ای از ویژگی های منحصر به فرد و معماری های زیربنایی، و درجات مختلف عملکرد و هزینه

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

نموداری که مجموعه‌ای از کاربران را نشان می‌دهد که یک KVStore API را فراخوانی می‌کنند، که با یک معماری موتور ذخیره‌سازی Key Value مرتبط است. این مقایسه سادگی نسبی را نشان می دهد