نقشه راه GIS

درخواست مشاوره

09120049370

8 صبح تا 12 شب

09120049370

Telegram Whatsapp Youtube
کاربرد جی ای اس

 

خلاصه

:

با استقرار گسترده منابع حسگر زمین، هوا و فضا (اینترنت اشیا یا اینترنت اشیا، شبکه‌های اجتماعی، شبکه‌های حسگر)، کاربردهای یکپارچه داده‌های مکانی بی‌درنگ از حسگرهای همه‌جا، به ویژه در حوزه امنیت عمومی و شهر هوشمند، در حال تبدیل شدن به مسائل چالش برانگیز سیستم اطلاعات جغرافیایی سنتی (GIS) عمدتاً داده های مکانی گسسته زمانی را با استفاده از سیستم مدیریت پایگاه داده زبان پرس و جو ساختاریافته (SQL) مدیریت می کند و بر پرس و جو و بازیابی داده های جغرافیایی تاریخی عظیم روی دیسک تأکید می کند. این قابلیت آن را برای دسترسی در حین پرواز به داده های مکانی هم زمان برای تجزیه و تحلیل آنلاین در زمان واقعی محدود می کند. این مقاله یک رویکرد سازماندهی و مدیریت پایگاه داده ترکیبی با پایگاه داده های رابطه ای SQL (RDB) و نه تنها پایگاه های داده SQL (NoSQL) (شامل پایگاه داده حافظه اصلی، MMDB، و سیستم فایل های توزیع شده، DFS) پیشنهاد می کند. این رویکرد ترکیبی از مزایای NoSQL و SQL DBMS برای دسترسی بلادرنگ به داده‌های ورودی و نتایج تجزیه و تحلیل ساخت‌یافته در جریان استفاده کامل می‌کند که می‌تواند الزامات افزایش تحلیل پیوند داده‌های بزرگ مکانی-زمانی را برآورده کند. MMDB دسترسی بلادرنگ به آخرین داده‌های ورودی مانند وب حسگر و اینترنت اشیا را تسهیل می‌کند و از پرس و جوی بلادرنگ برای تجزیه و تحلیل جغرافیایی آنلاین پشتیبانی می‌کند. RDB اطلاعات تغییر مانند ویژگی های چند وجهی و رویدادهای غیرعادی استخراج شده از داده های ورودی بلادرنگ را ذخیره می کند. DFS روی دیسک، داده های عظیم مکانی را مدیریت می کند، و معماری ذخیره‌سازی قابل توسعه و زمان‌بندی توزیع‌شده یک پایگاه داده NoSQL، الزامات عملکرد ذخیره‌سازی افزایشی و دسترسی همزمان چند کاربره را برآورده می‌کند. مطالعه موردی نظارت تصویری جغرافیایی (GeoVideo) بر امنیت عمومی برای اثبات امکان‌سنجی این سازماندهی و رویکرد مدیریت ترکیبی ارائه شده است.
کلید واژه ها: 

داده های مکانی در زمان واقعی ؛ NoSQL ; RDBMS ; مدیریت داده ها ؛ امنیت عمومی ؛ پایگاه داده های ترکیبی ; GeoVideo

 

1. معرفی

با استقرار گسترده منابع حسگر زمین، هوا و فضا (اینترنت اشیا یا اینترنت اشیا، شبکه‌های اجتماعی و شبکه‌های حسگر)، کاربردهای یکپارچه داده‌های مکانی بی‌درنگ از حسگرهای همه‌جا به مسائل چالش برانگیز تبدیل شده‌اند، به ویژه در مورد عمومی. مدیریت امنیت و مدیریت تسهیلات شهر هوشمند و ویژگی‌های موجود دسته‌های 4 ولت (حجم، سرعت، تنوع و ارزش) [ 1 ، 2]. با توجه به پیشرفت سریع ابزارهای جمع‌آوری داده‌ها و تکنیک‌های اینترنتی، نسل جدیدی به نام «عصر داده‌های بزرگ» ظاهر شده و تأثیر قابل‌توجهی بر تحقیقات علوم فضایی گذاشته است. چالش‌های بزرگ در بایگانی، بازیابی و استخراج داده‌های حسگر بدون ساختار و مجموعه داده‌های تولید شده توسط کاربر به طور موثر برای درک و درک آنی باقی می‌ماند [ 3 ، 4 ].
سیستم اطلاعات جغرافیایی سنتی (GIS) با استفاده از تداوم داده‌های جغرافیایی و به دنبال آن توسعه و ادغام بیشتر در پایگاه‌های اطلاعاتی رابطه‌ای تجاری (RDBs) مانند Oracle و MySQL، «عکس فوری» از جهان جغرافیایی را در یک لحظه در قالبی ساختاریافته نقشه‌برداری می‌کند. توابع کاربردی درخواستی بر روی سوابق پایگاه داده “منسوخ” [ 5 ] عمل می کنند. به دلیل تنگنای ورودی/خروجی (I/O) و تأخیر بالا برای حفظ ثبات در RDB، عکس فوری «جاری» در پایگاه‌های اطلاعاتی GIS همچنان با داده‌های ورودی بلادرنگ از دنیایی که دائماً در حال تغییر است، هماهنگ نیست. [ 6 ، 7]. این توانایی آن را برای دسترسی به اطلاعات مکانی بی‌درنگ برای تحلیل آنلاین در زمان واقعی محدود می‌کند. در همین حال، RDB به سختی می‌تواند قابلیت ذخیره‌سازی کافی را در مدیریت داده‌های مکانی بزرگ با رشد سریع فراهم کند، زیرا طرح گسترش سیستم «مقیاس‌سازی» است، که نیازمند ارتقاء مکرر دستگاه‌های ذخیره‌سازی است [8 ] . علاوه بر این، حالت «اول ذخیره، سپس محاسبه» ورودی بدون ساختار افزایشی داده‌های بزرگ را به صورت چند تایی با مقدار زیادی داده‌های نامعتبر یا تکراری ذخیره می‌کند، که نه تنها فشار قابل‌توجهی بر ذخیره‌سازی افزایشی و زمان‌بندی کارآمد وارد می‌کند، بلکه نمی‌تواند الزامات را برآورده کند. افزایش تحلیل پیوند داده‌های بزرگ مکانی-زمانی در مطالعات GIS مبتنی بر داده‌های بزرگ [ 9 ، 10]. بنابراین، روش‌های سنتی سازماندهی و مدیریت داده‌های مکانی با استفاده از پایگاه‌های اطلاعاتی GIS مبتنی بر RDB نمی‌توانند از تحلیل آنلاین در زمان واقعی پشتیبانی کنند.
برای رسیدگی به مسائل فوق، نه تنها سیستم های مدیریت پایگاه داده SQL (NoSQL) (DBMS) به عنوان یک راه حل جدید در حال ظهور هستند. پایگاه داده های اصلی NoSQL را می توان از نظر مدل ذخیره سازی داده به چهار دسته طبقه بندی کرد: ذخیره کلید-مقدار، ذخیره اسناد، ذخیره ستون و ذخیره گراف. ظهور NoSQL DBMS با تقاضای فوری برای مدیریت تولید مداوم، حجم زیاد و فرمت‌های بدون ساختار داده‌های بلادرنگ، با ویژگی‌های اصلی دسترسی کم تأخیر، توسعه‌پذیری و هزینه کم سخت‌افزار/نرم‌افزار/کار همراه بود [ 11 , 12 ، 13]. برای مثال، هائو و همکاران. از سیستم فایل Hadoop (HDFS) برای ذخیره داده های جریان چندحسگر در زمان واقعی از اینترنت اشیا برای ردیابی اشیاء، مانند ردیابی افراد در فضاهای داخلی با استفاده از شناسایی فرکانس رادیویی (RFID) استفاده کرد [14 ] . کانگ و همکاران یک مدل مخزن داده یکپارچه با حسگر را با استفاده از MongoDB برای ادغام منابع داده ناهمگن اینترنت اشیا مانند RFID، حسگر و سیستم های موقعیت یابی جهانی (GPS) و بهینه سازی یک کلید خرد برای به حداکثر رساندن سرعت پرس و جو و توزیع یکنواخت داده بر روی سرورهای داده پیشنهاد کرد [15 ] . وان و همکاران عملکرد خواندن/نوشتن داده‌های حسگر را بین Cassandra و MongoDB مقایسه کرد و به این نتیجه رسید که Cassandra برای مقادیر نسبتاً بزرگ‌تری از داده‌های حسگر انتخاب خوبی است، در حالی که MongoDB برای مقادیر کمتری از داده‌های حسگر خوب است [16] .]. کیم و همکاران از Redis برای حل ترافیک بالای خدمات وب در دسترسی همزمان استفاده کرد [ 17 ]. اگرچه این DBMS های NoSQL مزایای نوشتن/پرس و جوی با کارایی بالا را برای داده های ورودی زمان واقعی حجم زیاد ارائه می دهند، یک رویکرد جدید برای سازماندهی داده های مکانی بلادرنگ برای مقابله با داده های ورودی بلادرنگ و در حال رشد سریع مورد نیاز است. نتایج تجزیه و تحلیل پرواز برای پردازش جغرافیایی بلادرنگ.
در مقایسه با داده‌های ورودی بلادرنگ، که مشکلات مربوطه عمدتاً بر تأخیر کم نوشتن و جستجوی داده‌ها با حجم زیاد و همچنین ذخیره‌سازی سریع در حال رشد متمرکز است، مشکلاتی که باید برای رسیدگی به تجزیه و تحلیل در حین پرواز حل شوند. نتایج عمدتاً به توانایی پرس و جوهای انعطاف پذیر و پردازش تراکنش مربوط می شود. اگرچه RDB برای ذخیره سازی داده های ساخت یافته و پردازش تراکنش برجسته هستند، اما به سختی می توانند عملکرد کافی را در مدیریت داده های بزرگ با رشد سریع به دلیل طرح گسترش سیستم “مقیاس سازی” ارائه دهند [15] .]. پایگاه‌های داده NoSQL به عنوان مکمل RDB مجموعه‌ای از ویژگی‌هایی را ارائه می‌کنند که RDB نمی‌تواند ارائه کند، مانند مقیاس‌پذیری افقی، حافظه و نمایه توزیع‌شده، اصلاح دینامیکی طرح‌واره داده، و غیره. آنها می‌توانند داده‌های بدون ساختار را به‌طور کارآمد ذخیره کنند، زیرا قابلیت تغییر طرحواره داده‌ها آسان است. به دلیل طرح “scale-out” به هزینه گسترش سرور کمتری نسبت به RDB نیاز دارند. با این حال، پایگاه داده NoSQL فاقد محدودیت اتمی کامل، سازگاری، جداسازی و دوام (ACID) و پشتیبانی از پرس و جوهای پیچیده، پردازش تراکنش و عملیات پیوستن است [18 ] . بنابراین، امکان استفاده مصنوعی از ویژگی‌های پایگاه‌های داده NoSQL و SQL برای پشتیبانی از ذخیره‌سازی، پرس و جو و محاسبات بی‌درنگ برای داده‌های مکانی بلادرنگ وجود دارد.
برای ایجاد پایه‌های تحلیل آنلاین GIS در زمان واقعی، این دست‌نوشته یک رویکرد سازماندهی و مدیریت پایگاه داده ترکیبی از پایگاه‌های داده RDB و NoSQL پایگاه داده SQL (شامل پایگاه داده حافظه اصلی، MMDB، و سیستم‌های فایل توزیع شده، DFS) ارائه می‌کند. این رویکرد ترکیبی از مزایای NoSQL و SQL DBMS برای دسترسی بلادرنگ به داده‌های ورودی و نتایج تجزیه و تحلیل ساخت‌یافته در جریان استفاده کامل می‌کند. MMDB دسترسی بلادرنگ به آخرین داده‌های ورودی مانند وب حسگر و اینترنت اشیا را تسهیل می‌کند و از پرس و جوی بلادرنگ برای تجزیه و تحلیل جغرافیایی آنلاین پشتیبانی می‌کند. RDB اطلاعات تغییر مانند ویژگی های چند وجهی و رویدادهای غیرعادی استخراج شده از داده های ورودی بلادرنگ را ذخیره می کند. DFS روی دیسک، داده های عظیم مکانی را مدیریت می کند، و معماری ذخیره‌سازی قابل توسعه و زمان‌بندی توزیع‌شده یک پایگاه داده NoSQL، الزامات عملکرد ذخیره‌سازی افزایشی و دسترسی همزمان چند کاربره را برآورده می‌کند. رویکرد پیشنهادی قابلیت مدیریت داده‌های مکانی با حجم بالا را ارائه می‌دهد و الزامات افزایش تحلیل پیوند داده‌های بزرگ مکانی-زمانی را برآورده می‌کند. این تحقیق به جامعه تحقیقاتی کمک می کند تا مطالعات GIS مبتنی بر داده های بزرگ را به روشی کارآمدتر و سازنده تر انجام دهند. تجزیه و تحلیل موردی نظارت تصویری جغرافیایی (GeoVideo) از امنیت عمومی برای اثبات امکان‌سنجی این سازماندهی و رویکرد مدیریت ترکیبی ارائه شده است. رویکرد پیشنهادی قابلیت مدیریت داده‌های مکانی با حجم بالا را ارائه می‌دهد و الزامات افزایش تحلیل پیوند داده‌های بزرگ مکانی-زمانی را برآورده می‌کند. این تحقیق به جامعه تحقیقاتی کمک می کند تا مطالعات GIS مبتنی بر داده های بزرگ را به روشی کارآمدتر و سازنده تر انجام دهند. تجزیه و تحلیل موردی نظارت تصویری جغرافیایی (GeoVideo) از امنیت عمومی برای اثبات امکان‌سنجی این سازماندهی و رویکرد مدیریت ترکیبی ارائه شده است. رویکرد پیشنهادی قابلیت مدیریت داده‌های مکانی با حجم بالا را ارائه می‌دهد و الزامات افزایش تحلیل پیوند داده‌های بزرگ مکانی-زمانی را برآورده می‌کند. این تحقیق به جامعه تحقیقاتی کمک می کند تا مطالعات GIS مبتنی بر داده های بزرگ را به روشی کارآمدتر و سازنده تر انجام دهند. تجزیه و تحلیل موردی نظارت تصویری جغرافیایی (GeoVideo) از امنیت عمومی برای اثبات امکان‌سنجی این سازماندهی و رویکرد مدیریت ترکیبی ارائه شده است.
ادامه مقاله به شرح زیر تدوین شده است. بخش 2 رویکرد سازماندهی و مدیریت ترکیبی NoSQL-SQL را تشریح می کند. بخش 3 داده های GeoVideo را در زمان واقعی به عنوان یک مطالعه موردی برای نشان دادن جریان داده و الگوریتم های کلیدی در رویکرد پیشنهادی می گیرد. بخش 4 چندین مجموعه آزمایش مقایسه ای را گزارش می کند که برای نشان دادن مزایای رویکرد پیشنهادی انجام شده است. بخش 5 نتیجه گیری مطالعه و کاربردهای این تحقیق را تشریح می کند.

2. رویکرد سازماندهی و مدیریت ترکیبی NoSQL–SQL برای داده‌های مکانی بی‌درنگ

2.1. NoSQL–SQL DBMS Hybrid Storage Architecture

این بخش معماری ذخیره‌سازی رویکرد پیشنهادی را توصیف می‌کند که از مزایای NoSQL و SQL DBMS برای دسترسی بلادرنگ به داده‌های ورودی و نتایج تحلیل ساخت‌یافته در جریان استفاده کامل می‌کند. مفهوم نوآورانه اصلی رویکرد پیشنهادی، مدیریت جریان داده اطلاعات تغییرات مکانی-زمانی است و از عنصر تغییر برای اتصال سه پایگاه داده استفاده می‌کند. شکل 1 چارچوب سه نوع NoSQL-SQL DBMS را نشان می دهد. سه زیرساخت نقش های متفاوتی به شرح زیر انجام می دهند:

(1)
MMDB ساختاری برای دسترسی است. این برنامه از نوشتن بلادرنگ و پرس و جو از آخرین داده های ورودی پشتیبانی می کند و داده های تاریخی را پس از پیش پردازش به صورت دسته ای در DFS همگام می کند.
(2)
RDB بخش ثانویه است. نتایج تجزیه و تحلیل ساخت‌یافته و تغییر اطلاعات استخراج‌شده از داده‌های ورودی را ذخیره می‌کند، از مکانیزم ماشه‌ای برای شناسایی رویدادهای غیرعادی در زمان واقعی استفاده می‌کند، و به‌طور آنی رویدادها را به اشیاء و ماژول‌های جغرافیایی مرتبط با مکانیسم پیام «اشتراک/انتشار» تحویل می‌دهد. برای پردازش جغرافیایی پویا
(3)
DFS بخش اصلی است. این داده های مکانی تاریخی با حجم زیاد افزایشی را با توزیع یکنواخت و یک محیط ذخیره سازی مقیاس پذیر ذخیره می کند.

2.1.1. MMDB برای دسترسی در زمان واقعی

با انباشته شدن داده‌های مکانی عظیم بلادرنگ، کارایی دسترسی برای پردازش جغرافیایی بلادرنگ به دلیل تنگناهای ورودی/خروجی و مصرف زیاد برای نگهداری شاخص مکانی-زمانی به شدت کاهش می‌یابد. علاوه بر این، داده‌های مکانی-زمانی اصلی دارای یک مقدار داده توزیع‌شده ناهموار با مقدار زیادی داده‌های نامعتبر یا تکراری هستند که نیاز به پیش پردازش دارند، به عنوان مثال استخراج اطلاعات، پاک‌سازی داده‌ها و حذف موارد تکراری. به عبارت دیگر، فقط داده‌های مکانی-زمانی معتبر بی‌درنگ تکرار نشده ارزش سریال‌سازی را دارند. حالت سنتی «ابتدا ذخیره، سپس محاسبه» در SQL DBMS مقیم دیسک، داده‌های بزرگ ورودی اصلی را ابتدا به صورت چند تایی ذخیره می‌کند، سپس داده‌های فعلی را برای اجرای پیش‌پردازش و در نهایت به‌روزرسانی داده‌های از پیش پردازش شده، جستجو می‌کند، که نه تنها فشار زیادی بر توان عملیاتی دیسک وارد می‌کند. ،
سرعت خواندن/نوشتن حافظه به طور قابل توجهی سریعتر از دیسک است، بنابراین حافظه اصلی انتخاب خوبی برای مدیریت داده های ورودی بلادرنگ برای پرس و جو و پیش پردازش در یک محدودیت زمانی خاص است. به دلیل منابع محدود حافظه و یک جریان داده بی نهایت، ذخیره کل جریان داده در فضای حافظه محدود غیرممکن است. بنابراین، یک پنجره کشویی برای ذخیره جدیدترین داده های توالی و همگام سازی داده های از پیش پردازش شده در ذخیره سازی دائمی در دسته باز می شود. در مقایسه با حافظه نهان، MMDB دارای مزایای پایداری قوی، همزمانی بالا و مقیاس پذیری است. با این حال، MMDB موجود (مانند Redis و Cassandra) به پایگاه داده NoSQL تعلق دارد که با ثبات ضعیف مشخص می شود، به این معنی که فقط می تواند داده های اخیر را جستجو کند، نه درج داده ها در زمان واقعی. در مجموع، می توانیم از یک طول ثابت استفاده کنیم،

2.1.2. DFS برای داده های تاریخی افزایشی

حجم وسیعی از داده های مکانی-زمانی “منسوخ” باید روی دیسک ذخیره شود تا از داده کاوی بیشتر در آینده پشتیبانی شود. با تجمع داده‌های افزایشی، محیط‌های ذخیره‌سازی متمرکز سنتی RDB مشکلات تنگناهای ورودی/خروجی و مقیاس‌پذیری غیرمقیاس را دارند که برای ذخیره‌سازی در مقیاس بزرگ داده‌های مکانی-زمانی مناسب نیستند. به عنوان یک نوع معمولی از پایگاه‌های داده NoSQL، DFS پرکاربرد (مانند سیستم فایل Hadoop، HDFS و MongoDB) دارای معماری سیستم مقیاس‌پذیر متشکل از چندین سرور ذخیره‌سازی است که می‌تواند فشار بار ذخیره‌سازی و زمان‌بندی داده‌های مکانی-زمانی عظیم را متعادل کند. بسیاری از آزمایش‌ها ثابت کرده‌اند که DFS مزایای عملکردی بیشتری نسبت به RDB دارد.
کلید خرد عامل اساسی برای تعیین توزیع یکنواخت ذخیره سازی داده بین چندین سرور ذخیره سازی در DFS است. با در نظر گرفتن Mongos خوشه MongoDB، انتخاب کلید خرده مناسب با محدوده اعداد بزرگ مانند مهر زمانی می تواند توانایی توزیع بهتری را ارائه دهد. ایجاد یک شاخص صعودی بر روی مهر زمانی می‌تواند آخرین داده‌ها را در حافظه پنهان نگه دارد و کارایی پرس و جو داده‌های بلادرنگ را بهبود بخشد. علاوه بر این، تجمیع داده‌های مکانی مرتبط با زمانی- مکانی در یک منطقه در همان سرور ذخیره‌سازی می‌تواند کارایی پیش‌زمان‌بندی پرس‌وجوهای مکانی نزدیک‌ترین همسایه را بهبود بخشد. انتخاب کلید ترکیبی متشکل از کلید صعودی (مانند مهر زمانی) و کلید جستجو (مانند هویت شبکه فضایی، ID) می تواند داده های محدوده مکانی-زمانی خاصی را در همان سرور ذخیره سازی جمع کند و آخرین داده ها را در حافظه پنهان نگه دارد. بنابراین، استفاده از DFS با یک کلید شارد ترکیبی بزرگ می‌تواند فشار عملیات خواندن/نوشتن و هزینه نگهداری فهرست را با استفاده از ذخیره‌سازی توزیع شده و شاخص توزیع‌شده متعادل کند.

2.1.3. RDB برای داده های استخراج شده در پرواز

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

(آ)
ارزش بهره مهم ترین اطلاعات داده های مکانی به صورت عدد و کاراکتر است. به عنوان مثال، ما معمولاً به برخی از اطلاعات کلیدی که در داده‌های حسگر نهفته است، توجه می‌کنیم، مانند موقعیت فردی در ویدیوی نظارتی که به منطقه هشدار محصور نفوذ می‌کند.
(ب)
مقدار تغییر غیرعادی مقدار بهره خاص خارج از محدوده است. این اطلاعات تغییر اغلب شامل «فیوز انفجاری» برای هدایت فرآیند تکامل محیط جغرافیایی و آنچه مردم بیشتر به آن اهمیت می‌دهند، می‌شود. به عنوان مثال، مقدار بهره ممکن است وضعیت یک خودرو را ثبت کند، اما تنها زمانی که خودرو در حال سرعت زیاد، توقف طولانی مدت، یا دور شدن از یک مسیر از پیش تعریف شده است، مقدار تغییر غیرعادی می تواند پلتفرم GIS ترافیک را به حرکت درآورد. اجرای دفع اضطراری
(ج)
مقدار هضم روشی یکسان برای توصیف مختصر داده‌های چندرسانه‌ای مانند فیلم‌ها، تصاویر، صداها و سیگنال‌ها است که برای حذف و بازیابی مفید است [ 19 ]. به عنوان مثال، اگر دو فریم ویدیو یکسان باشند، مقادیر خلاصه تولید شده توسط الگوریتم Message Digest 5 (MD5) یکسان خواهد بود. بنابراین، هنگام بازیابی یک جریان ویدئو، فقط باید مقادیر خلاصه را با هم مقایسه کنیم و آن فریم های ویدئویی تکراری را نادیده بگیریم، که می تواند فشار زمان بندی را تا حد زیادی کاهش دهد.
همانطور که می دانیم، اطلاعات خاص استخراج شده از داده های ورودی بلادرنگ دارای ویژگی های چندوجهی، ساختار از پیش تعریف شده و الزامات پرس و جوی انعطاف پذیر است که برای ذخیره سازی چند تایی در RDB مناسب است. تشخیص تغییرات غیرعادی بلادرنگ برای پیاده سازی توسط تابع محاسباتی جاسازی شده “مکانیسم ماشه” در RDB بدون عملیات ورودی/خروجی خارجی مناسب است، و ما می توانیم مکانیسم پیام “اشتراک/انتشار” را در تریگر ادغام کنیم تا به طور فعال تغییر غیرعادی شناسایی شده را ارسال کنیم. اطلاعات به ماژول همبستگی برای پردازش بیشتر در زمان واقعی. با هدف ویژگی‌های چند مدلی مقدار هضم، می‌توانیم یک شاخص معکوس ایجاد کنیم که شامل یک شاخص هش بر روی تمام عناصر معنایی ویژگی استخراج شده از داده‌های مکانی است تا از پرس‌و‌جوهای معنایی در حافظه با پیچیدگی زمانی O(1) پشتیبانی کند.

2.2. روش سازماندهی چند دانه بندی

روش‌های سازمانی موجود عمدتاً بر ثبت وضعیت موجودیت‌ها یا پدیده‌های جغرافیایی بدون در نظر گرفتن ارتباط بین داده‌های ورودی گسسته‌شده با زمان تمرکز می‌کنند. این امر به طور قابل ملاحظه ای ارزش داده ها و در دسترس بودن تجزیه و تحلیل GIS آنلاین بر اساس این داده ها را کاهش می دهد. با توجه به تئوری GIS بلادرنگ [ 20 ، 21 ]، ما سه نوع عنصر جغرافیایی را تعریف کردیم: اشیاء جغرافیایی، رویدادها و فرآیندها. هنگامی که مقدار بهره یک شی، محاسبه شده از داده‌های مکانی بی‌درنگ، از آستانه از پیش تعریف‌شده فراتر می‌رود، یک رویداد تولید و به اشیاء جغرافیایی مرتبط ارسال می‌شود تا ماژول‌ها را برای دسترسی و تحلیل داده‌های فرآیند بعدی فراخوانی کند.

(آ)
شی جغرافیایی نشان دهنده نهاد نظارتی است، مانند شخص، وسیله نقلیه، منطقه یا شی مجازی. به عنوان مثال، داده های GPS در یک زمان معین منعکس کننده موقعیت یک تاکسی است. قاب ویدیوی نظارتی وضعیت امنیت عمومی یک جامعه را نشان می دهد. شیء جغرافیایی را می توان با ساختار شناسه شی، نام، نوع، طول عمر و توضیحات نمونه سازی کرد.
(ب)
رویداد جغرافیایی نشان دهنده تغییر حالت غیرعادی یک شی جغرافیایی در یک لحظه خاص است. به عنوان مثال، اگر ماشین “A” بیش از حد مجاز در زمان “t1” رانندگی کند. ما می توانیم رویداد “OverSpeed” را که توسط نقطه مسیر با پارامتر سرعت در زمان “t1” برای شی “A” تجسم شده است ایجاد کنیم. یک رویداد جغرافیایی را می‌توان با ساختار شناسه رویداد، نام، نوع، مهر زمانی، شناسه شی و اشاره‌گر به داده‌های ورودی غیرعادی تغییر یافته نمونه‌سازی کرد.
(ج)
فرآیند جغرافیایی نشان‌دهنده فعالیت یک شی جغرافیایی است که توسط رویداد ایجاد می‌شود، که با خوشه‌بندی توالی داده‌ها در طول یک یا چند دوره زمانی حول یک موضوع، تحقق می‌یابد. به عنوان مثال، مسیر یک تاکسی را می توان به چندین بخش فرآیندی تقسیم کرد که با معنای “حرکت” و “توقف” توصیف شده است. جریان داده سنسور سیل را می توان حداقل به سه دسته فرآیند «زیر سطح نرمال»، «سطح نرمال» و «بیش از حد نرمال» تقسیم کرد. فرآیند جغرافیایی را می توان با ساختار شناسه فرآیند، نام، نوع، دوره زمانی، شناسه شی، شناسه رویداد و یک اشاره گر به بخش داده، نمونه برداری کرد.

2.3. برنامه ریزی یکپارچه با طراحی ساختار شناسه یکنواخت

تقسیم بندی عناصر جغرافیایی ارتباط بین یکدیگر را جدا می کند. هنگام طراحی ساختار ID، ارائه ضمنی رابطه آن و حفظ منطقی یکپارچگی آن برای پشتیبانی از برنامه ریزی یکپارچه بین محیط های ذخیره سازی ترکیبی دشوار است. ساختار ID معمولی در پایگاه داده NoSQL MongoDB یکی از این نمونه ها است. کد شناسایی منحصر به فرد MongoDB شامل 12 بایت است که از ذخیره سازی توزیع شده پشتیبانی می کند. در میان آنها، 0-3 بایت مرجع زمانی را ذخیره می کند، تعداد مطلق ثانیه ها از 1 ژانویه 1970 00:00:00 UTC. 4-6 بایت شناسه سرور را ذخیره می کند که معمولاً یک مقدار هش نام دستگاه است. 7-8 بایت شناسه فرآیند نمونه MongoDB را ذخیره می کند. 9 تا 11 بایت عدد افزایشی را ذخیره می کند. اگرچه ساختار ID MongoDB منحصر به فرد بودن هر شناسه شی را تضمین می کند، دو مشکل وجود دارد که باید حل شود: (1) شناسه شی جغرافیایی، شناسه رویداد و شناسه فرآیند به طور جداگانه تولید می شوند و هیچ ارتباطی ندارند. بنابراین، رابطه نقشه برداری باید به طور کامل حفظ شود. (2) تکرار شناسه قابل شناسایی نیست. اگرچه ساختار ID تا حد زیادی منحصربه‌فرد بودن تولید را حفظ می‌کند، به دلیل نقص الگوریتم هش، ناگزیر احتمال تکرار کم وجود دارد. چنین طراحی ساختار شناسه باید تمام شناسه های شی را برای بررسی تکراری بودن طی کند. بنابراین، ساختار ID وقت گیر و ناکارآمد است. اگرچه ساختار ID تا حد زیادی منحصربه‌فرد بودن تولید را حفظ می‌کند، به دلیل نقص الگوریتم هش، ناگزیر احتمال تکرار کم وجود دارد. چنین طراحی ساختار شناسه باید تمام شناسه های شی را برای بررسی تکراری بودن طی کند. بنابراین، ساختار ID وقت گیر و ناکارآمد است. اگرچه ساختار ID تا حد زیادی منحصربه‌فرد بودن تولید را حفظ می‌کند، به دلیل نقص الگوریتم هش، ناگزیر احتمال تکرار کم وجود دارد. چنین طراحی ساختار شناسه باید تمام شناسه های شی را برای بررسی تکراری بودن طی کند. بنابراین، ساختار ID وقت گیر و ناکارآمد است.
بر اساس تجزیه و تحلیل بالا، این بخش یک ساختار ID جدید را همانطور که در شکل 2 نشان داده شده است، تعریف می کند.که عناصر جغرافیایی چند دانه بندی را به هم مرتبط می کند. مزیت این ساختار ID جدید، تشخیص سریع تکرار و پشتیبانی از تولید توزیع شده است. این ساختار ID 12 بایت را اشغال می کند و مقیاس پذیر است. در میان آنها، بایت 0 انواع فرآیند جغرافیایی، شی و رویداد را ذخیره می کند. اولین بایت بایت مدیریتی است که موقعیت ذخیره سازی این سه عنصر و نوع عنصر را متمایز می کند. بایت های 2-5 رابطه نگاشت بین سه عنصر را ذخیره می کنند. به عنوان مثال، بایت های 2-3 شناسه فرآیند جغرافیایی تعداد اشیاء جغرافیایی مرتبط را ذخیره می کند، بایت های 4-5 تعداد رویدادهای جغرافیایی مرتبط را ذخیره می کند. اگر مقدار این ناحیه “i” باشد، به این معنی است که این فرآیند حاوی عناصر جغرافیایی “i” است. تغییر مقدار این 2 بایت به محدوده [0, i – 1]، شناسه فرآیند جغرافیایی به شناسه منطقی عنصر جغرافیایی مربوطه تغییر می کند. سپس از یک جدول نگاشت برای تبدیل شناسه منطقی به شناسه عنصر جغرافیایی واقعی استفاده کنید. بایت های 6-7 یک عدد افزایشی را ذخیره می کنند و فضای کاری توزیع شده را شناسایی می کنند. فضای کاری حداقل واحد اداری برای مدیریت فرآیندها، اشیاء و رویدادهای جغرافیایی است. هر فضای کاری دارای شناسه های مختلفی در این سه بایت است، اما فرآیندها، اشیاء و رویدادها در همان فضای کاری دارای شناسه یکسان در آن بایت ها هستند. بررسی تکراری بودن بر اساس فضای کاری و پشتیبانی از تولید توزیع شده آسانتر است. بایت های 8 تا 11 عدد افزایشی را ذخیره می کنند. هر شناسه در هر نوع دارای مقدار متفاوتی در آن 4 بایت است. به طور کلی،

3. مطالعه موردی داده‌های ژئوویدئوی بلادرنگ در DBMS هیبریدی NoSQL–SQL

GeoVideo داده‌های مکانی معمولی بلادرنگ است که فریم‌های ویدیو را در یک فضای جغرافیایی نگاشت می‌کند. در این بخش، نظارت تصویری امنیت عمومی را به عنوان مثال برای نشان دادن جریان داده های عظیم داده های GeoVideo بین پایگاه های داده معمولی NoSQL (MMDB Redis و DFS MongoDB) و پایگاه داده SQL (RDB MySQL) در نظر می گیریم.

3.1. جریان داده در پایگاه های داده ترکیبی

تشخیص حرکت در زمان واقعی و استخراج پیش‌زمینه رویه‌های حیاتی برای نظارت GeoVideo امنیت عمومی است که فریم‌های ویدئوی اصلی را به عناصر جغرافیایی از جمله وسایل نقلیه مرجع جغرافیایی، بدن انسان و پس‌زمینه ثابت برای پردازش بصری سطح بالاتر و تجزیه و تحلیل GIS تبدیل می‌کند [22] . , 23 , 24 ]. بنابراین، پیوند ذخیره سازی و محاسبات جریان GeoVideo بلادرنگ راه موثری برای کاهش زمان پاسخ در مواقع اضطراری است. شکل 3 جریان داده های داده های GeoVideo را بین Redis، MySQL و MongoDB نشان می دهد.
مرحله 1: به استریم GeoVideo دسترسی پیدا کنید و جریان ویدئو را با توجه به نرخ فریم به فریم های ویدئویی تبدیل کنید. میدان دید (FOV) را بر اساس زاویه نگرش و فاصله کانونی دوربین محاسبه کنید.
مرحله 2: توالی فریم‌های GeoVideo در Redis ذخیره می‌شود و هر کانال ویدیویی مربوط به فهرست Redis است که از پرسش‌های مربوط به دوره اخیر داده‌های ویدیویی پشتیبانی می‌کند. سیستم تجزیه و تحلیل ویدیو، آخرین فریم‌های ویدیویی را از سر فهرست برای تشخیص منطقه حرکت و استخراج پیش‌زمینه در زمان واقعی به دست می‌آورد و طول لیست را با الگوریتم جایگزینی اول در اول (FIFO) ثابت نگه می‌دارد.
مرحله 3: ویژگی تغییر استخراج شده توسط تجزیه و تحلیل مقایسه ای فریم های ویدئویی را در جدول حافظه به نام Change_Attribute_Table MySQL ذخیره کنید و یک ماشه درج برای انجام نظارت بر زمان واقعی تغییرات غیرعادی ایجاد کنید. اگر مقدار تغییر از مقادیر آستانه از پیش تعریف شده بیشتر شود، ماشه یک رویداد مربوطه را با توجه به محدوده تغییر ایجاد می کند و رویداد را در جدول حافظه به نام Event_Table MySQL وارد می کند.
مرحله 4: یک تریگر درج در Event_Table ایجاد کنید و از سیستم زمانبندی توزیع شده Gearman برای همگام سازی رویداد در Redis به عنوان یک کش استفاده کنید. تاپل رویداد در MySQL به ساختار داده هش در Redis نگاشت می شود و شناسه رویداد منحصر به فرد جهانی را به عنوان کلید هش می گیرد.
مرحله 5: از مکانیسم پیام «اشتراک/انتشار» Redis برای انتقال فعال رویدادها به اشیاء جغرافیایی مربوطه استفاده کنید. دسته رویداد را به عنوان “کانال” برای اجرای عملیات فشار رویداد در نظر بگیرید.
مرحله 6: اشیاء جغرافیایی رویدادهای مشترک را دریافت می‌کنند، ویژگی‌های رویدادها را تجزیه و تحلیل می‌کنند، و به‌طور خودکار داده‌های GeoVideo مربوط به مکانی-زمانی را با استفاده از الگوهای رویداد از پیش تعریف‌شده بارگیری می‌کنند.
مرحله 7: فریم های ویدئویی از پیش پردازش شده در Redis را با معنای فرآیند جغرافیایی گروه بندی کنید و در خوشه MongoDB Mongos بنویسید. کلید ترکیبی – “day+cameraID” را انتخاب کنید و برای پشتیبانی از ذخیره سازی توزیع شده داده های GeoVideo عظیم، شاخص ترکیبی را روی این دو ویژگی ایجاد کنید.
مرحله 8: FOV فریم های ویدئویی را در Redis به عنوان مسیر حرکت دوربین گروه بندی کنید. حداقل مستطیل مرز سه بعدی این FOV ها را محاسبه کنید و در حین همگام سازی فریم های ویدئویی از Redis به MongoDB، شاخص فضایی-زمانی را به روز کنید.

3.2. ساختار و الگوریتم قابلیت همکاری

3.2.1. تشخیص تغییر و ماشه رویداد

مقدار تغییر غیرعادی استخراج شده از جریان GeoVideo در Redis، محرک اجرای تجزیه و تحلیل ویدیو است. استفاده از “مکانیسم ماشه” در RDB برای پیوند ذخیره سازی و محاسبات داده های GeoVideo می تواند به طور فعال تغییرات غیرعادی را شناسایی کند و رویدادها را در زمان واقعی بدون عملیات I/O خارجی ایجاد کند. در نظارت تصویری یک موزه، فاصله بین بازدیدکننده و نمایشگاه، مدت اقامت در سالن نمایشگاه، حرکت نمایشگاه و خطر آتش سوزی همه عوامل مهم در تعیین ایمنی نمایشگاه هستند. برای مثال، در نظارت بر فاصله بین بازدیدکننده و نمایشگاه، فاصله‌های متفاوت سطوح مختلفی از رویدادهای امنیتی را آغاز می‌کند. میز 1ساختار جدول Safe_Distance را توصیف می کند که فاصله بین یک نمایشگاه و بازدیدکننده استخراج شده از یک قاب ویدئو را ثبت می کند. جدول 2 ساختار جدول Event_Safe_Distance را شرح می دهد که رویدادهای شناسایی شده از جدول Safe_Distance را با بررسی مقدار فاصله بین یک نمایشگاه و بازدیدکننده ثبت می کند. ماشه Trigger_Safe_Distance (الگوریتم 1) فواصل غیرعادی را در جدول Safe_Distance بررسی می کند و رویدادها را در جدول Event_Safe_Distance وارد می کند. جدول Safe_Distance، جدول Event_Safe_Distance، و Trigger_Safe_Distance در MySQL یک فرآیند یکپارچه برای تشخیص تغییرات بلادرنگ و راه‌انداز رویداد را تشکیل می‌دهند.
الگوریتم 1: Trigger_SafeDistance (Tuple DistanceValue) 
1. Trigger_Safe_Distance را ایجاد کنید 
2. پس از  درج در جدول Safe_Distance
3. برای هر ردیف جدید
4.    شروع 
5.      اگر newTuple.distance < safe_distance_level1 سپس
6.        در مقادیر Event_Safe_Distance (event_type1، newTuple.attributes) وارد کنید .
7.      elseif newTuple.distance < safe_distance_level2 then
8.        در مقادیر Event_Safe_Distance (ویژگی های event_type2، newTuple.) وارد کنید .
9.      elseif newTuple.distance < safe_distance_level3 then
10.       در مقادیر Event_Safe_Distance (ویژگی های event_type3، newTuple.) وارد کنید .
11.     Other 
12.       درج در Event_Safe_Distance مقادیر (event_type4, newTuple. ویژگی ها)
13.     end if-then 
14.    end-begin 
15. end-foreach

3.2.2. اشتراک و انتشار رویداد

استفاده از مکانیسم پیام “اشتراک/انتشار” می تواند به طور فعال رویدادها را در اولین بار به اشیاء جغرافیایی مرتبط ارسال کند. ما تریگر درج Dispatch_Event (الگوریتم 2) را در جدول Event_Safe_Distance MySQL تعریف می کنیم. در رویه ذخیره شده تریگر Dispatch_Event، ما از سیستم زمانبندی توزیع شده Gearman برای همگام سازی رویدادها از MySQL به Redis، با ویرایش Gearman Worker به نام «SyncAndDispatchEvent» (الگوریتم 3) و استفاده از مکانیسم پیام تعبیه شده «اشتراک/انتشار مجدد برای» استفاده می کنیم. رویدادهای تولید شده در زمان واقعی را به اشیاء جغرافیایی مرتبط فشار دهید. در برنامه نظارت تصویری، ما هر دسته رویداد را به عنوان یک کانال جدا می کنیم و بخش های مختلف ایمنی در انواع مختلف رویدادها مشترک می شوند. به عنوان مثال، یک بخش ایمنی موزه تمام سطوح حوادث امنیتی را دریافت می کند، اما ایستگاه پلیس محلی فقط افرادی را در سطوح بالاتر دریافت می کند. از طریق انتشار بی‌درنگ رویدادهای امنیتی، مشترکین اعلان‌های رویداد را دریافت می‌کنند و داده‌های GeoVideo واقعی و تاریخی مربوط به رویداد را از Redis و MongoDB برای تجزیه و تحلیل جامع جستجو می‌کنند.
الگوریتم 2: Trigger_DispatchEvent (Tuple SafeDistanceEvent) 
1. ایجاد ماشه Dispatch_Event
2. پس از درج در جدول Event_Safe_Distance
3. برای هر ردیف جدید
4.    شروع 
5.      تنظیم @ret= gman_do_background ( GearmanWorker 'SyncAndDispatchEvent',
6.      json_object (newTupleInMySQL.attributes به عنوان newKeyValuePairInRedis.attributes))
7.    پایان-شروع 
8. پایان-فروچ
الگوریتم 3: GearmanWorker_SyncAndDispatchEvent (Tuple SafeDistanceEvent) 
1. $worker = new GearmanWorker()
2. $worker->addFunction('SyncAndDispatchEvent')
3. $redis = new Redis()
4. $redis->connect(IP، پورت)
5. while($worker->work())
6. شروع 
7.    تابع SyncAndDispatchEvent (Tuple $job)
8.      جهانی $redis
9. $workString = $job->workload()
10. $work = json_decode ($workString)
11. $redis-> hmset ( کلید : "attributeName"، مقدار : $work-> ویژگی)
12. $redis-> انتشار ( کانال : $work->event_type، $work->eid)
13.   کارکرد پایانی 
14. پایان-شروع

4. مطالعه تجربی

در این بخش، آزمایش‌هایی را با استفاده از رویکرد سازمان‌دهی و مدیریتی که در بالا توضیح داده شد ارائه کردیم و نتایج عملکرد را از نظر دسترسی به داده‌های GeoVideo در زمان واقعی، تشخیص و ارسال رویدادهای غیرعادی و ذخیره‌سازی گسترده داده‌های تاریخی تجزیه و تحلیل کردیم. در بخش 4.1 ، محیط نرم‌افزار و سخت‌افزار، مجموعه داده‌ها و سایر آماده‌سازی‌های درگیر در آزمایش‌ها را شرح می‌دهیم. آزمایش های مفصل در بخش 4.2 ارائه شد .

4.1. تنظیمات آزمایشی

تمام آزمایش ها روی دو ایستگاه کاری Dell OPTIPLEX 9020 انجام شد که هر کدام سه ماشین مجازی را به عنوان گره های کاری ایجاد کردند. هر نود دارای یک پردازنده 4 هسته ای Intel I7-4790M با فرکانس 3.60 گیگاهرتز با هشت رشته سخت افزاری و 4 گیگابایت رم بود. این دو ایستگاه کاری از طریق یک شبکه گیگابیتی با هم ارتباط داشتند. هر شش گره از یک سیستم عامل لینوکس 64 بیتی (سرور CentOS Enterprise) استفاده می کردند. یک MongoDB 64 بیتی، Redis 64 بیتی، MySQL 64 بیتی، سیستم توزیع وظیفه Gearman و 64 بیتی OpenCV برای پیاده سازی روش سازماندهی ترکیبی شرح داده شده در بالا بر روی دو گره کاری برای داده های GeoVideo بلادرنگ استفاده شد.
در آزمایش‌ها، ما 58 دوربین را که به طور تصادفی توزیع شده بودند، در داخل و خارج ساختمان اداری انتخاب کردیم. هر یک از دوربین ها 48 ساعت را با سرعت نمونه برداری 25 فریم در ثانیه، با یک فریم ارجاع جغرافیایی در ثانیه به دلیل سرعت نمونه برداری از GPS و قطب نما (قطب نما دیجیتال می تواند 30 یا 40 خواندن در ثانیه انجام دهد، اما GPS) ضبط کردند. فقط می توان یک نمونه در ثانیه دریافت کرد). اینها پارامترهای کلیدی برای محاسبه اطلاعات مکانی GeoVideo، مانند FOV و موقعیت شی نظارت بودند. بنابراین، ما یک مجموعه داده با حدود 250 میلیون فریم ویدئو و 10 میلیون فریم کلیدی مرجع جغرافیایی داشتیم. اندازه هر فریم حدود 100 K است. تشخیص تغییر فریم های ویدئویی، از جمله تشخیص ناحیه حرکتی و استخراج پیش زمینه توسط یک کتابخانه الگوریتم استخراج ویژگی منبع باز OpenCV اجرا شد.
به منظور اعتبارسنجی روش پیشنهادی، ما یک سری آزمایش را با استفاده از یک مجموعه داده نمونه GeoVideo انجام دادیم. آزمایش اول به‌روزرسانی و عملکرد پرس‌وجو را بین مخزن مبتنی بر Redis-MongoDB، مخزن مبتنی بر MongoDB و مخزن مبتنی بر MySQL مقایسه کرد تا بررسی کند که آیا روش ترکیبی از RDB و DFS مستقل عملکرد بهتری در دسترسی بلادرنگ دارد یا خیر. آزمایش دوم تشخیص رویداد غیرعادی و عملکرد ارسال فعال تشخیص-فشار و اسکن منظم را به منظور اعتبارسنجی پیوند ذخیره سازی و محاسبات با بازدید نزدیک مقایسه کرد و زمان پاسخ را به میزان زیادی کاهش داد.

4.2. نتایج تجربی

4.2.1. دسترسی به زمان واقعی

این آزمایش عملکرد دسترسی بلادرنگ مخزن پیشنهادی مبتنی بر Redis-MongoDB را با یک مخزن مستقل مبتنی بر MongoDB و مخزن مبتنی بر MySQL مقایسه کرد. برای این آزمایش، ما یک مخزن مبتنی بر MongoDB را پیکربندی کردیم که دارای یک سرور پیکربندی، سه سرور shard و یک روتر mongs، و یک مخزن مبتنی بر Redis و یک مخزن مبتنی بر MySQL در یک گره واحد است. ما از سه نسبت به روز رسانی/پرس و جو (75% به روز رسانی و 25% پرس و جو، 50% به روز رسانی و 50% پرس و جو و 25% به روز رسانی و 75% پرس و جو) استفاده کردیم و مقدار متوسط ​​را برای اندازه گیری توان عملیاتی به روز رسانی/پرس و جو و تاخیر پاسخ پرس و جو دریافت کردیم. آخرین داده ها به همین روش
از شکل 4a-c، می‌توان نتیجه گرفت که کارایی دسترسی و تأخیر برای جستجوی آخرین داده‌های مخزن مبتنی بر Redis-MongoDB به طور قابل توجهی بهتر از دو مورد دیگر بود. مخزن مبتنی بر Redis-MongoDB از مخزن مبتنی بر MongoDB عملکرد بهتری داشت، در حالی که مخزن مبتنی بر MongoDB از مخزن مبتنی بر MySQL عملکرد بهتری داشت، زیرا Redis مشکلات تنگنای ورودی/خروجی و مصرف بالا را برای نگهداری شاخص جهانی حل کرد و MongoDB کار را ساده کرد. عملیات پیچیده برای حفظ ثبات قوی برای به روز رسانی در زمان واقعی با حفظ ثبات نهایی. به طور کلی، ظرفیت دسترسی سه مخزن در ابتدا ثابت بود و سپس با افزایش مقدار داده های ذخیره شده در پایگاه داده به تدریج کاهش یافت. تعداد حجم داده های GeoVideo تأثیر کمی بر مخزن مبتنی بر Redis-MongoDB و تأثیر زیادی بر مخزن مبتنی بر MySQL داشت. بنابراین، جداسازی داده‌های ویدیویی بی‌درنگ و تاریخی، استفاده از MMDB برای مدیریت داده‌های بی‌درنگ و استفاده از DFS برای مدیریت داده‌های تاریخی عظیم، راهی کارآمد برای برآوردن نیازهای دسترسی بلادرنگ بود.

4.2.2. شناسایی و ارسال رویداد

برای نشان دادن عملکرد تشخیص تغییرات غیرعادی در زمان واقعی و ارسال رویداد، یک آزمایش مقایسه ای از هزینه زمانی تشخیص و ارسال رویداد در چهار حالت به شرح زیر طراحی شد. حالت 1: استفاده از مکانیسم ماشه MySQL در جدول حافظه Safe_Distance برای تشخیص تغییرات غیرعادی، و استفاده از یک Gearman worker تعبیه شده در ماشه جدول حافظه Event_Safe_Distance برای انتقال رویدادها به اشیاء جغرافیایی مرتبط با مکانیسم پیام “اشتراک/انتشار” بدون مکانیسم پیام عملیات ورودی/خروجی خارجی حالت 2: استفاده از مکانیسم ماشه MySQL برای تشخیص تغییرات غیرعادی و استفاده از Gearman worker تعبیه شده برای فشار دادن رویدادها به اشیاء جغرافیایی مرتبط، با این حال جدول Safe_Distance و جدول Event_Safe_Distance روی دیسک ذخیره شدند. حالت 3: استفاده از مکانیسم ماشه MySQL برای تشخیص تغییرات غیرعادی در جداول حافظه Safe_Distance و ذخیره انواع مختلف رویدادها در جداول حافظه مختلف. سپس، برنامه‌ها به‌طور دوره‌ای (500 میلی‌ثانیه) جداول رویداد را اسکن کردند تا آخرین رویدادها را دریافت کنند. حالت 4: استفاده از توابع رویه MySQL برای شناسایی دوره ای (500 میلی ثانیه) تغییرات غیرعادی و ذخیره رویدادهای محاسبه شده در جدول حافظه Event_Safe_Distance. سپس، ماشه در جدول حافظه Event_Safe_Distance رویدادها را به اشیاء و ماژول‌های جغرافیایی مرتبط با استفاده از کارگر Gearman جاسازی شده ارسال کرد. استفاده از توابع رویه MySQL برای شناسایی دوره ای (500 میلی ثانیه) تغییرات غیرعادی و ذخیره رویدادهای محاسبه شده در جدول حافظه Event_Safe_Distance. سپس، ماشه در جدول حافظه Event_Safe_Distance رویدادها را به اشیاء و ماژول‌های جغرافیایی مرتبط با استفاده از کارگر Gearman جاسازی شده ارسال کرد. استفاده از توابع رویه MySQL برای شناسایی دوره ای (500 میلی ثانیه) تغییرات غیرعادی و ذخیره رویدادهای محاسبه شده در جدول حافظه Event_Safe_Distance. سپس، ماشه در جدول حافظه Event_Safe_Distance رویدادها را به اشیاء و ماژول‌های جغرافیایی مرتبط با استفاده از کارگر Gearman جاسازی شده ارسال کرد.
از شکل 5 الف، می توان نتیجه گرفت که بازده تشخیص و اعزام رویداد حالت 1 به طور قابل توجهی بیشتر از سه حالت دیگر بود. مقایسه بین حالت 1 و 2 نشان داد که جداول حافظه می توانند هزینه زمانی راه اندازی رویداد و تحویل رویداد را تا حد زیادی کاهش دهند. مقایسه بین حالت 1 و 3 و همچنین حالت 1 و حالت 4 نشان داد که عملیات فعال تشخیص رویداد و ارسال رویداد کارآمدتر بود. شکل 5 b,c نشان می دهد که حالت 1 کمترین منابع MySQL را مصرف می کند و در مقایسه با سه حالت دیگر تأثیر کمی بر عملکرد دسترسی MySQL دارد.

4.2.3. توزیع داده های تاریخی

هدف از این آزمایش تأیید این بود که آیا خوشه MongoDB Mongos توزیع یکنواخت داده‌های GeoVideo، عملکرد جستجوی بهتر و ذخیره‌سازی مقیاس‌پذیر را تضمین می‌کند یا خیر. ما یک Mongos خوشه MongoDB را پیکربندی کردیم که دارای یک سرور پیکربندی، سه سرور خرد، یک روتر mongs و یک سرور جایگزین قابل توسعه بود. مقایسه بین سه کلید خرد شده: کلید ترکیبی “day+cameraID”، کلید هش “cameraID” و کلید افزایشی “day” انجام شد.
شکل 6 a,b نشان داد که کلید شارد مرکب در مقایسه با دو نوع دیگر کلید خرده عملکرد دسترسی بهتری دارد. اگرچه کلید هش توزیع یکنواخت و کارایی به‌روزرسانی داده‌های GeoVideo را داشت، اما به دلیل توزیع تصادفی داده‌های GeoVideo بدون خوشه‌بندی و شاخص توزیع نامعتبر، برای پرس‌و‌جوها تنگنا داشت. کلید افزایشی باعث شد که عملیات به‌روزرسانی روی یک سرور خرده‌ای متمرکز شود که آخرین داده‌ها را ثبت می‌کرد، که منجر به گلوگاه به‌روزرسانی شد که اجازه نمی‌داد فضای ذخیره‌سازی مقیاس‌پذیر به طور کامل وارد بازی شود. شکل 6c نشان داد که افزایش تعداد خرده‌ها عملکرد به‌روزرسانی را بهبود می‌بخشد، به این معنی که MongoDB توانایی قوی برای کاهش مقیاس دارد. عدد شارد بهبود عملکرد کمی در کلید افزایشی و بهبود عملکرد عالی در کلید ترکیبی و کلید هش داشت.

5. نتیجه گیری ها

ساختارهای پیچیده سیستم های مکانی نیاز مبرمی به مدیریت مناسب دارند [ 25 ، 26 ]. پیشرفت‌های اخیر در فناوری اطلاعات که معمولاً به عنوان «داده‌های بزرگ» نامیده می‌شود، همراه با زمینه‌های مرتبط با علم داده و تجزیه و تحلیل برای پردازش، تجزیه و تحلیل و تعیین ارزش حجم عظیم داده‌های مکانی مورد نیاز است [3، 27 ] .]. روش‌های تحلیل جغرافیایی موجود عمدتاً در زمینه داده‌های کوچک توسعه یافته‌اند. با این حال، تمام فرآیندهای مورد علاقه عموم مردم و تصمیم گیرندگان در زمان واقعی و زمینه ناهمگون عمل می کنند. عدم تعادل بین محصولات داده غنی و استفاده ضعیف از داده، توجه را به تکنیک های دسترسی و مدیریت داده های بلادرنگ جلب می کند. رویکرد ترکیبی سازماندهی و مدیریت NoSQL-SQL داده های مکانی بلادرنگ از مزایای عملیات دسترسی بلادرنگ NoSQL MMDB برای داده های ورودی ناهمگن مختلف، پرس و جوهای انعطاف پذیر و پردازش تراکنش های SQL RDBMS برای پشتیبانی از دسترسی استفاده می کند. نتایج تجزیه و تحلیل در حال پرواز، و توانایی مقیاس پذیر NoSQL DFS برای داده های عظیم. این رویکرد برای پشتیبانی از ذخیره سازی بلادرنگ، پرس و جو و محاسبات در GIS بلادرنگ موثر در نظر گرفته می شود. این مقاله با هدف مشکلات در ارتباط بین ذخیره‌سازی و محاسبات در تجزیه و تحلیل آنلاین GIS، یک استراتژی ذخیره‌سازی مشترک داخلی و خارجی را با مدیریت جداگانه داده‌های جغرافیایی زمان واقعی و تاریخی ارائه می‌کند، و یک گردش کار را طراحی می‌کند که شناسایی تغییرات در زمان واقعی و تحویل رویداد فعال را ادغام می‌کند. برای هدایت تکامل فرآیند جغرافیایی یک ساختار ID جدید نیز برای مرتبط کردن عناصر جغرافیایی چند دانه بندی برای زمان بندی یکپارچه در ترکیبی NoSQL-SQL DBMS طراحی شده است. علاوه بر این، با استفاده از مکانیسم پیام اشتراک/انتشار برای ترسیم روابط بین اشیاء، رویدادها و فرآیندهای جغرافیایی، این روش می‌تواند تأخیر زمان‌بندی مشترک داده‌های مکانی-زمانی بلادرنگ و تاریخی را به طور موثر کاهش دهد. نتایج تجربی از کاربرد بتن GeoVideo بر اساس Redis،
این رویکرد سازماندهی ترکیبی NoSQL-SQL یک پایه مهم در پلت فرم GIS بلادرنگ برای نظارت بر محیط است. این سیستم با موفقیت برای نظارت GeoVideo و ردیابی مسیر اعمال شده است و پشتیبانی تصمیم گیری امنیت عمومی را برای بخش امنیتی فراهم می کند ( شکل 7 را ببینید ). رویکرد مدیریت داده، دسترسی بلادرنگ و تشخیص تغییرات غیرعادی داده‌های بزرگ GeoVideo را تسهیل کرده است. رویکرد سازمانی و مدیریتی توسعه‌یافته داده‌های مکانی بلادرنگ با کمک به محققان در مقابله با چالش‌های ناشی از داده‌های بزرگ، پیشرفت‌ها را در طیف گسترده‌ای از کاربردها ممکن می‌سازد.

منابع

  1. کوان، نماینده مجلس؛ لی، جی. پاسخ اضطراری پس از 11 سپتامبر: پتانسیل GIS سه بعدی بلادرنگ برای واکنش سریع اضطراری در محیط‌های ریز فضایی. محاسبه کنید. محیط زیست شهری 2005 ، 29 ، 93-113. [ Google Scholar ] [ CrossRef ]
  2. زرگر، ا. اسمیت، DI موانع استفاده از GIS برای پشتیبانی تصمیم گیری بلادرنگ در زمان واقعی. محاسبه کنید. محیط زیست Urban 2003 , 27 , 123-141. [ Google Scholar ] [ CrossRef ]
  3. ژانگ، اف. ژنگ، ی. خو، دی. دو، ز. وانگ، ی. لیو، آر. Ye, X. پرس و جوهای مکانی در زمان واقعی برای اجسام متحرک با استفاده از توپولوژی طوفان. ISPRS Int. J. Geo-Inf. 2016 ، 5 . [ Google Scholar ] [ CrossRef ]
  4. نگاه به آینده: پنج تفکر در مورد آینده GIS. در دسترس آنلاین: http://www.esri.com/news/arcwatch/0211/future-of-gis.html (در 7 آگوست 2016 قابل دسترسی است).
  5. خو، دبلیو. زو، س. ژانگ، ی. دینگ، ی. Hu, M. Real-Time GIS و کاربرد آن در فاجعه آتش سوزی داخلی. طاق ISPRS. 2013 ، XL-2/W2 ، 121-127. [ Google Scholar ] [ CrossRef ]
  6. پلکیس، ن. تئودولیدیس، بی. کوپاناکیس، آی. تئودوریدیس، ی. بررسی ادبیات مدل های پایگاه داده مکانی-زمانی. دانستن مهندس Rev. 2004 , 19 , 235-274. [ Google Scholar ] [ CrossRef ]
  7. برونیگ، ام. تورکر، سی. Böhlen، MH; دیکر، اس. گوتینگ، RH; جنسن، CS; رلی، ال. ریگو، پی. Schek، HJ; Scholl, M. معماری و پیاده سازی سیستم های مدیریت پایگاه داده مکانی-زمانی. در پایگاه‌های داده مکانی-زمانی: رویکرد CHOROCHRONOS ، ویرایش اول. Frank, AU, Sellis, T., Koubarakis, M., Eds. Springer: برلین، آلمان، 2003; صص 264-314. [ Google Scholar ]
  8. شواچکو، ک. کوانگ، اچ. رادیا، اس. Chansler, R. سیستم فایل توزیع شده هادوپ. در مجموعه مقالات بیست و ششمین سمپوزیوم IEEE در سال 2010 در مورد سیستم ها و فناوری های ذخیره سازی انبوه، واشنگتن، دی سی، ایالات متحده آمریکا، 3 تا 7 مه 2010.
  9. آبادی، دی جی; احمد، ی. بالازینسکا، م. چتینتمل، U. چرنیاک، م. هوانگ، جی اچ. لیندنر، دبلیو. ماسکی، ع. راسین، ع. ریوکینا، ای. و همکاران طراحی موتور پردازش جریان Borealis. در مجموعه مقالات کنفرانس CIDR 2005، آسیلومار، کالیفرنیا، ایالات متحده آمریکا، 4 تا 7 ژانویه 2005.
  10. آراسو، ع. بابو، س. Widom, J. زبان پرس و جو پیوسته CQL: مبانی معنایی و اجرای پرس و جو. VLDB J. 2006 ، 15 ، 121-142. [ Google Scholar ] [ CrossRef ]
  11. گیلستروم، دی. وو، ای. Chae، HJ; دیائو، ی. استالبرگ، پی. Anderson، G. SASE: پردازش رویداد پیچیده از طریق جریان. در مجموعه مقالات سومین کنفرانس دوسالانه تحقیقات سیستم های داده نوآورانه، آسیلومار، کالیفرنیا، ایالات متحده آمریکا، 7 تا 10 ژانویه 2007.
  12. Demers، AJ; گرکه، ج. پاندا، بی. ریدوالد، ام. شارما، وی. White, WM Cayuga: یک سیستم نظارت بر رویداد با هدف عمومی. در مجموعه مقالات سومین کنفرانس دوسالانه تحقیقات سیستم های داده نوآورانه، آسیلومار، کالیفرنیا، ایالات متحده آمریکا، 7 تا 10 ژانویه 2007.
  13. گدیک، بی. آندراد، اچ. وو، KL; یو، PS; Doo, M. SPADE: موتور پردازش جریان اعلانی سیستم. در مجموعه مقالات کنفرانس بین المللی ACM SIGMOD 2008 در مدیریت داده ها، ونکوور، BC، کانادا، 9 تا 12 ژوئن 2008.
  14. هائو، ایکس. جین، پی. Yue, L. ذخیره سازی کارآمد داده های ردیابی شی چند سنسوری. IEEE Trans. موازی. منطقه 2015 ، 27 ، 2881-2894. [ Google Scholar ] [ CrossRef ]
  15. کانگ، ی. پارک، آی. ری، جی. لی، Y. طراحی مخزن مبتنی بر MongoDB برای داده های بزرگ RFID/سنسور تولید شده توسط اینترنت اشیا. IEEE Sens J. 2015 ، 16 ، 485-497. [ Google Scholar ] [ CrossRef ]
  16. Sipke، VDVJ؛ برام، VDW; عملکرد ذخیره سازی داده های سنسور Meijer، RJ: SQL یا NoSQL، فیزیکی یا مجازی. در مجموعه مقالات پنجمین کنفرانس بین المللی IEEE 2012 در محاسبات ابری، هونولولو، HI، ایالات متحده آمریکا، 24 تا 29 ژوئن 2012.
  17. کیم، سی‌چ. پارک، KW; بهبود عملکرد خدمات وب Choi، YL با Redis. J. Korea Inst. Inf. اشتراک. مهندس 2015 ، 19 ، 2064–2072. [ Google Scholar ] [ CrossRef ]
  18. جیانگ، ال. Xu, LD; کای، اچ. Jiang, Z. چارچوب ذخیره سازی داده مبتنی بر اینترنت اشیا در پلت فرم رایانش ابری. IEEE Trans. Ind. اطلاع رسانی. 2014 ، 10 ، 1443-1451. [ Google Scholar ] [ CrossRef ]
  19. لی، تی. لیو، ی. تیان، ی. شن، اس. Mao, W. یک راه حل ذخیره سازی برای داده های عظیم اینترنت اشیاء مبتنی بر NoSQL. در مجموعه مقالات کنفرانس بین المللی IEEE 2012 در محاسبات و ارتباطات سبز، Besancon، فرانسه، 20-23 نوامبر 2012.
  20. گونگ، جی. لی، ایکس. Wu, H. مدل داده های مکانی-زمانی برای GIS بلادرنگ. AGCS 2014 ، 43 ، 226-232. [ Google Scholar ]
  21. لی، ایکس. یانگ، جی. گوان، ایکس. Wu, H. یک مدل داده مکانی-زمانی رویداد محور (e-st) که از بیان پویا و شبیه‌سازی فرآیندهای جغرافیایی پشتیبانی می‌کند. ترانس. GIS 2014 ، 18 ، 76-96. [ Google Scholar ] [ CrossRef ]
  22. لو، ی. شهابی، ج. Kim, SH نمایه سازی و بازیابی کارآمد پایگاه داده های ویدئویی دارای برچسب جغرافیایی در مقیاس بزرگ. Geoinformatica 2016 ، 20 ، 829-857. [ Google Scholar ] [ CrossRef ]
  23. میلوساولیویچ، آ. رانچیچ، دی. دیمیتریویچ، آ. پردیچ، بی. Mihajlović، V. یکپارچه سازی GIS و نظارت تصویری. بین المللی جی. جئوگر. Inf. علمی 2016 ، 30 ، 2089-2107. [ Google Scholar ] [ CrossRef ]
  24. لوئیس، پی. فاثرینگهام، اس. Winstanley، A. فضایی ویدئو و GIS. بین المللی جی. جئوگر. Inf. علمی 2011 ، 25 ، 697-716. [ Google Scholar ] [ CrossRef ]
  25. الدهوکی، س. کامو، اف. ژائو، ی. مک.؛ وو، ی. یانگ، جی. بله، X. وانگ، اف. لی، ایکس. Chen, W. SemanticTraj: رویکردی جدید برای تعامل با مسیرهای عظیم تاکسی. IEEE Trans. Vis. محاسبه کنید. نمودار. 2017 ، 23 ، 11-20. [ Google Scholar ] [ CrossRef ] [ PubMed ]
  26. هوانگ، ایکس. ژائو، ی. یانگ، جی. ژانگ، سی. مک.؛ Ye, X. TrajGraph: یک رویکرد تحلیل بصری مبتنی بر نمودار برای مطالعه محورهای شبکه شهری با استفاده از داده های مسیر تاکسی. IEEE Trans. Vis. محاسبه کنید. نمودار. 2016 ، 22 ، 160-169. [ Google Scholar ] [ CrossRef ] [ PubMed ]
  27. بله، X. هوانگ، Q. لی، دبلیو. یکپارچه سازی داده های اجتماعی بزرگ، محاسبات و مدل سازی برای علوم اجتماعی فضایی. کارتوگر. Geogr. Inf. علمی 2016 . [ Google Scholar ] [ CrossRef ]
Ijgi 06 00021 g001 550
شکل 1. چارچوب معماری ذخیره سازی ترکیبی.
Ijgi 06 00021 g002 550
شکل 2. طراحی ساختار هویت عنصر جغرافیایی (ID) یکسان برای زمانبندی یکپارچه.
Ijgi 06 00021 g003 550
شکل 3. جریان داده های ویدئوی جغرافیایی (GeoVideo) در محیط ذخیره سازی ترکیبی.
Ijgi 06 00021 g004 550
شکل 4. عملکرد دسترسی بیدرنگ بین مخازن مبتنی بر Redis-MongoDB، MongoDB و مبتنی بر MySQL. ( الف ) به روز رسانی توان عملیاتی سه مخزن. ( ب ) عملیات پرس و جو از سه مخزن. ( ج ) تأخیر برای دریافت آخرین داده های سه مخزن.
Ijgi 06 00021 g005 550
شکل 5. مقایسه بین چهار حالت تشخیص تغییرات غیرعادی و ارسال رویداد. ( الف ) هزینه زمانی تشخیص رویداد و تحویل چهار حالت. ( ب ) به روز رسانی توان عملیاتی MySQL تحت اجرای تشخیص رویداد و تحویل چهار حالت. ( ج ) توان عملیاتی پرس و جو MySQL تحت اجرای تشخیص رویداد و تحویل چهار حالت.
Ijgi 06 00021 g006 550
شکل 6. دسترسی به عملکرد تحت یک کلید شارد متفاوت. ( الف ) به روز رسانی توان عملیاتی MongoDB با استفاده از یک کلید دیگر. ( ب ) خروجی پرس و جو از MongoDB با استفاده از یک کلید خرده متفاوت. ( ج ) بهبود عملکرد با یک عدد شارد متفاوت.
Ijgi 06 00021 g007 550
شکل 7. رابط پلت فرم نظارت بر سیستم اطلاعات جغرافیایی بلادرنگ (GIS)، که تصویری از داده های ویدئویی ارجاع داده شده در زمان واقعی را نشان می دهد که میدان دید آن (FOV) را به صحنه 3 بعدی برای مدیریت ویدئوی عظیم ترسیم می کند. داده ها از منظر فضایی ( الف ) انتخاب داده های GeoVideo بلادرنگ که لابی در طبقه اول را پوشش می دهد. ( ب ) تشخیص در زمان واقعی اجسام متحرک و مسیر ردیابی.
جدول
جدول 1. شرح جدول Safe_Distance.
جدول
جدول 2. شرح جدول Event_Safe_Distance.

;کاربردهای GISمقالات

آموزش کاربردی ArcGISالهام ابراهیم زادهکاربرد جی ای اسکاربرد جی ای اس در زمین شناسیکاربردهای GIs در زمین شناسی

بدون نظر

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

همواره حمایت دانشجویان عزیزمان همراه ما بوده و این سببب شده که گامی محکم به‌سوی ایجاد یک مرجع برای آموزش GIS برداریم. با این امید که بتوانیم قدردان حمایت شما بزرگواران باشیم.

  • خانه
  • آموزش
  • فیلم آموزشی
  • تماس با ما
  • درباره ما
  • وبلاگ
  • سمنان /خیابان کاشانی/ساختمان فناوری اطلاعات/پ 8
  • 09120049370