Ah, forgot to add my footnote to the dirspec - we all know the link, but in any case:<br><br>[1]: <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt">https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt</a><br>

<br>This was in the context of discussing which fields from 2.1 to include.<br><br><div class="gmail_quote">On Tue, Jun 11, 2013 at 12:34 AM, Kostas Jakeliunas <span dir="ltr"><<a href="mailto:kostas@jakeliunas.com" target="_blank">kostas@jakeliunas.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

<div>> Here, I think it is realistic to try and use and import all the fields available from metrics-db-*.<br>

> My PoC is overly simplistic in this regard: only relay descriptors,
 and only a limited subset of data fields is used in the schema, for the
 import.<br>
<br>
</div>I'm not entirely sure what fields that would include. Two options come<br>
to mind...<br>
<br>
* Include just the fields that we need. This would require us to<br>
update the schema and perform another backfill whenever we need<br>
something new. I don't consider this 'frequent backfill' requirement<br>
to be a bad thing though - this would force us to make it extremely<br>
easy to spin up a new instance which is a very nice attribute to have.<br>
<br>
* Make the backend a more-or-less complete data store of descriptor<br>
data. This would mean schema updates whenever there's a dir-spec<br>
addition [1]. An advantage of this is that the ORM could provide us<br>
with stem Descriptor instances [2]. For high traffic applications<br>
though we'd probably still want to query the backend directly since we<br>
usually won't care about most descriptor attributes.<br></blockquote></div><div><br>In truth, I'm not sure here, either.  I agree that it basically boils down to either of the two aforementioned options. I'm okay with any of them. I'd like to, however, see how well the db import scales if we were to import all relay descriptor fields. There aren't a lot of them (dirspec [1]), if we don't count extra-info of course and only want to deal with the Router descriptor format (2.1). So I think I should try working with  those fields, and see if the import goes well and quickly enough. I plan to do simple python timeit / timing report macroses that may be attached / deattached from functions easily, would be simple and clean that way to measure things and so on.<br>


<br>> [...] An advantage of [more-or-less complete data store of descriptor<br>> data] is that the ORM could provide us<div class="im"><br>> with stem Descriptor instances [2]. For high traffic applications<br>> though we'd probably still want to query the backend directly since we<br>


> usually won't care about most descriptor attributes.<br><br></div>I can try experimenting with this later on (when we have the full / needed importer working, e.g.), but it might be difficult to scale indeed (not sure, of course). Do you have any specific use cases in mind? (actually curious, could be interesting to hear.) [2] fn is noted, I'll think about it.<div class="im">

<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">> The idea would be import all data as DB fields (so,
 indexable), but it makes sense to also import raw text lines to be able
 to e.g. supply the frontend application with raw data if needed, as the
 current tools do. But I think this could be made to be a separate 
table, with descriptor id as primary key, which means this can be done 
later on if need be, would not cause a problem. I guess there's no need 
to this right now.<br>
<br>
I like this idea. A couple advantages that this could provide us are...<br>
<br>
* The importer can provide warnings when our present schema is out of<br>
sync with stem's Descriptor attributes (ie. there has been a new<br>
dir-spec addition).<br>
<br>
* After making the schema update the importer could then run over this<br>
raw data table, constructing Descriptor instances from it and<br>
performing updates for any missing attributes.<br></blockquote></div><div><br>The 'schema/format mismatch report' idea sounds like a really good idea! Surely if we are to try for Onionoo compatibility / eventual replacement, but in any case, this seems like a very useful thing for the future. I will keep this in mind for the nearest future / database importer rewrite. <br>

<div class="im">
<br>> * After making the schema update the importer could then run over this<br>
> raw data table, constructing Descriptor instances from it and<br>> performing updates for any missing attributes.<br><br></div>I can't say I can easily see the specifics of how all this would work, but if we had an always-up-to-date data model (mediated by Stem Relay Descriptor class, but not necessarily), this might work.. (The ORM <-> Stem Descriptor object mapping itself is trivial, so all is well in that regard.)<br>


</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote">On Wed, May 29, 2013 at 5:49 PM, Damian Johnson <span dir="ltr"><<a href="mailto:atagar@torproject.org" target="_blank">atagar@torproject.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> Here, I think it is realistic to try and use and import all the fields available from metrics-db-*.<br>
> My PoC is overly simplistic in this regard: only relay descriptors, and only a limited subset of data fields is used in the schema, for the import.<br>
<br>
</div>I'm not entirely sure what fields that would include. Two options come<br>
to mind...<br>
<br>
* Include just the fields that we need. This would require us to<br>
update the schema and perform another backfill whenever we need<br>
something new. I don't consider this 'frequent backfill' requirement<br>
to be a bad thing though - this would force us to make it extremely<br>
easy to spin up a new instance which is a very nice attribute to have.<br>
<br>
* Make the backend a more-or-less complete data store of descriptor<br>
data. This would mean schema updates whenever there's a dir-spec<br>
addition [1]. An advantage of this is that the ORM could provide us<br>
with stem Descriptor instances [2]. For high traffic applications<br>
though we'd probably still want to query the backend directly since we<br>
usually won't care about most descriptor attributes.<br>
<div><br>
> The idea would be import all data as DB fields (so, indexable), but it makes sense to also import raw text lines to be able to e.g. supply the frontend application with raw data if needed, as the current tools do. But I think this could be made to be a separate table, with descriptor id as primary key, which means this can be done later on if need be, would not cause a problem. I guess there's no need to this right now.<br>



<br>
</div>I like this idea. A couple advantages that this could provide us are...<br>
<br>
* The importer can provide warnings when our present schema is out of<br>
sync with stem's Descriptor attributes (ie. there has been a new<br>
dir-spec addition).<br>
<br>
* After making the schema update the importer could then run over this<br>
raw data table, constructing Descriptor instances from it and<br>
performing updates for any missing attributes.<br>
<br>
Cheers! -Damian<br>
<br>
[1] <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt" target="_blank">https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt</a><br>
[2] This might be a no-go. Stem Descriptor instances are constructed<br>
from the raw descriptor content, and needs it for str(), get_bytes(),<br>
and signature validation. If we don't care about those we can subclass<br>
Descriptor and overwrite those methods.<br>
</blockquote></div><br>
</div></div></blockquote></div><br>