6 ms·

SQL on Distributed GPUs now available on AWS Marketplace

qeternity 10y ago
This just seems like something riding GPU hype. We run a medium sized Memsql cluster, and get better performance on larger tables with more complex joins than they do in their demo video...and we do this for much cheaper than the lowest g2 instance + AMI. Our data is quite narrow, so fits in RAM quite well, but I would bet that even Citus would fare quite well against this.
- obstinate 10y ago
  I suppose it depends on what operations you do on your table and what your query stream looks like. It's hard to imagine compute being the bottleneck for most SQL workloads . . .
  - Wheaties466 10y ago
    On a Postgresql query before version 9.6 is limited to a single CPU core. Depending on the amount of data it has to query it absolutely can take forever.
    - qeternity 10y ago
      Even now, it's only multicore when doing full table scans (iirc...)
      - jasonmp85 10y ago
        True (see here: https://www.postgresql.org/docs/9.6/static/parallel-plans.html https://www.postgresql.org/docs/9.6/static/parallel-plans.ht... ), but in PostgreSQL 10 there are Parallel Bitmap Heap Scans and Parallel Index Scans (see here: http://rhaas.blogspot.com/2017/03/parallel-query-v2.html http://rhaas.blogspot.com/2017/03/parallel-query-v2.html ).
    - user5994461 10y ago
      Consider a paid database if that's what you need. It's not new that postgre has some limitations compared to the SQL servers/Oracle.
  - qeternity 10y ago
    For OLAP use cases, CPU is most often a bottleneck...
    - user5994461 10y ago
      Doesn't OLAP implies branching/conditions? GPUs are terrible at evaluating if.
      - arnon 10y ago
        OLAP is implied as a catch-all for analytics in this case
  - threeseed 10y ago
    SQL is an overloaded term these days. There are plenty of SQL queries happening on non-database platforms e.g. Spark, Impala all of which are entirely CPU bound.
- felipe_aramburu 10y ago
  If your problem can fit in RAM then this is probably not something that would help you. This solution is for people who are looking for massive scale. Also you are running a query from memory. We can run from memory as well and get much better throughput. The new version of BlazingDB also incorporates skip data which can improve join performance by several orders of magnitude for complex joins.
  - qeternity 10y ago
    What are you talking about? I am talking about terabytes of RAM in the cluster. I would love to see some benchmarks of terabyte datasets. Everything I saw from your demo video was under 1b rows. Hardly qualifies as massive scale.
    - felipe_aramburu 10y ago
      When we think about TB of data we do not want to store that in RAM. So if you are looking at a 10TB dataset. You may be willing to have 10TB of ram to fit it in but we aren't trying to solve that problem. We try to solve the problem of reducing the amount of information that has to be pulled from disk to be analyzed by having fine grain partitioning and using data skipping. We are optimizing the compression and decompression of the data to reduce file i/o bottleknecks. So your 10TB dataset can be analyzed with a 100GB of RAM. I agree that video is not very compelling. We are giving a talk at GTC that will show you something 3 orders of magnitude more interesting than that. https://gputechconf2017.smarteventscloud.com/connect/search.ww#loadSearch-searchPhrase=&searchType=session&tc=0&sortBy=dayTime&p=&i(40701)=109194 https://gputechconf2017.smarteventscloud.com/connect/search....
      - ruw1090 10y ago
        So blazing db mainly uses gpus to speed up compression/decompression? How do gpus help with partitioning and data skipping?
        felipe_aramburu 10y ago
mi100hael 10y ago
This is my first time hearing about BlazingDB. Looks like it's a pretty new application. Anyone have any experience actually running it in production that can speak to its real-world performance, reliability, etc?
makmanalp 10y ago
See also: https://www.mapd.com/ https://www.mapd.com/
- felipe_aramburu 10y ago
  We love what MapD is doing. We operate in different spaces. We have no visualization platform nor intention of making one. Instead of trying to solve problems in GPU RAM we focus on solving problems that require disk based storage. So whereas MapD will be able to perform faster queries on problems that fit in GPU Ram we are focused on problems that require orders of magnitude more storage than what can fit into GPU RAM. Think dumping a datalake into a database to make it all queryable.
  - makmanalp 10y ago
    So more out-of-core stuff. Sweet, thank you!
ganfortran 10y ago
No benchmark? I don't really think this hold against Redshift.
- felipe_aramburu 10y ago
  You can try out the community version and comapre it to a small redshift instance.
  - tycho01 10y ago
    I was curious, what's different about the community edition? It didn't really tell on the pricing page.
    - felipe_aramburu 10y ago
      The community edition works with a single gpu and does not allow horizontal scaling.
- tycho01 10y ago
  Would be interested to see this as well. Looks like TPC-DS would a big benchmark in SQL, though apparently aimed toward transaction processing... maybe more relevant when they add update/delete then.
pokoleo 10y ago
> The main admin login credentials are simply “admin” with your AWS assigned Instance-ID as the password. There's got to be a better way to do this... right?
- felipe_aramburu 10y ago
  This was suggested to me by AWS marketplace. They said it needed to be one click which meant I could receive user input from pepole loading the AMI through something like SSH. If you want to change this you can reach out to us on https://docs.blazingdb.com/discuss https://docs.blazingdb.com/discuss
cwyers 10y ago
Go to their documentation website. Search for "ACID." 0 results found. I'm shocked to find that you can make massive performance gains in a relational database if you make no guarantees whatsoever that data will actually be stored.
- tyingq 10y ago
  From https://docs.blazingdb.com/blog/welcome-to-blazingdb https://docs.blazingdb.com/blog/welcome-to-blazingdb "BLAZINGDB IS NOT: Built for transactions. Try to run your webapp backend in BlazingDB and we'll scream STOP! At the very least, we'll find your audacity impressive." There's no support for INSERT, UPDATE, or DELETE. There's a proprietary way to ingest data. No way at all to delete or update rows as far as I can see. So, I'm not quite sure what the popular use cases are here. Fast queries of relatively static data?
  - cwyers 10y ago
    > So, I'm not quite sure what the popular use cases are here. Fast queries of relatively static data? Yeah, and... their "impressive" benchmarks (which they don't publish near enough information about to be anything like impressive, and I'm sorry, but the idea that Postgres is something like seven times as fast as MySQL on a straight-up JOIN is not something I am going to believe without evidence) look a lot impressive if you add the time it takes to transfer your data out of an actually useful database to this read-only replica for querying. What is this intended to do? And what do GPUs have to do with it?
    - felipe_aramburu 10y ago
      Relatively static is correct. The data you bring into blazingdb is normally brought in ready to be operated on with the understanding that it will not change on a regular basis. So there are many datasets that already exist, do not change, and are absolutely enormous that people want to analyze. GPUs allow us to quicky compress and decompress data to reduce file i/o bottleknecks, perform massive transformations much more quickly than on cpu, give us the computational capacity to find the best ways to optimize the layout of the information to take the most advantage of data skipping. The intention here is to provide you access to arbitrary large amounts of data with a horizontally scalable database solution that has orders of magnitude more computational capacity than a cpu based solution.
nl 10y ago
For those puzzled, the use case for this is rapid, interactive data exploration via reporting tools.
Moter8 10y ago
Why did you [author] add these tiny gifs into the blogpost? They change enough to distract from the text and aren't clickable / are too small to actually understand. (Apparently only the first gif is sorta-zoomable)

This just seems like something riding GPU hype. We run a medium sized Memsql cluster, and get better performance on larger tables with more complex joins than they do in their demo video...and we do this for much cheaper than the lowest g2 instance + AMI. Our data is quite narrow, so fits in RAM quite well, but I would bet that even Citus would fare quite well against this.

obstinate 10y ago
I suppose it depends on what operations you do on your table and what your query stream looks like. It's hard to imagine compute being the bottleneck for most SQL workloads . . .
- Wheaties466 10y ago
  On a Postgresql query before version 9.6 is limited to a single CPU core. Depending on the amount of data it has to query it absolutely can take forever.
  - qeternity 10y ago
    Even now, it's only multicore when doing full table scans (iirc...)
    - jasonmp85 10y ago
      True (see here: https://www.postgresql.org/docs/9.6/static/parallel-plans.html https://www.postgresql.org/docs/9.6/static/parallel-plans.ht... ), but in PostgreSQL 10 there are Parallel Bitmap Heap Scans and Parallel Index Scans (see here: http://rhaas.blogspot.com/2017/03/parallel-query-v2.html http://rhaas.blogspot.com/2017/03/parallel-query-v2.html ).
  - user5994461 10y ago
    Consider a paid database if that's what you need. It's not new that postgre has some limitations compared to the SQL servers/Oracle.
- qeternity 10y ago
  For OLAP use cases, CPU is most often a bottleneck...
  - user5994461 10y ago
    Doesn't OLAP implies branching/conditions? GPUs are terrible at evaluating if.
    - arnon 10y ago
      OLAP is implied as a catch-all for analytics in this case
- threeseed 10y ago
  SQL is an overloaded term these days. There are plenty of SQL queries happening on non-database platforms e.g. Spark, Impala all of which are entirely CPU bound.
felipe_aramburu 10y ago
If your problem can fit in RAM then this is probably not something that would help you. This solution is for people who are looking for massive scale. Also you are running a query from memory. We can run from memory as well and get much better throughput. The new version of BlazingDB also incorporates skip data which can improve join performance by several orders of magnitude for complex joins.
- qeternity 10y ago
  What are you talking about? I am talking about terabytes of RAM in the cluster. I would love to see some benchmarks of terabyte datasets. Everything I saw from your demo video was under 1b rows. Hardly qualifies as massive scale.
  - felipe_aramburu 10y ago
    When we think about TB of data we do not want to store that in RAM. So if you are looking at a 10TB dataset. You may be willing to have 10TB of ram to fit it in but we aren't trying to solve that problem. We try to solve the problem of reducing the amount of information that has to be pulled from disk to be analyzed by having fine grain partitioning and using data skipping. We are optimizing the compression and decompression of the data to reduce file i/o bottleknecks. So your 10TB dataset can be analyzed with a 100GB of RAM. I agree that video is not very compelling. We are giving a talk at GTC that will show you something 3 orders of magnitude more interesting than that. https://gputechconf2017.smarteventscloud.com/connect/search.ww#loadSearch-searchPhrase=&searchType=session&tc=0&sortBy=dayTime&p=&i(40701)=109194 https://gputechconf2017.smarteventscloud.com/connect/search....
    - ruw1090 10y ago
      So blazing db mainly uses gpus to speed up compression/decompression? How do gpus help with partitioning and data skipping?
      - felipe_aramburu 10y ago

mi100hael 10y ago

This is my first time hearing about BlazingDB. Looks like it's a pretty new application. Anyone have any experience actually running it in production that can speak to its real-world performance, reliability, etc?

makmanalp 10y ago

See also: https://www.mapd.com/ https://www.mapd.com/

felipe_aramburu 10y ago
We love what MapD is doing. We operate in different spaces. We have no visualization platform nor intention of making one. Instead of trying to solve problems in GPU RAM we focus on solving problems that require disk based storage. So whereas MapD will be able to perform faster queries on problems that fit in GPU Ram we are focused on problems that require orders of magnitude more storage than what can fit into GPU RAM. Think dumping a datalake into a database to make it all queryable.
- makmanalp 10y ago
  So more out-of-core stuff. Sweet, thank you!

ganfortran 10y ago

No benchmark? I don't really think this hold against Redshift.

felipe_aramburu 10y ago
You can try out the community version and comapre it to a small redshift instance.
- tycho01 10y ago
  I was curious, what's different about the community edition? It didn't really tell on the pricing page.
  - felipe_aramburu 10y ago
    The community edition works with a single gpu and does not allow horizontal scaling.
tycho01 10y ago
Would be interested to see this as well. Looks like TPC-DS would a big benchmark in SQL, though apparently aimed toward transaction processing... maybe more relevant when they add update/delete then.

pokoleo 10y ago

> The main admin login credentials are simply “admin” with your AWS assigned Instance-ID as the password. There's got to be a better way to do this... right?

felipe_aramburu 10y ago
This was suggested to me by AWS marketplace. They said it needed to be one click which meant I could receive user input from pepole loading the AMI through something like SSH. If you want to change this you can reach out to us on https://docs.blazingdb.com/discuss https://docs.blazingdb.com/discuss

cwyers 10y ago

Go to their documentation website. Search for "ACID." 0 results found. I'm shocked to find that you can make massive performance gains in a relational database if you make no guarantees whatsoever that data will actually be stored.

tyingq 10y ago
From https://docs.blazingdb.com/blog/welcome-to-blazingdb https://docs.blazingdb.com/blog/welcome-to-blazingdb "BLAZINGDB IS NOT: Built for transactions. Try to run your webapp backend in BlazingDB and we'll scream STOP! At the very least, we'll find your audacity impressive." There's no support for INSERT, UPDATE, or DELETE. There's a proprietary way to ingest data. No way at all to delete or update rows as far as I can see. So, I'm not quite sure what the popular use cases are here. Fast queries of relatively static data?
- cwyers 10y ago
  > So, I'm not quite sure what the popular use cases are here. Fast queries of relatively static data? Yeah, and... their "impressive" benchmarks (which they don't publish near enough information about to be anything like impressive, and I'm sorry, but the idea that Postgres is something like seven times as fast as MySQL on a straight-up JOIN is not something I am going to believe without evidence) look a lot impressive if you add the time it takes to transfer your data out of an actually useful database to this read-only replica for querying. What is this intended to do? And what do GPUs have to do with it?
  - felipe_aramburu 10y ago
    Relatively static is correct. The data you bring into blazingdb is normally brought in ready to be operated on with the understanding that it will not change on a regular basis. So there are many datasets that already exist, do not change, and are absolutely enormous that people want to analyze. GPUs allow us to quicky compress and decompress data to reduce file i/o bottleknecks, perform massive transformations much more quickly than on cpu, give us the computational capacity to find the best ways to optimize the layout of the information to take the most advantage of data skipping. The intention here is to provide you access to arbitrary large amounts of data with a horizontally scalable database solution that has orders of magnitude more computational capacity than a cpu based solution.

nl 10y ago

For those puzzled, the use case for this is rapid, interactive data exploration via reporting tools.

Moter8 10y ago

Why did you [author] add these tiny gifs into the blogpost? They change enough to distract from the text and aren't clickable / are too small to actually understand. (Apparently only the first gif is sorta-zoomable)