[Ndn-interest] Repo vs aggregation queries

[Junxiao Shi]

Hi Nick


> On the other hand, I could have a separate "database" application
> answering aggregation queries. In this case, the database application could
> easily provide individual data points as well. Then, is there any value to
> still have the repo, and store every data point twice?
>
>
> I would not add aggregation operators to to the repo.  I would, however,
> have an aggregation app serving a slightly different namespace, that was
> able to locally access the data in the repo and provide the aggregated
> result to any clients requesting it.
>

Would this "aggregation app" be a general purpose utility, or does it have
to be tailored to each application such as building sensing?
If it's general purpose, how could the app understand the specific naming
and encoding format of building sensing protocol?

 That's going to be local, not network, I/O.  The aggregated response might
> be cached, possibly in the same repo as the raw measurements.  It doesn't
> require storing the data twice.
>

Is this "aggregation app" accessing the data directly on the disk, or does
it have to send Interests to the repo via a local socket?

If using disk access, what's the benefit of having it as a separate app?

If using Interest-Data exchanges, even if the packets are local, this still
has huge overhead (encoding, forwarding, processing, etc) compared to a SQL
query on the database.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190718/24d8229a/attachment.html>