You forget bandwidth. With local servers it is free. ^_^

Storm does not have 100's of jars of dependencies, nor does it require much memory to run. In fact, it's quite straightforward to spin up a Storm cluster (see https://github.com/nathanmarz/storm/wiki/Setting-up-a-Storm-... ) and Storm has a local mode where you can develop/test topologies on your local mode completely in-process.

No.

Don't bother replying to this guy. Read his comment history. He's either a professional troll or mentally ill.

There are two big ideas in REST. First one is in realm of system engineering, and second one in the realm of programming paradigms.

Using HTTP[S] protocol allows you to pass through almost every heterogeneous network. That means any highly restricted and protected (I prefer the term 'misconfigured') network of a cell phone provider, who blocks everything else, but http.

You can survive in that crazy hotel's or airport's wi-fi network, especially located in developing countries, which is a mess of cheap Chinese ADSL-modems and no-name Wi-Fi access-points with settings no one cares about.

It also means that you can pass through all these almost useless corporate firewalls made by idiots (why firewall if you have all those windows with IE6 boxes running by users with admin rights?).

The second big thing is about statelessness and using URI as a namespace - representing data as a file-system hierarchy and using one standard protocol everywhere - it is almost the same ideas which lays on the foundation of this enlightening Plan9 system. No xml, no BS, just names and simple standard protocol - 9P.

Together, those two ideas are enough to forget about all that proprietary crap, not because it is proprietary, but because REST is more general, flexible and easy to implement concept.

Yet another self-promotion article. Oh, we stuff data in memory and then when it is time to write changes on disk everything got frozen! MySQL suck, buy our solution! Nice guys.)

First, it is useless to store data in memory if you want them be committed into disk storage. The general idea here isn't about switching to some new version of mysql or SSD disks, it is about to realize that you have a data-flow inadequate for your one-server architecture.

Second - check-point intervals should be adjusted to your actual data-flow, which means they should be executed often enough. If there is situation of almost constant checkpoint - non-stop data writes, that is the sign that you need to consider sharding/multi-server solution.

The hints that there must be no other disk activity on the same hardware volume or any swapping in OS, I suppose, are obvious. People who have a /var/log and /var/db on the same volume are idiots.

There are also good idea to use one file per table storage and put a data and physical logs on a separate hardware volumes (links are your friends). One raid-X volume that fits all is a quite naive solution. Raid isn't a guaranty of reliability. Replications to a back-up servers are.

Third, when you test your configuration before put it into production, you should tune-up your servers to perform with data and log syncing, and then figure out appropriate buffer sizes and checkpoint intervals. Then, in production, when you're experiencing an increasing flow of queries, you may choice to switch into different syncing strategy and/or more often but a little bit faster checkpoints.

Configuring mysql with huge buffers and no sync means lack of understanding the basic concepts, self-delusion and misuse of software and hardware. ^_^

"Yet another self-promotion article. Oh, we stuff data in memory and then when it is time to write changes on disk everything got frozen! MySQL suck, buy our solution! Nice guys.)"

You got this part all wrong. He explicitly said that 'their solution' is unlikely to do any better. This is a real problem.

It isn't just FB's problem, and it is not becoming a new Yahoo (it is becoming a new MySpace). ^_^

The vision should be a little bit broader (and scarier to those invested in it and its clones) - OK, every teenager in the world already has a FB page and uploaded some photos of herself and exchanged some stupid messages with so-called friend. Wow-impulse has faded away. Now what? ^_^

Don't even try to say 'the next facebook' - it will be 'just another social site', af FB was for MySpace or Livejournal's addicts. ^_^

What it could be? Ok, something like a cam on your clothes to broadcast 24/7 via some G5 GSM directly to some datacity which sends it back to your personal 3D movie hall (forget Youtube with a that crappy flash player)?

No, I don't think so. The time of the mass-exhibitionism in the net is, it seems, over. ^_^

In the good old times, when sky was more blue and trees were taller, there was two almost distinct approaches to use SQL database. They call them OLTP and Data Warehouse. Some vendors, such as Informix or IBM even offered a different products for those two segments. The firs one, as one can understand from its name, is about fast and reliable online transaction processing, which means triggers and stored procedures and loads of small queries, mostly inserts or updates. Now all those no-fsync options and noSQL and mem-caching solutions solve similar problems their own way. You can have a thousands of writes and, if your system never crashes, with some data consistency (and forget about triggers) In old good times Informix Dynamic Server was the answer.

Data Warehousing is all about JOINS, big JOINS. Or that thing they call it data-cubes. In that case you need query optimizer, lot and lots of buffers, data partitioning and several layers of caches. You also should use stored procedures, because it is a good way to structure and manage your code, same way modules work for other languages. So, you know, that old lovely DB2.

Even in old times, people who claims that there is a solutions that fits both cases were considered crazy. That is why no sane person considered MSSQL (leave alone MySQL) as something other that a taste-less joke.

Nowadays people forgot about designing in terms of data flows. Everything starts with installing some framework, such as Spring+Hibernate, Rails or some PHP crap. They forgot that not tables itself, but queries (which type, how often) to them is what matters, that indexes optimized for actual query flow is what performance of a server is all about, and that actual structure of tables (and corresponding indexes) must be adapted/redesigned for that particular production flow of data. That was a DBA's job.

Today some people believe that they can eliminate smart but costly engineers (DBAs or sysadmins) by some software which is marketed to them as Easy, Smart, Fast, Zero-thinking or whatever - ready meals for a mediocre crowds. OK, if you're building a 20 pages web-site for a 100 visitors per day, that might work - you can save some money and time, but, if it is a industrial or internet-scale solution, there is no chance that you can run Rails or say Code Igniter crap in production without huge changes or total redesign. No fucking way.

So, all those specialized solutions, such as memcached, redis, membase, mongoDB are about dealing with flows of technical data, such as AJAX queries from UI, logs, authorization requests, chats, photos and other unimportant things, OR about building a huge distributed cache layer above actual data store. But, of course, you cannot build a Data Warehouse out of it. (Or invent a complete different approach to dealing with data, such as map/reduce).

So, ORM is anti-pattern? It is not efficient? Ridiculous. It is just broken by design. ^_^

You need not to be a genius to immediately notice that doing i-- inside a for loop is.. OK just not very smart. ^_^

Changing a loop counter in a loop is always a bad idea? You must implement only very simple algorithms.

There are more than one loop expression. Idiomatic usage of a for loop doesn't include changing counter variable in a loop's body. ^_^