داده سری زمانی در لبه؛ چه چیزی را نگه داریم، چه چیزی را بفرستیم و چه چیزی را دور بریزیم

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

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

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

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

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

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