×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Facebook Trapped In MySQL a 'Fate Worse Than Death'

timothy posted more than 3 years ago | from the cake-or-death-or-trapped-in-mysql dept.

Databases 509

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."

Sorry! There are no comments related to the filter you selected.

Commercial databases (2, Interesting)

drolli (522659) | more than 3 years ago | (#36704210)

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.

Nah, this is standard practice (1)

Colin Smith (2679) | more than 3 years ago | (#36704264)

Delegate scalability downwards. Throw hardware at the problem.

Re:Nah, this is standard practice (1)

Z00L00K (682162) | more than 3 years ago | (#36704620)

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:Commercial databases (1, Interesting)

cgeys (2240696) | more than 3 years ago | (#36704274)

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 (1)

Relayman (1068986) | more than 3 years ago | (#36704308)

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

Re:Commercial databases (0)

Anonymous Coward | more than 3 years ago | (#36704370)

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 (1)

mad_minstrel (943049) | more than 3 years ago | (#36704404)

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 (4, Insightful)

jjohnson (62583) | more than 3 years ago | (#36704492)

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 (4, Informative)

laffer1 (701823) | more than 3 years ago | (#36704576)

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 (1)

dgatwood (11270) | more than 3 years ago | (#36704664)

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 (2)

Surt (22457) | more than 3 years ago | (#36704590)

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 (3, Interesting)

Billly Gates (198444) | more than 3 years ago | (#36704540)

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 (1)

Anonymous Coward | more than 3 years ago | (#36704582)

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 (1)

mcavic (2007672) | more than 3 years ago | (#36704670)

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

Re:Commercial databases (2)

svick (1158077) | more than 3 years ago | (#36704374)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704382)

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 (2)

Loconut1389 (455297) | more than 3 years ago | (#36704592)

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

Re:Commercial databases (0)

Anonymous Coward | more than 3 years ago | (#36704418)

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 (1)

Loconut1389 (455297) | more than 3 years ago | (#36704602)

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 (2)

Dr.Dubious DDQ (11968) | more than 3 years ago | (#36704500)

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 (2)

kimvette (919543) | more than 3 years ago | (#36704552)

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 (2)

kimvette (919543) | more than 3 years ago | (#36704624)

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 (1)

ppanon (16583) | more than 3 years ago | (#36704648)

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

Re:Commercial databases (1, Insightful)

GooberToo (74388) | more than 3 years ago | (#36704628)

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 (1)

tgv (254536) | more than 3 years ago | (#36704434)

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 (1)

cyber-vandal (148830) | more than 3 years ago | (#36704616)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704494)

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 (4, Insightful)

NeoMorphy (576507) | more than 3 years ago | (#36704514)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704596)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704662)

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 (1)

mcavic (2007672) | more than 3 years ago | (#36704652)

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.

Still their fault (3, Informative)

nurb432 (527695) | more than 3 years ago | (#36704212)

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 (1)

jjetson (2041488) | more than 3 years ago | (#36704286)

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

Re:Still their fault (1)

Anonymous Coward | more than 3 years ago | (#36704352)

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 (1)

Haedrian (1676506) | more than 3 years ago | (#36704482)

3) They're not made of money.

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

Re:Still their fault (2)

Tridus (79566) | more than 3 years ago | (#36704510)

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

Re:Still their fault (1)

Anonymous Coward | more than 3 years ago | (#36704558)

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 (1)

jank1887 (815982) | more than 3 years ago | (#36704486)

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 (1)

ppanon (16583) | more than 3 years ago | (#36704668)

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

Still their fault ;) (1)

NSN A392-99-964-5927 (1559367) | more than 3 years ago | (#36704572)

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 ;) (2)

jjetson (2041488) | more than 3 years ago | (#36704654)

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

Isn't MySQL an Relational Database Management Sys? (1)

Anonymous Coward | more than 3 years ago | (#36704220)

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?

Re:Isn't MySQL an Relational Database Management S (0)

Anonymous Coward | more than 3 years ago | (#36704270)

Google would love to disagree with you.

The O in NOSQL stands for "only" (1)

tepples (727027) | more than 3 years ago | (#36704324)

"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 [wikipedia.org] in a non-relational manner.

Keep on backpedalling, you silly NoSQLers. (5, Interesting)

Anonymous Coward | more than 3 years ago | (#36704508)

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:Isn't MySQL an Relational Database Management S (1)

jjohnson (62583) | more than 3 years ago | (#36704338)

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.

Re:Isn't MySQL an Relational Database Management S (1)

laffer1 (701823) | more than 3 years ago | (#36704630)

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 (1)

sco08y (615665) | more than 3 years ago | (#36704638)

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.

Or in other words... (0)

Anonymous Coward | more than 3 years ago | (#36704222)

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

Repeated meme? (0)

Anonymous Coward | more than 3 years ago | (#36704232)

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

Obligatory Clue (1)

Dachannien (617929) | more than 3 years ago | (#36704240)

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

Re:Obligatory Clue (0)

Anonymous Coward | more than 3 years ago | (#36704520)

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

"Fate Worse Than Death" says man selling... (1)

Anonymous Coward | more than 3 years ago | (#36704244)

...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 (0)

Anonymous Coward | more than 3 years ago | (#36704246)

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 (1)

Loconut1389 (455297) | more than 3 years ago | (#36704632)

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

I thought about going cheap for my startup (1)

Billly Gates (198444) | more than 3 years ago | (#36704256)

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 (1)

cyber-vandal (148830) | more than 3 years ago | (#36704650)

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.

NoSQL? NewSQL? (1)

medv4380 (1604309) | more than 3 years ago | (#36704682)

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.

Subject line should read... (2)

arglebargle_xiv (2212710) | more than 3 years ago | (#36704258)

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

Re:Subject line should read... (0)

Anonymous Coward | more than 3 years ago | (#36704328)

Well, not beyond 500 million users apparently.

PostGreSQL is far better than MySQL (2)

darthium (834988) | more than 3 years ago | (#36704502)

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.

Abstraction layer (1)

fysdt (1597143) | more than 3 years ago | (#36704276)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704368)

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

mod .0p (-1)

Anonymous Coward | more than 3 years ago | (#36704294)

fear the reaper bot4 believed that a BSD box that

Migration is the cure !!! (0)

Anonymous Coward | more than 3 years ago | (#36704314)

Oracle databade should definitely work fine !!!

MySQL: Hosting nightmare (0)

Anonymous Coward | more than 3 years ago | (#36704334)

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 (1)

Anonymous Coward | more than 3 years ago | (#36704384)

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

Re:MySQL: Hosting nightmare (0)

Anonymous Coward | more than 3 years ago | (#36704426)

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 (1)

Billly Gates (198444) | more than 3 years ago | (#36704610)

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

It's a myth (1)

Anonymous Coward | more than 3 years ago | (#36704340)

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 (1)

edxwelch (600979) | more than 3 years ago | (#36704560)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704634)


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.

Umm Cassandra? (1)

Anonymous Coward | more than 3 years ago | (#36704354)

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" (5, Insightful)

michaelmalak (91262) | more than 3 years ago | (#36704360)

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" (0)

Anonymous Coward | more than 3 years ago | (#36704546)

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.

EPic! (1)

M0j0_j0j0 (1250800) | more than 3 years ago | (#36704362)

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

And this opinion has nothing to do with the fact . (1)

AftanGustur (7715) | more than 3 years ago | (#36704376)

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** !!

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

Lennie (16154) | more than 3 years ago | (#36704522)

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

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

Anonymous Coward | more than 3 years ago | (#36704530)

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

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

Billly Gates (198444) | more than 3 years ago | (#36704678)

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.

Oh dear (1)

Dunbal (464142) | more than 3 years ago | (#36704380)

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

Re:Oh dear (0)

Anonymous Coward | more than 3 years ago | (#36704666)

Jealous much, faggot cunt?

Oracle...Kool-Aid...I'm a moron (0)

Anonymous Coward | more than 3 years ago | (#36704408)

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.

"Good problems to have" (0)

Anonymous Coward | more than 3 years ago | (#36704424)

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 (0)

Anonymous Coward | more than 3 years ago | (#36704430)

"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 (0)

Anonymous Coward | more than 3 years ago | (#36704478)

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

Contractors will get rich doing the rewrite (1)

mikein08 (1722754) | more than 3 years ago | (#36704432)

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

Re:Contractors will get rich doing the rewrite (1)

Lennie (16154) | more than 3 years ago | (#36704538)

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

Different view point (1)

Anonymous Coward | more than 3 years ago | (#36704438)

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.

Peanut Gallery (0)

Anonymous Coward | more than 3 years ago | (#36704448)

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.

Successful Troll is Successful (5, Insightful)

tyler_larson (558763) | more than 3 years ago | (#36704480)

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.

Easy - Just Migrate to Oracle (1)

littlewink (996298) | more than 3 years ago | (#36704504)

That should do the trick, eh?

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

so mysql works (0)

Anonymous Coward | more than 3 years ago | (#36704526)

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.

looks like facebook is doing just fine... (5, Insightful)

tommeke100 (755660) | more than 3 years ago | (#36704534)

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

Delusional editorialism! (1, Troll)

GooberToo (74388) | more than 3 years ago | (#36704554)

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.

migration.... (1)

metalmaster (1005171) | more than 3 years ago | (#36704566)

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.... (0)

Anonymous Coward | more than 3 years ago | (#36704640)

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.

Michael Stonebraker & VoltDB (4, Informative)

solferino (100959) | more than 3 years ago | (#36704660)

The guy in the article [wikipedia.org] 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 [wikipedia.org] , based on the 'NewSQL' ideas touched on in the article, is Free Software licensed under the GPLv3.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?