gistfile1.txt

<mulander> Hi all, is riak a good choice for collecting and analyzing device readouts? 
A single readout is a tuple of integers, the number of parameter and their meaning depends 
on the device. Processing will involve drawing conclusions from the data (long term analysis 
doesn't have to be performed instantly and can be prepared for) plus some instant feedback 
(comparing current trend to a predefined set of redouts). 

07:36 <mulander> forgot to mention that readouts are associated to a single entity and 
short term comparisons are performed between average redouts of entities 

07:36 <seancribbs> mulander: it really depends more on whether you can map that data into a 
scheme that is key-value 

07:36 <seancribbs> i.e. device_id+timestamp where timestamp is at regular intervals 

07:37 <seancribbs> or something like that 

07:37 <mulander> entity:device:parameter:stamp : value ? 

07:37 <seancribbs> that can work, yep 

07:37 <marksteele> does restart reload config file? 

07:37 <seancribbs> but you wouldn't need to get that fine-grained 

07:38 <seancribbs> marksteele: restart calls 
init:restart(). http://erldocs.com/R14B/erts/init.html?i=0&search=init:rest#restart/0 

07:39 <marksteele> so yes? 

07:39 <marksteele> :) 

07:39 <mulander> I assume that a single key can have more complex data attached to it? ie. 
the whole readout tuple? 

07:39 <seancribbs> marksteele: yes, i believe so 

07:39 <seancribbs> mulander: values in Riak are opaque to the store, so you'd probably want to 
store data together that is tightly coupled 

07:39 <mulander> sorry for asking obvious things, started to evaluate riak for a project and as 
of now it's coming out on top because of most behaviour characteristics 

07:40 <seancribbs> that's great, we love to hear that. 

07:40 <seancribbs> now, if you're using Erlang for some of the other bits, you 
could just store terms (tuples, for example) 

07:41 <mulander> I also saw an offer regarding startups I assume this is still true? 

07:41 <seancribbs> yes 

07:41 <seancribbs> we recommend you get started on the open-source version first 

07:41 <mulander> this also was a factor :) (but if you are curious - plug and play 
nodes + replication and sharding were more important) 

07:42 <seancribbs> :) 

07:42 <mulander> seancribbs: that's what we are planning - still having 
the option is viable. 

07:42 <seancribbs> are you intending to deploy in your own datacenter or on a provider 

07:42 <mulander> I'm not responsible for the target architecture but I would guess 
we will control it. 

07:42 <seancribbs> ok 

07:43 <seancribbs> if not I was going to suggest Joyent since they have preconfigured machines 

07:43 <mulander> I'll take a note of this. 

07:43 <seancribbs> one word of warning: set your ring_creation_size before you start up your cluster 

07:44 <seancribbs> i.e. before you start ANY node 

07:44 <seancribbs> once it's set you can't change it 

07:44 <mulander> noted. 

07:44 <mulander> I'm impressed by the currently available documentation. 

07:44 <mulander> it beats the competition hands down. 

07:44 <seancribbs> mulander: that's refreshing to hear. :) 

07:45 <seancribbs> we try to be transparent about things 

07:45 <mulander> generally I'm impressed about most of the things I saw regarding riak :) 

07:45 <mulander> you are doing a great job. 

07:45 <mulander> also the provided datasets for testing is a brilliant touch :) 

07:45 <seancribbs> well feel free to ask any questions. if you want a contact person 
for the EDS 4 startups thing, let me know 

07:46 <mulander> I think it's in to early stages to start with EDS 4 startup offer 
07:48 <mulander> but I will definetly make notice as soon as we may need it