Few of those applications are satisfied by single-row or other tiny result sets; most require real analytic queries. That is, they’re on the analytic side of the short-request/analytic boundary.

Since a lot of customer response applications use tiny result sets, I imagine those two features are not coincidental. Even so, some customer-response applications can benefit from serious real-time analysis, such as graph-analytic techniques, which can be applied to antifraud and influencer-identifying anti-churn alike.

And thus I’ve shown that a list of bullet points, sized to fit on a single marketing slide, is imperfect. Oh, the humanity!

Comments

A frustrating limitation of low-latency or “real-time” analytics is the absence of visualization systems designed to be driven that way for many application domains.

If you have a logically contiguous model of reality that supports a very high update rate — some geo-sensing databases are like this — then it becomes a problem of detecting intersections with a visualization viewport on the backend and pushing that event to the frontend. For these applications it is not efficient to poll the database nor to let the visualization client decide what to render by drinking from the firehose. The backend needs to decide if an update needs to be rendered in a current visualization context and push it there.

While it is possible to build backends like this it turns out that it is quite difficult to find existing visualization frontends that are designed to support this “real-time” use case. Some of the closest software designs architecturally are server-rendered game engines. Real-time is cool but there seems to be little support for it on the frontend except for the trivial cases that fit inside the old models, which is a limiting factor.