Re: [GENERAL] Interesting article, Facebook woes using MySQL
On Tue, Mar 13, 2012 at 01:22:18AM +0100, Stefan Keller wrote: Hi all 2011/7/12 Chris Travers chris.trav...@gmail.com: I am not convinced that VoltDB is a magic bullet either. I don't I have the chance to help preparing an interview with Mike Stonebreaker to be published at www.odbms.org I'd really like to know, if he is up-to-date how Postgres performs these days and how he thinks how VoltDB overcame the overhead he claims to exist in old elephants. Do you all have more questions to Mike? I'm curious what he thinks about the role of the optimiser. IME postgresql wins for my workloads simply because PostgreSQL is smart enough to perform the joins in the right order and use the right indexes. MySQL seems to have some heuristics which are wrong just often enough to be irritating. Oh yeah, and it doesn't have CREATE INDEX CONCURRENTLY, that's *really* annoying. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ He who writes carelessly confesses thereby at the very outset that he does not attach much importance to his own thoughts. -- Arthur Schopenhauer signature.asc Description: Digital signature
Re: [GENERAL] Interesting article, Facebook woes using MySQL
Hi all 2011/7/12 Chris Travers chris.trav...@gmail.com: I am not convinced that VoltDB is a magic bullet either. I don't I have the chance to help preparing an interview with Mike Stonebreaker to be published at www.odbms.org I'd really like to know, if he is up-to-date how Postgres performs these days and how he thinks how VoltDB overcame the overhead he claims to exist in old elephants. Do you all have more questions to Mike? --Stefan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Interesting article, Facebook woes using MySQL
http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ How would PG stack up in a usage situation like this?
Re: [GENERAL] Interesting article, Facebook woes using MySQL
Dne 11.7.2011 21:50, Gauthier, Dave napsal(a): http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ How would PG stack up in a usage situation like this? This article (and the slashdot discussion) was already mentioned in the pg-advocacy list http://archives.postgresql.org/pgsql-advocacy/2011-07/msg8.php although it's mostly about the slashdot discussion - misconceptions, falsehoods and flame baits presented there. I don't think the slashdot it worth reading, it's full of nonsense (not a big surprise) and it's 48 hours old (which means 'dead' in slashdot terms). Regarding the article itself, it contains very little information about the new SQL - in short it just says three things: (1) It's difficult and expensive to build ACID-compliant distributed system using traditional RDBMS, especially if you don't know in advance you need to design it like that. This is where Stonebraker pokes into MySQL (or rather how Facebook used it), and I guess about the same could be true for PostgreSQL. (2) The NoSQL may help you to solve this problem when you don't need a relational storage and you have to respect the CAP theorem. (3) The New SQL is said to be the cure, i.e. SQL with advantages of NoSQL and without the disadvantages. As much as I respect Stonebraker, I doubt this can be done without breaking the CAP theorem but maybe I'm missing something ... I personally see the article as a propagation of VoltDB, but that does not mean it's a bad product. I guess it's time to play with it a bit. regards Tomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Interesting article, Facebook woes using MySQL
On Mon, Jul 11, 2011 at 2:50 PM, Gauthier, Dave dave.gauth...@intel.com wrote: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ Well, Stonebraker is pitching (for the Nth time) a revolutionary platform, VoltDB, which naturally brings up concerns about bias. For example, it's not clear why 1,800 servers running mysql is necessarily a 'fate worse than death'. Reading the article I find myself asking, 'what is the problem that needs solving here?'. I bet postgres would do just fine for facebook although it would take a lot of tweaking to get maximal numbers. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Interesting article, Facebook woes using MySQL
On Mon, Jul 11, 2011 at 03:53:20PM -0500, Merlin Moncure wrote: example, it's not clear why 1,800 servers running mysql is necessarily a 'fate worse than death'. Speaking personally, I find even one server running mysql (if it's my responsibility) is pretty enervating. I can imagine 1,800 could be worse than death. A -- Andrew Sullivan a...@crankycanuck.ca -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Interesting article, Facebook woes using MySQL
On Mon, Jul 11, 2011 at 12:50 PM, Gauthier, Dave dave.gauth...@intel.com wrote: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ How would PG stack up in a usage situation like this? My sense is that Pg would stack up no better. I suspect to make this work at this scale you'd have to sacrifice a lot of RI checking etc. and probably resort to similar tricks as with MySQL. I am not convinced that VoltDB is a magic bullet either. I don't think you can guarantee both consistency and speed across a database of that size, so you end up having to sacrifice one or the other. ACID compliance shouldn't generate nearly as much overhead on inserts of facebook likes as just simple things like verifying that the post one is liking actually exists, etc. In theory column-oriented databases come out ahead on those reads, but I would expect more overhead on writes (random seek for each field written?). So it might solve some problems but whether it would create others and whether there was a positive tradeoff is a good question. Best Wishes, Chris Travers -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
