TimescaleDB: داده‌های سری‌زمانی، روی قدرت PostgreSQL

زیرساخت سرویس، شامل اسکریپت نصب، محاسبهٔ هزینه و بخش مدیریت در پنل، ساخته شده است. اما ثبت سفارش تا زمانی که مخازن نصب و اولین راه‌اندازی واقعی به‌طور کامل آزمایش شود بسته است، تا هیچ مشتری‌ای برای سروری که نصبش کامل نمی‌شود هزینه ندهد.

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

هر جا که «زمان» محور اصلی داده باشد، TimescaleDB به کار می‌آید. چند نمونهٔ رایج:

hypertable مفهوم مرکزی TimescaleDB است. شما یک جدول معمولی با ستون زمان می‌سازید و با تابع create_hypertable آن را تبدیل می‌کنید. از آن به بعد INSERT و SELECT مثل قبل نوشته می‌شوند، اما دیتابیس فقط chunk‌هایی را می‌خواند که در بازهٔ زمانی query قرار دارند و حذف دادهٔ قدیمی هم به‌جای DELETE سنگین، با حذف کل chunk انجام می‌شود.

تابع time_bucket داده را به بازه‌های دلخواه مثل پنج دقیقه یا یک ساعت گروه‌بندی می‌کند و نوشتن گزارش‌های زمانی را ساده می‌کند. continuous aggregate نتیجهٔ این گروه‌بندی‌ها را به‌صورت پیوسته و افزایشی به‌روز نگه می‌دارد تا داشبورد هر بار کل داده را از نو حساب نکند. فشرده‌سازی ستونی هم برای chunk‌های قدیمی‌تر حجم دیسک را کم می‌کند؛ میزان آن به ساختار دادهٔ شما بستگی دارد.

نکتهٔ مهم در طراحی، انتخاب ستون‌هایی است که با آن‌ها فیلتر می‌کنید. اگر بیشتر query‌ها روی یک دستگاه یا یک سرور خاص زده می‌شوند، روی ترکیب شناسهٔ سری و زمان ایندکس بسازید و هنگام فعال کردن فشرده‌سازی، همان شناسه را به‌عنوان ستون segmentby معرفی کنید. با این کار هم query روی یک سری سریع می‌ماند و هم دادهٔ فشرده‌شده به‌خوبی گروه‌بندی می‌شود.

مشخصات زیر همان چیزی است که اسکریپت نصب آماده‌شده پیاده می‌کند:

هزینه مانند سایر دیتابیس‌های مدیریت‌شده ساعتی خواهد بود و از کیف پول کسر می‌شود: هزینهٔ سرور اختصاصی با اندازهٔ انتخابی به‌علاوهٔ هزینهٔ ثابت مدیریت. جدول زیر تعرفهٔ فعلی سامانه را نشان می‌دهد؛ چون سرویس هنوز فعال نشده، این ارقام تا زمان راه‌اندازی ممکن است تغییر کنند. معادل ماهانه بر مبنای ۷۳۰ ساعت است.

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

سه گزینه برای ذخیرهٔ دادهٔ زمانی کنار هم؛ انتخاب به حجم داده و نوع query بستگی دارد:

لازم نیست برای شروع منتظر بمانید. اگر حجم داده کم است، می‌توانید با PostgreSQL مدیریت‌شده و یک جدول معمولی با ایندکس روی ستون زمان شروع کنید. وقتی TimescaleDB فعال شد، داده را با pg_dump منتقل و جدول را به hypertable تبدیل می‌کنید؛ query‌های شما تغییر زیادی نمی‌کنند.

اگر از روز اول به hypertable و continuous aggregate نیاز دارید، یک سرور ابری بگیرید و PostgreSQL و TimescaleDB را خودتان روی آن نصب کنید. در این حالت نگه‌داری، تنظیم و بکاپ با خود شماست، اما کنترل کامل هم دارید.

احراز هویت با scram-sha-256 انجام می‌شود که روش امن فعلی PostgreSQL برای نگه‌داری رمز است و رمز کاربر postgres به‌صورت تصادفی ساخته می‌شود. اطلاعات اتصال پس از ساخت از پنل دریافت می‌شود و رمز در پنل رمزنگاری‌شده نگه‌داری خواهد شد.

برای هر اپلیکیشن یا جمع‌آوری‌کنندهٔ داده یک نقش جداگانه با کمترین دسترسی لازم بسازید؛ مثلاً نقشی که فقط حق INSERT روی جدول متریک دارد برای agent‌های حسگر، و نقشی با فقط SELECT برای داشبورد. این کار با دستورهای استاندارد CREATE ROLE و GRANT انجام می‌شود. برای ساخت رمزهای قوی از ابزار تولید رمز کمک بگیرید.

دادهٔ سری زمانی معمولاً سریع رشد می‌کند، پس از ابتدا تصمیم بگیرید هر داده را چه مدت نگه دارید. TimescaleDB با سیاست retention می‌تواند chunk‌های قدیمی‌تر از یک بازهٔ مشخص را خودکار حذف کند و با continuous aggregate خلاصهٔ آن‌ها را برای گزارش‌های بلندمدت نگه دارد.

بکاپ شبانهٔ خودکار در طراحی فعلی برای این سرویس پیش‌بینی نشده است. با pg_dump و فرمت custom به‌صورت دوره‌ای از دیتابیس خروجی بگیرید و فایل را در فضای ذخیره‌سازی ابری نگه دارید. برای بازگردانی hypertableها، پیش از pg_restore تابع timescaledb_pre_restore و پس از آن timescaledb_post_restore را اجرا کنید.

اگر داده در PostgreSQL معمولی است، جدول را با pg_dump منتقل کنید و سپس با create_hypertable و گزینهٔ migrate_data آن را به hypertable تبدیل کنید. برای جدول‌های بزرگ بهتر است hypertable خالی بسازید و داده را با INSERT ... SELECT یا COPY در چند مرحله منتقل کنید.

از InfluxDB یا سامانه‌های دیگر، ساده‌ترین مسیر خروجی گرفتن به CSV و بارگذاری با دستور COPY است. پیش از انتقال، نام‌گذاری ستون‌ها و نوع دادهٔ زمان (timestamptz) را مشخص کنید تا منطقهٔ زمانی ایران و تغییرات ساعت در گزارش‌ها دردسرساز نشود.

سرویس هنوز قابل سفارش نیست. پس از فعال شدن هم هر instance تک‌نودی است و replica‏، failover خودکار، بکاپ خودکار و بازیابی به نقطهٔ زمانی ندارد. نسخهٔ ارائه‌شدهٔ PostgreSQL فقط ۱۷ است و تغییر اندازه پس از ساخت از پنل ممکن نیست.

افزونهٔ TimescaleDB روی PostgreSQL مدیریت‌شده فعلی نصب نمی‌شود؛ این دو سرویس جدا هستند. اگر به چند نود یا تنظیمات خاص نیاز دارید، کلاستر اختصاصی یا نصب روی سرور ابری خودتان گزینهٔ مناسب‌تری است.