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