Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s About Time for Time Series Databases

nextplatform.com

Post reply on HN
Print view View original

41–50 of 151 posts

Re: It’s About Time for Time Series Databases

#41

Post by j_s »

kodablah wrote: post #4

Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered/hidden) and Riak (admittedly haven't kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech co…

There was a similar sub-discussion on the Datomic Cloud announcement last week: https://news.ycombinator.com/item?id=16168041#16168743

As an open source product it seems like TimescaleDB is less risky than Datomic. (Not that the comparison is even necessary -- I don't think they compete in the same category apart from both being non-relational DBs.)

[edit:link fixed, thanks! (and thanks for taking the time to correct my misunderstanding re:TimescaleDB as a relational DB)]

Re: It’s About Time for Time Series Databases

#42

Post by Steeeve »

kodablah wrote: post #4

Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered/hidden) and Riak (admittedly haven't kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech co…

You mean like Oracle? Or Sybase? Or Informix? Or Terradata?

Well, I guess you can stick to DB2.

Re: It’s About Time for Time Series Databases

#43

Post by kodablah »

linsomniac wrote: post #31
kodablah wrote: post #4

Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered/hidden) and Riak (admittedly haven't kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech co…

There are tons of justifications you can come up with for not using something you don't want to use. The down side is that you aren't going to be getting the upsides you'd get if you used a new technology, possibly to the extent of being no longer competitive with people who do use that technology. The important thing is balancing chasing the new hotness vs. always using the tried and true. Last year I ran into a sim…

> The down side is that you aren't going to be getting the upsides you'd get if you used a new technology

True of course. I've found that at least "premature abstraction" is almost a requirement when using persistence. I'm not talking an ORM or anything, but put a service in front of it if you have multiple things needing it, or put an in-code abstraction if you don't. And make each abstraction's/service's operation very specific to its caller. So a simple "fetchMarketData(timeRange, tickerSymbols) -> StreamOfData" will save you so much in the future.

Re: It’s About Time for Time Series Databases

#44

Post by kodablah »

Steeeve wrote: post #42
kodablah wrote: post #4

Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered/hidden) and Riak (admittedly haven't kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech co…

You mean like Oracle? Or Sybase? Or Informix? Or Terradata? Well, I guess you can stick to DB2.

Having worked at places where they paid tons for options like those, and suffering from the inability to move and the difficulty of finding non-company tooling and community around them, I'd say they have the same problem. Point being: if your ecosystem is a single company, it's at the whims of that company's success and give-a-shitness. Non-DB companies and open source communities tend to gouge less and share more.

Re: It’s About Time for Time Series Databases

#45

Post by j_s »

siculars wrote: post #25
kodablah wrote: post #4

Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered/hidden) and Riak (admittedly haven't kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech co…

Riak the database survives Basho the company. All assets (IP) were bought by bet365 (A large Basho customer) and made open source. Development continues. /former Basho employee.

> made open source

I hope things work out at least as well as they have for RethinkDB's resurrection/transition! The Riak Users mailing list seems like the best place to follow along: http://riak-users.197444.n3.nabble.com

https://github.com/basho/riak_kv/tree/develop-2.2.5 (November 2017)

http://bet365techblog.com/riak-workshop-summary (October 2017)

>the immediate goal of releasing a known good build as soon as possible [...] all code would be released under the Apache 2 license [...] contact the HLL developers to aid in the dependency and GPL removal

https://news.ycombinator.com/item?id=15182566#15183008 (September 2017)

>andrew_deane_: bet365 have signed the agreement to purchase all Basho IP [...] our intention is to open source all code, help rebuild the community and collaboratively take the development of RIAK forward

Re: It’s About Time for Time Series Databases

#46

Post by amelius »

cevian wrote: post #28
apohn wrote: post #10

Earlier quoted context omitted.

Not just OSISoft PI, but there are many other historians for time series data. https://en.wikipedia.org/wiki/Operational_historian At least in my experience, historians are rarely recommend for complex or ad-hoc queries. Typically you just pull the data (by tags) into another application and do your data processing there. It looks like in timeseriesdb lets you execute complex queries in the database. Historians typic…

Yeah, to underscore some differences more completely, timescale has: - Full indexing and secondary index support. - Support for transactional semantics - Support for living along side relational data - including foreign keys to the relational data. - Full trigger and constraint support - Support for all of Postgres's native data types including JSON(B) and GIS location data.

Transactional support? I was under the impression that timeseries data is considered immutable.

Re: It’s About Time for Time Series Databases

#47

Post by olympus »

The article recognizes that several time series databases already exist. They also say, "we aren't trying to compete against kdb+." They explain how they can handle time series data better than NoSQL databases that aren't time series focused.

But what are they doing better than the existing time series databases? Surely they must have some advantage or they wouldn't have raised 16.1 million dollars.

Re: It’s About Time for Time Series Databases

#48

Post by postwait »

tw1010 wrote: post #17

I have a hard time shaking the feeling that database innovation is being forced not by necessity, but by a culture of blind relentless change.

Relentless change is most likely the motivator for these innovations. However, I don't think it is needless innovation or innovation for the same of innovation. Personal opinion that there isn't much innovation in what this article covers, but still it is happening elsewhere.

Changes in telemetry production (IoT and others) have fundamentally changed the requirements... millions (and often billions) of data points points per-second are now happening. This is being driven by RSM and IoT. RSM is alluded to in my ACM Queue article: https://queue.acm.org/detail.cfm?id=3178371

Re: It’s About Time for Time Series Databases

#49

Post by grzm »

amelius wrote: post #46
cevian wrote: post #28

Earlier quoted context omitted.

Yeah, to underscore some differences more completely, timescale has: - Full indexing and secondary index support. - Support for transactional semantics - Support for living along side relational data - including foreign keys to the relational data. - Full trigger and constraint support - Support for all of Postgres's native data types including JSON(B) and GIS location data.

Transactional support? I was under the impression that timeseries data is considered immutable.

Being transactional is orthogonal to being immutable. For example, if you want to ensure that a given set of writes is applied atomically, you would issue them in a transaction.
Post reply on HN