kdb - customized data streaming/ticker plant?

Viewed 61

We've been using kdb to handle a number of calculations focused more on traditional desktop sources. We have deployed our web application and are looking to make the leap as to how best to pick up data changes and re-calculate them in kdb to render a "real-time" view of the data as it changes.

From what I've been reading, the use of data loaders(feed handlers) into our own equivalent of a "ticker plant" as a data store is the most documented ideal solution. So far, we have been "pushing" data into kdb directly and calculating as part of a script so we are trying to make the leap from calculation-on-demand to a "live" calculation as data inputs are edited by user.

I'm trying to understand how to manage the feed handlers and timing of updates. We really only want to move data when it changes (web-front end so trying to figure out how best to "trigger" when things change (such as save or lost focus on an editable data grid for example.) We are also thinking our database as the "ticker plant" itself which may minimize feedhandlers.

I found a reference below and it looks like its running a forever-loop which feels excessive but understand the original use case for kdb and streaming data. Feedhandler - sending data to tickerplant

Does this sound like a solid workflow?

Many thanks in advance!

Resources we've referencing:

  1. Official Manual -https://github.com/KxSystems/kdb/blob/master/d/tick.htm

  2. kdb+ Tick overview: http://www.timestored.com/kdb-guides/kdb-tick-data-store

  3. Source code: https://github.com/KxSystems/kdb-tick

1 Answers

There's a lot to parse here but some general thoughts/ideas:

  • Yes, most examples of feedhandlers are set up as forever loops but this is often just for convenience for demoing.
  • Ideally a live data flow should work based on event handling, aka on-event triggers. Kdb/q has this out of the box in the form of the .z handlers. Other languages should have similar concepts of event handling
  • Some more examples of python/java feeders are here: https://github.com/exxeleron
  • There's also some details on the official Kx site: https://code.kx.com/q/wp/capi/#publishing-to-a-kdb-tickerplant
  • It still might be a viable option to have a forever loop, or at least a short timer in the event you want to batch data.
  • Depending on the amount of dataflow a tickerplant might be overkill for your use-case, but a tickerplant is still useful for (a) separating your processing from the processing of dataflow (i.e. data can still flow through the tickerplant while another process is consuming/calculating) and (b) logging data for recovery purposes.
Related