Live data from Hacker News

Time Series, the new shiny?

basho.com

21–30 of 82 posts

Re: Time Series, the new shiny?

#21
post #16

> Riak uses the SHA hash as its distribution mechanism and divides the output range of the SHA hash evenly amongst participating nodes in the cluster. Wait, Riak uses SHA as distribution hash? Why use a cryptographic hash for distribution and not something like Murmur3, if you're talking about high-performant[0] ? [0] http://blog.reverberate.org/2012/01/state-of-hash-functions-...

i'd bet it doesn't matter.

Author here. We hash the key so the number of bytes are negligible. So, I'd agree, I don't think it matters.

Re: Time Series, the new shiny?

#22
post #20
post #13

I don't know Riak, other than its a distributed NoSQL key-value data store. Time series has always been prevalent in the fintec and quantitative finance, and other disciplines for decades. I read a book in the early 1990s on music as time series data, financial tickers, and so on. How is Riak different, or more suited to use than Kdb + q, J with JDB (free), Jd (a commercial J database like Kdb/q)[2], or the new Kerf…

Minor quibble: the article is about RiakTS, their time-series enhanced version of riak_core. riak_core's main strength is that it does key-value in a distributed/resilient manner, spreading values in multiple copies (at least 3) all over a cluster of servers. Kill one server, no problem. Need more capacity, add servers and it will rebalance itself. The TS part is just an optimization built on top of that, to make val…

Yes, exactly. (Author)

Re: Time Series, the new shiny?

#23
post #12

Earlier quoted context omitted.

> Time is the only true constant in the universe I'm not sure exactly what you mean by this, but relativity would seem to contradict you.

Have you ever seen Time suddenly stop? It doesn't. It just keeps on ticking. (okay, the theory of relativity may have other things to say about how those ticks propagate through space, however: we're talking about computers and user interfaces here..)

Time continues to tick, and space continues to not collapse in on me. I'm not sure in what sense you claim time is a constant and space is not.

Re: Time Series, the new shiny?

#24
post #4

Poses the question So what’s the big deal? People have been recording temporally oriented data since we could chisel on tablets. Never answers it, but instead explains how Riak handles large time series. Certainly interesting, but I would like an answer to this question, as I don't understand the big deal.

Immediately following the part you quote (my emphasis) Well, as it turns out, thanks to the software-eating- the-world thing and the Internet of Things we happen to be amassing *vast quantities* of all sorts of data [...] The demand for systems that are capable of storing and retrieving temporal data on an *ever increasing scale* necessitates systems that are specifically designed for this purpose. Strongly implying…

Thanks, ya I thought I answered my question there ;)

Re: Time Series, the new shiny?

#25
Looks really nice. although I am bit sad to see that - it requires structured schema. I have been lookout for a metric collection system (like influxdb) and this would fit very well - except the schema part.

Re: Time Series, the new shiny?

#26
post #25

Looks really nice. although I am bit sad to see that - it requires structured schema. I have been lookout for a metric collection system (like influxdb) and this would fit very well - except the schema part.

You can kinda fudge it by making one of the columns a varchar. It will store whatever you put in it like stringified json but not compute over it (arithmetic, filters, aggs).

(author)

Re: Time Series, the new shiny?

#27
post #15
post #5

Earlier quoted context omitted.

I think the big deal is allegedly "we now have so much data that we have a use for distributed databases with high performance", which allows them to go on and say "and our big deal is that we've built a high-performance distributed database tuned especially for time series". I only noticed it because I was shocked that there was an actual comprehensible value proposition in a blogpost about a NoSQL product.

However being system admin of a PostgreSQL database managing a lot of timeseries I was just like "meh use timestamp and good index, what's the deal?". Also for performance sake just cluster the data using the most used index... But yeah I guess if you really need NoSQL this should be nice. However sharding based on time will probably be one of the easiest approach for horizontal PostgreSQL deployment.

One of the most compelling features of Riak, both KV and TS, is that it is masterless and replicated. When nodes fail for whatever reason, the cluster handles it transparently.

Re: Time Series, the new shiny?

#28
post #16

Earlier quoted context omitted.

i'd bet it doesn't matter.

Author here. We hash the key so the number of bytes are negligible. So, I'd agree, I don't think it matters.

Isn't it more about the number of cycles it takes to generate the hash more than it's size, since you're likely to do that very often in a db context?

Re: Time Series, the new shiny?

#29
post #13

I don't know Riak, other than its a distributed NoSQL key-value data store. Time series has always been prevalent in the fintec and quantitative finance, and other disciplines for decades. I read a book in the early 1990s on music as time series data, financial tickers, and so on. How is Riak different, or more suited to use than Kdb + q, J with JDB (free), Jd (a commercial J database like Kdb/q)[2], or the new Kerf…

> How is Riak different, or more suited to use than Kdb + q, J with JDB (free), Jd (a commercial J database like Kdb/q)[2], or the new Kerf lang/db being developed by Kevin Lawler[3]?

I would really be interested to see an informed answer to this question!

Re: Time Series, the new shiny?

#30
post #28

Earlier quoted context omitted.

Author here. We hash the key so the number of bytes are negligible. So, I'd agree, I don't think it matters.

Isn't it more about the number of cycles it takes to generate the hash more than it's size, since you're likely to do that very often in a db context?

Probably. I'd venture to say the reason we use SHA is due to its uniform distribution over its speed (or lack thereof.)
Post reply on HN