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

همانطور که بودا گفت: "همه چیزهای شرطی ناپایدار هستند."

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

فهرست مطالب

زمان زندگی (TTL) در سیستم های توزیع شده چیست؟

نحوه استفاده از TTL در صف پیام (AWS SQS)

نحوه استفاده از TTL در سیستم های ذخیره سازی اشیاء (AWS S3)

نحوه استفاده از TTL در پایگاه داده (AWS DynamoDB)

نحوه استفاده از TTL در معماری مبتنی بر رویداد

خلاصه

زمان زندگی (TTL) در سیستم های توزیع شده چیست؟

همانطور که از نام آن پیداست، TTL مقدار زمانی است که یک قطعه داده مرتبط می ماند یا در یک سیستم توزیع شده یا یک جزء از یک سیستم توزیع شده ذخیره می شود. یک TTL ممکن است روی هر قطعه داده ای که به طور نامحدود مورد نیاز نیست تنظیم شود.

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

TTL کجا معنا دارد؟

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

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

داده‌های تجزیه و تحلیل : اکثر سیستم‌های مقیاس بزرگ، اگر نگوییم همه، انواعی از معیارها را ذخیره می‌کنند که به تجزیه و تحلیل مواردی مانند تأخیر، سلامت سیستم و معیارهای محصول از جمله موارد دیگر کمک می‌کنند. در تعداد زیادی از موارد، شما نمی خواهید این معیارها برای همیشه در سیستم ها ذخیره شوند. فقط داده های اخیر (مثلاً 60 روز یا 180 روز) ممکن است در بیشتر موارد مفید باشد. TTL روی داده در این مورد منطقی است، به خصوص اگر محدودیت هایی در حافظه داشته باشید.

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

برنامه های رسانه های اجتماعی با محتوای کوتاه مدت: برنامه های رسانه های اجتماعی با محتوای کوتاه مدت بسیار محبوب هستند و تصاویر/ویدئوهای ارسال شده اغلب کوتاه مدت هستند. در صورتی که این تصاویر برای آیندگان نیازی به ذخیره سازی نداشته باشند، می توانند از تنظیم TTL بر روی آنها بهره مند شوند. علاوه بر کارایی حافظه، به حفظ حریم خصوصی نیز کمک می کند.

کجا TTL معنی ندارد؟

در بخش بالا به چند مورد که TTL منطقی است نگاه کردیم. در مورد مواردی که TTL رایج نیست و مفید نیست چطور؟ بیایید به چند نمونه نگاه کنیم:

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

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

نحوه استفاده از TTL در صف پیام (AWS SQS)

AWS SQS یک راه حل صف بندی پیام توزیع شده است که ستون فقرات بسیاری از سیستم های توزیع شده همه کاره در سراسر جهان است. صف های پیام می توانند میلیاردها پیام را پردازش کنند و تقریباً به طور جهانی در سیستم های توزیع شده در سراسر جهان استفاده می شوند.

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

چه اتفاقی می‌افتد اگر از مصرف‌کنندگان یک صف پیام برای چند روز پشتیبان‌گیری شده باشد، یا پیام‌ها برای مدتی صرفاً مصرف نشده باشند، چه اتفاقی می‌افتد؟ ما این گزینه را داریم که یک زمان سفارشی برای زندگی در پیام های SQS تنظیم کنیم.

به طور پیش فرض، دوره نگهداری 4 روز است . حداکثر TTL در زمان نوشتن 14 روز است. پس مهم است که هنگام استفاده از AWS SQS برای طراحی سیستم ها، از محدودیت هایی مانند اینها آگاه باشید.

توجه داشته باشید که با AWS SQS، یک دوره نگهداری یک مجموعه در خود صف است و نه به صورت جداگانه برای هر پیام.

Boto یک AWS SDK برای پایتون است که به توسعه دهندگان امکان می دهد خدمات و منابع AWS را به صورت برنامه نویسی ایجاد، پیکربندی و مدیریت کنند. Boto به طور گسترده برای نمونه سازی، سیستم های تولید استفاده می شود و به طور کلی یک رابط کاربر پسند برای دسترسی به خدماتی مانند S3، EC2 و DynamoDB ارائه می دهد.

در اینجا یک قطعه کد با استفاده از Boto وجود دارد که به شما کمک می کند ویژگی MessageRetentionPeriod را که نام رسمی TTL در این زمینه است تنظیم کنید.

 sqs = boto3.client('sqs', aws_access_key_id=your_aws_access_key_id, aws_secret_access_key=aws_secret_access_key, region_name='your_region') # Set the desired retention period in seconds retention_period_seconds = 86400 # Example: 1 day # Set the queue attributes response = sqs.set_queue_attributes( QueueUrl=your_queue_url, Attributes={ 'MessageRetentionPeriod': str(retention_period_seconds) } )

وقفه دید در صف پیام (AWS SQS)

توجه داشته باشید که اگرچه وسوسه انگیز است که Visibility Timeout در SQS را به عنوان Time To Live در نظر بگیرید، اما اینها یکسان نیستند. Time To Live یا Retention Period با Visibility Timeout متفاوت است.

مهلت دید در عوض به دوره زمانی کوتاه تری اشاره دارد که طی آن یک پیام باید پردازش شود (پس از دریافت توسط مصرف کننده). در غیر این صورت، دوباره در صف SQS قرار می گیرد و دوباره برای مصرف کنندگان قابل مشاهده است و تعداد دریافت آن یک افزایش یافته است.

نحوه استفاده از TTL در سیستم های ذخیره سازی اشیاء (AWS S3)

AWS S3 همه کاره، که یک راه حل ذخیره اشیاء است، به کاربران این امکان را می دهد تا بر روی اشیاء ذخیره شده در سطل های S3، Time To Live را تنظیم کنند.

S3 با نحوه تنظیم TTLها روی اشیاء / سطل بسیار انعطاف پذیر است. می توانید قوانین چرخه حیات را تنظیم کنید تا مشخص کنید که چه اشیایی یا چه نسخه هایی از یک شی را می خواهید حذف کنید.

مدیریت چرخه عمر ذخیره سازی شما در وب سایت اسناد AWS مطالعه بسیار خوبی است.

نحوه استفاده از TTL در پایگاه داده (AWS DynamoDB)

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

TTL در DynamoDB یک رویکرد مقرون به صرفه را ارائه می دهد که به شما امکان می دهد مواردی را که دیگر مرتبط نیستند به طور خودکار حذف کنید. به صورت بومی پشتیبانی می شود و می توان آن را در کل جدول DynamoDB تنظیم کرد.

در اینجا یک قطعه کد وجود دارد که به شما امکان می دهد TTL را در جدول DynamoDB تنظیم کنید (دوباره با استفاده از Boto):

 ddb_client = boto3.client('dynamodb') # Enable Time To Live (TTL) on an existing DynamoDB table ttl_response = ddb_client.update_time_to_live( TableName=your_table_name, TimeToLiveSpecification={ 'Enabled': True, 'AttributeName': your_ttl_attribute_name } ) # Check for a successful status code in the response if ttl_response['ResponseMetadata']['HTTPStatusCode'] == 200: print("Time To Live (TTL) has been successfully enabled.") else: print(f"Failed to enable Time To Live (TTL)")

در اینجا، صفت your_ttl_attribute_name مشخصه‌ای است که DynamoDB به آن نگاه می‌کند تا مشخص کند که آیا آیتم باید حذف شود یا خیر. این ویژگی معمولاً در آینده روی مقدار زمانی تعیین می شود. وقتی به آن مهر زمانی رسید، DynamoDB مورد را از جدول حذف می کند.

نحوه استفاده از TTL در معماری مبتنی بر رویداد

تا اینجا ما درباره Time To Live و اینکه کجا می تواند مفید باشد صحبت کرده ایم. در مورد پیامدهای آن چطور؟ بسیاری از راه‌حل‌های مبتنی بر ابر، اعلان‌هایی را ارائه می‌کنند که می‌تواند نشان دهد که بخشی از داده واقعاً به پایان رسیده است و به شما امکان می‌دهد بر اساس انقضای آن داده، اقداماتی را انجام دهید.

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

نمودار زیر یک معماری ممکن را با کمی جزئیات بیشتر توضیح می دهد:

فرض کنید یک کاربر با کاربر دیگری پیام رد و بدل می کند. یک ورودی مربوط به یک پیام در ActiveMessageDB ذخیره می شود که برای سادگی، فرض می کنیم یک پایگاه داده NoSQL است که پیام ها را ذخیره می کند.

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

در نمودار بالا، رویداد توسط یک نمونه AWS Lambda انتخاب می‌شود و مقدار بسیار کمتری از داده‌ها در پایگاه داده دیگری MessageLogDB نوشته می‌شود که به اندازه ActiveMessageDB قابل دسترسی نیست. چیزی که ما دیدیم نمونه ای از معماری مبتنی بر رویداد است که با TTL همراه شده است.

خلاصه

TTL مدت زمانی است که یک قطعه داده مرتبط می ماند یا در یک سیستم توزیع شده یا یک جزء از یک سیستم توزیع شده ذخیره می شود.

TTL در مواردی که داده‌ها می‌توانند حذف شوند، منقضی شوند یا شکل آن بعد از مدت زمان مشخصی تغییر کند، منطقی است.

TTL محبوب است و به طور کلی بر روی بسیاری از سیستم های توزیع شده تنظیم می شود.

TTL را می توان با معماری رویداد محور برای تبدیل داده جفت کرد.

خبرکاو