سیستم مدیریت جریان داده ها: تفاوت میان نسخه‌ها

محتوای حذف‌شده محتوای افزوده‌شده

درخط

نسخهٔ ‏۲۴ ژانویهٔ ۲۰۱۷، ساعت ۰۸:۱۷

یک سیستم مدیریت جریان داده (DSMS) یک برنامه کامپیوتری برای مدیریت مستمر جریان داده است که شبیه به یک سیستم مدیریت پایگاه داده (DBMS) است که برای داده های استاتیک در پایگاه داده های مرسوم طراحی شده است.یک DSMS همچنین یک پردازش پرس و جوی انعطاف پذیر را ارائه می دهد به طوری که اطلاعات مورد نیاز بیان شده می تواند با استفاده از آن نمایش داده شود. اما در مقایسه با یک DBMS یک DSMS یک پرس و جو مستمر را اجرا می کند که نه تنها یک بار انجام می شود، بلکه به طور دائم نصب شده است. بنابراین پرس و جو به طور مداوم تا زمانی که آن را به صراحت حذف نکنیم، اجرا می شود. از آنجا که اکثر DSMS ها data-driven هستند، یک پرس و جوی مستمر تا زمانی که داده های جدید وارد سیستم می شود، نتایج جدید تولید می کند. این مفهوم اساسی شبیه به پردازش رخداد مجتمع است به طوری که هردو فناوری تا حدودی یکی هستند.

اصل عملکردی

یکی از مهم ترین ویژگی های یک DSMS امکان رسیدگی به طور بالقوه و همزمان به جریان داده هایی است که بی نهایت و به سرعت در حال تغییر هستند، اگر چه منابعی مانند حافظه ی اصلی محدود هستند. جدول زیر اصول مختلف DSMS را ارائه می کند و آنها را با DBMS سنتی مقایسه می کند.

سیستم مدیریت پایگاه داده (DBMS)	جریان داده های سیستم مدیریت (DSMS)
داده های ماندگار (روابط)	جریان داده های فرار
با دسترسی تصادفی	دسترسی ترتیبی
پرس و جو های یک باره	پرس و جوهای مداوم و مستمر
(از لحاظ تئوری) فضای ذخیره سازی ثانویه نامحدود	حافظه اصلی محدود
تنها به حالت فعلی وابسته است	ترتیب ورودی را در نظر می گیرد
نرخ به روز رسانی نسبتا پایین	به طور بالقوه نرخ به روز رسانی بسیار بالا
نیازمندی های کم	نیازمندی های بلادرنگ
داده های دقیق را دریافت می کند	داده های منسوخ یا نادرست را دریافت می کند
پردازش پرس و جو قابل برنامه ریزی وارد می شود	داده های متغیر و مشخصات داده ها وارد می شود

مدل های پردازش و جریان

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

فشرده سازسی

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

پنجره ها

به جای استفاده از سیناپس برای فشرده سازی مشخصات کل جریان داده، تکنیک پنجره تنها به یک بخش از داده ها نگاه می کند. این روش براساس این ایده که تنها داده های اخیر مناسب هستند، عمل می کند. بنابراین یک پنجره به طور مداوم بخشی از جریان داده ها را برش می دهد.به عنوان مثال ده عنصر اخیر جریان داده ها در طول پردازش مورد استفاده قرار می گیرند. انواع مختلفی از این پنجره ها وجود دارد مانند پنجره های کشویی که شبیه به لیست FIFO است و یا پنجره های لغزان که بخش های متلاشی شده را برش می دهد. علاوه بر این پنجره ها می توانند براساس عناصرشان نیز فرق گذاشته شوند، به عنوان مثال در نظر گرفتن ده عنصر آخر و یا براساس زمان فرق گذاشته شوند و ده ثانیه ی آخر داده ها در نظر گرفته شوند. همچنین روش های مختلفی برای پیاده سازی پنجره ها وجود دارد. برای مثال روش هایی موجود است که از برچسب زمانی و یا فواصل زمانی برای پنجره های سیستم گسترده یا پنجره های مبتنی بر بافر برای هر گام پردازش استفاده می کند. پردازش پرس و جو ای پنجره های کشویی نیز در پردازنده های موازی مناسب است که با بهره برداری از موازی سازی بین پنجره های مختلف و یا در داخل محدوده ی هر پنجره پیاده سازی می شود.^[۱]

پردازش پرس و جو

از آنجایی که نمونه های اولیه بسیاری وجود دارد یک معماری استاندارد وجود ندارد.با این حال، اکثر DSMS ها مبتنی بر پردازش پرس و جو در DBMS از تعریف زبان برای بیان پرس و جو ها استفاده می کند که در نهایت به یک طرح از عامل ها ترجمه می شود. این برنامه می تواند به بهینه سازی و اجرا شده است. یک پردازش پرس و جو اغلب شامل مراحل زیر می باشد.

فرمول بندی پرسو جو های مستمر

فرمول بندی پرس و جو ها عمدتا با استفاده از زبان اعلانی مانند SQL در DBMS انجام می شود. از آنجا که هیچ زبان استاندارد پرس و جو برای بیان پرس و جو های مستمر وجود ندارد، اما تعداد زیادی زبان و تفاوت بین زبان ها وجود دارد. اما بسیاری از آنها بر اساس SQL هستند مانند زبان پرس و جو مستمر (CQL) و StreamSQL و EPL. روش های گرافیکی ای هم هستند که هر گام پردازش به وسلیه ی یک جعبه و جریان پردازش توسط فلش هایی بین جعبه ها نمایش داده می شود.

زبان به شدت بستگی به مدل پردازش دارد. برای مثال اگر پنجره ها در حال استفاده برای پردازش هستند، تعریف یک پنجره باید بیان شود. در StreamSQL یک پرس و جو با پنجره های کشویی برای 10 عنصر آخر به نظر مانند شرح زیر است:

این جریان به طور مداوم میانگین "قیمت" 10 تاپل اخیر را محاسبه می کند، اما فقط آن تاپل هایی را مد نظر می گیرد که قیمت آن ها بیتشر از اما تنها نظر آن چندتایی که قیمت ها بیشتر از 100.0.

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

بهینه سازی پرس و جو ها

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

علاوه بر این تکنیک های بهینه سازی مبتنی بر قیمت مانند آنچه در DBMS هست،وجود دارد که در آن یک طرح پرس و جو با کمترین هزینه از بین طرح های پرس و جوی متفاوت معادل انتخاب می شود.انتخاب ترتیب دو عامل الحاق پی در پی مثالی از آن می باشد. در DBMS این تصمیم عمدتا توسط یک روش خاص به وسیله ی پایگاه داده های درگیر انجام می شود، اما از آنجا که داده های یک جریان داده نامعلوم هستند، در DSMS این چنین روش هایی وجود ندارد.با این حال می توان یک جریان داده را برای مدت زمان مشخصی مشاهده کرد و مقداریاطلاعات از آن به دست آورد.با استفاده از این اطلاعات، پرسو جوی موردنظر می تواند بعدا بهینه شود. بنابراین برخلاف یک DBMS بعضی از DSMS ها به پرس و جو ها اجازه ی این را می دهند که در زمان اجرا هم بهینه شوند.بنابراین یک DSMS نیازمند استراتژی هایی برای جایگزینی طرح یک پرس و جوی در حال اجرا با یک پرس و جوی جدید است.

انتقالات پرس و جو ها

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

اجرای پرس و جو ها

سیستم های مدیریت جریان داده

SQLstream
جریان خطای یادکرد: برچسب <ref> غیرمجاز؛ یادکردهای بدون محتوا باید نام داشته باشند. ().

شفقهایخطای یادکرد: برچسب <ref> غیرمجاز؛ یادکردهای بدون محتوا باید نام داشته باشند. ().

StreamBase Systems, Inc.

TelegraphCQ خطای یادکرد: برچسب <ref> غیرمجاز؛ یادکردهای بدون محتوا باید نام داشته باشند. ().

NiagaraCQباخطای یادکرد: برچسب <ref> غیرمجاز؛ یادکردهای بدون محتوا باید نام داشته باشند. ().

همچنین نگاه کنید

پردازش رویداد مجتمع
پردازش جریان رویداد
سیستم مدیریت جریان داده رابطه ای

منابع

↑ De Matteis, Tiziano; Mencagli, Gabriele (25 March 2016). "Parallel Patterns for Window-Based Stateful Operators on Data Streams: An Algorithmic Skeleton Approach". International Journal of Parallel Programming. doi:10.1007/s10766-016-0413-x.

[1] De Matteis, Tiziano; Mencagli, Gabriele (25 March 2016). "Parallel Patterns for Window-Based Stateful Operators on Data Streams: An Algorithmic Skeleton Approach". International Journal of Parallel Programming. doi:10.1007/s10766-016-0413-x.

[۱]

@@ خط ۱: / خط ۱: @@
+یک '''سیستم مدیریت جریان داده ''' (DSMS) یک برنامه کامپیوتری برای مدیریت مستمر جریان داده است که شبیه به یک [[پایگاه داده‌ها|سیستم مدیریت پایگاه داده]] (DBMS) است که برای داده های استاتیک در پایگاه داده های مرسوم طراحی شده است.یک DSMS همچنین یک پردازش پرس و جوی انعطاف پذیر را ارائه می دهد به طوری که اطلاعات مورد نیاز بیان شده می تواند با استفاده از آن نمایش داده شود. اما در مقایسه با یک DBMS یک DSMS ''یک پرس و جو'' مستمر را اجرا می کند که نه تنها یک بار انجام می شود، بلکه به طور دائم نصب شده است. بنابراین پرس و جو به طور مداوم تا زمانی که آن را به صراحت حذف نکنیم، اجرا می شود. از آنجا که اکثر DSMS ها data-driven هستند، یک پرس و جوی مستمر تا زمانی که داده های جدید وارد سیستم می شود، نتایج جدید تولید می کند. این مفهوم اساسی شبیه به پردازش رخداد مجتمع است به طوری که هردو فناوری تا حدودی یکی هستند.
-#تغییر_مسیر [[سیستم مدیریت جریان داده]]
-{{R from move}}
+== اصل عملکردی ==
+یکی از مهم ترین ویژگی های یک DSMS امکان رسیدگی به طور بالقوه و همزمان به جریان داده هایی است که بی نهایت و به سرعت در حال تغییر هستند، اگر چه منابعی مانند حافظه ی اصلی محدود هستند. جدول زیر اصول مختلف DSMS را ارائه می کند و آنها را با DBMS سنتی مقایسه می کند.
+{| style="margin-bottom: 58px;" border="1"
+! سیستم مدیریت پایگاه داده (DBMS)
+! جریان داده های سیستم مدیریت (DSMS)
+|-
+|داده های ماندگار (روابط)
+|جریان داده های فرار<br>
+|-
+|با دسترسی تصادفی
+|دسترسی ترتیبی
+|-
+|پرس و جو های یک باره<br>
+|پرس و جوهای مداوم و مستمر<br>
+|-
+|(از لحاظ تئوری) فضای ذخیره سازی ثانویه نامحدود<br>
+|حافظه اصلی محدود<br>
+|-
+|تنها به حالت فعلی وابسته است
+|ترتیب ورودی را در نظر می گیرد<br>
+|-
+|نرخ به روز رسانی نسبتا پایین<br>
+|به طور بالقوه نرخ به روز رسانی بسیار بالا
+|-
+|نیازمندی های کم<br>
+|نیازمندی های بلادرنگ<br>
+|-
+|داده های دقیق را دریافت می کند<br>
+|داده های منسوخ یا نادرست را دریافت می کند<br>
+|-
+| پردازش پرس و جو قابل برنامه ریزی وارد می شود<br>
+|داده های متغیر و مشخصات داده ها وارد می شود<br>
+|}
+== مدل های پردازش و جریان ==
+یکی از بزرگترین چالش هایی که یک DSMS دارد، رسیدگی به طور بالقوه به بی نهایت جریان داده با استفاده از یک مقدار ثابت از حافظه و هیچ گونه دسترسی تصادفی به داده ها است. روش های مختلفی به منظور محدود کردن مقدار داده ها در یک گذر وجود دارد که می توان آن ها را به دو نوع تقسیم کرد. نوع اول تکنیک های فشرده سازی است که سعی می کند داده هارا خلاصه کند و نوع دوم تکنیک های پنجره است که سعی می کند داده ها را به بخش های محدود تقسیم کند.
+=== فشرده سازسی ===
+ایده پشت تکنیک های فشرده سازی این است که تنها یک خلاصه ای از داده ها، اما نه همه (خام) نقاط داده ها از جریانی از داده ها حفظ می شود. الگوریتم ها به وسیله ی استفاده از هیستوگرام ها و یا طراحی، طیف وسیعی از نقاط تصادفی داده ها را به عنوان نمونه برای خلاصه سازی انتخاب می کند. یک مثال ساده از یک فشرده سازی محاسبه مداوم یک معدل است. به جای به خاطر سپردن هر نقطه داده ها، فشره سازی تنها حاصل جمع و تعداد موارد را نگه می دارد. معدل با تقسیم این حاصل جمع بر تعداد محاسبه می شود. با این حال باید ذکر شود که فشره سازی نمی تواند منعکس کننده اطلاعات دقیق باشد. بنابراین یک پردازش که بر اساس فشره سازی است  ممکن است نتایج نادرست تولید کند.
+=== پنجره ها ===
+به جای استفاده از سیناپس برای فشرده سازی مشخصات کل جریان داده، تکنیک پنجره تنها به یک بخش از داده ها نگاه می کند. این روش براساس این ایده که تنها داده های اخیر مناسب هستند، عمل می کند. بنابراین یک پنجره به طور مداوم بخشی از جریان داده ها را برش می دهد.به عنوان مثال ده عنصر اخیر جریان داده ها در طول پردازش مورد استفاده قرار می گیرند. انواع مختلفی از این پنجره ها وجود دارد مانند پنجره های کشویی که شبیه به لیست [[خروج به ترتیب ورود (رایانه و الکترونیک)|FIFO]] است و یا پنجره های  لغزان که بخش های متلاشی شده را برش می دهد. علاوه بر این پنجره ها می توانند براساس عناصرشان نیز فرق گذاشته شوند، به عنوان مثال در نظر گرفتن ده عنصر آخر و یا براساس زمان فرق گذاشته شوند و ده ثانیه ی آخر داده ها در نظر گرفته شوند. همچنین روش های مختلفی برای پیاده سازی پنجره ها وجود دارد. برای مثال روش هایی موجود است که از برچسب زمانی و یا فواصل زمانی برای پنجره های سیستم گسترده یا پنجره های مبتنی بر بافر برای هر گام پردازش استفاده می کند. پردازش پرس و جو ای پنجره های کشویی نیز در پردازنده های موازی مناسب است که با بهره برداری از موازی سازی بین پنجره های مختلف و یا در داخل محدوده ی هر پنجره پیاده سازی می شود.<ref>{{cite journal|title=Parallel Patterns for Window-Based Stateful Operators on Data Streams: An Algorithmic Skeleton Approach|last2=Mencagli|first2=Gabriele|date=25 March 2016|journal=International Journal of Parallel Programming|doi=10.1007/s10766-016-0413-x|last1=De Matteis|first1=Tiziano}}</ref>
+== پردازش پرس و جو ==
+از آنجایی که نمونه های اولیه بسیاری وجود دارد یک معماری استاندارد وجود ندارد.با این حال، اکثر DSMS ها مبتنی بر پردازش [[بازیابی اطلاعات|پرس و جو]] در DBMS از تعریف زبان برای بیان پرس و جو ها استفاده می کند که در نهایت به یک طرح از عامل ها ترجمه می شود. این برنامه می تواند به بهینه سازی و اجرا شده است. یک پردازش پرس و جو اغلب شامل مراحل زیر می باشد.
+=== فرمول بندی پرسو جو های مستمر ===
+فرمول بندی پرس و جو ها عمدتا با استفاده از زبان اعلانی مانند [[اس‌کیوال|SQL]] در DBMS انجام می شود. از آنجا که هیچ زبان استاندارد پرس و جو برای بیان پرس و جو های مستمر وجود ندارد، اما تعداد زیادی زبان و تفاوت بین زبان ها وجود دارد. اما بسیاری از آنها بر اساس [[اس‌کیوال|SQL]] هستند مانند زبان پرس و جو مستمر (CQL)  و StreamSQL و EPL. روش های گرافیکی ای هم هستند که هر گام پردازش به وسلیه ی یک جعبه و جریان پردازش توسط فلش هایی بین جعبه ها نمایش داده می شود.
+زبان به شدت بستگی به مدل پردازش دارد. برای مثال اگر پنجره ها در حال استفاده برای پردازش هستند، تعریف یک پنجره باید بیان شود. در StreamSQL یک پرس و جو با پنجره های کشویی برای 10 عنصر آخر  به نظر مانند شرح زیر است:<source />این جریان به طور مداوم میانگین "قیمت"  10 تاپل اخیر را محاسبه می کند، اما فقط آن تاپل هایی را مد نظر می گیرد که قیمت آن ها بیتشر از اما تنها نظر آن چندتایی که قیمت ها بیشتر از 100.0.
+در مرحله بعد پرس و جو اعلان شده به یک طرح پرس و جوی منطقی ترجمه می شود. یک طرح پرس و جو یک گراف جهت دار است که در آن گره ها، عامل ها هستند و یال ها جریان پردازش را توصیف می کنند. هر عامل در طرح پرس و جو معنا و مفهوم یک عمل خاص مانند فیلتر کردن و یا تجمع را کپسوله می کند. در DSMS ها که جریان داده های رابطه ای را پردازش می کند، عامل ها برابر و یا شبیه به عامل های [[جبر رابطه‌ای|جبر رابط ای]] هستند.بنابراین عامل هایی برای انتخاب، عضویت و عملیات مجموعه ها موجود است. این ویژگی عامل ها اجازه می دهد تا پردازش یک DSMS بسیار انعطاف پذیر و همه کاره باشد.
+=== بهینه سازی پرس و جو ها  ===
+طرح پرس و جو منطقی را می توان بهینه سازی کرد که به شدت بستگی به مدل جریان دارد. مفاهیم اولیه برای بهینه سازی پرس و جو های مداوم و مستمر مانند همان هایی است که در سیستم های پایگاه داده استفاده می شود. اگر جریان داده های رابطه ای وجود دارشته باشد و طرح پرس و جوی منطقی مبتنی بر عامل های رابطه ای از [[جبر رابطه‌ای|جبر رابطه ای]] باشد، یک بهینه ساز پرس و جو می تواند از هم ارزی جبری برای بهینه سازی این طرح استفاده کند.
+علاوه بر این تکنیک های بهینه سازی مبتنی بر قیمت مانند آنچه در DBMS هست،وجود دارد که در آن یک طرح پرس و جو با کمترین هزینه از بین طرح های پرس و جوی متفاوت معادل انتخاب می شود.انتخاب ترتیب دو عامل الحاق پی در پی مثالی از آن می باشد. در DBMS این تصمیم عمدتا توسط یک روش خاص به وسیله ی پایگاه داده های درگیر انجام می شود، اما از آنجا که داده های یک جریان داده نامعلوم هستند، در DSMS این چنین روش هایی وجود ندارد.با این حال می توان یک جریان داده را برای مدت زمان مشخصی مشاهده کرد و مقداریاطلاعات از آن به دست آورد.با استفاده از این اطلاعات، پرسو جوی موردنظر می تواند بعدا بهینه شود. بنابراین برخلاف یک DBMS بعضی از DSMS ها به پرس و جو ها اجازه ی این را می دهند که در زمان اجرا هم بهینه شوند.بنابراین یک DSMS نیازمند استراتژی هایی برای جایگزینی طرح یک پرس و جوی در حال اجرا با یک پرس و جوی جدید است.
+=== انتقالات پرس و  جو ها  ===
+از آنجایی که یک عملگر منطقی تنها مسئول معانی یک عمل هستند، اما شامل هیچ الگوریتمی نیستند. طرح پرس و جو منطقی باید تبدیل به یک فایل اجرایی شود. این عمل یک طرح پرس و جوی فیزیکی نامیده می شود. تمایز بین طرح عملگر منطقی و فیزیکی اجازه می دهد تا بیش از یک پیاده سازی برای یک عملگر منطقی ممکن باشد. برای مثال, عملگر الحاق از نظر منطقی یکی است، اگر چه می توان آن را توسط الگوریتم های مختلف مانند یک حلقه تو در تو پیوستن و یا مرتب کردن بر اساس ادغام پیوستن  پیاده سازی کرد.توجه کنید که این الگوریتم ها نیز به شدت وابسته به  جریان استفاده شده و مدل پردازش
+است.در نهایت یک پرس و جو به عنوان یک طرح پرس و جو فیزیکی در دسترس خواهد بود.
+=== اجرای پرس و جو ها ===
+== سیستم های مدیریت جریان داده ==
+* [http://www.sqlstream.com/stream-processing/ SQLstream]
+* [http://www-db.stanford.edu/stream جریان] <ref />
+* [http://www.cs.brown.edu/research/aurora/ شفق]های<ref /> [http://www.streambase.com/ StreamBase Systems, Inc.]
+* [http://telegraph.cs.berkeley.edu/telegraphcq/ TelegraphCQ] <ref />
+* [http://research.cs.wisc.edu/niagara/ NiagaraCQ]با<ref />
+* [http://wwwdb.inf.tu-dresden.de/research-projects/closed-projects/qstream/ QStream]
+* [http://dbs.mathematik.uni-marburg.de/Home/Research/Projects/PIPES لوله]های [http://www.softwareag.com/de/products/wm/events/overview/default.asp webMethods وقایع کسب و کار]
+* [http://www-db.in.tum.de/research/projects/StreamGlobe/index.shtml StreamGlobe]
+* [http://odysseus.informatik.uni-oldenburg.de/ اودیسه]
+* [http://www.microsoft.com/sqlserver/en/us/solutions-technologies/business-intelligence/streaming-data.aspx StreamInsight]
+* [http://www-01.ibm.com/software/data/infosphere/streams/ InfoSphere جریان]
+* [http://www.sas.com/en_us/software/data-management/event-stream-processing.html SAS رویداد جریان پردازش موتور]
+* [http://go.sap.com/uk/product/data-mgmt/complex-event-processing.html SAP رویداد جریان پردازنده]
+* [https://www.pipelinedb.com/ خط لوله DB]
+== همچنین نگاه کنید  ==
+* پردازش رویداد مجتمع<br>
+* پردازش جریان رویداد<br>
+* سیستم مدیریت جریان داده رابطه ای<br>
+== منابع ==
+{{Reflist}}
+[[رده:مدیریت داده‌ها]]