Live data from Hacker News

InfluxDB – Open-source distributed time-series, events, and metrics database

influxdb.org

71–79 of 79 posts

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#71
post #65
post #54

Earlier quoted context omitted.

... but that's sort of a stockholm syndrome; it's because you know SQL and it makes you feel comfortable, and you can think of worse options (like JSON). But SQL is really a bad option in the moodern world, especially since (I estimate) about 90% of SQL statements are built programmatically; Thus, a query language that is easier to construct from code makes a lot more sense. (And not, that's not JSON - some form of a…

I disagree - it's not stockholm syndrome.. for me it was realizing that SQL actually has solved a lot of common and useful ways of expressing the process of getting to the data you want in the order process you want... simply because we write code to generate SQL does not make it bad... I suspect you also think HTML is bad? Being able to say select x,y,z from table where x=1 is very simple and very clear IMO... I'm j…

HTML is indeed bad as a machine generated format -- which is what it is; e.g.

, list items and a few other things don't have a close tag, but most things do.

These things (like SQL) make sense if you assume that the input is (a) written manually, and (b) by people who are not expected to do this "professionally". Neither is the case of HTML nor SQL anymore.

(Seriously, SQL was originally marketed to managers with the idea that "it's just plain english so you can do it yourself, and don't need programmers!". You know how well that worked out)

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#72
post #71
post #65

Earlier quoted context omitted.

I disagree - it's not stockholm syndrome.. for me it was realizing that SQL actually has solved a lot of common and useful ways of expressing the process of getting to the data you want in the order process you want... simply because we write code to generate SQL does not make it bad... I suspect you also think HTML is bad? Being able to say select x,y,z from table where x=1 is very simple and very clear IMO... I'm j…

HTML is indeed bad as a machine generated format -- which is what it is; e.g. , list items and a few other things don't have a close tag, but most things do. These things (like SQL) make sense if you assume that the input is (a) written manually, and (b) by people who are not expected to do this "professionally". Neither is the case of HTML nor SQL anymore. (Seriously, SQL was originally marketed to managers with the…

> (Seriously, SQL was originally marketed to managers with the idea that "it's just plain english so you can do it yourself, and don't need programmers!". You know how well that worked out)

Pretty well, actually -- lots of nonprogrammer analysts use SQL for queries, and IME the ones that do consistently are better able to answer questions based on data than the ones that use "friendly" query tools, that inevitably end up being much more limited in practice, and requiring a lot more support from both programmers and DBAs to make the data that is already available accessible through.

Unfortunately, lots of environments prevent direct SQL access to DBs for "security" reasons (as if mutiuser DBMS's didn't have role based access controls as a core feature)

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#73
post #40

Every now and then I see a new opensource distributed and whatnot database pop out, now, I'm totally naive in terms of databases and distributed systems. Do we really need all this Databases? What's special about this one? Can someone give me a summary of the main ones (Mongo, Redis, Rethink, Riak, etc.) ? Now not discouraging InfluxDB or anything, as a systems programming fan it's great to see more things like this…

This talk by Martin Fowler on NoSQL http://www.youtube.com/watch?v=qI_g07C_Q5I and their use cases is a pretty good introduction.

Oh thanks, I'll look it tonight.

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#75
post #40

Every now and then I see a new opensource distributed and whatnot database pop out, now, I'm totally naive in terms of databases and distributed systems. Do we really need all this Databases? What's special about this one? Can someone give me a summary of the main ones (Mongo, Redis, Rethink, Riak, etc.) ? Now not discouraging InfluxDB or anything, as a systems programming fan it's great to see more things like this…

> Do we really need all this Databases? What's special about this one? Good point, Comrade. I will propose to GOSPLAN that we rationalise the development of all new technologies, to avoid such accidental evolutionary convergence in future.

As I said, "Now not discouraging InfluxDB or anything". I have nothing against freedom of choice (That's what I use Linux for example) But I do agree that fragmentation might be bad (E.g. 200 Linux distros).

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#76
post #71

Earlier quoted context omitted.

HTML is indeed bad as a machine generated format -- which is what it is; e.g. , list items and a few other things don't have a close tag, but most things do. These things (like SQL) make sense if you assume that the input is (a) written manually, and (b) by people who are not expected to do this "professionally". Neither is the case of HTML nor SQL anymore. (Seriously, SQL was originally marketed to managers with the…

> (Seriously, SQL was originally marketed to managers with the idea that "it's just plain english so you can do it yourself, and don't need programmers!". You know how well that worked out) Pretty well, actually -- lots of nonprogrammer analysts use SQL for queries, and IME the ones that do consistently are better able to answer questions based on data than the ones that use "friendly" query tools, that inevitably en…

I still think SQL is a needlessly verbose mistake. The same people who can successfully write SQL for queries would have just as easily (or more easily) been able to use some algebraic notation. I am not advocating GUI query builders - I'm advocating a non-natural-language-looking (and hopefully better) language, along the lines of kdb+/q.

If you can properly do inner/outer/cross/asof joins to get to the data you want, the english-like syntax is just a burden - two queries that seem similar in their English more often than not produce completely different results because of SQL's 3-value logic, the way NULLs are joined, and various other things like that.

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#77
post #54
post #51

Earlier quoted context omitted.

I really like SQL - as I was learning SQL, I thought it was terrible, but now after years of using it really makes getting to data easy, I'm very excited to see you choose SQL instead of JSON or something less query like to query...

... but that's sort of a stockholm syndrome; it's because you know SQL and it makes you feel comfortable, and you can think of worse options (like JSON). But SQL is really a bad option in the moodern world, especially since (I estimate) about 90% of SQL statements are built programmatically; Thus, a query language that is easier to construct from code makes a lot more sense. (And not, that's not JSON - some form of a…

This is a really strange opinion. SQL is an awesome DSL for interacting with structured, relational data. Got no idea where you get your 90% stat from; seems to me that's a product of your personal ecosystem rather than an objective statement about the universe.

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#78
post #76

Earlier quoted context omitted.

> (Seriously, SQL was originally marketed to managers with the idea that "it's just plain english so you can do it yourself, and don't need programmers!". You know how well that worked out) Pretty well, actually -- lots of nonprogrammer analysts use SQL for queries, and IME the ones that do consistently are better able to answer questions based on data than the ones that use "friendly" query tools, that inevitably en…

I still think SQL is a needlessly verbose mistake. The same people who can successfully write SQL for queries would have just as easily (or more easily) been able to use some algebraic notation. I am not advocating GUI query builders - I'm advocating a non-natural-language-looking (and hopefully better) language, along the lines of kdb+/q. If you can properly do inner/outer/cross/asof joins to get to the data you wan…

> I still think SQL is a needlessly verbose mistake. The same people who can successfully write SQL for queries would have just as easily (or more easily) been able to use some algebraic notation.

I don't think that's not true -- there's lots of adults that have anxiety around "maths-like" notations largely as a result of issues with maths education, cultural factors, etc., despite being able to intellectually handle the relevant manipulations -- and lots of those people end up in non-technical business positions that end up having to deal with data. Lots of the non-IT people I've seen using SQL definitely fall into that group, and I don't think they'd be as proficient with a more algebraic syntax like the comprehension syntaxes used in many modern programming languages.

Conversely, the people that can be proficient in those syntaxes almost certainly can be proficient in SQL, though they may complain about its verbosity.

Sure, in a perfect world where the cultural context was different, this wouldn't be necessary. But we don't live in that world.

Re: InfluxDB – Open-source distributed time-series, events, and metrics database

#79
post #67

Earlier quoted context omitted.

I get that. But, what's more worrying is that my password came through in the URL string (a GET request)

We're no longer putting the password in the URL, but play and sandbox aren't over HTTPS. And the password still gets sent. As their name implies, they're for playing around, not for real data. On a real installation you'll want to use SSL. We'll have that built into the prod releases or you can always have your load balancer/proxy handle that for you.

That's awesome then. Great product :)
Post reply on HN