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

121–130 of 156 posts

Re: Citus Unforks from PostgreSQL, Goes Open Source

#121

Post by microcolonel »

cm3 wrote: post #110
ozgune wrote: post #22

Earlier quoted context omitted.

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

What does "works well on the cloud" mean specifically? Is there some difference when run on your own hardware?

I imagine it means it tolerates unreliable or higher-ish latency networks, maybe avoids multicast.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#122

Post by Someone »

jasonmp85 wrote: post #120
takeda wrote: post #119

Earlier quoted context omitted.

Perhaps I'm missing something, but this is just an extension that works with standard postgres, there are no code changes in postgres itself, so it doesn't look like it ever was a fork.

(Jason from Citus here) Yes, that's what you're seeing right now , but in the past Citus (used to be "CitusDB") was a superset of the entire PostgreSQL codebase. During the lead-up to the open source release, we removed the use of any static methods or internal machinery and rewrote the installation process to use the PostgreSQL CREATE EXTENSION command. Additionally, we moved all of pg_shard's DML functionality into…

Aha. Should have read the announcement better. Thanks for the explanation.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#123

Post by belorn »

reitanqild wrote: post #42
kodablah wrote: post #19

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…

Opa is a really bad example since every program that uses the standard library will be utterly depended on that library. The program can not work at all without the copyrighted work of the library authors, and as such, do not even have basic aspect like independence.

If I write a program that connect to a database, my program will happy work fine without the database software. I could replace the database with a different one, and the program would work identically. Outside some database specific quirks, programs that connect to a database do so as independent works.

An other aspect is that if you change the standard library of a programming language, the programs that uses it will utterly change too. If you change the database software, most well written software won't be effected and will run identically as if it connected to a older version of the database.

And last, software that connects to a database won't share memory with the database software. Programs that uses a standard library will share memory with the standard library. The connection between a program and it's standard library is significant closer than the connection between a program and a database.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#124

Post by devit »

ozgune wrote: post #91
devit wrote: 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…

Does this mean that distributed transactions are not supported at all?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#125

Post by belorn »

singlow wrote: post #66
bryanlarsen wrote: post #40

Earlier quoted context omitted.

Not only that: running the app requires copying it into memory; editing files requires making copies; deploying it to your production servers requires making copies.

U.S. Copyright code allows you to make copies into memory or otherwise if it is required in order to utilize the software. https://www.law.cornell.edu/uscode/text/17/117

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 to the grant of permission, its hard sell to argue that the exception trumps the condition.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#126

Post by ahachete »

Congratulations, Citus.

Since I heard last year at PgConfSV that you will be releasing CitusDB 5.0 as open source, I've been waiting for this moment to come.

It makes 9.5's awesome capabilities to be augmented with sharding and distributed queries. While this targets real-time analytics and OLAP scenarios, being an open source extension to 9.5 means that a whole lot of users will benefit from this, even under more OLTP-like scenarios.

Now that Citus is open source, ToroDB will add a new CitusDB backend soon, to scale-out the Citus way, rather than in a Mongo way :)

Keep up with the good work!

Re: Citus Unforks from PostgreSQL, Goes Open Source

#127

Post by wmfiv »

ccleve wrote: post #79

I'd very much like to see what algorithm these systems are using to enable transactions in a distributed environment. Are they just using straight two-phase commit, and letting the whole transaction fail if a single server goes down? Or are are they getting fancy and doing some kind of replication with consensus?

I believe transactions must process against a single node.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#129

Post by TY »

umur wrote: post #83
flavor8 wrote: post #46

Earlier quoted context omitted.

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

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 following its progress closely. Once you have a more rounded story for the traditional Data Warehousing purposes, I can recommend it to my clients for evaluation purposes.

In terms of a sweet spot for you, here's a free tip for your sales: target customers of Unica (well, IBM Unica now). That's one application that would definitely benefit from your Operational Analytics positioning - lots of data ingested throughout the day, lots of queries to run for the analytics.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#130

Post by hercynium »

wstrange wrote: post #109
gtrubetskoy wrote: post #71

Earlier quoted context omitted.

>> The BSDL does not make much economic sense to the company open sourcing their code If this were true then Cloudera, Horton and a whole bunch of other companies would be out of business, yet in reality they are doing really well. All that AGPL is doing for Citus is: 1. Turning away people (customers) who are religious about licenses. 2. Eliminating any possibility of this code ever being integrated into PostgreSQL

Cloudera and Hortonworks have raised a ton of VC money, but it is not clear (yet) that they have viable, profitable business models.

I hope that at least Cloudera will profit and thrive. Having used plain Apache components, then Hortonworks, then Cloudera... They are far and away the superior distribution, regardless of whether or not you are an "enterprise" customer.

My $employer paid Hortonworks for a support contract and I have no qualms declaring publicly that it was a total and utter scam. (We are a Java shop and know our shit)

If I go into too much detail I'll write countless pages like my internal report on why we needed to switch, but the bottom line is that Cloudera's products are well and honestly documented, while, as of last year, Hortonworks' products are simply one land-mine after another.

Their management platform (Cloudera manager) being closed-source is barely a mark on the comparison analysis when you compare it to Ambari in practice. Ambari is a bad joke and I'd rather do without it after spending significant time using it and trying to extend it.

And I could go into excruciating detail as to how Hortonworks abuses the Apache License to try and force lock-in. It's disgusting and pathetic.

Post reply on HN