<div dir="ltr"><div>Dear folks</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="auto"><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="auto"><div dir="ltr"><div dir="auto">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?</div></div></div></div></blockquote><div><br></div>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. </div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Would this "aggregation app" be a general purpose utility, or does it have to be tailored to each application such as building sensing?</div><div dir="auto">If it's general purpose, how could the app understand the specific naming and encoding format of building sensing protocol?</div></div></div></blockquote><div><br></div>I would expect it to be designed in concert with the data logging application -- it could start off being single purpose but you might find that it generalizes.  In the same way that a SQL query has to know the naming and encoding of data in tables.</div></div></blockquote><div><br></div><div>I'm smelling <a href="http://www.named-function.net/">Named Function Networking</a> here: each data logging application could design its aggregation feature as a named function, that is executed on the same node as the repo.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> <br><blockquote type="cite"><div><div dir="auto"><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> 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.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div></div></div></blockquote><blockquote type="cite"><div><div dir="auto"><div dir="auto"><br></div><div dir="auto">If using disk access, what's the benefit of having it as a separate app?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div></div></div></blockquote><div><br></div><div>This is a pretty raw view of my reasoning, having thought about the problem for all of 10 minutes:</div><div><br></div>I'd design it as Interest-Data exchanges to start with, then I'd measure the system performance to see if it was acceptable and if it's scaling properties met my requirements, and if it wasn't performing/scaling reasonably then I'd look at where the problem was and design a solution that addressed the problem.  I am a fan of optimizing implementation/architecture based on actual measurement -- though of course one's choices should be informed by theoretical complexity issues... but the constants matter too!</div><div><br></div><div>I don't immediately come to the same conclusion as you do about a SQL query vs an application such as I'm describing.</div><div><br></div><div>Remember that the repo (at least the one I worked on & with) stores everything in wire-format packets.  It happened to use B-trees with pages of comparable size to a disk page so the I/O performance was good, there were many (if they were small) content packets in a B-tree block and there was caching of the B-tree blocks so the overhead for reading multiple sequential items was minimized.</div></div></blockquote><div><br></div><div>The B-tree appears to refer to CCNx 0.7.2 repo.</div><div>NDN's repo implementations are worse: all three known implementations use some form of database (SQLite, PosgreSQL, or RocksDB).</div><div><br></div><div>In either case, the main difference between SQL query and Interest-Data exchanges is that, the SQL server has access to a table index that is updated automatically when a row is inserted.</div><div>The example I gave in my first message is "what's the maximum temperature among all the data points collected in a set of rooms within a time period".<br></div><div>Suppose there was an index over timestamp-room-temperature columns, the SQL server can answer this question by reading just the index and a small number of rows (I know it's a very specialized index, but such index was mandatory during the early days of Google App Engine and can be created automatically with their development tools).</div><div>On the other hand, the repo has to pass every data point from these rooms in the requested time period to the aggregation app, incurring a much larger overhead.</div><div>Thus, the key of the issue is: SQL server can have index over columns needed for aggregation, while repo + aggregation app cannot add arbitrary index.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>The only *encoding* operation should be on the aggregation results.</div></div></blockquote><div><br></div><div>I should have said "decoding".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>All of the forwarding operations should be in-memory.  I doubt that you can get zero-copy from the in-memory repo packet through to the aggregation application's buffer, but it shouldn't be massively bad.</div><div><br></div><div>There are analogous operations in both the repo and SQL cases -- SQL is going to be interpreting a table schema to drive accesses to table data stored on disk (and cached in memory) and decoding and applying the operations from the query etc. etc.  For both SQL and stored content objects you'll be making data representation choices that affect the speed of the operations you'll be doing (e.g., storing measurements as text or binary values).</div><div><br></div><div>People have cared for some time that SQL databases had good performance... so a lot of time has been spent optimizing them.</div><div>Nobody has spent a lot of time optimizing repo query tools, and the supporting NDN components, but I think it would have a good payoff for many applications if someone did.</div></div></blockquote><div><br></div><div>Why should we spend time on optimizing "repo query tools", instead of reusing existing efforts of good enterprise-grade SQL databases?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">>From this discussion it almost seems like these repos should act as NDN adapters to existing storage and grid storage solutions providing a basic but extensible naming schema.  Of course developing that naming schema and mapping can be complex.  Lots of new storage solutions like <a href="http://redis.io" target="_blank">redis.io</a> are making querying language simpler and are used in enterprise systems today.  Redis is used extensively by Discord for instance.</div></blockquote></div></div><div><br></div><div>This describes an NDN frontend of a database, where the data schema is defined per application. I can certainly have a BLOB column that stores the original Data packets coming from the sensor, in addition to individual columns of temperature, humidity, etc, so that it can serve both original Data packets and aggregation queries.</div><div>However, this would not be a repo, because a repo is supposedly general purpose and can store data from any application (as permitted by trust policy).</div><div><br></div><div>Yours, Junxiao </div></div></div>