Achieving 10Gbps Line-rate Key-value Stores with FPGAs [pdf]
0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com
0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com
Given a 2x quad core box and a decent network card, I'm pretty sure you could approach or exceed 10Ge without requiring original research or an insane amount of code, especially as record size increases. Software could at least could compete on throughput, although the paper also indicates latency benefits using the FPGA design.
With anything that provides stable pointers to values like LMDB it should be possible to output to the network extremely efficiently. One thing to keep in mind with LMDB is that it's performance isn't so great with purely random keys such as SHA hashes. I'm fooling around on something similar myself targeting this use, and so far critbit tries are looking good (though I have yet to implement benchmarks I'm confident of).
I haven't dug through the OP paper yet, but my guess is that while the performance numbers are interesting, the cost of the FGPA itself would make it less desirable unless you really did need the latency performance/predictability.
"Many well-known web-sites deploy distributed in- memory caches, which are implemented with standard DRAM on a large array of x86 servers, to reduce access load on databases"
then a single server with an FPGA card on it is going to be a lot cheaper than an array of x86 servers. Plus I would imagine that real-estate in a data centre is another significant cost and having one server with an attached FPGA would also be an advantage in this situation
Compare all that to a $2k 1U Xeon with 32GB of ram and dual 10GbE and the prices aren't that dissimilar. Also one is a research project while the other is a commodity a phone call and fedex away.
My guess would be you'd need the FPGA design in high volume for the costs to work out. So it'd be good as an appliance product for a vendor, but unless you're google/facebook huge trying to build this sort of thing yourself would likely be a boondoggle. The exception is the latency performance: you'd have trouble duplicating that with the commodity server design. So if you're doing HFT or somesuch maybe this is interesting again.
A middle road might be something like the Fast Array of Wimpy Nodes design but with a lot more dram and hacking up the kernel to get you true zero copy io with minimal syscall overhead.
In fact, I've designed systems that go quite a bit beyond simple key-value stores e.g. wire speed polygon indexes with spatial operators. On modern hardware, if the system is efficient, the "put" side of a key-value store should only require a core or two to saturate the wire; the rest of the cores can be dedicated to saturating the outbound "get" side. It is dead simple to do at 1GbE; at 10GbE it does require some skill at high-performance algorithm design but I've seen it done many times.
What's strange is that they used an FPGA at all. The entire industry for network processors is moving the opposite way.
You could do this – heck, probably even twice this – easily on a processor with an integrated NIC like the TileGX or the Broadcom XLP. Is there a market for these things? Should I quit my job and make this product?
So it's more like a cache than a key/value store? Nothing wrong with that but to me a key/value store implies that data isn't lost in the case of a hash collision. Pretty cool stuff nonetheless.
Key/value lookups are something that's done by existing networking hardware very well. There are existing merchant-silicon chipsets that do this on-die very well.
There was once an evolving market for "network processor units" but it looks like that all cooled down. IIRC, there was an effort to do something akin to a database lookup on an NPU, but the tradeoff between flexibility and what the NPUs could provide wasn't amenable to the kind of work required to bring those solutions to market.
It could act like a super super fast memcached.