|
|
Sponsored Content
Special Forums
UNIX and Linux Applications
Virtualization and Cloud Computing
No bottlenecks in Complex Event Processing for Real-time BI
Post 302226447 by Linux Bot on Tuesday 19th of August 2008 04:40:03 AM
08-19-2008
No bottlenecks in Complex Event Processing for Real-time BI
vincent
08-18-2008 04:54 PM
A few BI-related posts show how CEP and CEP-related thinking is starting to trickle into conventional thinking on Business Intelligence.
First off, Intelligent Enterprise reports on some solutions to the problems of using data warehouses for real-time BI. Note that the solutions offered include Event Stream Processing (although why Forrester references ESP instead of CEP is a mystery only known to the analyst who authored this report - unless there is an expectation that just simple streamed correlations can be done in real-time analytics?) [*1].
Secondly,* Jerry Held relates in 2 articles how cloud computing will “save the day” for BI. In a nutshell, Jerry’s hypothesis is that a lack of cheap distributed computing resources are what is holding back BI, and clouds of massively parallel operations on huge datasets will be BI’s saviours. Jerry, methinks, is ahead of his time, as I can’t see data warehouses migrating to the clouds without large doses of security provisions and even cheaper bandwidth. But certainly the idea of highly parallel and scalable event+data processing operations is here today…
Notes:
[1] IE also suggests “informational fabric” for real-time BI. This is “the real-time in memory, distributed caching infrastructure embedded in a service-oriented architecture or enterprise service bus for analytic and transactional apps.” This is also CEP-relevant - the TIBCO BusinessEvents CEP platform includes such a data grid.
Source...
08-18-2008 04:54 PM
A few BI-related posts show how CEP and CEP-related thinking is starting to trickle into conventional thinking on Business Intelligence.
First off, Intelligent Enterprise reports on some solutions to the problems of using data warehouses for real-time BI. Note that the solutions offered include Event Stream Processing (although why Forrester references ESP instead of CEP is a mystery only known to the analyst who authored this report - unless there is an expectation that just simple streamed correlations can be done in real-time analytics?) [*1].
Secondly,* Jerry Held relates in 2 articles how cloud computing will “save the day” for BI. In a nutshell, Jerry’s hypothesis is that a lack of cheap distributed computing resources are what is holding back BI, and clouds of massively parallel operations on huge datasets will be BI’s saviours. Jerry, methinks, is ahead of his time, as I can’t see data warehouses migrating to the clouds without large doses of security provisions and even cheaper bandwidth. But certainly the idea of highly parallel and scalable event+data processing operations is here today…
Notes:
[1] IE also suggests “informational fabric” for real-time BI. This is “the real-time in memory, distributed caching infrastructure embedded in a service-oriented architecture or enterprise service bus for analytic and transactional apps.” This is also CEP-relevant - the TIBCO BusinessEvents CEP platform includes such a data grid.
Source...
|
|
LEARN ABOUT DEBIAN
trickle
TRICKLE(1) BSD General Commands Manual TRICKLE(1) NAME
trickle -- a lightweight userspace bandwidth shaper SYNOPSIS
trickle [-h] [-v] [-V] [-s] [-d rate] [-u rate] [-w length] [-t time] [-l length] [-n path] [-P path] command ... DESCRIPTION
trickle is a userspace bandwidth manager. Currently, trickle supports the shaping of any SOCK_STREAM (see socket(2)) connection established via the socket(2) interface. Furthermore, trickle will not work with statically linked executables, nor with setuid(2) executables. trickle is highly configurable; download and upload rates can be set separately, or in an aggregate fashion. The options are as follows: -h Displays help. -v Increases the verbosity level (can be specified multiple times). -V Prints version. -s Runs trickle in standalone mode, independent of trickled(8). -d rate Limit the download bandwidth consumption to rate KB/s. -u rate Limit the upload bandwidth consumption to rate KB/s. -w length Set peak detection window size to length KB. This determines how aggressive trickle is at eliminating bandwidth consumption peaks. Lower values will be more aggressive, but may also result in over shaping. The default value (512 KB) is usually suffi- cient. -t seconds Set smoothing time to seconds s. The smoothing time determines with what intervals trickle will try to let the application transceive data. Smaller values will result in a more continuous (smooth) session, while larger values may produce bursts in the sending and receiving data. Smaller values (0.1 - 1 s) are ideal for interactive applications while slightly larger values (1 - 10 s) are better for applications that need bulk transfer. -l length Set smoothing length to length KB. The smoothing length is a fallback of the smoothing time. If trickle cannot meet the requested smoothing time, it will instead fall back on sending length KB of data. The default value is 10 KB. -n path Use trickled(8) socket path to communicate with trickled(8). By default, /tmp/.trickled.sock is used. -P path Use the specified .so instead of the standard one, this is usefull if you don't run trickle from a standard installation. EXAMPLES
trickle -u 10 -d 20 ncftp Launch ncftp(1) limiting its upload capacity to 10 KB/s, and download capacity at 20 KB/s. SEE ALSO
trickled(8), syslog(3), socket(2), netintro(4) AUTHORS
trickle has been developed by Marius Aamodt Eriksen <marius@monkey.org>. BUGS
Does not support executables utilizing kqueue(2). Does not support statically linked executables. BSD
November 10, 2002 BSD