3 ms·

This is kind of amazing. I have often really wondered what would happen if you basically created a directed acyclic graph/dataflow for data processing (for exa

This is kind of amazing. I have often really wondered what would happen if you basically created a directed acyclic graph/dataflow for data processing (for example, how Apache Spark distributes processing/operations), and then accelerated the operations using physical implementations in FPGAs. After all, a SQL query, when optimized, is essentially a graph of operators that data flows through. You do have to pass your data through the accelerator to get the processing... which potentially means huge volumes of data moving into this physical processing layer (probably can be done in parallel over a network at high speed) - I would assume this is why shared memory bandwidth was a problem. This would provide some really interesting options though - imagine feeding data from two disparate databases (say, Oracle and SQL server) in a data flow into this thing - now you have accelerated cross database joins (as long as you can handle the bandwidth and processing on the way in). There was this post before on HN previously lamenting the state of tools for working with FPGAs, and my related comment wondering if what Baidu has done here was possible: - https://news.ycombinator.com/item?id=9408881 https://news.ycombinator.com/item?id=9408881 - https://news.ycombinator.com/item?id=9410160 https://news.ycombinator.com/item?id=9410160

gopalv 10y ago
> which potentially means huge volumes of data moving into this physical processing layer You get to cheat at that, because the naive implementation loads too much data, while most of it is going to drop off at the filter level. The ideal TPC-DS schema stores data partitioned by date and maintains a lookup index by item, store and clustered by store's state. In a database organized like that, neither part of the Query-3 item.i_manufact_id = 436 or dt.d_moy=12 should actually look at every row in the data-set in brute-force fashion - you get to skip massive parts of the data by just inspecting the index or going to the specific date partition and do it much faster than a naive C++ full-scan. However, if you were limited to a full-load + scan, this would really be killer to have a columnar format which can be handled by an FPGA. The really interesting quote in the blog (for me) is > the data for the queries is pushed to the accelerator card in columnar format (which is blazingly fast for queries) I sure could use FPGA filters for columnar data ... even after I've done all my indexing, since I can't index down AND clauses or OR clauses - unlike a traditional CPU, the FPGA will be able to evaluate my entire condition in one sequential flow instead of check + branching.
anonetal 10y ago
There is quite a bit of work on this topic in Databases, and stream processing is one of the primary use cases they identified (in particular, if you can put the FPGA device between the network and the CPU, it works out quite well). This is one of the early papers: http://dl.acm.org/citation.cfm?id=1687730 http://dl.acm.org/citation.cfm?id=1687730 This one appears to be a more recent survey paper by some of those authors: http://www.morganclaypool.com/doi/abs/10.2200/S00514ED1V01Y201306DTM035 http://www.morganclaypool.com/doi/abs/10.2200/S00514ED1V01Y2... As someone else pointed out, this was also one of Netezza's differentiation.
- sixdimensional 10y ago
  That book likes like an excellent resource. Thank you for sharing.
daxfohl 10y ago
This is all high-memory stuff though, so in the physical world it's all limited by cache speed and memory bus speed. And that generally is limited by branch prediction. So branch prediction is the area where a custom FPGA for SQL could see improvements. Hard-wiring operators is a minor improvement but really not much because compared to memory access it's not the bottleneck.

gopalv 10y ago

> which potentially means huge volumes of data moving into this physical processing layer You get to cheat at that, because the naive implementation loads too much data, while most of it is going to drop off at the filter level. The ideal TPC-DS schema stores data partitioned by date and maintains a lookup index by item, store and clustered by store's state. In a database organized like that, neither part of the Query-3 item.i_manufact_id = 436 or dt.d_moy=12 should actually look at every row in the data-set in brute-force fashion - you get to skip massive parts of the data by just inspecting the index or going to the specific date partition and do it much faster than a naive C++ full-scan. However, if you were limited to a full-load + scan, this would really be killer to have a columnar format which can be handled by an FPGA. The really interesting quote in the blog (for me) is > the data for the queries is pushed to the accelerator card in columnar format (which is blazingly fast for queries) I sure could use FPGA filters for columnar data ... even after I've done all my indexing, since I can't index down AND clauses or OR clauses - unlike a traditional CPU, the FPGA will be able to evaluate my entire condition in one sequential flow instead of check + branching.

anonetal 10y ago

There is quite a bit of work on this topic in Databases, and stream processing is one of the primary use cases they identified (in particular, if you can put the FPGA device between the network and the CPU, it works out quite well). This is one of the early papers: http://dl.acm.org/citation.cfm?id=1687730 http://dl.acm.org/citation.cfm?id=1687730 This one appears to be a more recent survey paper by some of those authors: http://www.morganclaypool.com/doi/abs/10.2200/S00514ED1V01Y201306DTM035 http://www.morganclaypool.com/doi/abs/10.2200/S00514ED1V01Y2... As someone else pointed out, this was also one of Netezza's differentiation.

sixdimensional 10y ago
That book likes like an excellent resource. Thank you for sharing.

daxfohl 10y ago

This is all high-memory stuff though, so in the physical world it's all limited by cache speed and memory bus speed. And that generally is limited by branch prediction. So branch prediction is the area where a custom FPGA for SQL could see improvements. Hard-wiring operators is a minor improvement but really not much because compared to memory access it's not the bottleneck.