پایگاه داده TimescaleDB

پایگاه داده TimescaleDB

مقدمه بر پایگاه داده TimescaleDB

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

تاکنون بیشتر ابزارهای تولید شده برای ذخیره و پردازش داده‌های سری زمانی، مبتنی بر مدل‌های داده‌ای NoSQL‌بوده است. دیتابیس‌های غیررابطه‌ای مختلفی توسعه داده شده اند که InfluxDB از معروف‌ترین آنهاست اما وجود یک دیتابیس رابطه‌ای کارآمد در این حوزه، به شدت احساس میشد. این نیاز باعث پاگرفتن پایگاه داده TimeScaleDb به عنوان یک افزونه بر روی پایگاه داده PostGreSQL شد.

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

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

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

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

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

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

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

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

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

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

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

  • Insertها در درجه اول اهمیت هستند.
  • نوشتن ها تصادفی نیست و در بازه زمانی اخیر انجام می شود. (زمان‌مند هستند و به ترتیب زمانی وارد می‌شوند)
  • کلید اصلی اغلب یک TimeStampاست و ممکن است علاوه بر TimeStampموارد دیگری نیز چون ServerID، ِDeviceID و … همراه با TimeStampباشد.

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

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

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

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

داده‌های سری زمانی و پایگاه داده TimescaleDB
داده‌های سری زمانی و پایگاه داده TimescaleDB  دز مقایسه با Postgresql

 مزایای 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/

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

نوشته های مشابه