Conceptual Analogies

<< Click to Display Table of Contents >>

Navigation:  Understanding Streaming SQL Concepts >

Conceptual Analogies

Previous pageReturn to chapter overviewNext page

Relational Databases

There are many similarities between the SQLstream s-Server and a relational database (RDBMS). Most importantly, both use the industry-standard Structured Query Language (SQL).

The main differences can be summarized in this table:

Concept

RDBMS

SQLstream

Data

Stored persistently

Flowing

Query

Static

Re-executed frequently

Live QueriesTM :

Active, continuous execution

Execution

Control

Application

calls RDBMS.

SQLstream calls

Application.

Publish/Subscribe Message-Oriented Middleware

Publish/subscribe ("pub/sub") systems are typically organized into a hierarchy of topics. The topics in that hierarchy offer a moderate amount of flexibility for content-based subscription. That is, the fields and metadata within each message can be used to determine which messages a subscriber will receive, based on a simple SQL, XPath or regular expression using that message content. Content-based subscriptions for different MOMs are implemented differently, rather than using a standard adhered to by all.

These pub/sub systems are not as flexible as the predicate-based filtering and routing offered by a relational SQL-based system. SQLstream's streaming queries provide a more powerful subscription capability, as follows:

By starting with a top-level message stream, that is, the first in a cascade, a cascading network of SQL views in SQLstream can create the equivalent of a dynamic publish/subscribe topic tree:

Publishers INSERT INTO ... the message stream through JDBC, or even through a JMS driver.
Subscribers SELECT STREAM * FROM ... the view representing the logical "topic," which can filter by tags in the message itself.
Unlike message-oriented middleware, SQLstream s-Server can join message streams.
This join capability allows SQLstream to filter content based on lookup information that is not directly contained in the message. Complex SQL can thus use multiple message attributes to create "calculated topics," beyond any original topic list, or even create time-based "aggregated topics," offering hourly or daily roll-ups of the published messages.

Since there is no automatic provision for storing messages if the subscriber is not connected, standard SQLstream subscriptions are non-durable in JMS terms.

A SQLstream application can transform messages as well as routing and delivering them. It accomplishes this through the pipeline of streams and views. The additional power of SQL views enables SQLstream to transform messages "on the wire" to match the needs of each receiver. In other words, the same message published by system A can be received by systems B and C in two different formats. At the same time, a compliance view can be "watching" the same message traffic and logging audit data or sending alerts. It's as if the single package you send with FedEx can be received in distinct variations by multiple recipients using different carriers, and you get a log of all the deliveries.