Database Reference
In-Depth Information
Fast events + Big Data
Yes, this simple equation leads us to something that Oracle branded as Fast Data (
ht-
tp://www.oracle.com/us/solutions/fastdata/index.html
)
, and this is just a logical outcome
of what we have learned so far:
• We provide most (if not all) of the basic data required for the complex event iden-
tification process, as the object context in the form of key-value (or name-value)
pairs. The CQL with its
MATCH_RECOGNIZE
and data
PATTERN
definition al-
lows us to do practically everything with inbound key-value event streams;
however, the main point of the following bullets is that we have something to rely
on in terms of data model standardization, even in such a simple form as key-
value pairs.
• Oracle's own NoSQL DB is also a key-value-based, robust, and high performing
database. Actually, you can configure almost any DB to be your events store as
usual; it's all about the available driver that you should declare in the
<driver-
name>
element. You just have to remember that sometimes this kind of integra-
tion could affect the performance, which is highly important for CEP.
• As a logical continuation of the first two points in addition to the inline events
stream processing, we have the possibility to record and then playback events us-
ing Oracle's CEP/CQL capabilities. This option is very powerful, and you can
consider it in additional queues and topics.
Thus, Oracle EPN Suite provides us with a truly powerful arsenal using which we can
process events in FIFO style from streams of various sorts—including memory
caches—pile up events in the intermediary storage (NoSQL, the most popular, or in tradi-
tional RDBMS), and reprocess them at our convenience at any given time interval.
There are two main technical reasons to use this approach. Some systems have to deal
with so many events that that we simply cannot predict the message format, representing
even a basic event. Downcasting any incoming object context and describing the event to
the key-value pairs that are suitable for NoSQL storage should not impose huge diffi-
culties. Naturally, we also cannot predict events' occurrence or their frequency, so the cor-
relation and aggregation of dispersed events will require enormous computing resources
and memory in particular (yes, Oracle has the answer to these high demands as well, but
we will touch upon HW triad and the Exalytics In-Memory machine in particular a bit
later). Here again the NoSQL storage comes to the rescue.
Search WWH ::
Custom Search