3 ms·
Could it be that facebook complete lack of innovation is due to them being stuck for years with the same issues on the db ?
by bsaul 13y ago
Could it be that facebook complete lack of innovation is due to them being stuck for years with the same issues on the db ?
- ddorian43 13y agoaren't they using many other dbs for different stuff, like hbase for messagess, some other for graphing etc
- bsaul 13y agoI don't know. That was an honest question. The original post seemed to mention facebook being stuck on mysql as a big issue. So that made me wonder if that could be a reason why the only useful feature facebook released was facebook chat, and it was more than two years ago.
- threeseed 13y agoYou don't really understand how popular websites work do you ? Their users don't want innovation. They want a stable platform with moderate and infrequent changes.
- ddebernardy 13y agoBest I recollect, FB is quite innovative in the data center. Also, it would be nice of you to step in and contribute to an open source database engine if your expertise is such that you can dismiss what FB did with them as lacking innovation. I'd wager they'll be all ears open for your explanation how to do multimaster replication and distributed joins efficiently while remaining ACID compliant.
- bsaul 13y agoI wasn't talking about facebook technical innovations, but rather end-user new features, sorry i wasn't clear.
- VLM 13y agoThis is an example of an interesting problem with "innovative" databases which is vaguely like the OSI networking model The first layer is business need, without one there is no point. You need to start here. Facebook is empty here, so no need for innovation and no concrete ideas about what to innovate about, means no point discussing arch or later tech. The next layer is architecture. Do you need joins? Well then use them. Do you need transactions, or not? Basically a big key value store? The final step / layer is tech. You can do a boring key value store on mysql just fine. There might be a slightly faster or cheaper software choice. Or maybe not. Or maybe some nosql thing fits the architecture. This is a huge problem I see with "the whole market is going to be disrupted totally and only I know how" type articles. So I herd cats around a quasi-geographic database at work (not directly geographic, but related). The only way to change its scale or business needs is to modify the geography of the United States or dramatic demographic changes that would even theoretically take generations to breed the eventual customers. So layer one can't change for that job. The arch doesn't seem like it can be improved very much. So layer two can't change for that job. Therefore because layer one and layer two are static, layer three will utterly change completely. Because he says so. LOL