Facebook Trapped In MySQL a 'Fate Worse Than Death'

wasimkadak writes with this excerpt from GigaOM: "According to database pioneer Michael Stonebraker, Facebook is operating a huge, complex MySQL implementation equivalent to 'a fate worse than death,' and the only way out is 'bite the bullet and rewrite everything.' Not that it's necessarily Facebook's fault, though. Stonebraker says the social network's predicament is all too common among web startups that start small and grow to epic proportions."

Comments

Commercial databases

[drolli]

Well. then they convert from one db to another. So what. its not like that would be a completely new thing to happen, and i am sure that oracle or any other big db provider will send experts to help with the task.

Re:Commercial databases

[cgeys]

But like the summary and article note, that requires rewriting the whole codebase. They should had gone with Oracle database to begin with, but of course no one ever thinks about the expanding possibilities when they're starting out and just want something free, ie. MySQL.

Re:Commercial databases

[Relayman]

Why would that require rewriting the whole codebase? Isn't SQL standard?

Re:Commercial databases

[Anonymous Coward]

No. Each implementation of SQL is slightly different than all the others. Unfortunately for Facebook, MySQL is *more than* slightly different that all the others. In a bad way. Real database programmers consider MySQL a toy, though a step up from MS Access.

Re:Commercial databases

[svick]

SQL is a standard, but every provider implements it differently, with their own additions. So, for any non-trivial uses of SQL, you need to do at least some changes.

In some cases, the changes could be really big. Especially when using some of the more complex features, like the support for recursive queries.

Re:Commercial databases

[Anonymous Coward]

MySQL is less faithful to the ANSI standard than most RDBMSs. Of course, this is one of *many* reasons why PostgreSQL is a better choice for free projects, but people still somehow think MySQL is "easier."

Re:Commercial databases

[mad_minstrel]

But aren't the differences relatively minor? Is there really so much that MySQL can do that Oracle can't? Can't these differences be resolved just by tweaking the queries?

Re:Commercial databases

[Anonymous Coward]

They shouldn't. They may have to rewrite database adapters, but that's the entire point of using an adapter or a "Data Access Object" rather than scattering SQL statements all over the place. If they have done this... then they deserve to tank.

Re:Commercial databases

[tgv]

They should have gone with Oracle? Why? I work with that expensive cr*p, and it can't perform its way out of an open box. They can't have that much db dependent software anyway. Just plug in a compatibility layer and use something fast under it. I guess this is only news because it's facebook and facebook is worth so much money.

Re:Commercial databases

[jjohnson]

A minor difference that exists in 4,000 instances and who knows how many places in the code that's also distributed across multiple servers, isn't minor, especially when there are hundreds or even thousands of minor differences.

And no, the differences in SQL between Oracle and MySQL aren't minor. It's not just syntax, and it's not MySQL-can-Oracle-can't. It's the performance characteristics of various queries, the logic of how they're implemented, and the incredible investment in configuring a large cluster to work smoothly (which MySQL and Oracle do extremely differently. Large scale systems add a layer of complexity all their own that's a totally separate engineering challenge.

Short version: Switching from MySQL to anything else would be the equivalent to a ground-up rewrite, though this is largely true of any database system. MySQL hasn't somehow uniquely trapped them here.

Re:Commercial databases

[Anonymous Coward]

It's been a loooooong time since I looked into Oracle, but last time I checked it was cost prohibitive to use it for startups.
Could they afford it now? Yes.
Could they afford it in the beginning? Probably not.

Re:Commercial databases

[Dr.Dubious DDQ]

I would guess that instead of using PDO or similar abstraction layer, their PHP code is littered with "mysql_*" function calls, so they'll necessarily need to modify everything to handle any other database.

Or just wait for enough people to move to Google+ instead so that their database load is reduced...

Re:Commercial databases

[NeoMorphy]

If you wan't to start a fun/interesting project that you didn't expect any revenue from, it would make more sense to use free software. MySQL is a popular choice for web applications and there is a lot of freely available documentation and examples available. Many people have been successful doing it, so it's a proven path that works.

Oracle is expensive. It would have cost a fortune to start Facebook with Oracle, and I can't imagine what it would cost them now. But even if they have to hire a ton of experts to convert to Oracle( assuming that is the best thing to do...) They can probably be funded by the money saved by not using Oracle over the past couple of years.

Maybe Oracle would have been a mistake, there are companies migrating from Oracle to DB2/DB2 to Oracle/Oracle to Sybase/Sybase to MySQL/Mainframe to AIX/AIX to Solaris/Solaris to Linux/etc.. It seems like nobody can agree to the best hardware/OS/database solution, but there are plenty of people who swear that the solution they know is the best one.

Re:Commercial databases

[cloudmaster]

Yeah, Oracle. Who owns MySQL again?

http://www.oracle.com/us/products/mysql/index.html

Re:Commercial databases

[Billly Gates]

I went for a job interview a few years ago which was very SQL intense. I looked at some SQL code in C# for both ODBC as well as direct SQL Server code, and it was the most complex thing I have ever seen and frankly hair pulling ugly. It was no simple UPDATE INTO TABLE like simply MySQL with php.

Rather, It was weird ASYNC VSYNC Data.adaptor,x and weird eseortoric lines consisting of 35 to 40 lines of code for each insert doing God knows what! Maybe a SQL programmer can explain what a Vsync was and what a data,adaptor is and why was that code so evil? The question was how to fix it? I realized I was obviously not qualified for the job.

I googled the code and it seemed it was operating optimally with all that stuff. Sure you can use a simple insert statement, but that is frowned upon as not optimized by SQL programmers. Most of them use very complicated steps and layers of abstraction where KISS is frowned upon, because if the database doesn't perform well you do not want to look like an *ss.

PHP is really nice for it's simplicity, but as soon as you move to Java or C# it gets very ugly and each database requires different code and optimization techniques and a rewrite if you change your schema. Again, I am not a SQL programmer so hopefully I wont get bashed too much here by the real ones, but it is just what I observe as I want to learn this myself. I have a feeling this is why Hibernate is becoming popular to avoid these things as it is a framework that does some of the nasty details in a seperate layer ... at least from what I read.

But with Java or .NET you can get caching, transaction control, and other neat things you can't get with PHP but it comes at a cost. Same is true with a real database like PostgreSQL, SQL Server, DB 2, or Oracle. SQL statements are a small part of the code and the rest is proprietary with working with the RDBMS. My hunch is the vendors love these as it encourages lock in with expensive licensing fees.

Re:Commercial databases

[kimvette]

SQL is a standard, but no, "SQL" isn't standard. There are syntax differences between databases, and if you get into stored procedures (or equivalent) and triggers (or equivalent), or rely on referential integrity (which is implemented on some RDBMS systems, but not others, and doesn't always work the same), it won't be a matter of dumping the database from one RDBMS and then importing it to another RDBMS. Things are going to break.

I'd hate to have to deal with a(-) Facebook dump file(s); I'm sure everything isn't crammed into a single table, or even a single database, but I'd imagine must be a horrible, fragile, scary mess even if the architecture is sound.

That's the beauty of MySQL, Postgres, etc. come into play - not only are they easily scalable, but they are open source so if you are a large organization, you can cook your own fork and address the shortcomings, unlike smaller organizations which lack the resources to even consider the "it's open source, fix it yourself" mantra. In fact, it'd be neat if for once Facebook does something less than evil and contributes significant enhancements to MySQL.

Re:Commercial databases

[laffer1]

This isn't true. I just migrated an application from MySQL 4.1 to Postgresql 9.0 at work. It took me about two weeks, but certainly not a complete rewrite from scratch. It varies greatly on the application, the language it's written in, frameworks in use, and the number of product specific features in use. This was a perl / mason app.

If an application was making extensive use of stored procedures, then it would require a lot of effort to rewrite those, but not the whole application. If the application were written in C, it would be a lot of work to change. I think facebook uses PHP and that's not too hard to change out especially if they were sane and used an abstraction layer like PDO.

If the app were written in Java or .NET and using an ORM, it would be TRIVIAL to change to another database.

With my experience, the biggest problems were date functions and the fact that MySQL embeds index creation in the create table syntax whereas postgres requires it be separate and the names of indexes are global. This meant that I had some work cut out for me changing index names. There were also a few quirks with some join queries as MySQL is not picky about ordering in the from clause.

You are correct that they'll have to tune queries and things, but it's not a total rewrite if they wrote their app in a reasonable way.

For the record, Postgresql 9 is faster for many of our queries but seems slower doing INSERT. YMMV

Re:Commercial databases

[Anonymous Coward]

IIRC, Facebook has been heavily optimized around MySQL's limitations to the point where they're using it in a way that's more akin to the NoSQL key-value databases. The article posted to Slashdot a while back on Facebook's infrastructure indicated that they don't do joins and have separate physical databases for different types of data. A database like Oracle won't really give you much of an advantage, if any, over MySQL when used this way. In the hands of a trained professional, Oracle can do some amazing things, but simple row retrieval is something that it doesn't really do any better than MySQL.

If that's the case, I think it's a bit more than tweaking a couple of queries and would likely involve redesigning much of the way they've architected their code and even probably changing their network infrastructure at the data center(s). The article indicates that the person advising Facebook isn't advocating Oracle or any SQL database. He also doesn't think much of the NoSQL options either, some of which Facebook already uses. Nope, he's advocating something he calls NewSQL which (surprise!) his company sells as a product.

Re:Commercial databases

[Surt]

This is exactly why anyone in their right minds puts some sort of ORM/query layer in front of their database so that their mid-tier/front-end code has no knowledge of what the sql looks like.

Re:Commercial databases

[Loconut1389]

if more hosts would offer PGsql, I would use it, but my clients options get limited otherwise.

Re:Commercial databases

[Anonymous Coward]

But like the summary and article note, that requires rewriting the whole codebase. They should had gone with Oracle database to begin with, but of course no one ever thinks about the expanding possibilities when they're starting out and just want something free, ie. MySQL.

Actually, they shouldn't have gone with Oracle to begin with. Given their size and non functional requirements for scalability MySQL was probably the better choice (yes partially because it is free but also because it is simple). Unfortunately, if you're one of the 4 or 5 mega hit sites in this world your NFRs will change. They have and now they need an industrial strength solution. Selecting Oracle up front when you don't have the resources (financial or experts) to run it would have been a mistake that would have caused more issues than it solved.

It's not a poor decision up front that got them here it's an impossible to predict growth. Success sometimes makes fools of us and our plans when it's so out of the norm with regard to scale and speed. Architectural decisions aren't made for all time they're made in the context of a particular moment and when you have no cash, no Oracle DBAs, and need a database for your new website Oracle is not the right choice. When you're one of the fastest growing sites on the planet who's NFRs have significantly changes rewriting in Oracle (or Teradata or some other enterprise RDBMS that meets your new NFRs) is the new right thing to do.

Re:Commercial databases

[Loconut1389]

I've done a number of Zend Framework projects, and while I've been pretty careful to use quoteInto and quoteIdentifier and try to use the zend db select objects and whatnot, there are some queries with joins and things that just can't be abstracted (yet, with ZF at least), so if I were to switch databases there's still a lot of things I'd have to rewrite on the larger projects.

Re:Commercial databases

[cyber-vandal]

You have no idea what it's like under the hood so 'just' plugging in a compatibility layer may be a real headache.

Re:Commercial databases

[kimvette]

And, to add to that, Facebook is insane if they didn't implement what is commonly called an "access layer" for abstraction, so that the system can be rapidly ported from one RDBMS to another. However, even if they did implement that in their architecture, some issues come up: is it implemented throughout the project, or did some developers bypass it for performance, and is it intermingled with presentation code? Can they re-implement the access layer without performance suffering? Does the new RDBMS provide similar performance under their circumstances (a faster DBMS isn't always faster if it's not highly optimized for a corner case that another RDBMS by pure chance happens to excel at).

So no, it's not a matter of export/import and forget about it, but if they were smart about it from the very beginning (doubtful) it could be painful - and even if they did have the foresight to make it modular, it doesn't mean that Oracle would actually perform better for them.

But, I think few outside of Facebook would know the answer to those questions, and I think given the size Facebook has grown to, I'm sure that they have the staff on hand to keep it under control. I'm far more interested in learning what Google uses on their back end for a database that rarely if ever breaks under the immense load Google faces. THAT is more impressive than Facebook, IMHO because as far as I am concerned Facebook doesn't really matter since it's not essential; it's just a toy, but Google is essential.

Re:Commercial databases

[GooberToo]

Yes and no. There is ANSI SQL. PostgreSQL is probably one of the more compliant databases and is by far one of the more portable solutions. But even that is iffy.

MySQL is on the other end. MySQL is well known for being non-compliant, teaching very poor SQL code, offering minimal SQL compatibility and lowest common denominator features to achieve the same goal. That's also why, contrary to the lies and marketing hype, MySQL is almost always one of the slowest and least scalable solutions of any generally available SQL RDBMS.

Generally speaking, if you think MySQL is a good solution, there is almost always a better solution available. Far too often, vast ignorance, huge ego, and massive pride prevent people from considering alternative database solutions and their ignorance of the domain allows them to quickly become self assured they've picked a winner. Sadly, their self assurance is typically masked by their massive ignorance of the problem domain. And rather than validating they've picked a winner, they've only confirmed they should never be in a position to be selecting a RDBMS solution in the first place. But when people point this out, their pride and and ego assures them that any counter argument is anti-MySQL and elitism rather than a valid warning to stay away.

I'm sorry, but unless you're positive your project is a toy project and will always remain so, it is extremely unlikely MySQL can be justified for a project. Bluntly, for the vast, vast majority, MySQL is the choice of the uneducated and ignorant. And as a rule of thumb, simply picking any other solution than MySQL means you are in fact, better than the next would-be MySQL user.

Re:Commercial databases

[ppanon]

It's not much of a RDBMS if it doesn't support referential integrity.

Re:Commercial databases

[mcavic]

There's nothing wrong with MySQL, but Facebook's code has to be written efficiently. When you're adding lots of new features, it's easy to outgrow the limitations of the original design.

Re:Commercial databases

[Anonymous Coward]

But like the summary and article note, that requires rewriting the whole codebase. They should had gone with Oracle database to begin with, but of course no one ever thinks about the expanding possibilities when they're starting out and just want something free, ie. MySQL.

RTFA...He's not pushing a bigger standard RDBMS he's pushing new technologies which (wrong solution or right) he undoubtedly has a stake in and can see just how it would fit into one of the worlds biggest target for software licensing. It's not an article about why MySQL is bad and Oracle is good it's an article about why SQL based RDBMSes are bad.

Re:Commercial databases

[dgatwood]

With my experience, the biggest problems were date functions and the fact that MySQL embeds index creation in the create table syntax whereas postgres requires it be separate and the names of indexes are global. This meant that I had some work cut out for me changing index names. There were also a few quirks with some join queries as MySQL is not picky about ordering in the from clause.

Don't forget that the names for column types are substantially different, that even when they are the same, the maximum data lengths for that column type may not be the same (unless you explicitly varchar(xxx)), etc. There's a lot of room for surprises....

Still, it's not nearly as dire as a complete ground-up rewrite.

Re:Commercial databases

[mcavic]

MySQL is light years beyond Access. MySQL programmers consider Oracle to be a waste of money.

Re:Commercial databases

[RichardJenkins]

Do you ever find when someone says Oracle it's hard to tell from the contect if they mean Oracle the corporation or Oracle the flagship database product from that corporation?

Re:Commercial databases

[sphealey]

> And, to add to that, Facebook is insane if they didn't implement
> what is commonly called an "access layer" for abstraction, so
> that the system can be rapidly ported from one RDBMS to another.

"Access layer" aka "database independence". Otherwise known as "absolute death to any hope of performance and scalability". The reason one pays large sums of money for an Oracle, DB2, or even SQL Server implementation and programming is _exactly_ to get the performance and scalability potential and improvements that only come from understanding what your code does in its actual operating environment. And that operating environment and its capabilities are different from product to product; otherwise why would there be more than one? Oracle and SQL Server, for example, use locking philosophies that are 123 degrees apart from one another - how the heck do you write performant code that works against both databases?

sPh

Re:Commercial databases

[thetoadwarrior]

To be fair PHP is ugly and if they've written all their own stuff then they'll have all sorts of mysql specific PHP functions, like mysql_connect that, at the very least, need to be replaced with oracle specific methods. It's PHP the language is ugly and in terms of languages it borders on retarded.

Re:Commercial databases

[sphealey]

> Far too often, vast ignorance, huge ego, and massive pride
> prevent people from considering alternative database solutions
> and their ignorance of the domain allows them to quickly
> become self assured they've picked a winner.

I won't say that those factors don't come into play, because they do. But I think a more fundamental problem is that there has never been a good source of education on how relational databases really work in the corporeal world (as opposed to the theoretical world of CS 350), nor on how to develop scalable performant applications against databases as discussed by Tom Kyte and the Oak Table Group [1]. Instead just about everyone is self-taught, and unfortunately today that means self-taught with Microsoft Access and either MS SQL Server or MySQL - both of which lead to developing bad habits of thought [2] (autoincrementing columns! Yeah! Let's use them as primary keys!).

The somewhere around 2000 everyone decided that "application servers" and "database independent code" were the Wave of the Future(tm), and those without fundamental understanding followed along with the crowd. I have watched more than one performant single-instance Oracle-based application be replaced by a network of 327 servers running a competing RDBMS with the application becoming slower and less stable at ever step, yet it is Inconceivable(tm) to consider going back to the "archaic" design of a single powerful Oracle or DB2 instance with the majority of the business logic integrated into stored procedures. That's fad and fashion working against lack of true understanding, not just inflated ego.

sPh

[1] I'm sure there are other examples of good database design practice out there; those are the two I am most familiar with.

[2] Not that it isn't possible to build good systems with MS SQL Server, because it is possible. It just is rare in my experience.

Re:Commercial databases

[curunir]

In my experience, you don't really have to worry about the types of SQL that MySQL won't accept or the specialized syntax that MySQL will accept. The biggest pain is worrying about the SQL that MySQL will accept and choose the stupidest execution plan possible. This leads to unintuitive queries designed around MySQL's shortcomings.

For example, one hack we had to employ regularly was to select only the columns from a table that were part of the WHERE or ORDER BY clauses and then join back against the original table once the results had been filtered and sorted. When we just selected normally from the table, MySQL would retrieve the entire rows and then determine that the amount of data it had to sort through exceeded the amount of RAM we had on the machine so it must use a file sort. This technique would commonly bring queries that were taking days to complete down to under 1 minute.

In the end, our application was full of this kind of "keep MySQL from doing the stupidest thing possible" queries that would probably run decently under Oracle or PostgreSQL but would be better written in a way that allows a real SQL database to perform its own optimization and allows the developer to easily grok what the query does. It's that kind of SQL that's the most insidious. The kind of SQL that MySQL forces on you not through syntax errors by through painful lessons.

Re:Commercial databases

[larry bagina]

face book uses php, yes, but it's compiled to c++ with hiphop, so it's a subset of php.

Perl's DBI has always encouraged placeholders whereas php/mysql has encouraged building your own query by hand.

Re:Commercial databases

[Gripp]

i'm *not* a db guy,(actually a software-development-platform QA guy... ) but i've dealt with a large variety of them, and oracle is the odd-ball by far. not MySQL. MySQL to Oracle would be a nightmare - but worth the performance benefits. MySQL to near anything else would be comparatively simple. but if FB plans to do it right, they will go with oracle. its not like they can't afford the investment....

Re:Commercial databases

[durdur]

It's been a loooooong time since I looked into Oracle, but last time I checked it was cost prohibitive to use it for startups.

It's not. Oracle has a free version (Oracle XE) although there it has limits. If I remember right, it's about $5K for a license of their standard edition. That's about the cost of 1-2 developer weeks, counting overhead. If you start running a big Oracle cluster (RAC) or you start adding enterprise edition features then it can cost you. But you can run a website quite a long time before you need that.

Re:Commercial databases

[qwijibo]

Ability to convert depends completely on the application. If the MySQL app written using simple or at least standard SQL, it will be easy to migrate. However, MySQL has some very problematic areas (i.e.: select foo from table1 where id in (select id from table2 where criteria='something')) that make people do some very nonstandard and MySQL-only style fixes to address performance. The query shown with 5000 rows in table1, 50000 in table2, table2 only having 50 rows that met the criteria took ~10ms on PostgreSQL 8.3, and 52 minutes on MySQL 5.1 on the same hardware. The only way I could find to get the ~10ms performance on MySQL was so goofy that MySQL itself refused to allow me to create a view from that select statement.

Converting from PostgreSQL to Oracle has always seemed much easier and smoother, but PostgreSQL isn't as popular as MySQL because it hasn't been as easy to throw hardware at problems with scaling PostgreSQL, whereas MySQL has always made that option easier.

Each database has its own pros and cons, but most times you don't discover how hard it is to migrate until it's too late.

Re:Commercial databases

[gomiam]

...how the heck do you write performant code that works against both databases?

Erm... writing _two_ code baselines that provide the same high level interface, perhaps. It's not as if that same problem hasn't been dealt with several times before (compiling to different architectures, for example).

Re:Commercial databases

[Anonymous Coward]

still, there's nothing wrong with loosely coupling the database calls so you only have to change your implementation (instead of replacing tons of calls to mysql_)

Re:Commercial databases

[Dorkmunder]

Yeah, I love how this whole discussion is now about why MySQL is so bad and if they had only chosen PostGre or Oracle or something things would've been much better when in actuality it is an article about using NewSQL instead of any other RDBMS. You are the first person to point it out. I know no one RTFA's but still

Re:Commercial databases

[FreelanceWizard]

You write the code that actually does the queries as stored procedures in the database, then write a DAL that essentially works as a database driver. Your code does nothing to the DB other than requesting that it execute an SP, and the SPs can be tuned for the specific database server.

Of course, if you use a persistence framework that makes SPs difficult or impossible to use or if you started out on a database without SP support, you're screwed. This is all the more reason to start with the free versions of DB2 or SQL Server during development and scale up to the higher performance (and cost) versions as needed. Note that I've explicitly excluded Oracle from that list, as I've never once seen a production Oracle database ever reach the performance of... well, any other database server, really. I don't doubt that Oracle can be made fast; I just doubt that getting the personnel who know how to do that and paying them to do so is worth the cost compared to easier to use, less expensive, and faster out of the box systems like, oh, DB2 and SQL Server.

Re:Commercial databases

[MightyMartian]

True enough, but providing they've isolated the querying functionality from the rest of the system, it's not an insurmountable problem, and hardly requires a major rewrite. I moved a custom Accounts Receivable system initially written with an MS-Access over to MySQL, but because I had encapsulated the queries into classes, the rest of the code remained largely untouched. Still a bit of effort, but certainly not a complete rewrite.

Of course, that means doing things properly, and maybe Zuckerberg just didn't your standard PHP job of slapping all the crap together. In that case, yes, it's a nightmare, but still, it's largely a matter of going query by query. I've done it in moving over from MySQL to SQL Server, a much smaller project of course, but still not insurmountable.

You'll probably spend nearly as much time massaging the SQL scripts to overcome incompatibilities.

Re:Commercial databases

[h4rr4r]

Or Postgresql, free and good.

Re:Commercial databases

[LurkerXXX]

Oh give MySQL a break. They finally fixed it so it no longer recognized February 31st as a real date, so they are making progress.

Re:Commercial databases

[h4rr4r]

Unless you care about your data. Then you could save your money and your data and just use Postgres.

Re:Commercial databases

[qwijibo]

There's a level of complexity and size where Oracle does a much better job out of the box than MySQL. Oracle is expensive - it can cost more to license than the expensive hardware it runs on. However, a team of people to address performance issues is not a trivial cost either. Trying to take something huge, like they have now, and switch databases is a giant undertaking and I wouldn't be surprised if it cost more than 10 years of Oracle licensing when you think of all of the manpower required. Oracle is an expensive, bloated pig of a database, but as databases grow in size, Oracle does well and they'll do everything they can to keep you happy. People look at the cost of converting from MySQL to Oracle, but I've never seen anyone try to go the other way around to save some money.

Re:Commercial databases

[onepoint]

Given it was 2 weeks for you and you were doing a lateral move ( I feel the Mysql and Postgre are very similar, so it's minor changes ).

The point is for Facebook, is that they built out a monster that needs to be tamed.

Can it be done in Mysql, Yes, it's a total pain in the ass, but they can do it.

it would require them to start with the least used parts of the platform, rip and replace with cleaner code that's well documented in order for future upgrades. step by step, in small targeted teams each working towards the frequently used routines.

As for those that complain about Mysql not being the best platform... How the heck are you to grow your business when you don't have the resources, not many people know how to tune an Apache server, say the least a Mysql server, so you start on the lower end. grow out, make some change then start thinking.

Now I will agree that most people never think of the Database side of web site, that's a shame.

Re:Commercial databases

[sphealey]

> You write the code that actually does the queries as stored procedures
> in the database, then write a DAL that essentially works as a database
> driver. Your code does nothing to the DB other than requesting that it
> execute an SP, and the SPs can be tuned for the specific database server.

True, but that is not writing "database independent code" - it is writing separate versions of the code for each database and building a good UI that can be configured to be compatible with all of the versions. That's exactly what Tom Kyte (of Oracle) recommends as a development strategy, and there is a funny case in _Tales of the Oak Table_ (a book I recommend to everyone involved with databases) where Oracle consultants called to a customer site ended up writing a second version of their customer's code for SQL Server, cleaning up the original version for Oracle, and having both be 100x faster than the original "independent" code with essentially the same total number of source code lines.

> Note that I've explicitly excluded Oracle from that list, as I've never once seen a
> production Oracle database ever reach the performance of... well, any other
> database server, really. I don't doubt that Oracle can be made fast; I just doubt
> that getting the personnel who know how to do that and paying them to do so is
> worth the cost compared to easier to use, less expensive, and faster out of the
> box systems like, oh, DB2 and SQL Server.

We'll have to agree to disagree here. I agree there is some truth in what you say about needing people who actually understand Oracle; if it is installed and used as if it were Access then it doesn't work well. My personal experience however is more with an application running with decent performance on a single Oracle instance being replaced with a "cluster" of SQL Server that starts out with 10 machines (5 databases, 5 of whatever application server Microsoft is pushing this year) and ends up as a cluster(-f***) of 300 or more machines and a constant cry for "more RAM", "more budget", "more servers" - and is never as fast as the system it replaced.

sPh

Re:Commercial databases

[Anonymous Coward]

Oracle and IBM's DB2, and probably all other commercial db vendors, have free offerings. Most have license restrictions on the number of processor cores or RAM. You pay the big bucks when you are ready to put the db on heavier metal.

Re:Commercial databases

[jonbryce]

$5k is a lot of money for a student who is hacking something together in their university dorm.

Re:Commercial databases

[Anonymous Coward]

I would suspect that if they were moving to another RMDB that it wouldn't be a total rewrite. I suspect what they are doing is moving everything to a NoSQL implementation, keeping in mind Cassandra was originally developed at Facebook. Even something like Oracle RAC stops scaling at a certain point, and if your main business is software, and you are as big as Facebook, you probably want the type of control that having access to the source code provides.

Re:Commercial databases

[h4rr4r]

There is a lot wrong with MySQL.
1. lack of referential integrity
2. least SQL std compliant of all the popular DBs
3. auto-incrementing rows that morons use as their keys
4. The default engine does not even support transactions.

I am sure other posters can add some more

Re:Commercial databases

[mooingyak]

...how the heck do you write performant code that works against both databases?

Erm... writing _two_ code baselines that provide the same high level interface, perhaps. It's not as if that same problem hasn't been dealt with several times before (compiling to different architectures, for example).

Sometimes. I once dealt with a database called UNIFY which had a piss-poor query planner. It tended to overwhelmingly favor certain types of indexes (which were built implicitly for you whenever you had a foreign key relationship) over any other kind. We had a frequently used query against a sku database on style, color, and size. There were indexes on any combination of those fields, but color was also a foreign key to the color table. Which meant that it ALWAYS used the color index. Problems rose up when the conditions were something like color = black, style = blah, size = medium. There were maybe 30 skus for any given style. There were around 650k skus with color = black. There were a number of ways we could solve this, but what ended up working out for us was to only query against style/size and then run the output through a filter that kicked out all the rows with the wrong color.

While you can still abstract something like that, it gets to be a bitchy problem and makes the overall work much more complicated.

Re:Commercial databases

[GP1911]

Google also uses MySQL for a lot of things. See http://www.mysql.com/customers/view/?id=555

"Google runs critical business systems with MySQL and InnoDB. The systems require 24x7 operation with minimal downtime. The systems support large OLTP and reporting workloads. We are very happy with the scalability, reliability and manageability of this software."

Google and Facebook have worked on many patches and tools for MySQL, and along with work from Percona, MySQL has come a long way as an extremely fast and scalable server in the last few years.

Re:Commercial databases

[sphealey]

> We had a frequently used query against a sku
> database on style, color, and size.

Love those apparel industry-specific systems and databases. There are reasons why they are designed the way they are (and different from everything else), but they are murderous to work with!

sPh

Re:Commercial databases

[JamesP]

Yes and no. There is ANSI SQL. PostgreSQL is probably one of the more compliant databases and is by far one of the more portable solutions. But even that is iffy.

MySQL is on the other end. MySQL is well known for being non-compliant, teaching very poor SQL code, offering minimal SQL compatibility and lowest common denominator features to achieve the same goal.

Except writing SQL manually with pgsql is painful. MySQL accepts most everything you throw at it (I'm not talking about writing that in programming, but opening psql or mysql and writing a query.

And don't get me started on '\dt;'

Configuring mysql is also much easier (especially on Fedora, so it may be not the fault of pgsql). Insecure? Not necessarily. (And they both fundamentally suck on pw and account management, so no one is better in that sense).

That's also why, contrary to the lies and marketing hype, MySQL is almost always one of the slowest and least scalable solutions of any generally available SQL RDBMS.

Out of the box, Mysql is faster in some situations. Maybe it has to do with the ORM or default distro configuration. But it may be faster sometimes (see other posts here on this discussion). But still, even Jacob Kaplan-Moss recommends Postgres for Django.

Generally speaking, if you think MySQL is a good solution, there is almost always a better solution available. Far too often, vast ignorance, huge ego, and massive pride prevent people from considering alternative database solutions and their ignorance of the domain allows them to quickly become self assured they've picked a winner.

It is a good enough solution considering time/implementation effort/performance and relevance to that to the overall solution. You can use PGSQL but if you still have SQL injection problems.

You can work around MySQL performance with caching and other techniques. Merely switching to Postgres won't get you the performance gains you need.

I'm sorry, but unless you're positive your project is a toy project and will always remain so, it is extremely unlikely MySQL can be justified for a project. Bluntly, for the vast, vast majority, MySQL is the choice of the uneducated and ignorant. And as a rule of thumb, simply picking any other solution than MySQL means you are in fact, better than the next would-be MySQL user.

Tell that to Facebook. Tell that to all the corporate portals using Wordpress (yes they should do a PSQL version).
Most projects are not a contest of who knows the most details of SQL specs.

Re:Commercial databases

[David Gerard]

No. And if you run MySQL and need actual performance, you need to over-optimise your code to MySQL to a horrible degree. Proper databases like Oracle and Postgres handle queries a lot more smartly.

MySQL is such a piece of shit. But Oracle's pricing model is "how much have you got?" and the M in LAMP is always MySQL and almost never Postgres unless you're going to take on the support for it yourself. Bah.

Re:Commercial databases

[tgv]

I can't believe you didn't point out that going with Oracle could also have meant doing everything in Java or using AutoVue or Oracle Linux (http://www.oracle.com/us/technologies/linux/index.html)

Re:Commercial databases

[Tablizer]

It seems like nobody can agree to the best hardware/OS/database solution, but there are plenty of people who swear that the solution they know is the best one.

Well, they may be right in a relative sense: master what you have and know and you can probably tune it better than something new to you. They are probably all scalable with enough fiddling and diddling; it's just a matter of experiments and experience with a product.

Re:Commercial databases

[mooingyak]

It got even worse when we started branching out to non-apparel retailers. Management had zero interest in maintaining multiple schemas, since a new schema would mean we couldn't leverage all of our existing (apparel specific) reports.

Re:Commercial databases

[durdur]

Oracle doesn't charge for developer use, not even of their high-end products. If you put in production then you need to pay.

Re:Commercial databases

[TheLink]

You write the code that actually does the queries as stored procedures in the database,

Uh, how would that achieve "database independence" (as the OP etc are talking about)? How would it make it easier to migrate to a 3rd DB?

Using lots of stored procedures would make it even harder to migrate, since you would have to rewrite most of them.

If you're actually suggesting writing X versions of stored procedures just to be able to run on X different DBs that's not solving the migration problem. That's continuously living in the migration problem.

That's like suggesting that people be in both the frying pan and fire just so that moving from one to the other is not more painful ;).

Yes I know some C programmers do something analogous for different platforms/architectures but there's a reason why people prefer to use what the C programmers write, rather than write C...

Re:Commercial databases

[isopropanol]

They're busy contributing significant enhancements to Linux Kernel block devices

Oh, also, MySQL.

Re:Commercial databases

[mlts]

FB architected themselves around cheap. Lots of cheap x86 boxes and have the backend application deal with failing servers.

In reality, FB should have considered moving to "big boy" hardware. Since they use MySQL, why not go with full blown Oracle clusters on SPARC M-Series with a decent EMC SAN? Backups are fairly easily done with replication and snapshots, with a tape library to store archives of the build tree. User data can happily remain on a deduped filesystem while business critical stuff like tax records can sit on disk, as well as get saved to tape.

Moving to Oracle also gives the benefit of being able to have the best RDBMS tool selection out there from a mom and pop shop all the way to multi-terabyte databases sitting on SSDs used at banks for 24/7/365 transaction processing.

IBM is another possibility. Upper end POWER7 boxes only need a few CPU and I/O drawers and have the I/O buses that can handle the load FB has. They can use Oracle on this platform, or use DB/2's new oracle compatibility mode and move to that. IBM has a decent AIX/POWER7/DB2 compatibility stack which can load-balance quite effectively.

Or, if FB was willing to reorganize, a couple IBM zSeries and a decent backend storage device (DS8000, EMC's Symmetrix or Celerra series) could sit in a fairly small data center, doing all the work that the tons of x86 boxes do for far less energy used and cooling.

I wonder how much money FB would save had they built their redundancy lower in the hardware/software stack as opposed to having their backend app do all the work? Of course, there is the understandable fear of being locked into a platform... but isn't this the issue with MySQL now? Better to be married to a platform that can scale than one that has been shown to require gymnastics to get it working on the level that FB needs.

Re:Commercial databases

[HornWumpus]

The rest of the database world considers MySQL programmers to be a waste of money. Worse a waste of money with lock in.

MySQL might be light years beyond Access. I put it on par with Dbase3, but rapidly catching up with Clipper.

Re:Commercial databases

[LordLimecat]

Does that mean no more Smarch?

Re:Commercial databases

[marcosdumay]

Some DBMS use a completely incompatible language instead of the standard. MySQL and Oracle are the most important guilty here.

Also, all DBMS implement extensions to the standard SQL, if you use those you'll have a hard time porting your software (but it will probably be cheaper to implement and run faster).

Re:Commercial databases

[LordThyGod]

If someone wanted/needed transactions, why would they ever opt for an engine that would not work for them? Ignorance? Laziness? Secondly, the "default engine" does indeed support transactions. And referential integrity.

Re:Commercial databases

[sphealey]

> If you're actually suggesting writing X versions of stored procedures
> just to be able to run on X different DBs that's not solving the
> migration problem. That's continuously living in the migration problem.

Yes, that is exactly what the parent is suggesting, since experience shows it is the only way to get correct, performant, scalable systems. Organizations that actually have a need to support multiple databases (few truly do) generally find that this method is in the end less labor-intensive than attempting to recreate the features and services that Oracle, IBM, Microsoft/Sybase have spent 10s of millions of manhours developing over 30 years; instead they use those features that they (and their customers, if they are software vendors) paid the big bucks for.

I'd would ask that you think deeply about this and do some research before replying; keep in mind that "common practice since 2000" is not the same thing as most efficient practice.

sPh

Re:Commercial databases

[drolli]

If i would start a fun, interesting project, and it would exceed 100000 - 1000000 Million users, i would think what to do.

Re:Commercial databases

[LordThyGod]

I'm sorry, but unless you're positive your project is a toy project and will always remain so, it is extremely unlikely MySQL can be justified for a project.

Unless you are looking to do something like Facebook. The proof is in the pudding. It works. It stays up. Its rarely seems to suffer performance issues. Its not been hacked (that I know of). Where's the real world problem? All the chest thumping is over "I could have done it better" is just hooey.

Re:Commercial databases

[genner]

Why would that require rewriting the whole codebase? Isn't SQL standard?

BAHAHAHAHAHAHA!
I'm sorry I don't have a mod points to mod this funny.

Re:Commercial databases

[jedidiah]

There are still some basic principles that exist on all databases that don't really change despite whatever minor quirks in syntax you might encounter.

Things that are going to clobber you during a port from one RDBMS vendor to another are going to be a bit more subtle than that.

Being able to use standard syntax from the start is potentially quite useful. You also don't have to actively seek out and use the non-standard features that are present in whatever product you are using. This applies to more than just RDBMS servers.

Re:Commercial databases

[dlweinreb]

While everything you say about MySQL is true, Facebook is using it in an extremely simple way: as a persistent key-value store, according to the talk they gave at MIT. That circumvents a lot of MySQL's weaknesses. Now, you might ask, if that's all they want, why not use software specialized for that? Well, I'm not sure, but (a) maybe they do use a bit more than that, such as MySQL async replication, and (b) I have heard from some people that MySQL (InnoDB) is actually surprisingly fast as a key-value store, though I do not particularly know why that would be. So although what you are saying is excellent general advice, the Facebook situation is very atypical.

Re:Commercial databases

[jjohnson]

How many database servers did you have backing your app?

My whole point was that the engineering concerns of a large-scale app are hugely different than those of a small app. I believe that you could port an app from MySQL to PostgreSQL in a couple weeks, assuming that it was as simple as going through the code and adjusting the queries. For Facebook there's a lot more than that to do, though. There's cluster performance, there's handling replication lag, there's integrating it back with memcached, etc. Cluster engineering is its own discipline.

A lot of people are saying "they'll be fine if they used an ORM layer", but it's highly doubtful they did because the first performance overhead to eliminate is the ORM layer by either writing directly to the database or customizing the ORM layer so much that it's equivalent to writing directly to the DB.

Re:Commercial databases

[drolli]

The fact is: there is no single best solution. Specific bottlenecks will require specific solutions.

Re:Commercial databases

[JAlexoi]

And, to add to that, Facebook is insane if they didn't implement what is commonly called an "access layer" for abstraction, so that the system can be rapidly ported from one RDBMS to another.

They chose to do the whole system in PHP. Having no abstraction layer doesn't sound that insane now, doesn't it?

Re:Commercial databases

[JAlexoi]

MySQL is a very fast data store, not so much a RDBMS.

Re:Commercial databases

[JAlexoi]

Maybe because Oracle forbids any public statements that could tarnish their image? When you license Oracle DBMS, you sing away a lot of your rights as a consumer. Including the right to complain about Oracle DBMS to anyone else other than Oracle.

Re:Commercial databases

[WaffleMonster]

This is exactly why anyone in their right minds puts some sort of ORM/query layer in front of their database so that their mid-tier/front-end code has no knowledge of what the sql looks like.

LOL because we all know thats how you improve performance.

Re:Commercial databases

[Anonymous Coward]

In a debate about how Facebook - one of the most successful, largest, and fastest growing web sites in history - one built around a core of massively shared data - one which has achieved amassing fast (for it's size) almost real time data updates and amazing levels of reliability (for it's size and speed of growth), by using MySQL, you are actually trying to argue that MySQL can't work for anything but "toy" sites? Really? Do you not see the total absurdity of your point? Facebook is, itself, the proof that your point is invalid.

If MySQL is in fact a current problem for them (and I don't yet see the evidence that this is even true), then they can throw it out, and rewrite the database from the ground up if that is what is needed. Or, more likely, offload the 20% of the database that is causing 80% of the problem, to a custom solution. Custom database code tailored to the needs of a specific application is always going to out-perform any off-the-self SQL solution. The last thing they should consider is getting locked into some vendor's proprietary database. Their database is the core of their business. If they handed that control over to the likes of Oracle, they might as well just be giving their business to Oracle. No one that is smart enough to create facebook, would be so stupid as to allow themselves to get chained into bed with a third party vendor like Oracle. It has nothing to do with how good or bad MySQL is vs products like Oracle. When the database _is_ your business, you don't outsource it unless your goal is to go out of business.

Curt Welch

Re:Commercial databases

[Anonymous Coward]

Maybe because Oracle forbids any public statements that could tarnish their image? When you license Oracle DBMS, you sing away a lot of your rights as a consumer. Including the right to complain about Oracle DBMS to anyone else other than Oracle.

Oracle sucks ass. Its security record is as much a joke as it is from a usability and performance point of view. Understanding rman is not a badge of honor it is a complete waste of time.

No transaction support for DDL.. Heck its own syntax is not even self-consistant. '' IS NULL. The hell it is!!

Oracle is an overpriced heap of shit written before I was alive.

Re:Commercial databases

[malakai]

This.

The complexity in moving a VLDB from one platform to another comes in the differences between the SQL compilers/tuning. What MySQL, Oracle, Postgre and SQL Server all have in common is SELECT * FROM FOO. After that, it gets complicated. Query's start timing our or taking 100x as long, because of some mystical magic you need to know in one of those DB's to help the query optimizer find the most efficient path.

Also, the physical and logical structure of the DB may need to be changed both for performance and refactoring reasons. For example, FB may have worked around limitations in MySQL by vertically partitions very large tables across multiple tables. In some DBMS's, this occurs behind the scenes with a partitioning index. I've seen people write code the 'understands' the vertical partitioning algorithm at the PHP level, because relying on a view or some other trick to combine them was too slow. So when you move to a new DB where you go back to just have a single "User" table, well, that's a refactor/rewrite ( albeit a more simple one )..

tl;dr: finely tuned VLDB do not port easily to new DBMS. Hell, sometimes they don't port to new hardware as you expect...

Re:Commercial databases

[i_ate_god]

1. InnoDB
2. fair enouogh
3. not a requirement
4. so?

Re:Commercial databases

[Bert64]

What you fail to consider tho, is that while Oracle is perfectly capable of scaling technically... It does not scale very well financially, once you get to the size and scale of facebook the cost of oracle licenses would be absolutely crippling... It makes more sense for them to modify mysql to better suit their requirements.

Re:Commercial databases

[mabhatter654]

MySQL is designed to grow in a completely different manner than Oracle.

There's NO database vendor with an off-the-shelf product that could do what Facebook does. The only comparable installs would be Social Security, IRS, or the VA, maybe something like Airline reservations.. Giant companies like GM or IBM aren't all run on one system like Facebook and other big web sites.

Sure on paper you can line up a half dozen IBM POWER 7 mainframes and DB2 or Oracle to handle to handle the current transactions and the consultants would optimize the hell out of it. That's on terms of a 5-year hardware and software plan with 3-years to implement. That would be more power efficient and stable and secure.... And even if you could cut implementation in half (and even if you could delivery is measured in BUSINESS QUARTERS) the lack of real science in the enterprise industry would kill Facebook dead long before the hardware hit the power sockets.

My company is doing one of those SAP roll-outs. Each business unit might have 100GB to 1TB of actual business data in their systems.... In various formats. In the world of Facebook, that's like a DAY of traffic and every 6 months they rework dataformats and add new features... So they are several times more flexible than just sucking in data from a 10 year-old ERP system.

The ONLY way to manage something like Facebook is to use an army of drone machines that can be repurposed nearly constantly. Sure IBM or ORACLE can do much better in a lab with a static copy of Facebooks data... Web startups are a problem Enterprise companies have never tackled. It's not a database science problem, it's a logistics problem. Like changing tires on your car while driving down the highway. Enterprise systems get around the problem by offering only a very narrow window into the data and limited client options. Facebook offers many more connection options to developers that make products like SAP look old.

The comparison in a nutshell: a massive credit card processor still only collects the tiny amount of data from the customer and retailer that has been basically the same for almost 20 years. Facebook changes the mix of it's traffic with new TYPES of data every 6 months... The comparison has nothing to do with bits and bytes... It has to do with managing change on a MASSIVE scale Enterprise vendors are incapable of wrapping their heads around.

Re:Commercial databases

[turbidostato]

"you are actually trying to argue that MySQL can't work for anything but "toy" sites? Really? Do you not see the total absurdity of your point? Facebook is, itself, the proof that your point is invalid."

Hummm, no. I'm not English native, so I may be wrong, but my reading comprehension doesn't parse his message that way.

What he says is not that MySQL is not capable for anything but toy sites but that MySQL is not the right answer for anything but toy sites. That's not an adherence statement neither to his opinion nor against it, but just what I read.

An example (with a car no less): can you go by car from Beijing to Minneapolis? Surely you can: it will take a lot of driving, weeks within a freigther and quite a lot of money, but it can be done. But is it the right solution in anything but the most bizarre situations?

And no: being the fashionable choice doesn't make it the right one.

Re:Commercial databases

[turbidostato]

"the M in LAMP is always MySQL and almost never Postgres"

I think it might be because in most programming languages I know of "M"=="P" returns False.

Re:Commercial databases

[turbidostato]

"If you put in production then you need to pay."

Maybe he wasn't clear enough: "$5k is *still* a lot of money for a student who is hacking something together in their university dorm even when it gets in production as a for free service."

Re:Commercial databases

[turbidostato]

"there are plenty of people who swear that the solution they know is the best one."

Well, my experience, that seems to be backed up by the very references you offer about companies migrating from RBDM to RBDM is that even more people tend to swear that the best solution must be any other *but* the one they know the best.

Re:Commercial databases

[petermgreen]

(i.e.: select foo from table1 where id in (select id from table2 where criteria='something'))

Haver you tried using a join and if so how well does it work?

e.g. select table1.foo from table1 inner join table2 on table1.id=table2.id where table2.criteria='something''

Re:Commercial databases

[mabhatter654]

How many THOUSAND nodes did you have to convert with zero downtime?

As powerful as Oracle is supposed to be, having access to all of MySQL as well converting should really be EASY for the end users.... Even at The scale of Facebook.

A LOT of the problem is culture. Oracle is a company that builds "bridges". They expect to research what the optimum DB science is, then spend 5 years between versions building a bridge that is going to have the exact same lanes for wheeled vehicles for 20 years. That's fine for utilities or governments. MySQL is like making scooters... More people NEED scooters than need expensive bridges.

Fundamentally, the PROBLEM is what Oracle's engineers cannot understand. That's how MySQL got to be a billion $ company in the first place. It's the classic Acadamia vs hackers. The Hacks get up every day and build something like their life depends on it. In the 6-12 months Oracle's skate people with papers take to mull the problem, the hacks have been DOUBLING your business.

Re:Commercial databases

[Daniel Phillips]

But like the summary and article note, that requires rewriting the whole codebase.

So? The original codebase was written on a shoestring by some college kids. The available budget for a rewrite is now millions to say it conservatively. Get started, do it. It's not like the current code base is a model of great design anyway.

Re:Commercial databases

[Daniel Phillips]

And, to add to that, Facebook is insane if they didn't implement what is commonly called an "access layer" for abstraction...

A large company could do something insane at the expense of security and profitability? Please tell me it ain't so.

Re:Commercial databases

[DamnStupidElf]

You might be underestimating the load facebook handles. Facebook routinely has tens of million of concurrent users, conceivably producing 100 million or more TPS at peak loads. Maybe the very latest hardware could handle that in a single database cluster, but I would bet that Facebook would still find it necessary to run separate databases for different types of data (users, posts, media, applications, ads, etc.) and use application nodes to glue it back together. At that point is it worth it to spend the $$$ on Oracle and big iron instead of making the application nodes do more work with an essentially free back end?

Re:Commercial databases

[Rayonic]

(i.e.: select foo from table1 where id in (select id from table2 where criteria='something'))

Haver you tried using a join and if so how well does it work?

e.g. select table1.foo from table1 inner join table2 on table1.id=table2.id where table2.criteria='something''

Or this might be better, depending on the quality of the query optimizer:
select table1.foo from table1 inner join table2 on table1.id=table2.id AND table2.criteria='something''

Re:Commercial databases

[Daniel Phillips]

Google also uses MySQL for a lot of things.

So if Google does it then it couldn't possibly be stupid, right?

Re:Commercial databases

[mabhatter654]

Of course Oracle is moot anyway. Microsoft owns a good stake in them already and also in Yahoo. If anything, they'd go MSSQL.

The REAL PROBLEM is that enterprise vendors think web apps are stupid and have no skill or want to LEARN skills needed to sell their products to those markets.

After all, if Oracle or Microsoft has such great developers, they should have tools to convert "amateur" work quite easily. Given that web sites like Facebook use clusters of non-homogenous hardware, it should be a piece of cake for such LEGENDARY companies to build a new DB farm that could learn from the old one and migrate the data. Think how Google achieves redundancy by using 3 different servers in different networks for the data. They "migrate" by adding a server with new code and pulling the plug on one old server.. For Oracle or Microsoft with all those PhDs they have that should be easy.

Fundamentally, when faced with problems like these in the past, companies like Oracle and Microsoft simply refuse to bid until an ISV figures out all the hard parts and tells them how to fix the problem.

Frankly, if I was Facebook I would not use either system unless I was dealing directly with a VP of the main product with direct reports that physically write code and implement databases. No ISV, no consultants... Put up a VP with a direct phone to the project lead or go home. I would put in the contract immediate termination for any employee on the project that says "cannot do..."

Oracle and Microsoft research are great.. But THOSE PEOPLE don't fulfill the contract... Some really stupid MCSE from India does... If I was Facebook refuse to allow ANY person on the project not a direct employee of the DB vendor.

Re:Commercial databases

[NeoMorphy]

I was thinking of the situation where a new vice president comes in and decides that the DB2 databases on AIX need to be migrated to Oracle on Solaris because that's what they were running at his previous company. If you have Oracle running on AIX, a new DBA might come along and insist that it should be migrated to Solaris, because in his experience it would be faster.

New vps also like changing PC vendors to the one they used at their previous company.

Re:Commercial databases

[Anonymous Coward]

nope.if someone was talking about Oracle Database, they'd say so. Otherwise they could mean MySQL or Sleepycat BDB. Or maybe the old black woman from The Matrix.

Re:Commercial databases

[Anonymous Coward]

As a php code monkey and not a certified DB engineer, I will admit a certain level of ignorance on the issue... however:

I am dumbfounded by the claim that they have an application that is stuck on one db and it is because of the code that runs the site. I have never, ever worked on a credible project that was not data-base agnostic. Many, many excellent tools exist for abstracting the DB out of your code entirely, many of them are part of newer php releases itself or as part of pear.

To be honest, if they are so tied to MySQL, that probably means that their code is a horrid nightmare that needs a complete re-write anyway, and there is no way to blame that kind of crappyness on MySQL. If, in the YEARS that they have been popular and getting more popular, they have not been doing incremental changes to move to one of these systems, that speaks very poorly of their development management. Hell, it probably means that their code is so bad that with a good rewrite they could stick with MySQL for a number of years to come.

Re:Commercial databases

[Evets]

And that's exactly what people use RDBMS's for 95% of the time.

Very few DB implementations leverage more than data storage and basic querying capabilities, and even fewer require real scalability.

Re:Commercial databases

[Evets]

You are better off with commodity hardware and a data layer with a code base that can be referenced. All high end hardware will get you is dollars out the door and a fraction of additional QA that may or may not be worth while.

All licensing costs for a commercial db will get you is access to a knowledge base and increased costs to run it.

You run into tougher road blocks with less (and sometimes no) solutions available with DB/2 and Oracle. On something the scale of Facebook, that simply will not work.

Re:Commercial databases

[LordThyGod]

I know that saying really stupid stuff is not a surprise on slashdot, but the "whole system" is not php. The front end code is. The backend is hybrid of various languages. And in fact, if php handles the 2nd heaviest traffic site on the internet without issues, what makes it so bad? The counter argument will be Facebook, of cousr. Or is it just a theoretical issue of some kind that does not really pertain to real world situations?

Re:Commercial databases

[Anonymous Coward]

They should had gone with Oracle database to begin with

And how would Oracle solve this problem?
By throwing even more Oracle Exadata racks on the problem?
Not very cheap either, and requires skilled Oracle DBAs - not that you can't find them ...

Re:Commercial databases

[maxwell demon]

3. auto-incrementing rows that morons use as their keys

You say it's a fault of the DB if morons misuse its features?

Re:Commercial databases

[SnowZero]

It's not a database science problem, it's a logistics problem.

You hit the nail on the head right there.

Re:Commercial databases

[Bert64]

All of this highend kit also carries a highend price tag, it's often cheaper to buy hundreds of lowend x86 boxes...

As for scaling, technical scaling is one thing, financial scaling is another. Consider that facebook not only need enough capacity to handle the load, they need to be able to replicate to other locations and handle the load somewhere else if the primary site goes offline etc so you need multiple sets of expensive servers, not to mention test environments which replicate live as closely as possible.

Also as you point out, not wanting to be locked in... Being locked to MySQL is bad, but nowhere near as bad because they have all the sourcecode and specifications. They have already done a lot of work improving the performance of PHP, and will most likely look at doing the same for MySQL, options which simply wouldnt be available to them with closed source software.

Re:Commercial databases

[nitehawk214]

But like the summary and article note, that requires rewriting the whole codebase.

Why? While dbms platforms are not usually an easy thing (unless you are using some super-high level framework that sucks the life out of your performance anyhow), why should this be an insurmountable task requiring every line to be rewritten? Its not like the thing is such a giant pile of shit that it would have to be recreated from the ground up....

Wait.

Re:Commercial databases

[Rufty]

NB, whilst there is no February 31st, there may well need to be a February 30th, 4000. (Wednesday, fwiw).

Re:Commercial databases

[ralphdaugherty]

Why would that require rewriting the whole codebase? Isn't SQL standard?

was this going for funny?

Re:Commercial databases

[laffer1]

I'm not saying a small app == big app, but everyone is acting like they're just going to flip the switch without QA, testing, etc. I realize that facebook doesn't normally do QA and they have small groups of users test. For something of this magnitude that would not work. They'd have to do it correctly.

You don't use an ORM layer for performance, you use it for flexibility. ORMs are slow. I'm not arguing that. In PHP, PDO is not that much slower than using mysql or mysqli. Based on my experience with PHP and a silicon valley startup, I can tell you that this is doable. They're not the size of facebook, obviously, but the software is similar. I doubt they'll even have to touch the memcache part of the code at all. It's very easy to use in PHP and they've probably wrapped that logic anyway.

Facebook can afford to hire a consultant to help them get the most out of a new database system and train their people (if they don't know already) how to tune the new system. A testbed allows them to find the right environment and test it. I don't think facebook would be done in two weeks, but it's not going to require rewriting the whole application and six years either.

They're not doomed.

For the record, the application I ported stores every math paper on the planet in it and it's distributed across mirrors all over the world. It's not a tiny application.

Re:Commercial databases

[ThePhilips]

They should had gone with Oracle database to begin with [...]

You probably never paid license fees for the Oracle.

While working in start-up, I had pleasure of seeing the decision making in progress: so we buy Oracle license for the server. Or we receive wages next three months. What should we pick?

Facebook might have not existed today (good riddance) if they had decided to use commercial DB back then.

Re:Commercial databases

[ralphdaugherty]

$5k is a lot of money for a student who is hacking something together in their university dorm.

That was the next step up. You missed the free version statement before it.

I am not an Oracle user, I'm a DB2 user, but I happened to read the post.

Re:Commercial databases

[qwijibo]

The join worked better in MySQL, taking 2s, compared with 10ms with PostgreSQL. I went with the join because I could also create a view, but was again dismayed that the 2s view took 14 minutes to run when I added "where hostname like 'foo%'" to the query on the view. The moral of the story seems to be that you can make things work with MySQL, as long as you're willing to spend the time figuring out how to do it their way and not trying to use any abstraction like views to keep the structure obvious. I've seen significant improvements with performance tuning in PostgreSQL and Oracle, but never had such simple queries take so long on relatively small data sets out of the box.

Re:Commercial databases

[MichaelSmith]

I pity the kid born on that day.

Re:Commercial databases

[Phantom of the Opera]

This is exactly why anyone in their right minds puts some sort of ORM/query layer in front of their database so that their mid-tier/front-end code has no knowledge of what the sql looks like.

You make it sound like SQL code is some sort of medusa that turns middleware and front end programmers to stone if they glance at it.

Re:Commercial databases

[SuperQ]

Yup, I love the "why not buy enterprise hardware" comments. Based on 250 Billion page views per month, we're talking about 100k views per second. I'd like to see a zSeries box keep up with just one of the tables needed to handle this traffic level.

And that's based on monthly average, I bet their daytime peak is 10x that.

Re:Commercial databases

[Phantom of the Opera]

Enter the conundrum of code sucking beyond all belief that still makes lots and lots of money. There's awe inspiring code of beauty out there that will never make a dime. Which is better and which would you rather own?

Re:Commercial databases

[Phantom of the Opera]

I just had to be the oddball programmer. Sigh

perl -e 'print "M" == "P" ? "yes" : "no"'

That's okey. At least it isn't VB where

if val( TRUE ) = val( FALSE )

Re:Commercial databases

[evilviper]

There is something significantly different, right between MySQL and Oracle. Postgres is widely recognized as scaling far better than MySQL, the documentation is great, and it's even more free, being both $0 and BSD-licensed.

I'd hate to have the job of scaling-up MySQL, but I wouldn't mind doing so with Postgres... In fact I usually prefer Postgres over Oracle, even where initial purchase cost isn't a concern.

Re:Commercial databases

[Verteiron]

All right. I'm a moron. Why is it bad to use an auto-incrementing row as the PK as long as it's never exposed to the end user?

(Please note I am not a DB guy, I just use MySQL as a backend for some simple PHP projects)

Re:Commercial databases

[Anonymous Coward]

There's no way that Facebook can be "rapidly ported", and I don't think that the problem here is a matter of the "mysql_" prefix.
It's not just one server, not even a single cluster. You simply cannot replace something that is unbelievably massive and always up and running just to see if another product does the task better. Rewriting the whole codebase is probably required to restructure the data to overcome current issues, and Mysql may not have the tools needed by Facebook at this stage. (Just guessing)

Re:Commercial databases

[Anonymous Coward]

Over the last 11 years, I have gone looking for comparisons between MySQL and PostgreSQL 3 times - in each case PostgreSQL came out ahead in terms of performance and reliability, but I did not consider the use of master/slave database scenarios nor of using lots of shards.

However, PostgreSQL 9.0 has support for master/slave scenarios as well as hot standbys.

I would suggest that MySpace start testing a pilot with PostgreSQL 9.1 beta, with the idea of implementing with PostgreSQL 9.2 (or later). It will take a long time to fully evaluate and decide on how to implement their system with another DBMS, so they might as well start testing with a yet to be released version of PostgreSQL. So as to benefit from the additional maturity of key enterprise features, and to ensure any show stoppers can be can be dealt with in PostgreSQL in a timely manner before they do a production install.

By testing a subset of the MySpace 'application' - it will provide valuable fodder for improving the PostgreSQL optimiser (which is already very good, but a DBMS optimiser can always be improved!!!) in ways that will not only benefit MySpace, but others users of PostgreSQL as well .

If they donate a reasonable amount of money to the PostgreSQL developers, then they will get a lot more benefit, than paying a many times bigger amount to Oracle for licences - not to mention the cost of Oracle consultants!.

While PostgreSQL has a zero licence cost, offering to cover some of the real development costs is likely to generate a lot of good will, not to mention allow more people to spend more time on PostgreSQL development.

Re:Commercial databases

[Nivag064]

Hmm...

I use Fedora, I still prefer to use PostgreSQL to MySQL. I have yet to find anything easier to do in MySQL than PostgreSQL.

People keep saying MySQL is easier than PostgreSQL, but I have yet to see an example.

Re:Commercial databases

[gfody]

I'm sorry but the use of auto-incrementing columns as primary keys is considered very good practice these days for anything beyond first normal form. Of course they can be abused/misused and wreak all sorts of havoc but that's no reason to make blanket statements. It reminds me of the greybeards that vehemently reject NULL/3VL as anything but nonsense and refuse to use nullable columns even when the situation calls for it.

Re:Commercial databases

[Nivag064]

Hmm...

Parent is mine, I had not realized I wasn't logged in!

I read the PostgreSQL Forums, so I'm aware of the shortcomings of PostgreSQL and some of what is being worked on, but I'm also aware of its benefits.

Hence, I would always advise businesses to do a pilot before committing to change from one RBDMS to another, unless there are compelling reasons not too.

Re:Commercial databases

[fferreres]

Did you have the right indexes? You can even create combined indexes. I have used MySQL extensively from 2000 to 2003, and had thousands of complicated queries that asked in realtime. Having one single column index wrong could cause massive delays. The website had thousands of visits per hour (not much, but we ran it from a modest 1U server with one core), and was very DB intensive, so whenever something wasn't perfectly indexed (sometimes including combined indexes), the server would crawl as each query took longer and therefore queries would pile up and would have so many simultaneous queries killed the CPU, RAM and IO. After diagnosing a lot, and trying some different index strategies, a query that took 60s could take >0.01s. Also, the way to join things so as to minimize table size affected performance in a big way. I am not saying Postgre isn't faster here, only saying that it was very fun to learn how much fun it was to understand exactly what was happening and how to write the indexes depending on the kind of answers that we needed. Then again, just saying that maybe you didn't have as much fun as I had with that.

Re:Commercial databases

[Anonymous Coward]

Oh please. FB are not doing anything the big boys consider even remotely challenging. I have seen military installations processing over a million transactions a second analyzing input from war simulations and revising strategies in real-time powered by a supercomputer built by IBM that occupies about 900sqft.

FB make it hard on themselves by insisting on unstructured/schema-free and open source. Those are the initiatives set by FB because they want to contribute to open source because it's cool. Don't delude yourself into thinking they're actually breaking new ground in any area of modern computing.

Re:Commercial databases

[cloudmaster]

I replied to a comment which indicated that a database-driven site probably doesn't have much DB-dependent code, and which suggested solving underwhelming database performance by adding an additional compatibility layer. Somehow, I presumed that the bar for humor wasn't set all that high.

Re:Commercial databases

[WaffleMonster]

In a debate about how Facebook - one of the most successful, largest, and fastest growing web sites in history - one built around a core of massively shared data - one which has achieved amassing fast (for it's size) almost real time data updates and amazing levels of reliability (for it's size and speed of growth), by using MySQL, you are actually trying to argue that MySQL can't work for anything but "toy" sites? Really? Do you not see the total absurdity of your point? Facebook is, itself, the proof that your point is invalid.

Facebook might be a large popular site however not everyone has the luxury of managing large volumes of worthless data.

The use of facebook as an example greatly limits the applicability of the analogy to other domains.

Re:Commercial databases

[Surt]

Nah, it's just that they shouldn't be specialists in understanding the peculiarities of different DBs. If they were, they'd be DBAs. You (literally) can't be an expert in everything. There's too much to learn in a human lifetime.

Re:Commercial databases

[Surt]

That's right. By allowing your specialists to specialize, you do improve performance.

Re:Commercial databases

[Anonymous Coward]

It's not just another greybeard stuck in the past. he probably refuses to use nulls as well

Re:Commercial databases

[WaffleMonster]

All right. I'm a moron. Why is it bad to use an auto-incrementing row as the PK as long as it's never exposed to the end user?

The main reason against using them as PK only is that in a distributed environment with replicated data it can be hard to maintain consistancy across all systems with these types of primary keys.

Database A write row 101
Database B writes row 101

Ooops...

Nowadays systems have built in methods to coordinate global reservations of sequences so it is less of a problem. It could still easily break down if there is a need to consider multiple disconnected datasets.

Personally I always use sequences for PKs when I know I can get away with it.

Re:Commercial databases

[qwijibo]

I created new databases and tables to have a fair comparison for performance testing. There were no indexes at all used for testing. That wasn't meant to be a robust test of the capabilities, but more of a validation of what was happening and why. I agree that with the right architecture and strategy it's entirely possible to make MySQL perform well, I was just surprised to see such a dramatic performance difference in some relatively simple queries. It's always going to be necessary to do some work on performance tuning to get the best results, I was just surprised with how much earlier in the process that's required under MySQL.

I keep coming back to trying MySQL and finding it disappointing, usually related to work. I've been using PostgreSQL since 1997 and it's always worked well for me. The most interesting comparison isn't between MySQL/PostgreSQL, since that is a religious war with a lot more people on the MySQL side. The best comparison is how easy/difficult it is to migrate from one DB to another. Migrating from PostgreSQL to Oracle has been very simple when I've done it. Everything just basically works the same out of the box. If it's common to need to do so much MySQL-specific performance tuning, I would see converting to/from it to be a much more difficult project.

I really wonder how much time and effort goes into large MySQL databases and how much is related to how it works. Basically, from a practical standpoint, is that money being spent on people's time costing more than Oracle licenses would? I'm not even a big Oracle fan, but I have developed data warehouses on Oracle and I can't argue with using a tool that works. At the end of the day, finding the right solution to the problem is what counts. It would just be interesting to see cases (other than small, simple databases) where MySQL really shines. A lot of people really like MySQL and use it for some pretty large and business critical applications. I would like to think there's more than ignorance of other databases that drive those decisions. =)

Re:Commercial databases

[tgv]

The bar for sarcasm is considerably lower when Oracle is involved.

Re:Commercial databases

[Anonymous Coward]

Lots and lots of this.

Re:Commercial databases

[fferreres]

This is probably true. At least from what I read, I tend to see people that know databases very well like Postgre more than MySQL. Those that are very entepreneur or practical (and likely know DBs ewll but not as a core skill) are very happy with MySQL. I too would like to a research piece on large scale "scenarios", and try out the different solutions through a competition with sensible rules (like a standard hardware platform, etc).

Re:Commercial databases

[dave420]

I don't think he does make it sound like that. Using an ORM means that you essentially have a common API for interacting with databases of any variety. Change the database, and you get to keep the vaaaast majority of your code, if not all of it.

Re:Commercial databases

[Anonymous Coward]

If you read the article they are not saying MySql needs to be replaced with another SQL Database like Oracle, MS SQL, or DB2. According to the article they are just as bad if not worse than MySql. In fact they would be worse as they cost so much more but will not scale any better for these types of applications. Of course there are other types of applications that Oracle, Ms SQL, and DB2 might work better for than MySql, but I am not personal aware of any and my guess if you have someone that really knows MySql set it up it would be shown that MySQL is still just as efficient if not better than any of the paid versions. The point really should be that once you get to the scale of Facebook, Google, etc... any SQL based database will not be able to handle the load. However, most companies will never reach that level so MySql is all they will ever need.

If they get to a point where they are at Facebook or Google's traffic level they will have the nice problem of having the money to be able to redesign the app, but lets face it they would be completely different apps. Also, they would most likely never make it to this level if they spent the time and money to try and scale to this level from the start. No one goes out on day 1 of their business and buys a million square foot warehouse just in case one day they might need it. Nor do they setup their warehouse processes in a way that would flow better in the 1 million square foot building. They design their business for what they need at the time with allowance for some future growth. A MySql based web application is all that 99% of the businesses in the world will ever need. It is only the top 1% of web applications that may need something different.

The good news is because there are companies like Facebook and Google there are becoming more and more options for databases that are not based on old technology (SQL) that have the ability to scale a little more than a SQL based DBs like Oracle, MS SQL, DB2 or MySQL. However, I think it is way too early for most companies to use anything but a SQL based database. Given that you will be able to easily find resources , templates, and knowledge bases for SQL based databases there is no reason to use some new experimental technology when there are proven options available that meet your current and future needs.

MySQL is FREE and can handle the needs for 99% of the web applications on the internet today just ask Facebook and Google. My guess is that it is only when you start getting 25% plus of all the daily internet users going to your website that a SQL based database is going to be an issue for your application. Just because Oracle, MS SQL, and DB2 cost more does not make them any better. In my opinion MySql if properly configured can run any web based application as efficiently and scale for much less than any of the paid versions of SQL.

Re:Commercial databases

[kimvette]

Do you have aspergers' syndrome or some other form of mild autism? "Rapidly" is not an absolute term; it is a relative term. In this case, "Rapidly" would mean "far more quickly than if presentation and logic are mixed into a spaghetti dish"

I know, I fed the troll. Shame on me!

Re:Commercial databases

[innerweb]

writing a second version of their customer's code for SQL Server, cleaning up the original version for Oracle, and having both be 100x faster

That is correct way to implement. I keep my display logic, my business logic and my data logic separate. None of the code that needs the data has any clue where the data is coming from or how it was retrieved. All of that logic stays in a segregated block of code for data management for each method needed. If I need to tweak or modify one, I only have to bugger with that one. Rarely, I have to bugger with more than one when a major change in data comes up. That is more time consuming this way, but very rare, but for day to day (overall time), it is far cheaper to keep them separate. When I need to add a data source, it is as simple as making the new data source interface and providing it as an option. All of the data scrubbing is already there (except some that need special data encapsulation - like CSV), all I need is to create new code for retrieving and storing. If I need to move an app from a MSSQL to MySQL or Oracle or something else, All I have to do is go through the data logic. Once that is done, the process is done.

The problem I see more often than not (esp working with manufacturing) is the fragmentation of different data sources (true in education, research and general business as well). I have to deal with everything from Excel, Access, MSSql, text, DIF, specialized data feeds, ... you name it. Some of the apps I have had the *pleasure* of working with are pulling from more than 3 sources. No choices, no consolidation allowed. Different customers/suppliers have made different decisions as to how they are going to store and share their data. So, the application I am working on has to be fluent in whatever it needs to be in.

This ends up looking like this:
Program needs data A from clients 1,3 and 8.
Client 1 uses a pseudo api that I have to call.
Client 3 has a live person to request from via email who will reply with a spreadsheet that has to then be parsed.
Client 8 has a website we can query directlly against.

The application at large needs to remain completely isolated from that kludge. I simply have an object (module) for each data source, then each client has a module for how to retrieve the data from its own data source. The scary part is that I see 300 to 600 thousand line spreadsheets broken into multiple sheets that need to be treated as a single table. lmao! Excel is the normal database for most people in small to medium size companies, not anything else.

Re:Commercial databases

[HappyPsycho]

If "big boy" hardware is the answer then why does google not have a similar issue. They built their setup pretty much the same say and it works. Google doesn't use Oracle, postgre, etc. heck last I checked their entire map / reduce setup relies on a in house solution. Why? because nothing they tried scaled to what they do. Facebook is in pretty much the same boat.

In case u haven't noticed throwing hardware at the problem only works when your load is low and even then it tends to be a temporary solution.

Re:Commercial databases

[HappyPsycho]

Would more locks and referential integrity help performance or hinder it?

Re:Commercial databases

[HappyPsycho]

I'll leave 1 and 2 for the sibling poster, I have nothing to add to those 2 points.

3. What do you use to ensure unique keys? It is a feature, if you app doesn't need it then don't use it. Does not mean it isn't useful to others. The few apps I see controlling unique keys themselves tend to keep them in a separate table which eventually becomes the bottleneck once allot of inserts start happening (pretty much any sort of logging).

4. MySQL unlike just about any other database engine actually allows you to chose the best tool for the job. Last I checked database admins are pretty smart people so picking the appropriate tool seems like a no brainer to me. The default is meant for someone who doesn't know better aka n00b / beginner at which point a simple table will be better than a complex one which may scare / confuse.

Re:Commercial databases

[fuzzytv]

It does not matter if they used PDO or mysql_ calls directly - that could be fixed with a search'n'replace. The real problem is the SQL that's executed - to rewrite that you need to understand what it does etc. And if you're going to switch to a different database, you're doing it to use unique features it provides, which often means you need to rewrite parts of the SQL.

Re:Commercial databases

[fuzzytv]

I prefer databases that support FK, but I don't see why a RDBMS has to support FKs.

Re:Commercial databases

[KingMotley]

Not sure what "VSYNC" is, I'm guessing that you just remembered it wrong, or made it up. Perhaps you are thinking of optimistic and pessimistic locking currency?

As for a data adapter, that's what you would use to convert an in memory table representation (or subset of) (AKA disconnected dataset) like in a dataset to generate the necessary data statements to do mass update/insert/deletes to physical table in the database. One of the best features of a dataset is it's ability to do batch updates, which only does a real physical commit every n-th record. As the real commits are what are most expensive, you can easily do updates that take 1/n-th the amount of time as generating a n updates. This works well if you expect that the vast majority of updates will have no conflicts, but performance suffers if you have a large number of conflicts and you need to rollback the batch, and then figure out how to handle the partially committed dataset,

Re:Commercial databases

[KingMotley]

Well except for the whole GUI part of access, and stored procedures.

Re:Commercial databases

[KingMotley]

I do believe that most DBS (SQL Server, Oracle, DB2) would optimize that out back into a standard query anyhow, even if you wrote it that way or MySQL.

Re:Commercial databases

[KingMotley]

Unfortunately, auto-incrementing keys are very bad for performance in quite a few scenarios. Every insert requires a table-wide lock (No concurrent inserts). In many cases it also causes problems with replicated tables (many master), or partitioned tables. Better would be uuid/guid for these scenarios.

Re:Commercial databases

[KingMotley]

Facebook is, itself, the proof that your point is invalid.

While I find you post mostly insightful, the one problem with your argument is that you make the assumption that facebook is not a toy.

Re:Commercial databases

[Anonymous Coward]

...especially if they were sane and used an abstraction layer like PDO.

Fail.

DB abstraction layers invariably create more problems than they purport to solve.

Re:Commercial databases

[ppanon]

The C in ACID stands for Consistency.

Re:Commercial databases

[Anonymous Coward]

MySQL accepts most everything you throw at it

Did it ever occur to you that this might be a bad idea, Sherlock?

Re:Commercial databases

[JamesP]

How about trying to run initdb after a reinstall and it gives 'FAILED' without explanation?

How about config files outside of etc?

How about properly configuring it to use MD5 passwords?

Re:Commercial databases

[fuzzytv]

The ACID does not imply that the database has to support foreign keys. A RDBMS may be ACID compliant and not to support referential integrity. It just says that if it does, it must enforce it properly. I'm not saying I like RDBMS that lack FKs. I was just a bit afraid you believe "relational = allows to create relations between tables (FK)" - I've heard that nonsense too often.

Re:Commercial databases

[GooberToo]

A rarity these days on slashdot. You did, in fact, parse my statement correctly.

Re:Commercial databases

[Phantom of the Opera]

That is a decision that pits performance vs ease of use vs likelyhood you'll up and change your databases. It depends on the space you are working in.

If your target is low to moderate traffic, simplicity and abstraction is certainly the way to go.
If your target is very high traffic, you'll need something tighter.

I'm not for or against a particular technique but I am against 'Once Size Fits All'.

(yes, I was exaggerating what the parent had said, I admit it)

Re:Commercial databases

[Nivag064]

If you have any problems with (or concerns about) PostgreSQL, then I suggest that you either file a bug report or post to the appropriate PostgreSQL forum or mailing list. You can see all the mailing lists for PostgreSQL at http://archives.postgresql.org/ and anyone can post to them. The PostgreSQL developers appreciate feedback and thoughtful suggestions.

I have run various versions of PostgreSQL on both 32 & 64 bit machines, for over 10 years - and never had strange problems running ininitdb that were not PEBKAC (a fancy term for user error!). Strange things happen to the best of software. Did you raise a bug report? was it reproducible? I once had a weird problem with another software package - that after much investigation, was put down to a transient RAM failure.

There are other software packages that do not store their config files under /etc, such as moodle and ultimatestunts.

Note that the rpm for Fedora does use /etc for the postgresql.conf. However, for evaluation purposes, I have run several different versions of postgreSQL installed concurrently, which I downloaded and compiled myself - so it not automatically on insisting on storing its config file under /etc is good thing.

I have had no problems with configuring it to use MD5 passwords - once I read the documentation properly, but then it was quite simply to do so. What were your problems?

You have not mentioned anything really significant. Whereas, there are plenty of gotchas setting up and running MySQL - like choosing the right engine, and the numerous 'quirks' in its SQL. Both MySQL and PostgreSQL require modifications to their configuration files for proper production running.

I read the mailing lists for PostgreSQL on a daily basis, so I am aware of problems with it. However, in my experience, all major software packages have problems, including the Oracle RDBMS. I am sure that if I read the MySQL forums or mailing lists that I would find further problems with that RDBMS as well. Note that several big corporations have, or are in the process of, migrating for an Oracle RDBMS to PostgreSQL - you can be assured that they did due diligence first.

Over the last 30 years I have used at least 6 different RDBMS, not counting different versions of each under a variety of different Operating Systems, and I much prefer PostgreSQL. I know that whatever one's preferred RDBMS, one can always find at least one feature that is better on some other RDBMS (for an example, there is one aspect of using variables in stored procedures that is superior in Sybase transactSQL than in PostgreSQL pgSQL). I am quite happy to accept that in some situations, that MySQL is better than PostgreSQL.

The key is to use the most appropriate database technology for the business case, allowing for current and likely future needs.

Re:Commercial databases

[Nivag064]

Hmm...

I find pgsql very easy to use, but I use it in conjunction with other tools. For SQL queries I use gedit to create and edit an SQL script which I then execute in psql. I have used GUI applications to create and run SQL, but I find pgsql much more practical in conjunction with a good editer that is SQL aware.

I make full use of the advantages of Linux to apply a range of tools to my development process, so I don't expect one tool to fulfil all my development needs. Though Eclipse, with additional plugins, comes close for Java development (although, when I teach Java, I get students to use an editer rather than a full blown IDE like Eclipse when they start off).

For really complicated SQL tasks, I use several SQL scripts. Note that you can cause execution of several other SQL scripts from a master SQL script, breaking down SQL into logically coherent files makes understanding and maintenance easier. Perhaps I should never admit to having written a single stored procedure in Sybase TansactSQL of over 3000 lines of code in a single file (in a Microsoft environment, shudder)! :-)

Re:Commercial databases

[Nivag064]

An unfair comment you made, but you were funny!

To be honest I don't like Facebook either, especially their cavalier attitude to their users' privacy and their attempts to lock up their users' data - compare these aspects with the Google+ approach. I have also seen too many security issues relating to Facebook use data.

Re:Commercial databases

[Nivag064]

Java is a great language for building serious Enterprise applications, and has a really ferocious JIT that compiles frequently used Java byte code into native machine instructions.

How many software frameworks are there, that can make effective use of a Terrabyte of memory and multiple cores, other than Java? See: http://blogs.oracle.com/java/entry/java_7_celebration_begins
[...]
A representative from the Royal Bank of Scotland explained that RBS relies on the JVM, a TB (Terrabyte!) of in-memory data 24 x 7, and is looking forward to Java 7 improvements.
[...]

I have written software in over 15 different languages in a variety of operating systems, and I prefer Java to all the others. Though I wish I could write Java without the curly brackets and semicolons 1ike python - but Python does not scale, nor does it handle multi threading very well, nor has much of the functionality, library support, and performance aspects, that Java has.

You can always find another language that has features that are superior to Java, but you cannot find another language that is overall superior to Java for serious software.

Though I admit I am not keen on the Oracle connection!

Re:Commercial databases

[JamesP]

Great answer, thanks

Note that all the problems I mentioned are specific issues I found with Fedora 14

There you have config files in var

Being outside of etc is not a showstopper, but strange to say the least.

The issue with MD5 passwords is that in Ubuntu, for example, you have "the magical line":
local all postgres ident

Whereas in F14 (no line present) if you try to change it, to use MD5, for local connections, you can't (because you'll set a 'ident' password, switch to md5 and it stops working) So either you set it for tcp only or you configure it like Ubuntu (took me a while to figure this). Anyway it makes you set the config file one way, do something then change it again.

Anyway, I've found PGSQL more difficult overall than MYSQL for most admin operations (and no, I have very little experience with both, maybe it's the docs, but pgsql seems to be 'more picky' especially with the sql syntax (where you have to use quotes or double quotes accordingly), but I have to say that Pgadmin ROCKS

For example, select * from table where field=blah works with single quotes and double quoeta in MySQL but only with single quotes in PostgreSQL (Also, I don't get dt instead of show tables)

And yes, I've been bitten by MySQL table types as well.

The way I see it, PostgreSQL is a great SQL Database. If you need SQL features, if you'll use every nook and cranny of the SQL spec go for it. If you're a bank for example.

MySQL is a great 'thing that stores data' that presents a basic SQL interface. But it's ok, I'm not writing SQL by hand, I'm using an ORM. I don't need all the security features, the ORM supports only one user. The ORM optimizes the queries. It's not going to be very fast, but that's ok. And in this case it's better to move the 'intelligence' outside of the DB.

Re:Commercial databases

[Nivag064]

Great answer, thanks

Note that all the problems I mentioned are specific issues I found with Fedora 14

I am using Fedora 14, as well!

There you have config files in var

Being outside of etc is not a showstopper, but strange to say the least.

You're right! I had forgotten that I had manually moved the configuration file to /etc, with a symbolic link in the original data directory!

The issue with MD5 passwords is that in Ubuntu, for example, you have "the magical line": local all postgres ident

Whereas in F14 (no line present) if you try to change it, to use MD5, for local connections, you can't (because you'll set a 'ident' password, switch to md5 and it stops working) So either you set it for tcp only or you configure it like Ubuntu (took me a while to figure this). Anyway it makes you set the config file one way, do something then change it again.

I have done stuff in Ubuntu with MySQL with SQL, but only used PostgreSQL on Red Hat and Fedora.

If you find similar problems in Fedora, raise it with the Postgres folk, else with the Ubuntu crowd.

Anyway, I've found PGSQL more difficult overall than MYSQL for most admin operations (and no, I have very little experience with both, maybe it's the docs, but pgsql seems to be 'more picky' especially with the sql syntax (where you have to use quotes or double quotes accordingly),

As a general rule, I prefer software frameworks to be strict (or 'picky' in your terminology) as this tends to lead to fewer surprises with unintended consequences - such unexpected ambiguities where a developer interprets something one way and the software interprets it another way, you may usually get the same results except in some special corner cases (that knowing Sod's Law, will only turn up once you get into production!).

but I have to say that Pgadmin ROCKS

For example, select * from table where field=blah works with single quotes and double quoeta in MySQL but only with single quotes in PostgreSQL (Also, I don't get dt instead of show tables)

And yes, I've been bitten by MySQL table types as well.

The way I see it, PostgreSQL is a great SQL Database. If you need SQL features, if you'll use every nook and cranny of the SQL spec go for it. If you're a bank for example.

I have been developing with databases for about 30 years, and PostgreSQL for about 10, but I probably know less than 1% of what PostgreSQL can do. Reading the PostgreSQL mailing lists is a great way to erase any pretensions of expertise about PostgreSQL!!! :-)

I think it is worth while using PostgreSQL even for simple or 'toy' projects, as it leads to better habits and a greater understanding of what is involved in serious database work. And as PostgreSQL is reasonably standards compliant, the knowledge can carry over to Oracle and other databases. Not to mention that a 'toy' project might one day grow up and be quite substantial - and during a period of rapid growth there will be no time to change your RDBMS!

PostgreSQL gives far more options, so that it might be best to use it from the beginning to save being painted into a corner - a little extra pain at the beginning to avoid major pain later!

MySQL is a great 'thing that stores data' that presents a basic SQL interface. But it's ok, I'm not writing SQL by hand, I'm using an ORM. I don't need all the security features, the ORM supports only one user. The ORM optimizes the queries. It's not going to be very fast, but that's ok. And in this case it's better to move the 'intelligence' outside of the DB.

From an application developer's viewpoint I agree with you 100%, as a DBA I disagree 100%! As a software architect, I would first look at the business case and the volume and other performance requirements - before deciding which ways I would jump, both aproaches may be valid to some extent.

Re:Commercial databases

[Nivag064]

Just noticed I got a bit confused when responding to your md5 comments!

Re:Commercial databases

[ppanon]

Hm, point. It's been a while since I was dealing with this stuff. I almost did make that mistake and, having worked with PostgreSQL, where metadata frequently refers to tables as relations, I should know better. Nevertheless, it can be pretty hard to put data into normalized forms that are more space-efficient and more easily kept consistent like 3rd or 4th Normal forms if you don't have FKs and RI. So, sure, you can have an RDBMs that doesn't support foreign keys and referential integrity, but you're probably going to run into efficiency or consistency issues unless you're dealing with relatively simple or disjointed data models.

I probably should have said: it's a pretty poor RDBMS if it doesn't support RI. That admits it's still an RDBMS, albeit a relatively poor one. In general conversation, that statement would probably be considered close to, if not interchangeable with my original statement. However I appreciate your request for the semantic correction.

Re:Commercial databases

[tgv]

The topic was of course relational databases.

With respect to frameworks: I've found that Objective-C(++) scales pretty well, and is very, very friendly in terms of multithreading. But I agree that Java has an edge in ease of deployment. And I quite like the braces and semicolons...

Anyway, Java is not Oracle's product, just as MySQL really isn't. These were conceived and grown elsewhere, just to end up in the portfolio of a company that took 8 versions just to improve SQL*Plus a bit...

Re:Commercial databases

[Nivag064]

The topic was of course relational databases.

Well, to bring it back on topic briefly: Java is one of over 10 languages that stored procedures can be written in for PostgreSQL - but I have only ever used pgsql PostgreSQL stored procedures.

With respect to frameworks: I've found that Objective-C(++) scales pretty well, and is very, very friendly in terms of multithreading.

I once got offered a six month contract in C++ - on the basis of a little C++ experience at university as part of a course in Object Oriented databases (having gone back to University and just completed a post grad diploma in computer science) and having read 'The Book' by the creator of C++ - mind you, I had many years prior development experience in several other languages. However, I chose to get into Java.

I have heard of Objective-C, but never seen it, I have seen it mentioned at in the release notes for a version of gcc. Is this a purely Mac thing?

But I agree that Java has an edge in ease of deployment. And I quite like the braces and semicolons...

In the best traditions of slashdot, I should focus on off-topic trivia and deride you vehemently for liking "braces and semicolons", because that differs from my preferences and therefore obviously makes you inferior - but I can't be bothered! :-)

Anyway, Java is not Oracle's product, just as MySQL really isn't. These were conceived and grown elsewhere, just to end up in the portfolio of a company that took 8 versions just to improve SQL*Plus a bit...

I started programming in Java just after Java 1.1 came out. I was learning it in my own time and giving seminars to interested colleagues after hours. I remember struggling with the understanding of the Java I/O classes, and the next day presenting a seminar on it as though I was an expert...

Re:Commercial databases

[tgv]

Java can also be used in Oracle (the db), but PL/SQL works better. It still is very messy though. At this moment, I prefer to do the data massaging in Java and keep the sprocs to a very bare skeleton. A bit of aggregation ok. But where I work now, complex reporting stuff is done in PL/SQL and that is not a nice sight.

I've got about 20 years experience in C++. I installed the first preprocessor on a Sun workstation (there's that Oracle connection again) if memory serves, and it didn't work well. Stroustrup certainly made a mess out of it, multiple inheritance and all. And then he scorned the most elegant thing in the language, templates.

Objective-C is mainly a mac thing, but it does compile on other platforms. It's a pretty interesting language. And rather efficient. However, there is nothing comparable to Tomcat/JBoss/... or Active Mqueue or any of that stuff that makes Java so versatile. On the other hand, perhaps there is, but it might be expensive. Objective-C totally rules for GUI development though.

And I mock you for your love of Python! A language where your editor's tab settings can change the meaning!! A language without semicolons!!! Everyone know that the only language without semicolons was (visual) basic and that is a bad thing. By association, Python must be bad.

Java 1.1 I/O... there's something to be improved. Or Calendar, my goodness. Thank The Force for JodaTime.

Re:Commercial databases

[fuzzytv]

100% true

Re:Commercial databases

[Nivag064]

Java can also be used in Oracle (the db), but PL/SQL works better. It still is very messy though. At this moment, I prefer to do the data massaging in Java and keep the sprocs to a very bare skeleton. A bit of aggregation ok. But where I work now, complex reporting stuff is done in PL/SQL and that is not a nice sight.

I think that the disadvantages of Java outweigh its many advantages, when used in stored procedures - not that I ever used Java for such, so I could be wrong...

I once wrote a stored procedure in Sybase TransactSQL of over 3000 lines, using 7 temporary tables that accessed at least 15 tables from 2 databases for a reporting program. I would have preferred to do the bulk of the logic id Java, but it was not practical - partly because of political reasons.

I've got about 20 years experience in C++. I installed the first preprocessor on a Sun workstation (there's that Oracle connection again) if memory serves, and it didn't work well. Stroustrup certainly made a mess out of it, multiple inheritance and all. And then he scorned the most elegant thing in the language, templates.

Objective-C is mainly a mac thing, but it does compile on other platforms. It's a pretty interesting language. And rather efficient. However, there is nothing comparable to Tomcat/JBoss/... or Active Mqueue or any of that stuff that makes Java so versatile. On the other hand, perhaps there is, but it might be expensive. Objective-C totally rules for GUI development though.

Oh! Another ancient one, but I bet I am more ancient than you!!! :-)

I probably have the dubious distinction of developing the last commercial paper tape application in New Zealand in the late 70's. Some bright spark noticed Teletypes produced paper tape and realized computers could read it... Do you know that an 8 track paper tape reader can read 5 track paper tape 4 different ways? The program was in COBOL for the business logic with a module I wrote in assembly language to interface with the paper tape reader - it ran on an ICL 4/72 mainframe with a massive 1MB of memory and a fast 2MHz processor (you try telling that to the younger generation, they won't believe you...). Fun and games getting a computer program to process data typed in by humans. It was about inputting details of inward collect phone calls from Australia to New Zealand.

And I mock you for your love of Python! A language where your editor's tab settings can change the meaning!! A language without semicolons!!! Everyone know that the only language without semicolons was (visual) basic and that is a bad thing. By association, Python must be bad.

Java 1.1 I/O... there's something to be improved. Or Calendar, my goodness. Thank The Force for JodaTime.

Such ignorant comments I would expect from a mere Oracle lackey! I fart in your general direction (The Python documentation says that references to Monty Pythin, are not only permitted, but encouraged!)!

//////

I think I have far exceeded my 6 monthly quota for writing comments to Slashdot, for this one article! Now I really need to concentrate on pretending to work...

Re:Commercial databases

[Nivag064]

[...]And I mock you for your love of Python! A language where your editor's tab settings can change the meaning!! A language without semicolons!!! Everyone know that the only language without semicolons was (visual) basic and that is a bad thing. By association, Python must be bad.[...]

Visual Basic is the only language that I have written a program in and never succeeded in getting a program to run (with, or without, errors)!

While Python is a very poor relative of Java, it is orders of magnitude nicer than Visual Basic - IMnsHO.

Re:Commercial databases

[ZosX]

Mod up please. Postgres is great and certainly better for a lot of enterprise applications than mysql. Scaling being one of the concerns here.

Re:Commercial databases

[Zontar The Mindless]

The default engine does not even support transactions.

Wrong.

The default storage engine in 5.5.5 and later is InnoDB, which handles both transactions and foreign keys very nicely.

Thanks for playing, though.

Still their fault

[nurb432]

Once they started the trend to grow beyond being a toy, they should have redone things right then.

Waiting until you are painted in a corner is irresponsible.

Re:Still their fault

[jjetson]

Who said they're "painted in a corner"?

Re:Still their fault

[Anonymous Coward]

There are only two reasons why any person or organization would use MySQL:

1) They are ignorant of real database systems.
2) They have an existing code base that has trapped them into using MySQL.

I imagine that the first reason does not apply to Facebook.

Re:Still their fault

[Haedrian]

3) They're not made of money.

Doesn't apply to Facebook either, but would apply to startups in general.

Re:Still their fault

[jank1887]

but thought the entire web was supposed to run off the almighty LAMP stack? you just can't make a neat acronym with Oracle in there.

Re:Still their fault

[Tridus]

PostgreSQL can be had at a similar price point to MySQL only is better at pretty much everything else.

Re:Still their fault

[Anonymous Coward]

That's covered by 1).

If they weren't ignorant, and money was an issue, then they would just use PostgreSQL or Firebird.

Re:Still their fault

[ppanon]

Well you could try to use Oracle Apps and tools on MySQL but that would be LAMO.

Re:Still their fault

[jjetson]

They've made it this far with it. And "painted in a corner" would suggest there is no way out. Which is ridiculous considering what they're worth. The OP was trying to be wise I assume, but instead came off arrogant and narrow minded.

Re:Still their fault

[larry bagina]

There are only two reasons why any person or organization would use MySQL:

1) They are ignorant of real database systems. 2) They have an existing code base that has trapped them into using MySQL.

I imagine that the first reason does not apply to Facebook.

3) you stole the website from somebody using mysql

Re:Still their fault

[jonbryce]

When Mark Zukerberg was a student doing Facebook in his spare time while studying at uni and writing websites for firewood merchants at $1000 a time to pay the bills, he certainly wasn't made of money.

Re:Still their fault

[jonbryce]

SAJO - Solaris Apache Java Oracle?

Re:Still their fault

[Inthewire]

Sure you can. ALPO. And then make bad jokes about eating our own dog food.

Re:Still their fault

[Anonymous Coward]

well if you wanted to piss Jobs off, you could call it an APOL stack

Re:Still their fault

[Tablizer]

Once they started the trend to grow beyond being a toy, they should have redone things right then.

Waiting until you are painted in a corner is irresponsible.

To be fair, Facebook may be the next Myspace and disappear into oblivion any month now. Long-term planning is sometimes overkill in the short-term world of web companies. There's already rumor that Twitter is eating Facebook's lunch.

Re:Still their fault

[jedidiah]

A basic copy of Oracle really doesn't cost that much money really. Compared to other small business expenses, it's not that terrible. Being a cheap bast*rd and underfunded isn't really a very good excuse. It's even easy to get completely for free if you are just futzing around in your free time.

Re:Still their fault

[superwiz]

...or responsible

Re:Still their fault

[Reality Master 101]

I don't feel like rehashing this YET AGAIN, but I will only say that I've used both, and in my experience the snobbery against MySQL is misplaced and is based on knowledge a decade out of date. We moved our database platform from PostgreSQL to MySQL a few years ago for various technical reasons and it has worked out well. Like I said, I don't feel like rehashing this yet again, my only point is that PostgreSQL and MySQL are roughly comparable, and each has advantages over the other (in MySQL's case, some significant advantages).

(and I refuse to be dragged into this yet again! :) But I felt like I had to throw in something.)

Re:Still their fault

[Anonymous Coward]

Yes, shame they didn't listen to you several years ago. No point building a mega billion dollar site that still works despite the alarmist headlines. No no no, far better to skip that and listen to pricks online that believe they know best. WAAAANNKERRR!

Re:Still their fault

[syockit]

There's OPAL, i.e. Oracle+PHP+Apache on Linux.

Re:Still their fault

[NNKK]

3) They don't buy in to the ridiculous self-serving rhetoric of overpriced "DBAs" who think they're something more than an IT monkey.

Re:Still their fault

[Anonymous Coward]

Irresponsibly rich, perhaps.

Re:Still their fault

[Anonymous Coward]

Once they started the trend to grow beyond being a toy

I'm not convinced that has happened yet - I think people made the mistake of initially thinking it was more than a toy, but that bubble is starting to burst

Re:Still their fault

[HappyPsycho]

How old is Postgre's Replication & Clustering support? These aren't nice to have for businesses like Facebook, they are must haves. They must work and work extremely well.

You are thinking a bit too small if you think the problems facebook are facing are the everyday run of the mill issues. Postgre is better at keeping a smaller set of data in order better but at certain levels the overhead is too much.

Re:Still their fault

[HappyPsycho]

Care to point us n00bs to a example? Last I checked I couldn't find a price, and as they say "if you have to ask..."

Isn't MySQL an Relational Database Management Sys?

[Anonymous Coward]

I was under the impression that there was no feasible way, performance wise, to run something as big as Facebook without using a non-relational database system.

Am I mistaken?

Or in other words...

[Anonymous Coward]

Database vendor says someone elses database is rubbish and they'd be much better to use theirs.
This isn't news.

Repeated meme?

[Anonymous Coward]

Why do I feel like I read this a couple days ago?

Obligatory Clue

[Dachannien]

Professor Plum: What are you afraid of, a fate worse than death?
Mrs. Peacock: No, just death, isn't that enough?

Re:Obligatory Clue

[Anonymous Coward]

Blackadder: So, it's a fate worse than a fate worse than death. That's pretty bad.

"Fate Worse Than Death" says man selling...

[Anonymous Coward]

...a product called NewSQL.

Even his product name is an indication that SQL is not the evil it is professed to be.

You know For Mysql That is great

[Anonymous Coward]

I don't really understand what is bad about this. Facebook is this big of a site and it seems to work great. Good Job mysql. But most information sites like this run some kind of database back end. I don't know what he would really goto after this. Oracle perhaps? Maybe something from IBM. Forgive me I'm not a programmer so I wouldn't know what would be the best backend for a site like this. But anytime you start out using something. You can get stuck int he world of software.

TTFN,

Jake_Paws
IdahoFur

Re:You know For Mysql That is great

[Loconut1389]

Exactly- the fact that pretty much one of the largest sites in the world is running mysql should tell you something good about mysql.

Re:You know For Mysql That is great

[Surt]

I don't really understand what is bad about this. Facebook is this big of a site and it seems to work great.

Have you actually seen facebook?

Re:You know For Mysql That is great

[h4rr4r]

Not it does not. Lots of people smoke, use windows, and do all kinds of other stupid things. This again only proves lots of people like to do stupid things.

Re:You know For Mysql That is great

[abarrow]

I agree with the parent. When you have a user base that makes you the third largest country in the world, what, exactly, is the problem? Are there new features they are trying to add, reliability issues, or what?

I thought about going cheap for my startup

[Billly Gates]

When you have several billion from investors, you can rewrite your stuff later.

FYI I plan to use PostgresSQL and perhaps a little noSQL in the mix to reduce the need to use joins for multiple tables (where SQL really hurts when doing ACID). I am just not a DBA person nor do I have the experience to learn how to do relational math with a no-SQL database.

Anyway PHP is another problem for such a large scale site. Wasn't Facebook the one who had to rewrite php in C++? I plan to switch to Java or C#.NET later on when I have money, Facebook has the cash to do this. The only downside is it will take hundreds of thousands if not millions of lines of code in either platform and rushing programmers is bad and creates the same problem of bad design in the first place. Are there any frameworks or CMS that only require a few months instead of years to setup that can handle the needs of a company like facebook? I could only imagine it would take years to write a few million lines of code in Java that is well written and tested and this is not an option for Facebook.

Re:I thought about going cheap for my startup

[cyber-vandal]

Are there any frameworks or CMS that only require a few months instead of years

No but there will be plenty of vendors promising such a thing.

Re:I thought about going cheap for my startup

[16K Ram Pack]

The 2 key words about a startup are "fail cheap". Spend as little as you can to deliver the business functionality that you need on day 1. Because if the customers don't come, you haven't lost much. If they do come, you'll have plenty of money to rewrite it, or be able to get the funding for it.

Personally, I'm doing a startup in .net because I know .net, and can code faster in it. So, that's a smaller cost. The main downside is hosting charges, but even that has a tiny per-transaction cost difference.

Re:I thought about going cheap for my startup

[horza]

Probably the simplest solution is to use PHP and MySQL. As Facebook shows, it can scale up to hundreds of millions of users. There is no shortage of developers and they come as default on most hosting solution. If you outgrow PHP/MySQL then you will already be in a position to proposition investors.

Phillip.

Re:I thought about going cheap for my startup

[h4rr4r]

Which has nothing to do with this topic, since postgres is just as free as mysql and is an actual DB.

Re:I thought about going cheap for my startup

[Billly Gates]

Well 16k Ram Pack has a point. Yes Visual Studio is not cheap, but it would take him much longer to start in Php and therefore it would eat up the cost savings rather quickly. Businesses sometimes pay more for non free software because they have a time/money cost analysis functions at play from the bean counters.

The downside of course is after you need your own dedicated servers you are looking at some serious licensing fees. I had a friend who was part of a failed startup that did financial services for clients and banks on their startup. MS charged them $100,000 for an unlimited licensing free for SQL Server, Windows 2003 Server, IIS, and Visual Studio 2005. In the end they couldn't afford the licensing fee and pay all 4 of the developers and they went out of business.

So if you are going to use the big boys you need to make sure you each transaction brings in a good revenue each with the higher cost. If your site is like a news site ...ala slashdot or digg ... then a free mysql or casandra would be better as it has the least transaction cost.

To me by the time I am making 400k a year in transactions then I can dump the free ones and I wont care which platform as I will pay someone else to write it and focus on just business at that point.

If you are a one man show never doubt the productivity gains you can make with tools you know. It is his work or his idea is done.

Re:I thought about going cheap for my startup

[Bert64]

And far less well known, people use what they're comfortable with, even when it's a poor tool for the job.

Subject line should read...

[arglebargle_xiv]

... "Michael 'Ingres' 'Postgres' 'VoltDB' Stonebraker says 'MySQL doesn't scale'".

Re:Subject line should read...

[Anonymous Coward]

Well, not beyond 500 million users apparently.

Nah, this is standard practice

[Colin Smith]

Delegate scalability downwards. Throw hardware at the problem.

Re:Nah, this is standard practice

[Z00L00K]

It may not be a hardware problem, it may be a problem that actually has more to do with the fact that Oracle owns MySQL.

Re:Nah, this is standard practice

[Anonymous Coward]

Delegate scalability downwards. Throw hardware at the problem.

If that's your real approach, you're doomed. Scalability is always a combination of choosing the right architecture in the first place, and hardware. It sounds like Facebook made the wrong architecture choices, and is now simply "throwing hardware at it". (And now they're doomed).

Re:Isn't MySQL an Relational Database Management S

[Anonymous Coward]

Google would love to disagree with you.

Abstraction layer

[fysdt]

They would probably need to build an abstraction layer on top of MySQL. Something like "FBSQL" :) . This would create the ability to move to whatever database system they want.

Re:Abstraction layer

[Anonymous Coward]

They've had quite a few design changes in the last few years, well since they became popular. I do not see how the hell they could hire developers and start coding without some sort of db abstraction layer. I find this story fishy

Re:Abstraction layer

[sphealey]

> They would probably need to build an abstraction layer on top of MySQL.
> Something like "FBSQL" :) . This would create the ability to move to
> whatever database system they want.

And get equal performance on all of them. Equally poor, that is.

sPh

Re:Abstraction layer

[MightyMartian]

So do I. Zuckerberg may be the posterboy for Aspergers assholeishness, but he doesn't strike me as a two-bit fly-by-night LAMP hack. I'm sure early iterations were not optimized, but to imagine that Facebook is this far a long serving this many requests and is nothing more than a glorified hacked together quickie LAMP app.

Re:Abstraction layer

[ralphdaugherty]

They would probably need to build an abstraction layer on top of MySQL. Something like "FBSQL" :) . This would create the ability to move to whatever database system they want.

The other way around. IBM wrote a DB engine plugin for MySQL that is an interface for DB2 on the iseries AS/400. So we can run PHP apps on the iseries written for MySQL against our enterprise database.

Migration is the cure !!!

[Anonymous Coward]

Oracle databade should definitely work fine !!!

The O in NOSQL stands for "only"

[tepples]

"NOSQL" doesn't mean "don't use SQL at all"; it means "not only Structured Query Language". It's possible to store some data in a relational database and other data in a non-relational database. It's also possible to store the authoritative copy of data in a relational database and various frequently used cached views in a non-relational manner.

PHP too

[Bogtha]

The ex-Facebook developers who founded Quora think Facebook is stuck on [PHP] for legacy reasons, not because it's the best choice right now .

Re:PHP too

[Needlzor]

Except they "solved" that problem already by developing a PHP -> C++ compiler (http://en.wikipedia.org/wiki/HipHop_for_PHP).

Re:PHP too

[Anonymous Coward]

Except that only improves performance, it doesn't fix all the mindblowingly bad "design" decisions in the language.

MySQL: Hosting nightmare

[Anonymous Coward]

I'm a sysadmin at a large hosting provider, and we see this every day. MySQL replication is a nightmare -- if it's not done perfectly, it will break. (And it will probably break anyway) And then there's the "skip n errors on the slave and restart replication" move we do, usually knowing deep down that we'll have to rebuild the whole slave again anyway.

But MySQL is also one of the biggest causes of site slowdowns and downtime. If for example a site is being cached heavily by Varnish or Nginx, the database will rarely be queried and everything works great. But introduce a header into the code that breaks or stops caching, and peak times of the day will have regular pile-ups of MySQL queries hundreds or thousands of queries deep. Then you have to restart the daemon, and you start risking data loss when you're doing this everyday.

Really, Wordpress and Drupal are the most common offenders. The sequences of database queries they come up with are downright astoundingly bad sometimes. Literally searching millions upon millions of rows of data only to find one row in the end.

This behavior is not sustainable, from a systems perspective, or even from an environmental perspective.

Re:MySQL: Hosting nightmare

[Anonymous Coward]

Shitty code is shitty code. WTF does your war story have to do with mysql?

Re:MySQL: Hosting nightmare

[Anonymous Coward]

Shitty code is shitty code. WTF does your war story have to do with mysql?

Well it's like the facebook situation, the performance just is not there with MySQL when you are scaling a large dynamic web-site up. Sure, shitty code is shitty code, but even good code will crumble under the right load. MySQL is just not well designed if your purpose is a redundant cluster - replication is difficult or downright impossible to maintain under a lot of conditions. I haven't used NoSQL, so I can't contrast, but MySQL is not well suited to these kinds of applications.

Re:MySQL: Hosting nightmare

[Billly Gates]

Well if you guys stopped forcing Mysql as the only RDBMS on your ISP we would use PostgreSQL instead.

Re:Isn't MySQL an Relational Database Management S

[jjohnson]

Not mistaken, but the issue the NoSQL people face when trying to replicate something like a Facebook-sized cluster of relational databases is that they have to build the ACID features back in, which tends to negate the performance advantage.

Facebook isn't really using a relational database system either: they have a gigantic memcached layer on top of a gigantic MySQL layer. They have, effectively, a massive in-memory database that's continually being written back to MySQL for permanence. That's the only way they could get sufficient read performance.

It's a myth

[Anonymous Coward]

It's a complete fallacy that oracle or SQL server has any advantage over mysql or postgres. Having implemented both Oracle and mysql in large scale environments its not any easier dealing with Oracle. It's a beast to scale and many oracle consultants will simply recommend large multi-CPU systems instead of going to a parallel server mess....or whatever they're calling it these days.

Facebook would be in hell no matter what db they chose. It's more about poor design choices early on than the database software.

Re:It's a myth

[edxwelch]

The article isn't saying Oracle is better, in fact it's saying that all SQL type databases are outdated and unsuitable for large web apps

Re:It's a myth

[Anonymous Coward]

It's a complete fallacy that oracle or SQL server has any advantage over mysql or postgres.

Not everyones problems are scalability. The impression I've always had of mysql is it's a database always in search of "being a real database". I looked at it a few years ago, and was surprised it only recently got stored procedures. Postgres is significantly better of course, and competes on about the same level as Oracle and SQL Server.

Re:It's a myth

[Lehk228]

so the article is saying that the backbone for every single large application web applicaiton of any consequence, is unsuitable for large applications.

riiiiiight

Umm Cassandra?

[Anonymous Coward]

Facebook uses Cassandra for a lot of their storage requirements... I am sure that they use MySQL for some things too, but they have an amazing team of people who come up with stuff like Cassandra, thrift, and scribe. My guess is they will manage well enough.

"We're so new"

[michaelmalak]

I love the snippets "After all, he explained, SQL was created decades ago before the web, mobile devices and sensors forever changed how and how often databases are accessed" from the article and "We’ve been using stonge age technology to solve problems that didn’t exist 30 years ago." Yes, the problems existed 30 years ago, such as (land-line) telephone billing. I don't know how those problems were solved -- probably with a mainframe and a custom non-SQL database and not a PC running a SQL-based server -- but they were solved.

Re:"We're so new"

[Anonymous Coward]

I love the snippets "After all, he explained, SQL was created decades ago before the web, mobile devices and sensors forever changed how and how often databases are accessed" from the article and "We’ve been using stonge age technology to solve problems that didn’t exist 30 years ago." Yes, the problems existed 30 years ago, such as (land-line) telephone billing. I don't know how those problems were solved -- probably with a mainframe and a custom non-SQL database and not a PC running a SQL-based server -- but they were solved.

It's called Erlang people.

Re:"We're so new"

[aliquis]

> "We're so new"
> "We’ve been using stonge age technology to solve problems"

Maybe he's talking about doing serious projects with MySQL?

Me? Trolling? Nah..

Re:"We're so new"

[excelsior_gr]

Probably using C, COBOL or (less probably) FORTRAN...

Re:"We're so new"

[Anonymous Coward]

I don't think that the problems were solved. There is an entire industry devoted to auditing phone bills and they almost all work for a portion of the savings. So I would say that there are still many problems with telephone billing.

Re:"We're so new"

[Splab]

Yes, but those solving them did it by using well understood algorithms. The problem with MySQL is the developers chose to look at the best practice, what other people did and said: "meh".

MySQL is not a database suited for anything with critical information.

Re:"We're so new"

[Nivag064]

FORTRAN is extensively used on supercomputers and is still in active development (each new version of gcc has tons of new features for FORTRAN, not just enhancements to C, and C++ etc. see http://gcc.gnu.org/gcc-4.7/changes.html).

So don't knock FORTRAN!

Re:"We're so new"

[excelsior_gr]

I meant nothing against Fortran. I am a Fortran programmer myself. It is just that although Fortran supports direct access files, it has no intrinsic subroutines/functions for database management and back then (Fortran 77) did not support multidimensional arrays of mixed data types (character strings together with reals and integers and so on...). That is why although Fortran might have been an option back then, I find it more probable that the database programmers of that era would have used some other language (either C or Cobol) instead. Not necessarily because they were better (in my opinion, they weren't), but also because Cobol was more popular with businesses back then.

Re:"We're so new"

[Nivag064]

To be honest, (until today!) I last used FORTRAN when it was version IV, in the early 70's! I have even seen FORTRAN II code.

I just went looking on Google for 'FORTRAN database' etc. - next to nothing turned up.

In my searching, I came across a comment that FORTRAN compiles into smaller, and far more efficient code, for extensive number crunching - than C++. I suspect that Java (with its vicious optimising JIT) might do better, as it can optimise based on the run time execution profile - in terms of speed.

I suspect that in supercomputing, they use massive in memory data structures, and rely on flat files to store data - maybe they can store memory data structures on disk?

Just compiled my first FORTRAN program for over 30 years, using gfortran under Linux! If I have to pick another language to learn, for fun rather than commercial gain, I would pick a dialect of Lisp rather than FORTRAN.

Re:"We're so new"

[excelsior_gr]

I don't know about Lisp, but Fortran is one of my favorites!

I suggest you focus on Fortran 95, maybe with some features of Fortran 2003. Thus, the book by Chapman (Fortran 95/2003 for scientists and engineers) would be the one to recommend. You can also check out the comp.lang.fortran group. I also use the gfortran compiler, but the g95 compiler is also pretty good (although it looks like it's abandonware nowadays). A few years ago gfortran was not able to compile a lot of features, but I gave it a spin a few weeks ago and it seems that they are up to speed again.

I am not surprised that Fortran+database return no results. Someone that programs databases would not use Fortran, and someone that uses Fortran would never program a database, if you get my drift... :-)

Happy programming!

EPic!

[M0j0_j0j0]

You got to love problems of companys that go large on epic proportions!

And this opinion has nothing to do with the fact .

[AftanGustur]

And this opinion has nothing to do with the fact that this is the guy who write PostgreSQL and he has been bitching about how MySQL has a to big market share, for years??

MySQL has been faster that PostgreSQL for years, it doesn't have as many features, but it is **fast** !!

Oh dear

[Dunbal]

What, you want to make 100 billion dollars through an IPO and you moan because you might actually have to WORK?

Re:Oh dear

[Anonymous Coward]

Jealous much, faggot cunt?

Re:Oh dear

[tqk]

Jealous much, faggot cunt?

Do you have no idea how silly that makes you look? Think anatomically, assuming you're at least capable of some thought. Twit.

Trolls: The Town Drunks of the Internet

Oracle...Kool-Aid...I'm a moron

[Anonymous Coward]

You people who think Oracle would be any better are hilarious. If they'd gone with Oracle, they'd be in even worse shape. Read the article. He's saying SQL is terrible at Facebook-scale, period.

Re:Oracle...Kool-Aid...I'm a moron

[Anonymous Coward]

They scale through DDR you idiot. What do you think there's behind Hotmail and the whole Windows Live infrastructure? MySQL or any other NoSQL crap du-jour? Get real moron!

"Good problems to have"

[Anonymous Coward]

When starting your company, these are the problems you wish you have one day. As the saying goes, "Those are good problems to have".

Common amongst one-in-a-millions = NOT COMMON

[Anonymous Coward]

"all too common among web startups that start small and grow to epic proportions."

Dear editors: please review the definition of the word "common". This statement is like saying, "confusion is common among people who get hit by a meteorite while pouring hot grits on a naked and petrified Natalie Portman". 99.9% of web startups don't have to worry about this, they need to worry about running out of money...

Re:Common amongst one-in-a-millions = NOT COMMON

[Anonymous Coward]

Dear AC,

You need to work on your reading comprehension on this one. The statement says this problem is common among an uncommon subset of all startups. The statement never said this was a common problem among all startups. Please think what you say through before complaining next time.

Much love,
Another AC

Re:Common amongst one-in-a-millions = NOT COMMON

[ppanon]

On the other hand, if it really is that common among startups that grow to epic proportions, then it means that startups that use other methods run into so many problems trying to "do it right" off the bat that they overspend early and never get to grow to an "epic" point.

Contractors will get rich doing the rewrite

[mikein08]

Could it be that facebook will have vanished before any rewrite is ever done?

Re:Contractors will get rich doing the rewrite

[Lennie]

Its probably better to give all investors and employees their money and kill the whole Facebook project. No one likes their privacy policies anyway.

Re:Contractors will get rich doing the rewrite

[insertwackynamehere]

Your bitterness is astounding

Re:Contractors will get rich doing the rewrite

[Lennie]

Why would I be ?

I do however have no idea why people use it.

But other people obviously found a use for it.

Maybe I just don't see it as I'm in Europe. I know it's really, really big in the US.

Re:Contractors will get rich doing the rewrite

[insertwackynamehere]

I dunno why man. You are like "well Facebook oughta just pay back the investors and close down, they are taking a nosedive. Good game everyone"

Anyone with even a pinky finger on the pulse of current business and technology knows that Facebook is doing well. Your comment about being in Europe is just because you assume I am a dumb American who will buy that excuse. I don't know if Facebook is as big in Europe as America, but I do know that Facebook is viewed as a world wide phenomenon by this point and you have to be pretty out of touch to not know that it is doing well, especially in this industry (I assume since you post here you are tangentially related to the industry).

So in short your comment was equivalent to someone posting "who's Taylor Swift" after clicking on an article mentioning her name. You probably know who she is but wanted to sound cooler than that or you legitimately don't know but instead of using Google you act like it is someone else's job to tell you. It's like saying "I don't own a TV" when people are discussing breakfast.

The bitterness is because I can only assume you said anything, especially anything so glib and dismissive and so blatantly contrary to reality (you: Facebook is a failure, reality: Facebook is just going up) because you are bitter that something you dislike is a billion dollar idea.

Different view point

[Anonymous Coward]

Reading through the interview my reaction was: "If MySQL scales well enough it can handle Facebook's load then it can handle just about anything." Really, Facebook is one of the highest traffic sites on the web, saying they use MySQL is a huge endorsement.

Re:Different view point

[geckipede]

People have made pedal powered helicopters, aircraft that run on AA batteries, wooden frame towerblocks... They all worked, but weren't exactly an endorsement of the techniques.

Peanut Gallery

[Anonymous Coward]

Raise your hand if you have a website the size of facebook? It's surprising it's lasted this long is supposedly on a limping system. I don't see what Oracle or other larger database could offer facebook at this point. I'm sure they are already doing replication, transactions, stored procedures, object caching. What more is there? Secondly who are you to even begin to criticizer, there are only a few people on this planet with sites as big as there, so just shut your trap and watch.

Re:Peanut Gallery

[Anonymous Coward]

I don't know what fb is doing, but I can give you a little prespective from the high volume systems I've helped migrate.

It's the difference between a data center full of expensive single servers and a row of high performance SAN + clustered servers running an enterprise grade RDBMS (which can replicate reliabily and quickly). There are many advantages to this, but above everything else (it seems) is cost. Put simply you have as much horsepower and more features in a smaller footprint and you need less people to run them.

At fb's scale, while MySQL is free I imagine they need gobs of hardware. I don't know if they use the commodity hardware model that Google uses, but if they do there is probably hundreds of millions of dollars to be saved by having less data centers, servers, etc.

Of couse, for all I know they're already doing this...

Successful Troll is Successful

[tyler_larson]

Academic purist discovers that one of the most prolific and successful database users in the world is using a system he doesn't approve of. He decides, with no insider knowledge at all, and despite all evidence to the contrary, that they should throw everything away and start over from scratch using a system that he thinks would allow them to see the performance and scalability that they've already achieved.

Presumably he's tired of Facebook being used as a counter-example to everything he's been preaching.

Re:Successful Troll is Successful

[fermion]

And note that two stories down it is reported that SAP is once again over budget and over schedule on a major implementation. So I suppose that now everyone will stop using SAP as it unreliable.

Re:Successful Troll is Successful

[rgmoore]

No, he's not an academic purist; he's a businessman who's selling a product that competes with MySQL. So he's trying to convince web startups to pay a bunch of money for his product rather than rely on free MySQL because he claims it will help them scale better than Facebook. IOW, businessman trashes competitor's product, claims you should buy from him instead. Nothing to see here.

Re:Successful Troll is Successful

[sco08y]

Academic purist discovers that one of the most prolific and successful database users in the world is using a system he doesn't approve of. He decides, with no insider knowledge at all, and despite all evidence to the contrary, that they should throw everything away and start over from scratch using a system that he thinks would allow them to see the performance and scalability that they've already achieved.

Presumably he's tired of Facebook being used as a counter-example to everything he's been preaching.

He's no academic purist. He's pushing his product, and he's either an outright liar or, worse, doesn't know what he's talking about:

Stonebraker said the problem with MySQL and other SQL databases is that they consume too many resources for overhead tasks (e.g., maintaining ACID compliance and handling multithreading)

Is that so? MySQL, as with virtually all SQL DBMSs, defaults to "repeatable read" transactional guarantees, and it doesn't even spend time guaranteeing foreign key relationships by default. About the only thing MySQL really guarantees out of the box is durability.

It's just nonsense to talk about all the "wasted resources" when, if they don't need them, it's a few lines in a config file to turn them off.

Re:Successful Troll is Successful

[AnEducatedNegro]

and replace it with what...

Re:Successful Troll is Successful

[Needlzor]

MySQL is not free ; and considering his curriculum, I'd put more trust in Stonebraker's advice than in any of Facebook's "engineers".

Re:Successful Troll is Successful

[repetty]

And note that two stories down it is reported that SAP is once again over budget and over schedule on a major implementation. So I suppose that now everyone will stop using SAP as it unreliable.

One can only hope.

Re:Successful Troll is Successful

[midom]

Don't trust Facebook's "engineers".

Re:Successful Troll is Successful

[marcosdumay]

No SAP is very reliable. Before contracting them you'd expect your project to be budgeted a lot of time and money, and for it to actualy costs several times the initial budget. And, after you contract them, they never fail that prediction. They are that reliable.

Why people do busines with them, for me it's a mistery. But you can't go calling them unreliable.

Re:Successful Troll is Successful

[JAlexoi]

Sorry, but VoltDB is as "free" as MySQL. The VoltDB is GPLv3 and MySQL is GPLv2.

Re:Successful Troll is Successful

[tqk]

... SAP is very reliable. Before contracting them you'd expect your project to be budgeted a lot of time and money, and for it to actualy costs several times the initial budget. And, after you contract them, they never fail that prediction. They are that reliable.

I was thinking the same thing based on my experience. They must have damned near the most effective marketing machine the world has ever known (well, next to the Vatican). If they farmed out that expertise, they'd make a killing.

Re:Successful Troll is Successful

[Anonymous Coward]

Hear Hear!!

Re:Successful Troll is Successful

[Anonymous Coward]

lol, nice

or he has his own dbm program to sell.

Re:Successful Troll is Successful

[marcosdumay]

They are making a killing right now. They are killing several business everywhere.

Re:Successful Troll is Successful

[Anonymous Coward]

I am fairly sure MySQL at FB is run on InnoDB not MyISAM. That does have better ACID (and FK) support

Re:Successful Troll is Successful

[fuzzytv]

You're mixing MyISAM and InnoDB storage engines. REPEATABLE READ is the default level for InnoDB, but most RDBMS default to READ COMMITED isolation level (e.g. Oracle, PostgreSQL). With MyISAM this does not make much sense, it's similar to READ UNCOMMITED. And it's not true MySQL does not enforce foreign keys - you've mentioned REPEATABLE READ so you've been talking about InnoDB, and that engine does enforce foreign keys.

Re:Successful Troll is Successful

[sco08y]

Yeah, mea culpa, didn't want to spend *that* much time reading over the MySQL docs, but you missed my qualifying it as "by default" a few times. You're right about Oracle et al using read committed, brainfart there, but the larger point was that only "serializable" is truly guaranteeing consistency, and you specifically have to turn that on.

Re:Successful Troll is Successful

[fuzzytv]

SERIALIZABLE is not truly guaranteeing anything. A common misunderstanding is that SERIALIZABLE is equal to running the transactions in a serial fashion. That is not true! Those levels are defined using phenomena (dirty reads, non-repeatable reads and phantom reads) or rather lack of those phenomena. But that does not mean there are no other problems - the ANSI just decided those three and defined the isolation levels. There are other phenomena / dependencies that make the transactions 'not serializable'.

See this excellent post on this topic http://iggyfernandez.wordpress.com/2010/09/20/dba-101-what-does-serializable-really-mean/

The only DB (I'm aware of), implementing true SSI (Serializable Snapshot Isolation) is the upcoming PostgreSQL 9.1. See this http://wiki.postgresql.org/wiki/SSI

Re:Successful Troll is Successful

[sco08y]

God damn it! I don't come to slashdot to learn things! But just this once...

PostGreSQL is far better than MySQL

[darthium]

MySQL is 'fast' because its lack of feature and robustness mainly. Implying maketshare means qualit.is like implying that current crappy pop music is better than Classica Music because of the marketshare they get.

Re:PostGreSQL is far better than MySQL

[laffer1]

How ten years ago of you. You do realize that MySQL and Postgres are getting rather close on feature parity right? Both of them have been adding features the other lacked. MySQL 5.5 has stored procedures, views, triggers, etc.

The biggest selling point with Postgres for me is the schema handling/support. One database can have many schemas.

It's fine if you like postgres, but saying that technologically advanced in every way is wrong. There are benefits to both systems.

Regarding the marketshare comments, I'm not so sure I buy that. Postgres is a good alternative to MySQL because it's the other commonly used database in the FOSS world. Many apps work with both databases. If you have an Ingres database, you'd beg for Postgres. The marketshare of Ingres is a joke. Few apps work with it. So quality is not determined by marketshare, but usefulness might be.

Re:PostGreSQL is far better than MySQL

[sourcerror]

Maybe geature wise they're on par, however the MySQL syntax for nested queries is incredibly weird.

Re:PostGreSQL is far better than MySQL

[segedunum]

How ten years ago of you. You do realize that MySQL and Postgres are getting rather close on feature parity right? Both of them have been adding features the other lacked. MySQL 5.5 has stored procedures, views, triggers, etc.

Not sure which way to take that to be honest. Postgres has got faster without sacrificing useful and sometimes essential features while MySQL has had to scramble to catch up. It's an ass backwards way of going about things and it's one of the reasons why there are so many problems with it. Facebook, Google and God knows who else has goodness knows how many forks of MySQL now. That's the complaint being levelled by the article.

Re:PostGreSQL is far better than MySQL

[repetty]

MySQL is 'fast' because its lack of feature and robustness mainly.

I've read the same thing about C.

Re:PostGreSQL is far better than MySQL

[Anonymous Coward]

well, define better ...

Re:PostGreSQL is far better than MySQL

[fuzzytv]

And how does that contradict the fact that MySQL gains some speed advantage due to lack of some features? Yes, the situation improved recently - the InnoDB fixed some of the MyISAM problems (altough the system catalogs are still MyISAM).

Re:PostGreSQL is far better than MySQL

[DragonWriter]

How ten years ago of you. You do realize that MySQL and Postgres are getting rather close on feature parity right?

No, they aren't.

Both of them have been adding features the other lacked.

Maybe true, but PostgreSQL has also been adding features that neither PostgreSQL nor MySQL had before, and keeping its lead.

The biggest selling point with Postgres for me is the schema handling/support.

The rule system and support for more-advanced standard SQL features like Common Table Expressions is a big one for me. The richer type system is a plus, too. And there's a slew of new stuff well along in the pipeline (like Range Types).

Easy - Just Migrate to Oracle

[littlewink]

That should do the trick, eh?

Oops, time to buy Oracle stock and short FaceBook, I guess!

Keep on backpedalling, you silly NoSQLers.

[Anonymous Coward]

It's hilarious how the NoSQL fools are now constantly backpedalling these days.

It turns out that writing database queries in JavaScript is a stupid idea! Imagine that! All of their attempts to invent a better query language end up being almost identical to, guess what, SQL!

Then they realize that trying to maintain data consistency using logic written in JavaScript, Ruby or PHP doesn't work so well. Values go unconstrained, and the referential integrity gets fucked up. Soon the data is nearly worthless.

The smarter/less-ignorant ones then think that they'll just use transactions. But wait, their NoSQL database of choice doesn't support that, or doesn't support it properly. So they tell themselves that their data will become "eventually consistent", or worse, they try to implement some shitty ass "transaction" support using Ruby. Regardless of the path chosen, failure is the result.

Now they're realizing that it's mandatory to use a real relational database when working on anything remotely serious. So we see this bullshit about "no" now meaning "not only". That's funny, last month it meant "no", as in, "we will never write a SQL query again, and we will never use a relational database again."

I'm going to make a prediction: Next month, we'll get to read articles and comments from them about these amazing new database systems that they've just discovered. These new systems avoid all of the problems associated with NoSQL databases! What are their names? Oracle, DB/2, SQL Server, PostgreSQL and SQLite.

Re:Keep on backpedalling, you silly NoSQLers.

[Surt]

Trollishly stated, but oh so true.

Re:Keep on backpedalling, you silly NoSQLers.

[Joe U]

Meh,

If NOSQL really means Not Only SQL, then it's a smart idea.

If it means re-writing relational database code to behave like SQL, then you should have been using SQL in the first place.

If it means that your live object database that doesn't follow normal relationships has a much more efficient system, then you should not have been using SQL in the first place.

Simply, use the right tool for the job.

[I prefer a well defined stored procedure interface to my data, the slight amount of extra design time makes up for the fact that I not only reduce round trips to the DB server, I can scale it out easily without code changes on the web server. ]

Re:And this opinion has nothing to do with the fac

[Lennie]

Actually, if I understand it correctly he worked on Postgres, not PostgreSQL which came later.

so mysql works

[Anonymous Coward]

This article shows that mysql can somehow handle possibly one of the largest databases in the world. Who would expect it to be easy? Hard to maintain, painful to manage but after all it works. What is the other option that would work from a small web site scale to facebook scale.
Some retards, including the ones I know in person, will read this article and start saying that mysql has poor performance.

Re:And this opinion has nothing to do with the fac

[Anonymous Coward]

Pentium was *fast* too, just a bit wrong sometimes :-)

looks like facebook is doing just fine...

[tommeke100]

If anything, it's a success story for MySQL.

Re:looks like facebook is doing just fine...

[cshark]

Damn right it is.

The most interesting piece of information in this article is the fact that there's nothing in it other than the vague assertion that its a "fate worse than death" that's actually specific to Facebook.

If I didn't know better, I would say it almost sounds like he's being a media troll, and trying to hock his relatively obscure product by mentioning one of the biggest data consumers in the world, and his most successful direct competitor. It's a good thing I know better though, because if I didn't, I would have to say it's a gutless business marketing move, along the lines of old school Microsoft tactics, that is wholly lacking in integrity.

See, if you have to stoop to mentioning the perceived weaknesses of a major competitor without provocation or reason, that only means that your product has no merit to stand on. And we all know what a fine upstanding database system VoltDB is.

Or do we?

Re:looks like facebook is doing just fine...

[Dilaudid]

I accept your point that it is impressive that such a mountain of suck runs so effectively on MySQL. However it is still a mountain of suck. Or to put it another way, I don't think computers were invented so some mini bill gates can try to cajole me into "poking" my friends for the purposes of selling advertising.

Re:looks like facebook is doing just fine...

[Doc Ruby]

You're right. Computers were invented to steer bombs to people and kill them. Through WWII and the 1960s missiles that brought us the IC and beyond.

As mountainous as advertising suck is, bomb suck is worse. I like where computers have gone from their purely murderous beginnings.

Re:looks like facebook is doing just fine...

[Rich0]

Fate worse than death indeed.

If my biggest problem in life were having to spend a few million dollars out of my billion-dollar bank account to help me make a few billion more, than I think I'd sleep pretty well.

Which is the smarter choice if you're starting a new company:

1. Spend an extra $100k now before you collect a dime.
2. Save the money now, but once your company is worth $100B you'll have to spend $5M.

The chances of #2 ever happening are probably one in a million at best, so that $5M should be viewed as spending a risk-adjusted $5 years from now rather than a certain $100k today. Gee, that's a hard decision...

Delusional editorialism!

[GooberToo]

Not that it's necessarily Facebook's fault

Absolute bullshit. So now people are no longer responsible for the decisions they made? Of course they are.

It has been long known MySQL is a low end, non-compliant (slightly better over the years) solution, which teaches poor SQL, poor solutions, and even worse design, generally aimed at people who don't know any better. When MySQL launched, PostgreSQL was always an option. Furthermore, Oracle even had solutions for them to grow into. Now, both solutions look dramatically better than MySQL ever has. Furthermore, commercial support and even very high end HA/clustering PostgreSQL solutions are available. There exists no valid reason to make the same dumb mistake hundreds repeatedly make every day.

So hurray for MySQL. They saved 45-minutes during their installation on day one and now they'll spend a year or two plus millions of dollars to move away from their extremely dumb and uneducated decision. That's got to be one of the most expensive 45-minutes on earth - and yet its one of the single biggest decisions which MySQL users defend on a daily basis.

Sorry, but reality has spoken. Is it Facebook's fault? Absolutely!!!! Anyone who says otherwise has lost any and all credibility and only enforces they should never be in a position to be picking a database solution in the first place.

Re:Delusional editorialism!

[rasherbuyer]

Mod parent up!

I couldn't have put it better myself...

Re:Delusional editorialism!

[kimvette]

So hurray for MySQL. They saved 45-minutes during their installation on day one and now they'll spend a year or two plus millions of dollars to move away from their extremely dumb and uneducated decision. That's got to be one of the most expensive 45-minutes on earth - and yet its one of the single biggest decisions which MySQL users defend on a daily basis.

IMHO it was a bargain - MySQL has worked up until now, it is still working, so as far as I am concerned that's a big success story for such a low-end free/free database - and it was a choice they made based on what they already had skills in and it enabled them to earn billions, so it was a very smart, inexpensive way for them to get started. Now for Facebook, spending a few million to get on to big iron is cheap money, whereas back in the day spending a week or two to really learn the ins and outs of Postgres or spending thousands on Oracle could have prevented them from surviving in the first place.

Re:Delusional editorialism!

[Anonymous Coward]

> It has been long known MySQL is a low end, non-compliant (slightly better over the years) solution

That low-end solution is successfully handling the needs of one of the largest websites that's ever existed, which kinda proves it's nowhere near as low-end as you'd like to believe.

Re:Delusional editorialism!

[Needlzor]

My thought exactly - wish I could mod you up.

Re:Delusional editorialism!

[cshark]

Right. And the troll in the original article couldn't even point out anything facebook specific. Not even so much as "I have a friend who knows somebody who works there, and he said...."

No, all he could say was Facebook, and "worse than death" and basically say that it's worse than death because it's sharded, and since he's not competetent enough to understand that, then it must be bad.

Whatever. If MySQL is doing the job, and Facebook isn't losing database admins in droves (which they're not), then there's nothing wrong with their cluster. Period.

It's complete horseshit.
I have zero respect for VoltDB. Zero.

Re:Delusional editorialism!

[Anonymous Coward]

You mean that collage student sitting his dorm room? The one needing to put his little site together on some sort of budget? You're a tool.

Re:Delusional editorialism!

[swillden]

So hurray for MySQL. They saved 45-minutes during their installation on day one and now they'll spend a year or two plus millions of dollars to move away from their extremely dumb and uneducated decision. That's got to be one of the most expensive 45-minutes on earth - and yet its one of the single biggest decisions which MySQL users defend on a daily basis.

You're assuming that this random blogger has a clue, and that FB really is having problems due to their choice of MySQL. We have no evidence to support that.

Re:Delusional editorialism!

[Anonymous Coward]

Look, maybe you read something different than I did. But this guy doesn't work for Facebook, or have any inside track to know anything other than publicly available facts about its DB structure.

That plus I can't say Facebook isn't exactly falling down all over itself despite millions of concurrent users. That means this guy has no idea what he's talking about, and frankly for a free SQL solution it seems to be an EXCELLENT argument for using MySQL on other projects.

Just because this guy says they needs to delete everything and start from scratch is probably not going to convince the powers-that-be to give up their golden goose they got for free, and then go buy another golden goose for millions of dollars.

Re:Delusional editorialism!

[decula03]

"When MySQL launched, PostgreSQL was always an option."

Note: the article picks on all "OLDSQL" engines, so don't be so smug in having Postgres to choose
from. It's are next on the bashing list.

If people were complaining about how /slow/unreachable/screwed up/ Facebook was, this might have
been an actual article and not FUD about Mysql. But they aren't. Even Google has an investment in
mysql. and there is very little complaint about how reachable they are. If it ain't broke - invent something
new and PROFIT!

Re:Delusional editorialism!

[Anonymous Coward]

It has been long known MySQL is a low end,

which has superior performance to high-end databases

non-compliant (slightly better over the years) solution

like every other non-compliant SQL database

which teaches poor SQL

Like other databases with "varchar2", MS-specific syntax, and routine vacuuming

poor solutions, and even worse design

n00bs use it as their first database, so it must be the database's fault they aren't experienced designers yet

generally aimed at people who don't know any better

How dare mysql be free and well documented and have a good reputation.

When MySQL launched, PostgreSQL was always an option.

And when mysql gained subquery support in 2003, there was no longer any reason for most developers to use the slower Postgres.

Furthermore, Oracle even had solutions for them to grow into.

Facebook has money. If they thought the Oracle solutions were preferable, they would use them.

Re:Delusional editorialism!

[KermodeBear]

MySQL has never made a secret that it favors speed over 100% compliance. But, for applications that just need to write and read data, without any complex requirements, it's perfectly fine. For example: Facebook. Nothing on Facebook is really all that important. It doesn't need something with all of the extra functionality and data checking and other stuff.

Take a banking institution as an opposite example. They would need a database system that is very compliant and is extremely picky about data types and has excellent support for triggers, transactions, super high availability, etc., etc., etc. With all those features comes a cost of performance but, in their case, it's quite worth it for what they need.

MySQL, like PostgreSQL, like Oracle, like MS Access, is a tool. Part of being a good engineer / developer / artist is using the right tool for the job. People who run around and scream that their product is the best product for every situation no matter what are delusional.

Re:Delusional editorialism!

[JAlexoi]

PostgreSQL wouldn't have been an option for them at the time also. MySQL is still the best option for a quick setup queryable data dump and nothing else.
Their best solution would have been developing something along the lines of BigTable or other post RDBMS solutions. But when they started the NoSQL movement was nowhere on the horizon and now they have Cassandra to migrate to.

Re:Delusional editorialism!

[Anonymous Coward]

They aren't having any problems with MySQL. Believe it or not LAMP works great on large scale deployments despite what people who have no idea seem to think. The loudest are not necessarily correct.

Re:Delusional editorialism!

[Anonymous Coward]

which has superior performance to high-end databases

With all of the "high-end" features turned off. In an apples to apples comparison, MySQL is ALWAYS middle, last, or can't finish. Disgusting!

Like other databases with "varchar2", MS-specific syntax, and routine vacuuming

Nice dipshit troll. That's not even part of the standard - but aparently you're so stupid you don't realize this is what MVCC databases do. Them, like PostgreSQL, do it automatically though different implementations do it at different times with different pros and cons. Dip shit.

The rest of your idiocy is just that - uneducated, ignorant, bullshit, stupid, trolling. You must be a high ranking, in good standing, member of the Pro-MySQL community.

Re:Delusional editorialism!

[guruevi]

MySQL has been historically faster than PostgreSQL though although hardware improvements have closed that gap. MySQL may not be as persistent with the data as other SQL engines try to be but in Facebook's world, that's not really a problem. If you lose some data on FaceBook the world is not going to end, you're not losing money, all you do is maybe make an emo teen a bit sad but then just offer him a special cow on FarmVille and they're happy again.

migration....

[metalmaster]

If what this guy says is true and facebook devs have to rewrite everything the solution(as i see it) is quite simple.

Facebook user data is relatively similar across profiles. Their export application lends credit to this. Correct me if im wrong, but wouldnt it be simple to write a routine to port data from one product to the other? Test this thoroughly to make sure its bulletproof. Then run it until the job is done. To make this simple purge all the bullshit like wall posts, messages, notes and other user content. The only problem I see with this would be scale, and that can be mitigated by doing this a few thousand or million items at a time.

Re:migration....

[Anonymous Coward]

True, but while you do it, the data will become outdated. So you have to account for that. Facebook is too large to take down for a few days' migration.

Re:migration....

[cyber-vandal]

Exporting the data isn't the issue. The issue is going through the codebase and altering all the MySql specific code and then making sure it all works.

Re:migration....

[kimvette]

To make this simple purge all the bullshit like wall posts, messages, notes and other user content.

So, what you are saying is to purge everything which makes Facebook worthwhile to the masses? What else could possibly give Google+ an opportunity to instantly overtake Facebook? :)

Re:migration....

[sco08y]

Correct me if im wrong, but wouldnt it be simple to write a routine to port data from one product to the other?

Depends on your definition of "simple":

1. You build a second system.
2. Your "porting routine" has to keep both systems constantly in sync, bidirectionally.
3. You rewrite every client for the first system, or add bridges, to talk to the new system.
4. Finally, once all the clients are updated, you can switch off the old system.

Re:migration....

[Anonymous Coward]

Oh, sure... delete the user content. That's brilliant. Totally piss-off over 700 million people in the process! They log on, and ... what?! ALL of my pictures are GONE? ALL of my posts?! ^$#@)(*&#@_ UNSUBSCRIBE

"User content" is what people are on Facebook for, in the first place!

Re:migration....

[metalmaster]

aside from messages, that content is old 10 seconds after it is posted. Anyone with a reasonable amount of active friends isnt likely to notice a difference if you stagger the migration

Re:migration....

[cshark]

Why? Nobody at Facebook has even said there's a problem.

Re:migration....

[cyber-vandal]

Yeh this is all theoretical but the GP is over simplifying.

Still their fault ;)

[NSN A392-99-964-5927]

Well said, but there is no excuse for not doing things right first time. This just goes to show you face book is like the Death Star and it will only go one way.

Corporate businesses are so embroilled in FB and have put all their eggs in one basket, counted chickens before they have hatched, actually you can see what is on it's way.

Twitter will survive the death of facebook. Everything is under 256 chars.

Re:Still their fault ;)

[jjetson]

I'm sure this opinion is based on your experiences with 750,000,000 user sites. Thanks for the input Miss Cleo.

Re:Still their fault ;)

[NSN A392-99-964-5927]

I'm sure this opinion is based on your experiences with 750,000,000 user sites. Thanks for the input Miss Cleo.

Actually, you are right, I do not. Therefore you win.

Re:Still their fault ;)

[Rich0]

Well said, but there is no excuse for not doing things right first time.

I disagree.

Let's say I'm a start-up. I have very little cash. Do I spend that cash on database licenses, just in case I'm the 1 out of 2 billion startups that ends up with a billion dollar market cap? Do I take an extra six months to create a design that will scale to 3/4ths of the world's population?

99.9999999 times out of 100 you're better off assuming that you're not going to end up being Facebook, and start out modest. A website that actually is running on a mediocre RDBMS is worth more than a website that isn't done on an amazing one. If your developers know MySQL, then you're probably best off using it. If you bet wrong and turn out to be Facebook, then I'm sure you'll be crying about your decision all the way to your private island.

So what, Facebook needs to spend some money redesigning their software. That should certainly be hard for them to afford!

And total rewrite is an exaggeration - they only need to edit the SQL and mysql function calls and add in an abstraction layer. Sure, that takes time, but it isn't super-high-risk or anything. In fact, they can implement that abstraction layer one module at a time. Step 1, create abstraction function, step 2 replace direct mysql calls with calls via the function, step 3 unit test. Do that maybe a few hundred times and the whole thing is properly designed. Now you can start editing the abstraction functions to support some other storage backend.

As long as they get it done before mysql melts down they'll be fine.

Re:Still their fault ;)

[NSN A392-99-964-5927]

Congratulations you are hired by Facebook!

Re:Isn't MySQL an Relational Database Management S

[laffer1]

And if you need to use memcache, then it doesn't matter what database you're using. You can scale out read only nodes with most larger database systems, but it's not always a good idea.

Usually the issue is write performance. You can only write to one MySQL server in a cluster (unless using the newer mysql cluster storage engine). Some other commercial products let you partition data across multiple servers and write to different servers.

If you have a lot of read only nodes then all that data has to get replicated back out to them and that can get very slow if you're huge like facebook. I bet they use some type of crazy manual partition scheme to pull it off.

Re:Isn't MySQL an Relational Database Management S

[sco08y]

I was under the impression that there was no feasible way, performance wise, to run something as big as Facebook without using a non-relational database system.

Am I mistaken?

Plenty of financial institutions are working on a similar scale to Facebook, and they use SQL-based DBMSs. Facebook doesn't need transactional integrity for a lot of what they do. They don't have an elaborate set of regulations that they need to be in compliance with, and a large set of accounts that must all be constantly balanced. And Facebook can't charge a fee for every transaction that takes place.

Your standard SQL DBMS is doing OLTP, or online transactional processing. That usually means that it's running lots of small transactions that must follow business rules. Facebook has a lot of processes that can be extremely lossy, and they do a lot of analytics behind the scenes. So while they could, theoretically, shoehorn it all into Oracle, it would just be ludicrously expensive. The MySQL databases they have would be only one system out of many, probably managing things like logins and privacy and such.

Michael Stonebraker & VoltDB

[solferino]

The guy in the article does have some cred. He was a professor at UC Berkeley for 29 years where he was project leader on Ingres and led the creation of its follow up, Postgres.

His new database, VoltDB, based on the 'NewSQL' ideas touched on in the article, is Free Software licensed under the GPLv3.

Re:Michael Stonebraker & VoltDB

[FlyingGuy]

Oh My Fucking God! A database that you have to write stored procedures in Java!!!!! Are you fucking kidding me!

Re:And this opinion has nothing to do with the fac

[Billly Gates]

The benchmarks I have seen are debatable. PostgreSQL performs slower for the first 100 users but quickl outscales it when access becomes heavy with hundreds of concurrent connections. I do admit this was several years ago and Mysql is adding the extra features, but views, triggers, and stored procedures are usefull in conserving memory and optimizing performance with large tables if used properly and this is where PostgreSQL shined as Mysql 4.0 did not have half of these. PostgreSQL comes iwth the most conservative settings by default too on a fresh install on any Linux distro. You need to configure it to boast performance.

Features are not just for easier development, but also to reduce the work on the RDBMS and increase performance. ... I am not a DBA so I dunno. I am learning postgresql for a project I am working on so I am little biased.

NoSQL? NewSQL?

[medv4380]

I wouldn't be surprised if a lot of their issues was because of their vain quest to use NoSQL. They were willing to sacrifice good design for minor speed gains and if that was their mentality all along who knows what else they did. The article also reads as another NoSQL plug but instead is plugging NewSQL. These are fads and just need to be ignored and the problems that they are intended to solve only exist because of bad code design, and exist to allow bad coders a way out of their craziness.

MySQL is facebook's issue?

[sgt scrub]

I don't think so. Facebook isn't known for having a lot of down time. It is known for opening up information to the public. If anything, that would be considered too much up time. I've used MySQL and PostgreSQL. I found MySQL to be limited but most limitations were easily worked around in code. PostgreSQL wasn't as limited. However, the options that it provided forced the need to vacuum the database. I would rather write code but to each his own.

Re:MySQL is facebook's issue?

[canajin56]

TFA is saying that both MySQL and PostgreSQL are absolute shit, as is anything that uses SQL. For one, they waste time with ACID and concurrency. For another, they waste time with hard drives when RAM is so cheap and you can just throw TB upon TB into a single server (right?)

He's saying that instead of clicking "like" instantly pausing the entire facebook system while the "like" is written into the "likes" MySQL table, it should just store that in RAM and not worry about having to lock the entire website to maintain consistency. In other words, he's a complete moron because Facebook doesn't work that way at all, it works how he wants it to work.

No solution provided by the author......

[sp4ni3l]

While finding te story very interesting, there is no real solution at the end of it. In one or two sentences: what would facebook have to hoose as the database and then : why that option , or weigh the alternatives.

Re:No solution provided by the author......

[Anonymous Coward]

The author of the article is a businessman who sells a competing product with MySQL. He probably advertises his product as something easy to migrate from MySQL to, and people searching for such a system may very well find his.

It's in his best interest to trash talk MySQL. This whole article is a troll.

Re:No solution provided by the author......

[cshark]

It was alluded to. And obviously, since people can't be bothered to write or scale SQL properly, the only solution has to be to go with an obscure untested solution like VoltDB, right?

That's not Facebook's problem

[Animats]

Academic purist discovers that one of the most prolific and successful database users in the world is using a system he doesn't approve of. He decides, with no insider knowledge at all, and despite all evidence to the contrary, that they should throw everything away and start over from scratch using a system that he thinks would allow them to see the performance and scalability that they've already achieved.

Right.

Some of the key architects of Facebook have spoken at Stanford about how the system is put together, and I went to that presentation and had a chance to talk to them. They didn't consider MySQL to be a bottleneck. Their big problem was PHP performance. They were writing a PHP compiler to fix that.

Internally, the user-facing side of Facebook is in PHP. But the front end machines don't talk directly to the databases. They use an RPC system to talk to other machines that do the "business logic" parts of the system. Building a Facebook reply page may involve a hundred machines. There's heavy caching all over the system, of course, so the databases aren't hit for most read requests.

The RPC system isn't HTML, JSON, or SOAP. It's a binary system that doesn't require text parsing. Otherwise, RPC would be the bottleneck.

This makes for a flexible, easy to enhance system. New services go in new machines, which talk to existing machines.

Re:That's not Facebook's problem

[rekoil]

The RPC system they're using is Thrift (http://thrift.apache.org/)., which they developed because JSON was becoming a bottleneck. And yeah, there's a metric crapload of memcached in their data centers as well. The multi-hour outage Facebook had late last year was due to a near-complete failure of the memcached layer, resulting in an overload of requests to the main mysql farms.

Re:That's not Facebook's problem

[Anonymous Coward]

Internally, the user-facing side of Facebook is in PHP. But the front end machines don't talk directly to the databases. They use an RPC system to talk to other machines that do the "business logic" parts of the system. Building a Facebook reply page may involve a hundred machines. There's heavy caching all over the system, of course, so the databases aren't hit for most read requests.

Which, ironically, is exactly the design pattern built into J2EE, except you don't need to invent your own n-tier software stack or do the optimizations for your custom stack - they've already been done for you.

Re:That's not Facebook's problem

[dlweinreb]

Right, exactly. There is no evidence in the gigaom article that there is a problem needing to be solved. Whether MySQL is "what's causing the problem" can't be evaluated without that. Facebook does, pretty much, work. I am not aware of any major complaints for users where MySQL has been traced as the root cause. I am NOT a MySQL fan, far from it, but if it's working, then why talk about gloom and doom?

Re:That's not Facebook's problem

[dgriff]

Internally, the user-facing side of Facebook is in PHP. But the front end machines don't talk directly to the databases. They use an RPC system to talk to other machines that do the "business logic" parts of the system. Building a Facebook reply page may involve a hundred machines. There's heavy caching all over the system, of course, so the databases aren't hit for most read requests.

The RPC system isn't HTML, JSON, or SOAP. It's a binary system that doesn't require text parsing. Otherwise, RPC would be the bottleneck.

Um, if a single reply page involves a hundred machines, I don't think the RPC mechanism is the root cause of their problem.

Re:That's not Facebook's problem

[Anonymous Coward]

They didn't consider MySQL to be a bottleneck. Their big problem was PHP performance. They were writing a PHP compiler to fix that. Ahh, Facebook. Proof of two things:

1. You can write an extremely scalable web platform in PHP, and use it to drive one of the world's most popular websites.

2. You will regret it if you do.

I find it amusing that the PHP fans' reply, whenever their language is criticised for its poor performance, is "it doesn't matter, because the bottleneck is in the network and the database". So much for that one, fanboys!

(Good thing they didn't use Ruby, like the Twitter guys did. They actually did have to start over from scratch in a compiled language!)

Worse than death?

[AlecC]

Becoming very, very rich but being locked out from becoming extraordinarily rich is a fate worse than death? Many of us would be very happy to have problems like this.

Total rewrite is always bad... mkay?

[spectro]

Over and over we hear about this "scrap and start over" concept. It sounds like a great idea but you are assuming you can do a better job than the guys before and more often than not you will be wrong.

I used to suggest it but now I know better. I have seen new devs with little experience passionately suggest so called "total refactoring". It has never ended well.

Re:Total rewrite is always bad... mkay?

[tirk]

"scrap and start over" should be a last resort, but I know from experience there are times it benefits. In the best world all development would be forward thinking and designed and written modular enough to handle future changes and growth without causing muddled and or patched code. However, in practice this is not always the case and forward thinking can't handle all the possibilities that might come along. Sometimes things become so tangled that a rewrite is the best option out. Not so much because you think you can do it better then the previous developers, but because you have a better definition of the evolved project that is now in use and can design the pieces to interact better now. If an application is static, it probably would never need a start over, but if it's dynamic and evolved over years a scrap and start over approach can sometimes save great amounts of time in the future. I will say though that I have found that most times the culprit of muddled and patched code is rushed development in trying to just get a result to the public as quickly as possible. This however has been an unfortunate side effect of doing business long before the computer age, if your competition beats you to the opening you'd better have something far better to even be noticed.

Re:Total rewrite is always bad... mkay?

[tqk]

"scrap and start over" should be a last resort, but I know from experience there are times it benefits.

I agree with pretty much everything you said here, and I'll increment that with you don't need to scrap it to start over.

Every time I've found myself in this position, it's been a monolithic monstrosity banged together years ago by someone who barely knew how to design and build a system, held together with duct tape over the years. It's been relatively simple to break the monstrosity up into discrete functions to minimize the complexity leaving you with a far more managable system to work with. Shampoo, rinse, repeat. This's simple maintenance, something any competent developer should be capable of. On top of all that, for the developer it's fun to do! You know you're doing something valuable for which the poor sod who follows you will be thankful (and sing your praises).

Once you've been through a few iterations of this, you'll have something any child could maintain, and you'll have a lot less cost and difficulty adding new features or tracking down and fixing bugs when desired/necessary.

Additionally, this's a great way to find and fix bugs. I found four monster bugs in my last one; features that'd never worked for a decade that the users just worked around and avoided (costing gahd knows how much of their time and hair), inconsistent datestamp handling (that almost made their transaction history useless), etc.

Unfortunately, there's far too few management types who understand this sort of thinking. Anything that costs their budget anything is anathema, so the thing has to get really broken before they'll man up and do anything about it and even then, they only want the immediate problem fixed. They generally don't want to pay for any maintenance, much less a thorough reworking of the system in any way.

Or you could....

[MAXOMENOS]

The underlying problem according to Stonebrook:

During an interview this week, Stonebraker explained to me that Facebook has split its MySQL database into 4,000 shards in order to handle the site’s massive data volume, and is running 9,000 instances of memcached in order to keep up with the number of transactions the database must serve.

Or you could put MySQL on an IBM Power Systems LPAR and use a commercial MySQL plug-in to store the data in a DB2 database. Then you can get away with maybe a dozen database machines instead of thousands. I have to imagine, btw, that Oracle has a similar offering in the works.

Lesson: academic credentials are no match for real world experience.

Re:Or you could....

[sphealey]

> Or you could put MySQL on an IBM Power Systems LPAR and use a commercial
> MySQL plug-in [krook.net] to store the data in a DB2 database. Then you can
> get away with maybe a dozen database machines instead of thousands. I have
> to imagine, btw, that Oracle has a similar offering in the works.

Buh.. buh.. buh.. buh... But - that would be like a /mainframe/! Mainframes are archaic and obsolete - everyone knows that! How would you cluster the application servers to a system like that?!? _Everyone_ knows you need application servers!

sPh

Re:Or you could....

[JAlexoi]

There is not a single reference to a mainframe. System p is not mainframe and has LPARs

Think *that* is bad? Bah!

[Anonymous Coward]

PHP is being developed by Zend. Zend also develops one of the most widely used software frameworks for PHP (Zend Framework), a server environment (Zend Server), a PHP development environment (Zend Studio) and god knows what else... You're in for a world of pain when you have a problem and try to google for help.

Re:And this opinion has nothing to do with the fac

[dzfoo]

And this opinion has nothing to do with the fact that this is the guy who write PostgreSQL and he has been bitching about how MySQL has a to big market share, for years??

Not at all. But it does have something to do with the fact that he is plugging his new product, which implements something he calls "NewSQL."

      dZ.

Mongo DB

[fredan]

They can't switch to Mongo DB because ?

Re:Mongo DB

[Anonymous Coward]

Mongo is web scale.

Re:Mongo DB

[Anonymous Coward]

MongoDB is a pile of shit. It makes MySQL look like a good option. That's why.

(I assume that you're not joking, and actually are recommending the use of MongoDB. My apologies if I'm wrong.)

Oracle vs Facebook?

[AliasMarlowe]

It may not be a hardware problem, it may be a problem that actually has more to do with the fact that Oracle owns MySQL.

It's not unreasonable to suppose Oracle might "nudge" Facebook into the deeper end of Oracle's trough of slimy swill. But who to root for? This is a bit of a conundrum. Seeing Facebook's delicate bits getting squeezed is not an unattractive proposition, but seeing Oracle benefit therefrom would be appalling.

Re:Oracle vs Facebook?

[Midnight Thunder]

Is Oracle really the only alternative?

How does Postgres, DB2 and Sybase compare?

I have a new project and although I don't have the cash for the big DBs due to cost, I am wondering whether there are any more affordable solutions that would give MySQL a run for it's money?

Re:Oracle vs Facebook?

[h4rr4r]

Use Postgres.
It costs the same as MySQL $0 and is a 100 times the DB.
It offers far better data integrity, it supports transactions out of the box, it will handle DBs in the TB range, and is about as standards compliant as DBs get.

The company I work for uses it for our service that we sell.

Re:Oracle vs Facebook?

[davester666]

Maybe Facebook should just put all our data in the cloud...it's not like security or privacy is a big concern for Facebook...

Re:Oracle vs Facebook?

[isopropanol]

Seconded.

Re:Oracle vs Facebook?

[marcosdumay]

I'll second h4rr4r. Use Postgres. Until you are very big, a DBMS will only make any difference if you choose one of those that trade reliability and compatibility for speed (like MySQL). Your best strategy at the beginning is to start with a cheap one, and there is none cheaper than 0.

When you get big enough that the DBMS will make any difference, you'll discover it is cheaper to add hardware than going with a proprietary one anyway. The best strategy here is to go with a cheap one, and there is none cheaper than 0.

Once you are so big that adding hardware won't help, you'll discover that your only chance is to customuze your data layer. No out of the box DBMS will be usefull here, but if you are on Postgres you'll discover that it is easy to customize, and there are some companies that will even do that for you. The best strategy here is to go with a free (speech) DBMS, and the worst one is to go with an imcompatible propretary one (like Oracle).

So, going with Postgres you'll save some bucks at the short term at the cost of saving a few more bucks at the middle and long term.

Re:Oracle vs Facebook?

[thejuggler]

Agreed - PostgreSQL all the way - and now with replication.

Re:Oracle vs Facebook?

[Daniel Phillips]

Use Postgres.
It costs the same as MySQL $0 and is a 100 times the DB.

I think you need a few more zeros on your multiplier. MySQL is not ACID, so for an enterprise to rely on it for anything important is just pure idiocy. Not that Facebook people are the only idiots in this respect, a certain large search company said to only hire smart people also relies on MySQL for its critical infrastructure.

Re:Oracle vs Facebook?

[sirsnork]

And if you use stored procedures for everything from the start, even if you do have to change DB's at some point in the future, you won't have to re-write everything, just the stored procedures.

Re:Oracle vs Facebook?

[multi io]

I think you need a few more zeros on your multiplier. MySQL is not ACID, so for an enterprise to rely on it for anything important is just pure idiocy.

InnoDB can be configured to be ACID compliant. That said, a database that contains 600,000 user records and associated data, is distributed worldwide, and provides 0.1 seconds of response time at several million queries per second can't be ACID anyway.

Re:Oracle vs Facebook?

[Mr Z]

So let me see if I follow: If I use stored procedures for everything, then when I change DBs, I won't have to rewrite everything, just the stored procedures. But didn't I use the stored procedures for everything? What part am I not rewriting again?

Re:Oracle vs Facebook?

[swalve]

In almost all cases, more applications will be using the stored procedures than there are procedures. Very simply, for example, your admin screen might need to get a user profile, and then your client screen might need to get a user profile. If they are both programmed separately, you have two things to change. If they use a stored procedure, $GetUserProfile(), then you only have to rewrite one thing.

Re:Oracle vs Facebook?

[Skal Tura]

If you are worth your weight as a developer, you've already done model isolation layer where your all queries would be, thus it's not that hard to rewrite the queries. If this was to be expected, you've made it far simpler already.

In any case, i don't see the anti-MySQL points. I've tried Postgres once - that was enough, i'm not going back to it. It was weird as shit, required some weird conundrums for permissions and DBs changes, didn't seem to be properly isolating but more like hacked together to support more than 1 DB, with 1 set of perms per server - no, i don't mean it didn't support, that's just the way it felt.

If you got 2 choices, otherwise equal for what you need now - always choose the simpler one. Postgres definitely is not the simpler one.

Re:Oracle vs Facebook?

[lpp]

And if your admin screen and client screen are both written to invoke the GetUserProfile() method in the Profile class, then you still only have one thing to rewrite.

Not to say there isn't a case where you absolutely must have multiple points in your code invoking the same stored procedure but then again there's nothing preventing you from designing things so that you have a 1:1 mapping between stored procedures and methods in your code to invoke them.

Re:Oracle vs Facebook?

[Anonymous Coward]

Replication is not ready for primetime. It is still kludgey.

Re:Oracle vs Facebook?

[jellomizer]

Legacy systems built over the years rarely if ever are pure in style, and every intro programmer goes back and sees the legacy code will gasp in horror that they did things that way.

Early LAMP designs were often very basic. With SQL queries built right in in a bunch of random spots, yes it is bad design, but the alternative was parsing a flat text file.

Many apps were not really expected to be huge, but released fast when you want a fast release there is little time architecting it to work well. I use to be a Software Architect at a former job, who demanded the product to be released fast. So the best I could do is give a basic structure on how it should work and pray to God that the developers do a good job. Then I got a boss who was more interested in control of his product idea, that we would be punished for trying to advocate best practices. And he used buzz words like "this is agile development" or "enterprise class" while the method he had us do it just made it worse.

The moral is, bad code is an organizational problem, not any one person in the chain.

Re:Oracle vs Facebook?

[evilviper]

I agree that Postgres is vastly superior to MySQL and competitive with enterprise-class databases. We're using Postgres for databases in excess of a terabyte ourselves, for large-scale production purposes, so I know it works... HOWEVER, I think the XID issue is significant, not getting any developer attention, and is something you're just about guaranteed to run-into with terabyte databases.

You see, even if you run Postgres on a 64-bit platform, you're limited to XIDs of 2^31, or 2 billion rows. Now, to prevent this causing a problem, Postgres' VACUUM process will start running when you get close to 1 billion, killing your performance. Of course there are a dozen possible ways to workaround this, but none are trivial or work perfectly and consistently. This is postgres' biggest scalability limitation, ahead of even the imperfect replication options available.

That said, Postgres is still a great choice for an enterprise application. In fact EnterpriseDB simply added PL/SQL to Postgres so that it's a drop-in replacement for Oracle. Postgres' XID and replication limitation are notable, but the price of something like Oracle is so astronomical that working-around this limitations of Postgres is vastly more cost-effective in all cases I can think of.

Re:Oracle vs Facebook?

[theshowmecanuck]

I have to agree with about the brutality of the Postgres security model. It is fucking horrible. It seems to work so incredibly different than everything else, and just seems to put a ton of horrible roadblocks in front of the programmers. The new replication stuff is also pretty rough around the edges and there is a lack of high availability built in. As are items like differential backups and restores (at least compared to DBs like Oracle, MS SQL Server, and DB2). The core database aspects of it are excellent. But as much as I really like it as a DB system, if I were to recommend a system I would have to go to one of the proprietary DBs, then Postgres, then MySQL. And if you needed high availability MySQL would be before Postgres. If Postgres could clean up security and high availability failover, then it would be a go to DBMS. High availability features are really a no brainer requirement these days. All said and done, for home projects for learning, I use Postgres. Not for money projects as yet. Feel free to slag away at this, everyone has an asshole... I mean an opinion. :P

Re:Oracle vs Facebook?

[Anonymous Coward]

Postgres is better than MySQL but Firebird is better than both. Also free.

Re:Oracle vs Facebook?

[Nivag064]

Hmm... I can do reasonable stuff in PostgreSQL without buying any books; but when I got a client using MySQL I found it necessary to buy a book on it.

Now I've been using database from my Mainframe days, and have experience on Oracle and Progress RDBMS's, plus Sybase. Writing SQL queries and stored procedures in PostgreSQL, is generally far better than any other RDBMS (you can almost always find situations where another RDBMS is better, no matter what your current RDBMS is!).

So I would far rather create and maintain a database using PostgreSQL, than any other RDBMS that I have ever used.

Re:Oracle vs Facebook?

[arglebargle_xiv]

You see, even if you run Postgres on a 64-bit platform, you're limited to XIDs of 2^31, or 2 billion rows. Now, to prevent this causing a problem, Postgres' VACUUM process will start running when you get close to 1 billion, killing your performance. Of course there are a dozen possible ways to workaround this, but none are trivial or work perfectly and consistently. This is postgres' biggest scalability limitation, ahead of even the imperfect replication options available.

What are you doing that requires 2 billion rows?

Re:Oracle vs Facebook?

[Anonymous Coward]

Thanks for your positive comments about PostgreSQL. I wanted to respond in detail to the points made about limitations, which aren't correct.

You are correct that PostgreSQL uses only 2^31 XIDs or transaction ids. That means every billion write transactions PostgreSQL needs to perform a VACUUM operation. You mention that kills performance. PostgreSQL allows you to run this as a low priority background job, which continues to allow reads and writes, yet runs at a deliberately slower pace to avoid impact on system resources. All of that is automatic, with the VACUUM task even cancelling itself if it really does get in the way of any user request. The way this works has received significant improvements in performance and operability in every annual release for many, many years. The benefit of all of this is that read queries aren't blocked by write queries - an incredibly important feature for general purpose computing.

The number of XIDs has no effect whatsoever on the number of rows in a database. There is no limit of 2 billion rows - in fact there is no limit to the number of rows in a table at all. Currently, tables are limited to 32TB, but we can increase that if people find that a limiting factor. There *is* an object PostgreSQL called an OID, that acted somewhat similar to that described by the poster but any limitation there was removed more than 7 years ago. Many PostgreSQL users have installations above a Terabyte in size.

Replication has been one of the areas that has received significant and consistent developer attention across many years. Starting in 9.0 we have native binary replication, with options that make it the full equivalent of the best options in Oracle Enterprise Edition, including pay for options of Active Data Guard. Synchronous replication will be available in PostgreSQL 9.1, out real soon now. PostgreSQL 9.2 will have cascaded replication, multiple performance options and other features, many of which are in advance of what is available in pay-for commercial systems. We think this area so important that there is a dedicated conference on this aspect of PostgreSQL.

Yes, I'm a PostgreSQL developer: Simon Riggs of 2ndQuadrant

Re:Oracle vs Facebook?

[bruce_the_loon]

Lessee, Chinese government citizens' annual loyalty test results for 3 years, Indian government election results tally for 1 election, Facebook's wall. CitiBank's payoff records.

You will be surprised how fast 2 billion records gather when you've got a large enough client base.

Re:Oracle vs Facebook?

[fuzzytv]

I wonder what you find "horrible" on the PostgreSQL security model. It's not perfect (what is?), but I find it comparable to other databases I work with. I've never considered it a roadblock, especially compared to quirks in the security models of other databases. Plus the config is very flexible and easy (have you ever tried to use Kerberos with MySQL?). Yes, the replication stuff may seem a bit rough, and you're right it's not a complete HA solution. But it's not that difficult to prepare a shell script that does that last step (switching to a slave database when the master fails). But it's a matter of preference - I've been working with other databases and I really appreciate this flexibility over a very limited GUI tool. And there are tools that might work for most users (e.g. repmgr). Differential backups - yes, that's one feature I'm missing. Although you can archive transaction logs, and you can do filesystem snapshots and combine that.

Re:Oracle vs Facebook?

[marcosdumay]

The security model is different because it was created to plug* into the OS (unix) security model. I think that was a bad idea, and it seems most of the world agrees with me on that... But it is not less functional, it will just take longer for installing the DBMS at the first time.

The hight availability is cripped because it was made to plug* into the Linux HA and similar projects. That I think is a good idea, but the judge is still out and you may quite well disagree. Anyway, when implementing a HA solution with postgres, just use Linux HA or some similar environment.

* You'll see there is a theme repeating here. Postgres is based on plugins, and for some people it is a quite valuable form of organization. That is what makes postgres easy to customize.

Re:Oracle vs Facebook?

[HappyPsycho]

I don't think you read the article, ACID and its associated overhead is Facebook's problem. Adding more of it isn't going to help them.

Also MySQL might not be fully ACID compliant but instead it is fast, substituting postgres will only make their lives more painful.

Re:Oracle vs Facebook?

[jadavis]

"You see, even if you run Postgres on a 64-bit platform, you're limited to XIDs of 2^31, or 2 billion rows."

That is false. You can insert as many rows as you want into a table as long as it's less than 32TB (8KB page size * 4 billion). In practice, people partition tables long before they hit 32TB, so that is not a practical limitation even if you do have more than 32TB. "Typical" rows might fit 100 to a page, so it's more like 400 billion rows per partition of a table in practice.

The XID limitation to which you are referring is much different, and refers to the number of transactions that the system keeps track of total (completed or not). That's OK, because after a while, individual transaction IDs become irrelevant. If transaction ID 100 and 103 both committed a long time ago (there is a technical definition here with several conditions, but it's not important for this discussion), do we really care that they were separate transactions? The answer is no. So vacuum can replace every instance of 100 and 103 with a marker that just says "committed a long time ago".

In fact, you probably want to do this quite a lot more often than every billion transactions (100M is the default). Why burden the system with having to keep track of the difference between 100 and 103 for a long time after that distinction is meaningless? It just happens that the maximum time you can wait is limited to a billion.

Does vacuum have a cost? Yes. Is it a good trade-off? I think so -- it takes care of a lot of cleanup tasks (this is only one) and it does so in the background, batching up work. And it's fairly intelligent about when it works and what it does.

Re:Oracle vs Facebook?

[evilviper]

I wanted to respond in detail to the points made about limitations, which aren't correct.

Yes, I'm extremely sloppy when posting details to /. particularly when I believe a simple explanation is good enough to get the point across, and not confuse too many people...

You mention that kills performance. PostgreSQL allows you to run this as a low priority background job, which continues to allow reads and writes, yet runs at a deliberately slower pace to avoid impact on system resources. All of that is automatic, with the VACUUM task even cancelling itself if it really does get in the way of any user request.

That's certainly a good tip. The company I work for is, sadly, one where there is never time to do any in-depth research, tuning, debugging, etc., unless/until a major component is completely falling apart. Try as I might to change that, it's slow going...

Our fix to this point has been partitioning and truncating old data, and vacuuming the empty tables to reclaim XIDs, and hoping all goes well and we never need a full auto-vacuum...

I must ask, though, if adjusting the priority is so safe, why are the defaults so aggressive that they are guaranteed to have a major performance impact? I don't see where anyone would want an aggressive autovacuum, which is, by definition, not happening during a maintenance window nor scheduled during off-peak hours, dramatically affecting DB performance.

The number of XIDs has no effect whatsoever on the number of rows in a database.

Well, only in that (at least when left to defaults) a full autovacuum is so long-running and such a painful performance hit that avoiding it has undeniably limited us to a 1B limit.

Many PostgreSQL users have installations above a Terabyte in size.

Replication has been one of the areas that has received significant and consistent developer attention across many years. Starting in 9.0 we have native binary replication,

I have been following these recent developments with anticipation. But I must say it has honestly come a decade late. At least I've been personally (either directly or indirectly) having to work around the lack of postgres multi-master replication for that long, and having a harder and harder time justifying the lack thereof in something that is supposedly enterprise-class open source software.

with options that make it the full equivalent of the best options in Oracle Enterprise Edition, including pay for options of Active Data Guard. Synchronous replication will be available in PostgreSQL 9.1, out real soon now. PostgreSQL 9.2 will have cascaded replication, multiple performance options and other features, many of which are in advance of what is available in pay-for commercial systems.

That, I had not heard. Simple 2-node multi-master clustering has been so long in coming that I was happy to just finally see that available, and didn't expect to see much more coming down in the near future. I certainly look-forward to having the option of a 16-node Postgres cluster. And maybe I can justify investing more time in profiling and tuning our postgres DBs, rather than only ever our Oracle (RAC) installations.

Re:Oracle vs Facebook?

[h4rr4r]

Say Hi to Noah for me.

Re:Oracle vs Facebook?

[raphael75]

a certain large search company said to only hire smart people also relies on MySQL for its critical infrastructure.

It seems to be working pretty well for them, don't you think?

Re:Oracle vs Facebook?

[theshowmecanuck]

I don't think writing a script to cover the last step of switching in the even of failure as a viable option. The architecture should be able to sense that the primary has gone down, and the secondary/slave should become the primary automatically and immediately. That is what HA is supposed to do.

Setting up security I find to be tedious etc. What bothers me is the pretty non standard way of working with data. With just about every other database out there, once you log in to the server, as long as you have permissions granted to a schema that is not your default, all you need to do is reference schema_name.table_name, nothing else. And as for your default schema you should only have to reference the table_name. And in fact, regardless of schemas, if there are no conflicts in table names between schemas you have permissions on, you shouldn't really even have to use the schema reference in that case either. (If your app uses multiple schemas, and say you want to use a different dev schemas or testing schemas, you should not have to change the schema_name references in your queries, dml, etc.). It seems like I am constantly finding Postgres 'gotchas' with this aspect that get in the way, and sometimes prevent generic coding of procedures, sql, and dml. Now as for the hba conf file.... grrrrrrrr! What a waste of time. If you don't want to give access, don't let people log into the box and don't give them database user and/or permissions for f sake. That hba conf is just plain useless cruft. Any other config (like with Ker... ) should be done in the main config file.

Re:Oracle vs Facebook?

[theshowmecanuck]

I don't think Postgres HA should be something that plugs in to Linux HA or similar. That is passing the buck. You should not have to count on other HA solutions to 'know' about Postgres or vice versa. It should be able to take care of its own business. That is what the other DB solutions out there do. And they are far more successful with it. That is why people trust those other DBs for HA more than they do Postgres.

And believe me, I really do like most aspects of Postgres, but the security and HA aspects are show stoppers for me. The HA more than the security with me, but I know others I have worked with have almost 'lost it' because of the Postgres security model. And then in steps MySQL (unfortunately).

I don't think MySQL is generally robust enough for major implementations, but its security model and replication/HA are head and shoulders above Postgres's; and yes I know that isn't saying much, but it is enough for just about anyone else I've worked with when it came to choosing open source DBs. And when all the other devs want something other than Postgres because they hate the security model and the lack of ready for prime time HA, and the PM sees more press about MySQL than Postgres (i.e. the PM says, "I've never heard of Postgres"), then in comes MySQL, and out goes Postgres.

I think the Postgres team really needs to stop worrying about just about every other feature request until they have a much better point in time data recovery model (required for HA... and from some of the technical seminars I've watched, is why HA is not very good), AND a self contained and ready for prime time HA solution that does automatic cut over, AND... until it has a really clean and industry/standards standard security model (and please don't knit pick about 'what is standard anyway'.... I'm sure you know what I am talking about... make it at least close to what the others are doing so people don't freak out trying to figure out how postgres does it... since it is the only one this 'far out').

Re:Oracle vs Facebook?

[theshowmecanuck]

Oh yeah, I forgot to add. I don't know any person or organization that customizes their RDBMS. They may use different features, but that is because other databases have all their features built in so they won't fail because someone upgrades an O/S or some other piece of software that the DB is built to rely on and that is now no longer compatible (on purpose or due to bugs) with their RDBMS. This argument is a lame as assuming that almost everyone out there can debug and fix a program because it is open source and they have the code. The reality is that almost no one does this, and if it doesn't work, they will use something else that does. Postgres has got to pull up its socks on this one and handle the really important items like HA internally, not as a plug in.

Re:Oracle vs Facebook?

[fuzzytv]

Yes, the HA stuff is not as nicely wrapped as in other databases and may require a bit of work (e.g. to write a script). There are two main reasons for that - first, the replication stuff is about 1 year old and the developers prefer to build just very basic functionality first and see how that works. Second, the developers tend to have "unix mentality" i.e. they prefer to build tools that are easy to extend with other tools (as with "|" in the unix shell). So there's just a bare replication stuff, they're improving it where needed (e.g. the monitoring is going to be much better in 9.1, synchronous replication was added etc.), and some of the stuff has to be implemented in external tools (e.g. the management utilities - repmgr looks really promising). I personally don't see the need to write a script as a major obstacle, for me it's a big advantage. I work in this area for a few years and I'm really sick of those nice GUI management tools, because with a reasonably complex environment you'll have to log into multiple such tools, click a few buttons and so on. That's manual work, it's takes time and it's error prone. A simple script is much more reliable for us and it's really easy to integrate into other scripts. And the automatic failover - I really don't like fully automatic jobs in most cases. I've seen so many cases when this backfired I prefer a solution that gives the admin an opportunity to verify failover really is the right thing to do. For example when replicating to different location, there're so many possible reasons why the master might be unavailable and the slave might belive it's time to become master ... But even when such automatic failover should happen, it's usually pretty simple to script that does it. Not sure what you find tedious on the security ... For me it's pretty straigtforward, and actually you don't need to modify the config file when creating a new user in most cases. I usually set it once at the beginning, stating something like 'remote users need to provide password, local users can access without password' or something like that. And then you don't need to touch it for a year, then someone wants to add kerberos for some users - a simple edit. I'm a really confused by the rest of your post, because schemas are threated almost exactly as you describe. It seems you've missed the 'search_path' that allows you to define a list of schemas - the objects are searched in those schemas and the first matching object is returned. So you don't have to prepend the object name with a schema name, just set the search_path properly. BTW I'm not aware of a database that searches for the object in all schemas the user has permissions on - e.g. Oracle searches in the "current schema" only and you have to create synonyms to access objects in other schemas this way. Try to create two users, create a table in one of them, grant privileges on the table to the other user and let the other user select data from it (without referencing the schema name) - doesn't work. You have to create a synonym. You can create a 'invoke rights' procedure, but even that one resolves the objects this way. Actually this makes the application a bit fragile - say there are three applications in separate schemas A, B and C. Application A uses table X in schema C without schema name. Then the application C is extended with a table X - ooops, the application suddenly does not work, because it references the wrong table.

Re:Oracle vs Facebook?

[fuzzytv]

Aaaaarghhhhh, submitted before noticing the whole post is a single paragraph. So once again in a bit more legible form:

Yes, the HA stuff is not as nicely wrapped as in other databases and may require a bit of work (e.g. to write a script). There are two main reasons for that - first, the replication stuff is about 1 year old and the developers prefer to build just very basic functionality first and see how that works. Second, the developers tend to have "unix mentality" i.e. they prefer to build tools that are easy to extend with other tools (as with "|" in the unix shell). So there's just a bare replication stuff, they're improving it where needed (e.g. the monitoring is going to be much better in 9.1, synchronous replication was added etc.), and some of the stuff has to be implemented in external tools (e.g. the management utilities - repmgr looks really promising).

I personally don't see the need to write a script as a major obstacle, for me it's a big advantage. I work in this area for a few years and I'm really sick of those nice GUI management tools, because with a reasonably complex environment you'll have to log into multiple such tools, click a few buttons and so on. That's manual work, it's takes time and it's error prone. A simple script is much more reliable for us and it's really easy to integrate into other scripts.

And the automatic failover - I really don't like fully automatic jobs in most cases. I've seen so many cases when this backfired I prefer a solution that gives the admin an opportunity to verify failover really is the right thing to do. For example when replicating to different location, there're so many possible reasons why the master might be unavailable and the slave might belive it's time to become master ... But even when such automatic failover should happen, it's usually pretty simple to script that does it.

Not sure what you find tedious on the security ... For me it's pretty straigtforward, and actually you don't need to modify the config file when creating a new user in most cases. I usually set it once at the beginning, stating something like 'remote users need to provide password, local users can access without password' or something like that. And then you don't need to touch it for a year, then someone wants to add kerberos for some users or something like that - a simple edit.

I'm a really confused by the rest of your post, because schemas are threated almost exactly as you describe. It seems you've missed the 'search_path' that allows you to define a list of schemas - the objects are searched in those schemas and the first matching object is returned. So you don't have to prepend the object name with a schema name, just set the search_path properly.

BTW I'm not aware of a database that searches for the object in all schemas the user has permissions on - e.g. Oracle searches in the "current schema" only and you have to create synonyms to access objects in other schemas this way. Try to create two users, create a table in one of them, grant privileges on the table to the other user and let the other user select data from it (without referencing the schema name) - doesn't work. You have to create a synonym. You can create a 'invoke rights' procedure, but even that one resolves the objects this way. (With search_path this can be done quite easily, just put there more schema names.)

Actually this makes the application a bit fragile - say there are three applications in separate schemas A, B and C. Application A uses table X in schema C without schema name. Then the application C is extended with a table X - ooops, the application suddenly does not work, because it references the wrong table.

Re:Oracle vs Facebook?

[theshowmecanuck]

I love synonyms. And you are right, it is probably that I am thinking of (possibly because I always thought of synonyms as a form of permission since when I have used them we make sure table names never overlapped between schemas... or very little anyway). I don't like the search path method as I never seem to get it right... I would love to see synonyms in Postgres. I used to work on Oracle and DB dev a LOT up to about 5 years ago (team lead C/Unix/Oracle etl, warehouse, app DBA etc...). Switched to BSA and now am wondering why. :) Don't enjoy politics and project politics bs. I play with Postgres a fair bit now as I still like programming (except for all the frameworks now.... is there no original thought in development any more... so sad for innovation), so I find myself doing more and considering the 'retrograde' action of going back into the trenches. Anyway, I also want to say that if you modify hbaconf to allow a DBA to create users from anywhere, it means you aren't limiting anyone via hbaconf from connecting to the database. In that case hbaconf is meaningless and not needed. Especially as all O/S's provide the same functionality (limiting access to the box).

Where I've worked with HA, the volumes are so high that if you wait for a DBA to verify whether it should cut over or not, the company can lose literally millions of dollars (systems with no exaggeration, up to hundreds of millions of accounts). i.e. Even if the switch was done because someone unplugged a network cable and the primary never actually went down. The primary should be able to become the secondary once the cable is reattached (since the secondary is now the primary). Often the primary/secondary are in the same general location and network because it is more likely that one will go down due to hardware problems than because of natural disasters requiring a remote backup server. In these cases sync issues are not an issue and if they are, then the system is not adequate to your needs. I agree a DBA should investigate if for some reason a remote slave (placed remote in case of environmental disaster) wants to try to take over, but not for the very much more common local primary/secondary set up.

Re:Oracle vs Facebook?

[fuzzytv]

I love synonyms. And you are right, it is probably that I am thinking of (possibly because I always thought of synonyms as a form of permission since when I have used them we make sure table names never overlapped between schemas... or very little anyway). I don't like the search path method as I never seem to get it right... I would love to see synonyms in Postgres.

Well, it's a very different concept and if you're used to synonyms it's going to feel strange. I work with Oracle too and while I like synonyms I don't think they're somehow superficial to search_path (or vice versa).

Anyway, I also want to say that if you modify hbaconf to allow a DBA to create users from anywhere, it means you aren't limiting anyone via hbaconf from connecting to the database. In that case hbaconf is meaningless and not needed. Especially as all O/S's provide the same functionality (limiting access to the box).

I've just wanted to point out that the need to modify the pg_hba.conf is not very frequent and in some cases you may configure it so that you don't need to modify it at all. It's just a way to define access rules outside the database. Maybe I'm missing something but I still don't see a problem with this approach.

Where I've worked with HA, the volumes are so high that if you wait for a DBA to verify whether it should cut over or not, the company can lose literally millions of dollars (systems with no exaggeration, up to hundreds of millions of accounts). i.e. Even if the switch was done because someone unplugged a network cable and the primary never actually went down. The primary should be able to become the secondary once the cable is reattached (since the secondary is now the primary).

With the built-in replication, it's a bit difficult to turn primary to a slave (I'm not aware of a way/tool to do that and I suspect it's not possible, but maybe I'm wrong). With slaves this is possible, i.e. you may promote one slave to primary and switch the other one to follow it (instead of the old primary).

Often the primary/secondary are in the same general location and network because it is more likely that one will go down due to hardware problems than because of natural disasters requiring a remote backup server. In these cases sync issues are not an issue and if they are, then the system is not adequate to your needs. I agree a DBA should investigate if for some reason a remote slave (placed remote in case of environmental disaster) wants to try to take over, but not for the very much more common local primary/secondary set up.

I don't think there's a big difference between local and remote replication, although keeping a slave at a different location makes certain kind of problems more likely (I've seen cables nicely cut with a digger, data centers that went completely down because of failed ups, we had floods here a few years ago, etc.) but even with a single site you need two separate network paths (what if a switch fails?). And it's very easy to end with two machines thinking they're primary. That's a classical network partitioning problem and it may do a lot of harm ...

But sure - there are cases where automatic failover is probably the right thing to do, no doubt about that. I'm just saying it's very difficult to implement that in a sufficiently generic way - that's one of the nice things on PostgreSQL that you may configure it to your needs. The "unix mentality" of the development means there won't be any such "complete HA solution" anytime soon, but I do expect external packages to do the same thing (I've already mentioned repmgr) and some might move to contrib eventually.

Re:Oracle vs Facebook?

[theshowmecanuck]

The "unix mentality" of the development means there won't be any such "complete HA solution"

That is too bad, because from what I have seen, this is a really big show stopper for a lot of people. I really have tried to talk people on different projects to adopt Postgres over MySQL, and this is one of the more frequent arguments against Postgres (and is often the straw that breaks the camel's back). Ah, well... I can only hope in future people working on Postgres figure out that this is something that a lot of people want. Good thread... cheers.

GWT and appspot

[Anonymous Coward]

Quick re-write in GWT and host it on Google App Engine. Plenty of time left for the consumption of small woodland creatures.

I See An Old COBOL Programmer Dusting Off...

[littlewink]

his CODASYL network database engine in the backroom.

For high-throughput those mainframe databases still rule the world of business on IBM, FUJITSU, UNISYS and other platforms.

They can handle the throughput and maintain ACID compliance but they certainly are not relational. Perhaps Facebook should take a look. Indeed sometimes "a foolish consistency is the hobgoblin of little minds."

Re:I See An Old COBOL Programmer Dusting Off...

[swillden]

Doubtful.

Beyond a certain scale, ACID compliance becomes the problem, not the solution. The mainframe DBs like IMS do provide high throughput from the standards of single organization workloads, but web-scale workloads managing petabytes of data, performing tens or hundreds of thousands of transactions per second and requiring extremely high uptimes are a different beast entirely. To address those, you start with sharding to split the load (and replicating the shards to provide for high availability), but when you don't have a nice shardable key then you have to look at distributed systems that simply cannot provide all of the ACID guarantees without very expensive commit protocols which destroy the performance you're hoping to gain.

To satisfy all of the requirements, then, you have to start giving up, or at least delaying, the ACID guarantees. The most common approach is to discard immediate consistency in favor of eventual consistency, and there are some nice protocols that make it work well... but not on those mainframe DBs.

It's fun to take curmudgeonly pleasure in pointing out that the problems young whippersnappers are scratching their heads over were solved 40 years ago, but it's really not the case here.

Re:I See An Old COBOL Programmer Dusting Off...

[JAlexoi]

Mongo is web scale.

Re:I See An Old COBOL Programmer Dusting Off...

[swillden]

That video is content-free.

Re:I See An Old COBOL Programmer Dusting Off...

[komissar]

still LMAO! as former military i do admire the creative use of profanity.

2 Things..

[SuperCharlie]

First.. yes, they have a mega-ton of data but really... theres not *that* much to their nifty little web app..re-writing it from scratch with 100% hind sight would probably be not omfg difficult and second.. its a pretty good time to start a makeover since the wife just got in google+ and they will be loosing people by droves pretty soon..

If SQL is so old how come he still uses it?

[Anonymous Coward]

If SQL is so old how come he still uses it in his "new" VoltDB that he is trying to sell?

Stonebraker trapped in Stonebraker

[midom]

(reposting as a logged in user) I wrote a bit longer response to this:
stonebraker trapped in stonebraker 'fate worse than death'

I think I know a bit more about database situation inside FB than Mr.Stonebraker. Go figure.

Google tried Oracle for AdWords and came back

[Anonymous Coward]

"The AdWords system was initially implemented on top of the MySQL database engine. After the system had been launched, management decided to use Oracle instead. The system became much slower, so eventually it was returned to MySQL [3]. The interface has also been revamped to offer better work flow with additional new features, such as Spreadsheet Editing, Search Query Reports, and better conversion metrics."

http://en.wikipedia.org/wiki/Adwords#Technology

Re:And this opinion has nothing to do with the fac

[horza]

views, triggers, and stored procedures are usefull in conserving memory and optimizing performance with large tables if used properly

They are also what lock you into one particular RDBMS. Hence the whole "being tied to" alleged fiasco. I'm not saying they are a bad thing but they can prevent you from abstracting the code away from the database layer.

Phillip.

Awh, that is so cute

[SmallFurryCreature]

A nobody claims that a billion dollar company doesn't know what it is doing.

I am reminded of the last tech bubble and all the companies that happily put all their investor money in Sun servers and Oracle databases and never actually delivered a working product.

Facebook used PHP and MySQL and delivered the largest social networking site with millions of daily users and you get deadbeats saying they did it wrong. The guy above even wants to use an existing CMS or framework for something like Facebook. Talk about not getting it.

There are two kinds of people on this planet. Those that get things done and those that spend all their time talking about how they would they do it, someday.

It might well be that Facebook will need to replace a tech someday but they reached this size already with tech that a lot of armchair developers claimed couldn't do it but did. Doesn't that tell you something?

The biggest reason PHP and MySQL and Linux are so successful over other solutions is a simple one. They are used by people that want to get things done. Ask on a python forum about json and you get a discussiuon on json vs xml. On a BSD forum ask about FTP and you get a lecture on plain text passwords. MySQL just gives you the newly created key and doesn't want you to first learn to write a procedure for it. It is about getting stuff done vs talking about it.

There is a place for talking about all the latest gadgets but it is not where investors money is being burned trying to deliver a product. Just take a good hard look at all the new crap like python and ask yourself this, where is the forum and webshop software for it? Non-existent. Why? Because everytime a future chasing developer comes close to delivering something he is on to the next thing. Duke Nukem Forever development style.

Re:Awh, that is so cute

[elvis the frog]

I am reminded of the last tech bubble and all the companies that happily put all their investor money in Sun servers and Oracle databases and never actually delivered a working product.

Hah! that was fun. The best part was how much they paid the consultants, heheheh.

Re:Awh, that is so cute

[Billly Gates]

I am biased agaisn't MySQL because I remember 3.x didn't have triggers, views, transactions, inner joins etc. True I am more of a dreamer, but I am aware of it at least and want to change that. I am leaning more towards PostgreSQL due to transaction and ACID support so it is more tailored to my goals. It is interesting you brought up python as it is very popular and runs the glue behind Gnome and popular tools like add/remove program for Ubuntu. There was a famous win32 program tool that used it and I just can't remember the name? I know bittorrent is python based too and it is quite popular. It seems like a great tool for rapid prototyping to get stuff done simply with a good range of api's to choose from. It is quite popular, but it is interpretted and therefore sucks as serving web pages. Jython though would solve this running inside a JVM, but yes that is academic more than practical.

But like you said, the business leaders focused on the technology more than the goal to make money. This is what happens when simple undergraduates in computer science try to do a startup. This not to say that all non business majors or MBA's are morons, but many are just not the managerial or CEO type of person. They do not have the mindset nor the training to understand how financing, leadership, nor process engineering work. To me I view technology as a way to do a demo to an investor or make small money on the side first and as I grow I can then get a large scale Java or .NET program in later. It maybe a fun project but it needs to generate money. Other than that is is a cute portfolio for a web designer job otherwise.

Re:Awh, that is so cute

[portnoy]

A nobody claims that a billion dollar company doesn't know what it is doing.

Michael Stonebreaker is probably the best-known database researcher alive. He invented Ingres, the first relational database, and developed the core of what is now PostgreSQL. Since moving to MIT, he's continued to push some of the bounds of database technology.

Disagreeing with his conclusions here due to the success of Facebook is reasonable. But to call him a nobody exposes your ignorance, not his.

Re:And this opinion has nothing to do with the fac

[Anonymous Coward]

It's faster at small scale if you use a non ACID complaint data store (MyISAM). Use their acid compliant one (Innodb), as all real RDBMSs do, it's no faster than Postgres.

So yeah, if you don't want real data integrity, then sure, it can return the wrong data real fast. Awesome.

Two options

[Anonymous Coward]

Facebook has two options: add very large database support for MySQL (or MariaDB if thats your fancy), or switch to some other database. If they have been using MySQL all this time, then for most people MySQL might be big enough (considering the size of Facebook). Personally, I would prefer to see the former option, since if its open source, then you still keep the keys to your kingdom (you aren't beholden to someone else for your software, you can deal with bugs and problems on your schedule instead of someone elses, you aren't dictated as to what you can do with the software, you aren't forced to upgrade to more expensive versions even if the current software meets your needs (no forced end-of-life), and of course, no expensive licenses, royalties, and you can modify it on your own if you wish to better suit your needs. I'm building a set of web sites with MySQL (actually MariaDB), and if I have problems when I get to be the size of Facebook, I will worry then about scalability issues.

Success sometimes makes fools of us and our plans

[handy_vandal]

It's not a poor decision up front that got them here it's an impossible to predict growth. Success sometimes makes fools of us and our plans ....

Very true: mod parent +Insightful.

We see the same principle when some individual acquires Sudden Wealth, as for example by winning the lottery. Sudden Wealth -- it's every man's dream, right?

On closer inspection, Sudden Wealth is not a miracle cure for unhappiness or any other problem. Quite the contrary: Sudden Wealth brings new problems, new diseases of the soul.

Example: there is, I'm told, a self-help group (somewhere in America) whose members are Sudden Wealth lottery winners, who meet to share and discuss the problems brought on by Sudden Wealth, ranging from vague and inexplicable dissatisfaction, through family crises and grasping relatives and bitter divorces, all the way to abject misery and blatant death wish.

So too with corporations and other collective enterprises. Growth without preparedness can elevate a Mom 'n' Pop storefront operation to the skyscraper heights of corporate power ... but I would keep a watchful eye for embittered alcoholics and starry-eyed madmen among the board members and executives.

Maybe...

[sycodon]

Maybe this guy's problem is that Facebook HAS created such a large and successful business without paying Oracle millions of dollars or his company millions of dollars.

Kinda of sounds like that commercial for Scott trade where the Fat Cat broker is trying to keep his clients so he gets his fat commissions.

Re:Maybe...

[shutdown -p now]

Um, RTFA? It's not a pitch for Oracle. In fact, it's a rant against SQL in general. Quote:

In Stonebraker’s opinion, “old SQL (as he calls it) is good for nothing” and needs to be “sent to the home for retired software.” After all, he explained, SQL was created decades ago before the web, mobile devices and sensors forever changed how and how often databases are accessed.

Sounds like the usual NoSQL FUD, right? But wait, there's more here:

Stonebraker thinks sacrificing ACID is a “terrible idea,” and, he noted, NoSQL databases end up only being marginally faster because they require writing certain consistency and other functions into the application’s business logic.

Right... so what then? More magic buzzwords to the rescue!

But Stonebraker — an entrepreneur as much as a computer scientist — has an answer for the shortcoming of both “old SQL” and NoSQL. It’s called NewSQL or scalable SQL ... Pushed by companies such as Xeround, Clustrix, NimbusDB, GenieDB and Stonebraker’s own VoltDB, NewSQL products maintain ACID properties while eliminating most of the other functions that slow legacy SQL performance. VoltDB, an online-transaction processing (OLTP) database, utilizes a number of methods to improve speed, including by running entirely in-memory instead of on disk.

Now the article is pretty light on details regarding what is that "new" SQL, and Googling around doesn't really help. So far, to be honest, it sounds more like a bunch of DB makers have ganged together and came up with a nifty word to market their products against Oracle, DB2, MSSQL, Postgres etc - if it's "new" it must be good, right?

Re:Maybe...

[maxwell demon]

They are doing everything in RAM? Well, have fun at the next power failure. :-)
Maybe the solution would be to invest in SSDs?

Re:Maybe...

[JMJimmy]

It's a database that operates in memory instead of on the hdd... other than that there's nothing special about it. The big problem is that that's no a solution, if you have a power failure you're screwed. It fails the so called "ACID properties" because it's not durable. The problem to me is that you've got 2 layers doing the same task - the file system and the database. The database should be it's own file system running on a separate portion of the hdd.

Re:Maybe...

[shutdown -p now]

Well, there surely must be more to it than that. The guy touts "new SQL" as being much more scalable (horizontally) than traditional RDBMS. I don't see how putting the DB into RAM would do that.

Re:Maybe...

[JMJimmy]

I'm sure they've tweaked it to solve certain problems but I guarantee you there are trade offs for each and every tweak. A lot of companies and talented people have been working with various databases for years and there's no perfect solution, it's always about trade offs.

Sacrifice accuracy for speed and increase the servers to create redundancy for errors or preserve accuracy at the cost of speed and increase the servers to handle the load. The former gets used more often than the latter because the latter ideally should have some redundancy as well.

Re:Maybe...

[mwvdlee]

AFAIK, Most DB's can be configured to run mostly from RAM.
RAM-only DB's might have some issues with tables that exceed RAM size though.

Re:Maybe...

[RockDoctor]

They are doing everything in RAM? Well, have fun at the next power failure. :-) Maybe the solution would be to invest in SSDs?

Maybe the solution would be to invest in UPS?

FTFY.

UPS is not a sexy or new technology. And that makes it inappropriate?

Actually, thinking about it a little more, the reduced power demands and higher speeds of SSDs might make the UPS requirements less stringent, but for any high-availability system, UPS is an essential part of the mix.

Wikipedia can and epSos.de can too.

[Anonymous Coward]

MySQL Rulez !!!

If you look at people who use PostgreSQL, you will see that they are not successful.
Myspace uses Postgre. Who are they now ?

Re:Wikipedia can and epSos.de can too.

[midom]

I don't think MySpace used PG - they were MS SQL shop (though I hear there were attempts to switch to other engines)

Half the story. FB MySQL - 500k transactions/sec

[Zoson]

Not mentioned is that Facebook's implementation of MySQL uses a custom engine and can perform about 500,000 transactions a second with only 1.2Gb/sec worth of bandwidth. A far cry from 'regular' MySQL and performs better than many enterprise products like Postgre.

That's one of the primary beauties of MySQL, the engine can be changed to suit your needs.

MySQL - Oracle Migration?

[Doc Ruby]

Doesn't Oracle have a tool that will analyze a MySQL schema, (optimize), generate an Oracle schema, query MySQL and populate Oracle? Even for pretty large live databases (~20GB in RAM) that need some cycles to update the new DB to sync with the old DB then cutover, this seems like a highly automatable and deterministic procedure, at least to get started. Then DBAs to optimize the new schema more, using the superior Oracle features.

This seems like exactly why Oracle bought MySQL AB: to be the default upsell path for MySQL instances that have outgrown MySQL. Isn't this something that comes cheap or free with an Oracle database?

If not, this seems like a success-defining opportunity for EnterpriseDB to do the opposite: use Oracle's promotion of MySQL but hard path to Oracle to save MySQL users from their Oracle destiny with free/open migration tools.

Re:MySQL - Oracle Migration?

[Anonymous Coward]

Ha ~20GB in RAM a large database? Oh my, I wish I had the cute little scalability concerns you do...

Re:MySQL - Oracle Migration?

[Doc Ruby]

Hmm, an Anonymous Coward condescendingly bragging about the size of their database, with no facts or any other content.

Get a grip on something other than your penis.

What's better on a site as big FB?

[hunangarden]

So this guy Stonebraker thinks Facebook is running too many servers or something, or its just too complex, whatever. Seems to be working for me as a user so not sure what the problem is.

Is there something that can scale to support something as big as Facebook and be done using fewer servers with less complexity? What site has actually proven that? Was it because of the underlying db engine or just a better design from the get go?

This quote: "“old SQL (as he calls it) is good for nothing” and needs to be “sent to the home for retired software.” Is just flame bait (of course I'm taking it though).

His only real point is this: "the problem with MySQL and other SQL databases is that they consume too many resources for overhead tasks (e.g., maintaining ACID compliance and handling multithreading) and relatively few on actually finding and serving data. ". He has some engine he thinks does it better (VoltDB), which does a lot of stuff in memory, similar to memcached, but built into the engine. Good idea. Oracle DB has in memory tables as well.

Has anyone put this VoltDB to the test? Is it better?

Re:And this opinion has nothing to do with the fac

[Sxooter]

Stonebraker abandoned first Ingress as hopelessly broken to build Postgres. Which he then abandoned as hopeless broken to move on to various projects like the more recent VoltDB. He left Postgres a VERY long time ago, and hasn't been involved in the project since well before pg 7.0 hit the scene.

Re:Isn't MySQL an Relational Database Management S

[MightyMartian]

If they're using memcache being fed from a database, then it doesn't matter what database they use.

Reply from a former FB engineer

[prostoalex]

Reply from an engineer who worked at Facebook 2007-2011.

Re:Reply from a former FB engineer

[KermodeBear]

For those who don't want to follow the link:

Evan Priestley, Worked at Facebook from 2007-2011
46 votes by Ricky Elrod, Tom Cook, Andy Bartholomew, (more)
Obviously, Stonebraker's competing product, VoltDB, would have been a much better solution. Didn't you read the article? The series of outlandish, unsubstantiated claims it presents make a clear, convincing argument that MySQL is dead and VoltDB is a strictly superior alternative.

Design, design, design

[biodata]

It sounds as though the author blames the problem on too small a transaction scope, in other words they are carrying out a commit on every single Like response from a site visitor. They could queue such non-essential transactions in the middleware and commit en bloc using a queue that commits chunks at a time, or commit them to an unindexed shard that then propagates to the other shards. He says too many resources are being used in one part of the process (data integrity) and too little in another (queries). Index much? Rebalance hardware towards the instances supporting queries? These things do seem soluble by some effort in system design and engineering. I get that the rollout is tricky to test under load and all that, but if your database grows you need to expect to engineer it, there is no such thing as scalability, different designs are optimal at different scales. All this is independent of DBMS. Is a message of the article just that Facebook had no idea they were going to grow so big so didn't design their middleware and backend with that in mind? Of course that happened. As for the book, another DBMS? We have some thanks.

Re:Half the story. FB MySQL - 500k transactions/se

[HuckleCom]

At the butt-rape cost of switching to Oracle, they could hire an extra small army of programmers to turn MySQL into FBSQL and give the haters the middle finger (Hell, they're already there from what I understand).

Re:Stonebraker trapped in Stonebraker

[HuckleCom]

Why the hell isn't this modded up?

Seems to me, one needs a room full of people

[PotatoHead]

anyway!

So then, why not use the cheaper / open DB, and build out the thing with that room full of people?

Fair question, particularly given the extreme size in this case.

If We Say This Loud Enough?

[Bing Tsher E]

If we say this loud enough, could it maybe (please?) Zuck up the Facebook IPO. I'd love nothing more than to know that the suits who've spent so much loot on getting control of that particular group of servers were out on the curb looking for food.

SQL

[Anonymous Coward]

If they do indeed need to upgrade, it is SQL, going to a higher performance SQL database probably is not that big of deal.

Ahh the irony

[Anonymous Coward]

The irony of this little battle going on here that all the MySQL haters are posting to /. which uses MySQL as a database as does Twitter and Wikipedia. Priceless!

Re:Ahh the irony

[Anonymous Coward]

Another Irony, MySQL is owned by...wait for it....ORACLE!

Inversion of control?

[AC-x]

Surely they must have, at some point, refactored their code to use IOC so they can just replace all their MySQL data access classes with another data store, no?

Re:Inversion of control?

[julesh]

Yes.

The point: FB don't think MySQL is a problem. Only the article author does. Author suggests replacing MySQL with an in-memory database, and is presumably ignorant of quite how many TB of data Facebook handles.

Re:Inversion of control?

[fuzzytv]

Separating all the data access into a DAO layer might make the switch easier, although it may be a significant amount of code and it may even require a rewrite of some parts of the application. Anyway IoC has nothing to do with it - IoC is mostly about instantiation and lifecycle management, not about proper layering.

Progress

[Anonymous Coward]

Or, as they now call it: OpenEdge ABL, now there is a really nice RDBMS. An absolute joy to work with.

MySql itself is an abstraction

[Anonymous Coward]

You know, for all the hatred of MySql's scalability, it's not really MySql that's at fault. It's the storage engine. MySql is actually a pretty lightweight administrative framework for routing queries to storage engines. In what it does, it does it pretty well, except the permissions part (which sucks). The real meat of MySql is Innobase on the back end. But there are many backends to MySql like MyISAM, BDB (cluster), Percona, etc. And lately there's some activity with Hadoop as a backend, which would have probably fit their needs perfectly.

But the problem is that they decided to roll their own syncronous transaction mechanism on top of innobase by patching the shit out of it. The idea is that they have datacenters on both sides of the country and if you make an update to your "wall" on the west coast servers, it needs to post to the east coast servers as well before you can serve up subsequent wall pages from the east coast. The stuff that links it to all your friends is probably NOT a relational DB, but the publishing system is. So anyway, they patched and hacked mysql to kinda do this and it's just not stable. People are getting tired of the slowdowns and delays, especially when other sites are doing it better.

So, they will most likely have to rewrite that part if they move to a new backend that does the distributed synchronous stuff. The beauty of moving to a different backend is that it is totally transparent to the client. But Facebook is screwed because they didn't try to use the "standard" MySql interface, they rolled their own. I'm sure they have some other extraordinary problems as well, with the type of site they are. Sell your Facebook stock! ;)

Another garbage article

[Anonymous Coward]

Oracle, DB2, postgres and MSSQL have more issues than MySQL for huge databases. I've worked huge sites on all of them and MySQL is best! Instead of sharding they need to optimize queries better, decrease data maintained and archive data a little better if they are having issues. Sharding is a temporary measure.
    Facebook was always a little unstable, they need to hire some better db engineers if this is their issue. Moving to a new DB is TRIVIAL. I'm ported huge sites from all sorts of dbs from one to another.

And MySQL hates babies and kittens!

[DragonHawk]

Geez, GooberToo, did a MySQL developer kill your father or something? You've posted two giant rants about how MySQL is so unsuitable for anything that it can't possibly work for any serious project. You make it sound like simply installing MySQL causes a server to immediately explode.

You *are* aware that Facebook, Slashdot, Wikipedia, and many other sites use MySQL, yes? Maybe there are better choices (more likely, there are different tradeoffs, but whatever), but MySQL works well enough to power some of the most popular websites in the world. Proof by existence that what you claim is inaccurate.

Re:And MySQL hates babies and kittens!

[Anonymous Coward]

but whatever), but MySQL works well enough to power some of the most popular websites in the world

And some people spend a great effort just to keep it this way - time they actually could spend on more useful things.

Re:And MySQL hates babies and kittens!

[GodfatherofSoul]

Hmmm...MySQL doesn't support foreign keys so that would explain all the dupes.

Re:And MySQL hates babies and kittens!

[fuzzytv]

MySQL does support FKs if you're using InnoDB engine. And how's that related to duplicate items? That's a UNIQUE constraint ...

Lack of discipline and data modeling

[WaffleMonster]

When a system grows beyond its practical design limits lets just blaim our choice of tools rather than the architect and their data model.

As low as my opinion of MySQL is I consider the entire argument to be a false choice.

Re:And this opinion has nothing to do with the fac

[JAlexoi]

He however still is in a very good relations with the community.

Re:And this opinion has nothing to do with the fac

[JAlexoi]

That's just his response to NoSQL.

Re:Stonebraker trapped in Stonebraker

[HuckleCom]

Mod this up!

Re: VoltDB [was: Reply from a former FB engineer]

[kangsterizer]

There's a comment about VoltDB (is the whole thing a commercial thing for VoltDB? XD)
Anyway, I looked up VoltDB and they provide additional software for a fee, software that is also distributed under the GPL v3.
Wondering why they don't just offer it for free and only ask payment for the service. It's only a matter of time before the software is distributed freely otherwise.

http://voltdb.com/products-services/voltdb-editions-pricing

Re:Stonebraker trapped in Stonebraker

[JAlexoi]

Learn to identify marketing speak. Stonebreaker has been at it for at least 4 years now.

How hard is it to write portable code?

[mark-t]

I mean, really... is it that difficult to hide all your dependencies on a particular system (such as utilizing database-specific features) into methods that you call from elsewhere so that you don't end up rewriting your whole application from scratch when you change the underlying architecture? This should be done WHILE YOU ARE WRITING the damn thing in the first place... it doesn't matter if you never expect it to get ported elsewhere, because the simple truth is that if other people, particularly people you do not personally know, are ever going to use the software, then you really just never know... and don't ever kid yourself otherwise. Write your code in layers... and the main application should never have to be aware of what the underlying system actually is. Optimize later.... not while you develop.... and in cases where performance is absolutely critical, hide any system dependencies from the actual application, either via function calls, or even macros. At most, you will have to rewrite those functions, but the application itself, which for larger applications will tend to be over 70% of the code, will not have to be changed.

... And the small amount of additional time you spend doing it right the first time for each of dozens of projects can pay for itself quite easily many thousands of times over when just one of your projects has to be ported.

Re:How hard is it to write portable code?

[shutdown -p now]

Some database features are pretty fundamental and hard to encapsulate. For example, MVCC versus traditional locking have wildly different behavior when races occur, and if you test on an MVCC implementation and it runs fine, you can end up with deadlocks (with a severe perf impact due to having to break them) on a different system.

Luckily, there has been a convergence on MVCC - which really is the more sane model - in the last decade or so.

Why, What is not working

[Anonymous Coward]

Just asking the question. It seems to be working fine..

Re:Isn't MySQL an Relational Database Management S

[AmberBlackCat]

I think the real lesson here is you can't assume MySQL is useless and unsuitable for a major website just because Slashdotters hate it and declare it unsuitable for a major website. Even in the midst of news that its being used successfully on the biggest website in the world, Slashdot still says it can't work.

OK, I'll admit it

[hey!]

If I were about to die and the only way I could save myself was locking in my employer to a huge, mission critical MySQL installation, I'd prefer the MySQL fate to death.

Call me weird.

Don't bother...

[D-OveRMinD]

Don't worry Facebook. You don't have to rewrite anything from scratch. Google already has, so don't bother. Mark? Sell while you can dude...sell while you can.

All too common

[Anonymous Coward]

Right, it's all too common on startups that reach 600 millon users... Once we reach Facebook's size we might start worrying about MySQL performance.

Re:And this opinion has nothing to do with the fac

[Anonymous Coward]

Practically any non mysql database has all of the listed things described. What makes it proprietary is not the SQL but the stupid proprietary api's and protocols for each RDBMS that co-exist with each SQL statement. It is not simple SQL at all and SQL Server vs Oracle data adapter objects and the the very api's itself are then called upon and finally in there is the SQL statement if you use a language like C# or Java. Yuck.

A few other ways to use it is nothing. I personally think all non free RDBMS hate SQL and secretly want there own API, protocol, and even their own language sdks. Witness Oracle's Java tools (Not the ones from Sun) as an example of tying you into their expensive products.

Re:And this opinion has nothing to do with the fac

[Anonymous Coward]

MySQL has been faster that PostgreSQL for years, it doesn't have as many features, but it is **fast** !!

Fast - and ugly.
MySQL is only faster if you don't need all the ACID functionality in your database.
Everything else - PostgreSQL is way faster and performs better than MySQL.

Give Stonebreaker a Chance

[Anonymous Coward]

I mean he's just the guy behind Ingres, Postgres, and Vertica. And his new company VoltDB, which I haven't used, can either put up or shut up.

But I doubt very seriously he's a troll. He's a legend with a strong opinion and he's willing to put his time and energy behind his thoughts instead of just spouting off about them.

Re:Give Stonebreaker a Chance

[guruevi]

VoltDB is a commercial solution (yeah it has a free 'demo' but for large systems it expects you to pay) so pushing something like it as the be-all, end-all of some perceived, unknown problem is at best a sales tactic.

I have heard a lot from several No/NewSQL folks and it's great to push large amounts of specific data in and out of it but it's a solution looking for a problem most of the time. If you spend a lot of time designing and normalizing your data structures (large well-designed data warehouses) it is a great solution but in most cases that's not what developers want or need. They just need to store some values in a relation to each other quickly and get it out quickly. MySQL (or any other SQL flavor) will do for that. For example most posts on Facebook would do much better in performance with a NoSQL solution but it would be pretty hard to get eg. relationship trees or commercial value out of that data. Facebook 'fixed' the SQL problem with a heavy-caching middle layer (and if data gets lost, it's not important). Most companies can 'fix' their SQL problems by throwing some cash at it - it's easier (and usually cheaper) to just add some SSD's to your SQL system than having to move and shard your data into a farm.

if ACID is the problem

[jsprenkle]

mysql will let you choose a storage mechanism that doesn't pay the overhead of ACID. Sounds like the same old tired **** I've heard over and over. "Just rewrite xxx using xxx and it will solve all the problems." Sorry dude, it's a difficult problem and there aren't any easy answers.

Re:And this opinion has nothing to do with the fac

[Rufty]

MySQL has been faster that PostgreSQL for years, it doesn't have as many features, but it is **fast** !!

/dev/null is even faster, but I wouldn't use that for data storage, either.

The Bell System billing.

[Anonymous Coward]

Astonishingly, a few minutes with saint google gives a clue:

http://www.freepatentsonline.com/4468728.html

I suspect that the Bell System invented everything themselves, and did a remarkably good job.

Ever hear of Bell System outages? When I grew up the phone always worked. Always, always.

The problem with databases is...

[Glasswire]

... that the customer for a SQL (or other) db is not the end user. Except for freakish entities like Facebook that write their own application layer that uses the db, most users have a commercial application which is really what the db is serving. For instance, an application tier software vendor will support MS-SQL or Oracle or MySQL or DB2 (or some combination of these) depending on end user preference. But if an end user decided to be clever and wants a next gen database architecture, they can't decide that for themselves, they need to ask their app vendor to please use and support the db we want. The app tier vendor doesn't particularly want to incur the costs of re-architecting the app to support a different db ESPECIALLY (horrors!) if you want a non-SQL db which will REALLY make the re-engineering painful and create two codes steams - one for you funky odd customers and one for the sensible ones that want to stay on an SQL db.
So, you need a value proposition for app vendors to make this huge change occur. Don't try saying that the overall solution will perform better - from the app vendor's point-of-view, customers can fix that by throwing lots of hardware at it and (golly!) that also means more app tier system (cpu, core, socket or whatever) licenses for the app vendor. So existing app vendors are not likely to do this.
This is only going to happen when the performance of app solutions (probably wholly new ones) that will use non-SQL dbs is so massively superior that insurgent app vendors threaten to displace the incumbents. Don't hold your breath for this though. There are lots of fine application solutions out there with many many person-years of code which are solving real problems and for a large enterprise application, simply having a much faster db backend won't overcome lack of features so the insurgent app vendors will have to be superior there too. Tough job.
So. I'd bet on inertia (never a risky proposition) and assume that for large databases, non SQL dbs (or even new SQL entrants in the dbs market) are not going to make much headway over the next 5 years of so.

Not only with MySQL

[unsolicited]

Any sophisticated software will have these issues as it matures.

What's his point?

[Anonymous Coward]

"...predicament is all too common among web startups that start small and grow to epic proportions."

A "common" predicament? Just how many web-whatevers of epic proportions are there? Or is this based on a sample size of 1 (facebook)?

This article may just as well be interpreted as "there's no reason not to use SQL (including MySQL) in your next web-startup, the chances of growing to a point where SQL becomes a problem are next to none."

Is this common?

[tkrotchko]

" all too common among web startups that start small and grow to epic proportions"

How often has this happened?

before oracle

[vonshavingcream]

when we heard at work that oracle "might" be buying MySQL ... we switched to postgres and never looked back. I wish most hosting companies and software developers would add support for postgres

Another paid for slashvertisement

[Anonymous Coward]

Why do I still come here...

I see this as more a success for MySQL

[Anonymous Coward]

How is this a failure? Oh My God the mighty facebook isn't running on some uber expensive database like Oracle. This reads like an Ad for VoltDB.

Re:And this opinion has nothing to do with the fac

[Anonymous Coward]

In fairness, /dev/null makes a strong guarantee of what it'll do with your data.

Hubris. Here, and in article.

[sloth jr]

I find it bemusing the "should've done X" arguments being made here and in the referenced article.

Facebook is bigger than anything you've ever done, or likely ever will do, and despite Stonebraker's impressive cred, bigger than anything he's ever done, or will do. That it works as well as it does is enormously impressive. Articles like "oh, just throw Oracle at it, or DB2 could handle it with a couple dozen machines" are completely ludicrous. Is it that easy? Then build it. Throw down or shut up.

thought fb doesn t use mysql anymore

[Anonymous Coward]

strange, on the fosdem a facebook developer told us, that they nearly migrated everything from mysql to h base

Re:Isn't MySQL an Relational Database Management S

[HappyPsycho]

And most financial institutions of the nature you are describing don't do everything in real time, thats why there are close off times and most of the fees, etc are added after in batches. This applies to almost all transactions save cash which requires little to no verification.

One of the few institutions I know that deal with such large transaction volumes are stock exchanges and just like banks they close at some point and the real heavy processing happens at night. Same applies to central banks / regional centers for almost any financial institution, I am not aware of any that processes everything in a central facility.

Once nice thing most financial institutions have going for them is that the data is already localized, it is rare that someone in another country wants to see your bank account. What most banks do is have a simple hierarchy to keep the overall load down (the transaction is passed to the appropriate branch for processing).

obvious solution, I hope this has been said before

[databaseadmin]

mySQL is open source. Facebook has so much money and time and design invested in its current db implementation. It seems to me the cheapest, and most straight forward thing to do, is just fix their issues in the mySQL base. How much could that cost? I'll bet less than 1% the cost of a db system change.

god... hope this is true!

[Anonymous Coward]

I looked at the SQL Injection techniques earlier this week -- just to see if (1) I had a reasonable understanding of tech and (2) was there really big money to be made here ? I'll leave it to you, my SQL heavyweight friends to decide for yourselves. However, I think it is certainly an area of technology worth looking at. Stick with Linux and a really good intrusive language, like Python. Most operations, even financial ones, are running at minimal security. Follow Goldman Sachs lead, rob the country blind now!

DocLazier

Re:Stonebraker trapped in Stonebraker

[zhuzhu]

(reposting as a logged in user) I wrote a bit longer response to this: stonebraker trapped in stonebraker 'fate worse than death'

I think I know a bit more about database situation inside FB than Mr.Stonebraker. Go figure.

Are you a FB DBA. Mr.Stonebraker is a DBA in FB.

If FB the Movie taught me anything...

[DarthVain]

It's that Zuckerberg can fix this by the weekend...

no problems here!

[hesaigo999ca]

If anyone knows, you can have a max size usage of a database, but that does not mean you are limited to it, you can have a database of databases technically....i can use a database to help me manage all my databases in order to avoid overloading any one single database from having too many records....this is done in many companies that have excessive accounting, and drop the older years off in their own separate databases, and use a master database to know where to look...for path info etc...

the only rewrite that facebook would need is to add the extra length and code to alter any reports, queries to include a db alias, in order to pinpoint where the info resides...but not the whole thing, and certainly not everywhere...i could even inject text into connection strings on the fly, in order to avoid rewritting any code at all, if you actually had low level programers knowledged enough about such things...sort of like the malware packets that get injected into dlls etc....

Postgres Troll Hates MySQL.

[Anonymous Coward]

News at 11.

why not double-down?

[Anonymous Coward]

I'm not a fan of mysql but since its an open-source system, I don't understand why Facebook wouldn't put time and money in to transforming in to an ideal rdbms for their specific purposes.

Having worked with Oracle and ms for years in the private and public sector, I know that the primary reason IT management go with commercial software is so that its easier to point a finger at someone outside the company when something goes wrong. The software itself is seldom going to suit your needs and you'll end up customize it anyway (for a major player like facebook).

I think Google has been quite successful because they've taken this approach. It's often seen as risky by management but if you have the right people that can get the job done right-its well worth the investment.