Live data from Hacker News

Citus Unforks from PostgreSQL, Goes Open Source

citusdata.com

91–100 of 156 posts

Re: Citus Unforks from PostgreSQL, Goes Open Source

#91
post #60

I've been unable to find any clear description of the capabilities of Citus and competing solutions (postgres-x2 seems the other leader). Which of these are supported: 1. Full PostgreSQL SQL language 2. All isolation levels including Serializable (in the sense that they actually provide the same guarantees as normal PostgreSQL) 3. Never losing any committed data on sub-majority failures (i.e. synchronous replication)…

(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, Citus currently isn't the best fit.

Citus supports sharding and replication out of the box (#4, #5). On #6, reads go through a master node (metadata server) and you see what you write.

We don't have #7. The way in which we implement this also has implications on your other questions. Multi-master (no single metadata server) is by far the biggest feature request that we receive: https://news.ycombinator.com/item?id=11353866

If we go with the approach in https://github.com/citusdata/citus/issues/389, you will be able to configure #3, #6, #7 through PostgreSQL's streaming replication settings. We still won't support distributed transactions that span across multiple machines.

On #8, could you elaborate a bit more? Do you mean a logical identifier for the node?

Also, it's hard to write a concise reply on a topic that requires so much context. I'd love to grab coffee with anyone who's interested in diving deep into distributed databases. Feel free to shoot me an email at ozgun@citusdata.com

Re: Citus Unforks from PostgreSQL, Goes Open Source

#92

Earlier quoted context omitted.

No, it means if you make changes to the code and use it over a network you have to be AGPL too (think "network" as "distribution" in the GPL sense).

As far as I know it means it is contagious over the network. If not I have misread and quite a few other people have misunderstood as well I guess. See for example MongoDB and others that distribute the core under AGPL and the drivers under MIT or something so that you can actually use it for something without having to make your product AGPL licensed as well. Edit: did some quick googling and found this in another H…

No license is contagious, or viral. It's a license, not a law, you are under no obligations to honor it. It is not an implicit contract between you, or anybody else. It simply states what rights are granted to you, and under which conditions. If you fail to comply you simply don't have those rights, and it's just normal copyright violation.

Should you redistribute a modified copy, and not license your modification accordingly, the recipients do not get an implicit license to you modifications.

The only way your code will get licensed to others is when you explicitly say so.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#93
post #91
post #60

I've been unable to find any clear description of the capabilities of Citus and competing solutions (postgres-x2 seems the other leader). Which of these are supported: 1. Full PostgreSQL SQL language 2. All isolation levels including Serializable (in the sense that they actually provide the same guarantees as normal PostgreSQL) 3. Never losing any committed data on sub-majority failures (i.e. synchronous replication)…

(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…

What key feature makes Citus different/better than RethinkDB?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#94
post #91
post #60

I've been unable to find any clear description of the capabilities of Citus and competing solutions (postgres-x2 seems the other leader). Which of these are supported: 1. Full PostgreSQL SQL language 2. All isolation levels including Serializable (in the sense that they actually provide the same guarantees as normal PostgreSQL) 3. Never losing any committed data on sub-majority failures (i.e. synchronous replication)…

(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?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#95
post #87
post #46

Earlier quoted context omitted.

...and Redshift. I love what Amazon provide, but it gets expensive.

(Part 2) Now comes the storage engine, and cstore_fdw as it relates to PostgreSQL. Built by the Citus Data team, cstore_fdw is entirely a separate component from the Citus product above. It enables columnar storage for your vanilla, single-node PostgreSQL to provide data compression for faster analytics. As such, cstore_fdw does not come with any of the parallelism I've described above that Citus (or Redshift, Vertic…

Thanks for the answers - makes a lot of sense. I'm replying to this one just to clarify one point:

> cstore_fdw has certain limitations, importantly it is not updatable

Does it support insert, or are tables completely immutable once created?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#96

Earlier quoted context omitted.

Odoo thinks it is viral over the net? I've never seen that argument. It was only viral to modules running on the Odoo server. If you used XML-RPC to talk to it over the net, I don't think Odoo S.A. would claim you had to distribute your code.

Possibly I'm wrong again. Actually happy about it. If the network part of AGPL only affects the original AGPL software then it even kind of makes sense although I still wouldn't use it myself except as an extortion scheme :-P

Well, I can't say I agree with your position on the AGPL. But as a side note, Odoo has recently been re-licensed as LGPL, so one can now distribute proprietary modules for it (and even sell them on the official Store).

Re: Citus Unforks from PostgreSQL, Goes Open Source

#97
post #61

Earlier quoted context omitted.

So you take a BSDL codebase, fork it, close it, make proprietary changes, profiting from the BSDL codebase, then slap the PG community in the face by open sourcing it under a more restrictive license hoping to benefit from the community you just slapped in the face but restricting competition. They are of course free to release their code under any license they wish. I just think releasing code under the *GPL when yo…

I also have qualms about distributing changes to non-copyleft license code under a copyleft license, but it seems strange to make this the "slap in the face" moment - wasn't distributing them under a proprietary license even worse?

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 nozzle thing to do. But again they are free to do that, it's within their rights! Just don't be shocked when people like me call you out for what you are. Keep on rocking Citus! Stay classy.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#99
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?

(Jason from Citus here)

As soon as they're built in PGDG! Our Docker image just builds on the PostgreSQL 9.5.1 image, then installs a .deb we built.

I've been wrapping up all our packaging work during the past week, but not having a OSS release yet was the final blocker for getting into well-known repos. We'll probably have a post about this in the near future.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#100
post #22

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…

(Ozgun from Citus Data) We're working on making Citus masterless. In all openness, we evaluated two different approaches to this in the past six months, and wrapped up the design for one. This design works well on the cloud, and we already demonstrated a working version: https://youtu.be/_nun2S6EdWo?t=411 For on-premise deployments, the primary challenge is set-up complexity. We're now prototyping one of those design…

good work! congrats =)

also in Turkish: kolaylıklar dilerim :)

Post reply on HN