0

Need to know if it is possible (and will have effect) to implement a b-tree within a the CEP (single corerlator). The problem we face is that we can not handle more then 1000 messages per second. I think it is caused by the way the solution has been implemented.

We want to detect if a position is wihtin a zone and raise an event on entering, stop, start and leaving zone. We have now just around 500 zones and up to more then 1000 positions per second want to increase the zones. Messages are now being back-up. I think the solutions would be introducing a B-tree within the CEP. So firts you would detect if a position is in the head zone and then query if the positons are in the zones within this head zone. I think this could increase perfomance, but not realy sure if it is possible or wise.

Has anyone had any experience?

Caribou
  • 2,070
  • 13
  • 29
Andy
  • 1
  • Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. – Gustavo Morales Jun 24 '16 at 13:07
  • That is true. But I was hoping that somebody would have experience in such a problem and my tried this path. Especially if the CEP could handle B-Tree like logic. – Andy Jun 26 '16 at 20:05
  • Hi Andy - It might be worth posting this on the new Apama Community forum also (http://www.apamacommunity.com). – moraygrieve Jul 27 '16 at 15:04
  • Ok, thanks. I will check it out. – Andy Jul 29 '16 at 05:35

1 Answers1

2

Firstly, we're deprecating the community forum in favour of answering questions here, so you're in the right place.

Secondly, the answer to your question probably needs a bit more detail about what you're doing at the moment. How are you managing your geofencing at the moment? Apama has built-in support for matching locations against rectangular areas with the location type. Using that in a hypertree expression with a listener should be very fast.

To manage other shaped geofences we'd recommend starting by using the bounding box in a listener and then doing your specific geofence calculation on events that fall within the bounding box.

To answer your question about a hierarchical approach - if the above does not help enough then you could start with corse-grained bounding boxes in an ingestion context which then delegates to multiple secondary contexts with more detailed bounding boxes again using the hypertree. These secondary contexts would be able to work in parallel.

On a single large machine we've managed to handle hundreds of thousands of location updates across thousands of geofences, although this will very much depend on what action you're taking when you get a match and what your match rate is.

HTH, Matt