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

Citus Unforks from PostgreSQL, Goes Open Source

citusdata.com

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Citus Unforks from PostgreSQL, Goes Open Source

#141

Post by anjanb »

TY wrote: post #129
umur wrote: post #83

Earlier quoted context omitted.

Umur from Citus here. For purposes of this question, I’ll bucket traditional data warehousing (DWH) solutions like Redshift, Vertica, Greenplum together, although there are many nuances among each of them of course. First, Citus is not a traditional data warehouse. We position Citus as the real-time, scalable database that serves your application under a mix of high- concurrency short requests and ad-hoc SQL analytic…

Thank you for the answers, Umur. I've used both Vertica and ParAccel in production environments for the traditional Data Warehousing projects and have come to appreciate both good and the bad that analytic RDBMS engines bring to the table. Currently, my favorite is Vertica, but I do have concerns about its future under the stewardship of HPE. I'm quite interested in what Citus brings to the market and will be followi…

"Currently, my favorite is Vertica, but I do have concerns about its future under the stewardship of HPE." HPE employee here (Not a vertica team member, though) Many teams within HP are very excited to use Vertica. Many more teams are looking to use Vertica for our own product offerings. There's no reason, in the short term, for HPE to shift away from Vertica. On the other hand, I'd say that HPE will invest more into Vertica.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#143

Post by belorn »

singlow wrote: post #138
belorn wrote: post #125

Earlier quoted context omitted.

I remember that exception, and it was very explicit that you needed to already have obtained copyright permission to use the software. The legal theory behind the "copy to memory" exception is that if a end-user already have been granted permission to use a copyrighted work, then it make sense that they also have permission to "copy" it to their computers memory. If you have a copyright license that adds a condition…

It says, explicitly, that making copies for the purpose of executing it is not an infringement. I do not need permission if it is not an infringing act.

"Notwithstanding the provisions of section 106, it is not an infringement for the "owner" of a copy of a computer program"

If you do not have a licensed permission from the author, you now have to prove that you are the legal owner of the copy. It could be said that they intended to address people who pirated a copy from a torrent site (or a BBS, since this is before the time of torrents), but its a major claim that someone can own a copyrighted work without, 1) purchasing it, 2) having a copyright license to it.

When it comes to GPL in particular, the question is also if the recipient is a owner or a licensee. The license text specifically call "you" to be equivalent with "licensee", which makes the claim of ownership even more dubious.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#144

Post by rch »

gtrubetskoy wrote: post #135
rch wrote: post #101

Earlier quoted context omitted.

That's correct, and with such a significant license change I think the term 'unfork' is being used inappropriately in the title. Edit: the PostGIS extension is GPL, and that license choice has been very successful. Hopefully the AGPL works out at least as well for Citus, I'm just not familiar enough to know what the implications will be in this context.

>> the PostGIS extension is GPL But then it doesn't really belong or aim to be in PostgreSQL proper, at least IMO, so I think that's fine. The functionality (i.e. distributed processing and horizontal scaling) that Citus has done is something that I predict will eventually be part of standard PostgreSQL, but it will not be Citus's code (unless they change the license, of course).

Alternative implementations will probably surface, but those will almost certainly be packaged as extensions as well.

I think the model could work in this case, both for the business and for PostgreSQL in general.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#145

Post by heme »

no1youknowz wrote: post #10

This is awesome. I have experience with running a CitusDB cluster and it pretty much solved a lot of the scaling problems I was having at the time. For it to go open source now, is of huge benefit to the future projects I have. > With the release of newly open sourced Citus v5.0, pg_shard's codebase has been merged into Citus... This is fantastic, sounds like the setup process is much simpler. I wonder if they have i…

Can you elaborate on the scaling problems you were having?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#146

Post by amitlan »

faizshah wrote: post #38

So this sounds similar to Pivotal's Greenplum which is also open source, can anyone compare the two?

Greenplum is a fork of Postgres codebase, Citus is not; it's an extension that leverages community Postgres's extensibilty APIs. This point seems to be highlighted in their post.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#147

Post by jasonmp85 »

gorodetsky wrote: post #94
ozgune wrote: post #91

Earlier quoted context omitted.

(Ozgun from Citus Data) On PostgreSQL language support, we're updating our FAQ to have more information: https://www.citusdata.com/frequently-asked-questions Since the PostgreSQL manual (and its feature set) spans over 4K+ pages, we found that the best way to think about Citus' capabilities is from a use-case standpoint. If your workload needs distributed transactions that span across machines, or large ETL jobs, Cit…

Thanks for awesome product! Do you know when you're planning to release Citrus 5.0 deb/rpm packages?

Looks like the RPMs are now up: https://twitter.com/DevrimGunduz/status/713282614468222976

Re: Citus Unforks from PostgreSQL, Goes Open Source

#148

Post by anonbanker »

icebraining wrote: post #107
X86BSD wrote: post #97

Earlier quoted context omitted.

No that IS what the BSDL allows for. I wasn't arguing that they shouldn't have made a commercial product on BSDL code. That also was within their rights using said BSDL code. It's just my opinion that to do that, then release your proprietary "bits" under the GPL or variation thereof with more restrictions than what you started with instead of the same BSDL you used to start your business is a dickheaded douche nozzl…

I understand you weren't saying they don't have the right to do so, I just find it weird that you consider distributing it under the AGPL to be douchy, while not considering the distribution under a proprietary licence to be (even more) douchy.

A relicense is a relicense. When you impose new rules on a product, especially if you weren't the original author, is rude.

I'm a GPL zealot, to the point that I've used the GPL as a weapon and as a shield against others in multiple capacities ("You own all my code when you employ me? Sure, as long as I get to dictate the license"). However, I would never take someone's 2 or 3-clause BSD-licensed product, and relicense. Those of us that value sofware freedom value the rights of other licenses that believe the same.

We all see why it was done in this case, however; In order to ensure software freedom in the cloud (someone else's computer), there isn't another license to use. the BSD license completely breaks down in this use scenario, and the best we have is AGPL.

I'd say cloud usage is to 3-clause BSD what Tivo was to GPLv2.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#149

Post by hblanks »

rkrzr wrote: post #16
hblanks wrote: post #8

Earlier quoted context omitted.

We've been running CitusDB for a couple years now at CloudFlare for serving aggregated analytics to customers (cf. https://blog.cloudflare.com/scaling-out-postgresql-for-cloud... ). It's a good product, and it was even fairly easy to do a major version upgrade / cluster relocation. At least as easy as such a thing can be. :-)

Are there any limitations you have run into? E.g. can you still use all index types that Postgres offers or are there any special distributed index types that CitusDB adds perhaps?

Correct. CTEs are pretty much a no-go, and you also can't do things like join between distributed and non-distributed tables.

Your queries tend to break down into ones where you're hitting a small number of shards (such as when we serve data for the analytics page), or else ones where you tend to aggregate up into temporary, non-distributed tables for further analysis (such as you'd do for infrequent business reporting).

All told, it's been one of the easier tools for us to operationalize, largely thanks to the fact that it's "just PostgreSQL." The one thing I wish we had was better documentation of what kind of consistency guarantees to expect, although for an append-only store like our current use case, that's less of a concern. And to be fair, Ozgun and the other guys at Citus have always been really happy to answer any questions we have.

With this code now going open source, it should be pretty easy to look into these sorts of internals.

Post reply on HN