پایگاه داده TimescaleDB

داده های سری زمانی متفاوت هستند!

مشکل اصلی در رابطه با پایگاه داده های سری زمانی از جایی شروع شد که شرکت IBMدر سال ۱۹۷۰، Seminal System R را راه انداخت و از پایگاه داده های رابطه ای برای پردازش تراکنش های آنلاین (OLTP) استفاده شد.

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

در داده های سری زمانی ، با جریان پیوسته‌ای از داده‌ها و یا اندازه‌گیری‌ها (در مورد حسگرها) مواجه هستیم که در همه آنها، عملیات اصلی مورد نیاز، اضافه کردن “اطلاعات جدید” به پایگاه‌داده به صورت پیوسته است.

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

در OLTP یا داده‌های تراکنش محور :

در داده‌های سری زمانی:

راه حل پایگاه داده‌های رابطه‌ای برای پردازش سری زمانی در پایگاه داده TimescaleDB

در شکل زیر راه حل استاندارد اولیه پایگاه داده های رابطه ای برای پردازش جریان داده ای و ایده نوین اَبَرجدول در TimescaleDBدیده می شود. در راه حل اولیه که همان استفاده از ایندکس‌های B+‌است، بخشی از نودهای میانی، در حافظه نگهداری می‌شوند تا فرآیند جستجو و بازیابی اطلاعات سرعت مناسب داشته باشد اما در رهیافت جدید TimescaleDB، داده‌ها به بخش‌ها یا Chunkهایی تقسیم و ذخیره می‌شوند و همواره آخرین بخش‌ها در حافظه نگهداری می‌شود. کاربران از طریق اَبَرجدول‌ها به این بخش‌ها دسترسی خواهند داشت.

به عبارت دقیق‌تر، در پایگاه داده TimescaleDBکه قصد دارد از پایگاه‌داده رابطه‌ای پستگرس برای ذخیره داده‌های سری زمانی به نحو موثر استفاده کند، از مفهوم Hyper table و Chunk استفاده می شود. یک جدول مجازی یا اَبَرجدول، در واقع یک تجرید یا یک دید مجازی از همه جداول منفردی است که داده ها را در خود جای داده اند. این جداول منفرد تشکیل دهنده یک اَبَرجدول، chunk نامیده می شوند.

هر Chunkدر یک جدول پایگاه داده داخلی (به عنوان یک جدول معمولی) ذخیره می‌شود، بنابراین ایندکس ها فقط با اندازه هر Chunkرشد می کنند و نه به اندازه کل. در HyperTableاز آنجا که داده‌‌ها معمولاً در یک بازه محدود (چند ثانیه قبل یا بعد از زمان جاری سیستم بسته به تاخیر یا عدم تنظیم بودن ساعت دستگاه‌ها) وارد می‌شوند، می‌توان همواره آخرین Chunkرا در حافظه نگه‌ داشت. با این‌کار  از یک Swap  پرهزینه به دیسک جلوگیری می شود.

 مزایای Chunking

از آنجا که هریک از این chunk ها به صورت جدولهایی در پایگاه داده ذخیره می شوند، و Query Plannerاز محدوده chunkها آگاه است (اندیس زمان و مکان)، Query Planner می تواند به سرعت تعیین کند که کدام داده عملیاتی متعلق به کدام chunk است. این موضوع می تواند هم برای درج سطرها، وهم برای انتخاب مجموعه ای از chunkها که برای اجرای کوئری مورد نیاز است، استفاده شود.

منبع:

https://blog.timescale.com/blog/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c/

مدیریت سرور پشتیبانی و مشاوره – ثبت دامنه