I work for a certain agency which maintains a list of names of individuals who are on a "no-fly" list. Every day, sometimes several times per day, we get updates to this list, which can have tens of thousands of names on it.
At the same time, we receive lists of passenger ticket bookings from around the globe...this list, as you can imagine, is absolutely massive. At the moment it's around 150 gigabytes per day, as it contains passenger names, dates of birth, locations of departure, destination, payment details, travel agency (if used) and much, much more.
The question is, what's the most efficient way, in Splunk, to cross-reference these lists and only find, on a given day, or even within a given hour (happy with a sliding search and summary-index, if needed), those people on our no-fly list on the much larger all-passenger list?
Making a query like so is hardly efficient:
index=travellers [ search index=nofly | fields name]
As that would result in Splunk "parsing" the search and realising it's essentially being asked to do:
index=travellers (jane OR bill OR eve OR bob OR ... )
Where the OR clause could be tens of thousands of names long.
I've pondered creating a summary-index of just the traveller names from the travellers index, which would be a smaller amount of data, but would still take considerable time to extract, and would also need at least the Date of Birth and likely other fields as it turns out a lot of humans share the same name, and that can get rather embarrassing when adding people to the no-fly list, let me tell you.
The typical approaches that I've used for other queries work great when the data set is small, but at the scale we're looking at here, it becomes a painfully slow process. Obviously, we could throw more hardware at the problem, as our agency budget is unrestricted and no one is allowed to question it, but I'm hoping that there's a much better way to do this and ensure that we have optimal tracking of people on the no-fly list with all potential travellers.
Thanks!
NB: (I jest; this isn't really what I'm trying to compare, it's just a great example of the type and scale of data)
... View more