SQL on Distributed GPUs now available on AWS Marketplace(blog.blazingdb.com)
blog.blazingdb.com
SQL on Distributed GPUs now available on AWS Marketplace
https://blog.blazingdb.com/sql-on-distributed-gpus-now-available-on-aws-marketplace-c2b80fe012aa
36 comments
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.
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.
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.
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....
So blazing db mainly uses gpus to speed up compression/decompression? How do gpus help with partitioning and data skipping?
BlazingDB uses gpus to speed up transformations, predicates, running predicates on skip data metadata, gpu accelerated join algorithms. In terms of partitioning we use both to generate the data skipping meta data on the partitions and to reorder data around so that we can minimize the number of comparisons joins will likely require or reduce the number of partitions that need to be operated on. At large scale reorganizing information becomes very expensive the gpus allow us to crunch those numbers very quickly.
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 . . .
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.
There are plenty of SQL queries happening on non-database platforms e.g. Spark, Impala all of which are entirely CPU bound.
For OLAP use cases, CPU is most often a bottleneck...
Doesn't OLAP implies branching/conditions? GPUs are terrible at evaluating if.
OLAP is implied as a catch-all for analytics in this case
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.
Depending on the amount of data it has to query it absolutely can take forever.
Even now, it's only multicore when doing full table scans (iirc...)
True (see here: 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 ).
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.
For those puzzled, the use case for this is rapid, interactive data exploration via reporting tools.
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.
From 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?
"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?
> 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?
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?
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.
Might be good to get that "read+append only" message more upfront. Redshift has update, delete, etc, and you're making direct comparisons.
You do push the "data warehouse" message, but it may not be clear that anything other than append would require reloading the entire database.
You do push the "data warehouse" message, but it may not be clear that anything other than append would require reloading the entire database.
Update / Delete is forthcoming. We have a version of it working but have not pushed it yet because it is part of a broader set of changes that have not been made availble yet.
The blog post compares this to Redshift, so this is for OLAP workloads, not OLTP.
In all honesty we get very few questions about ACID compliance from users and customers but I can go into how Blazing handles this. When you are importing data that data is always being imported into a temporary store where we will compress and process that data to get it ready for being added to the database. When you run a query you create a snap shot of what information is available at the beginning of the query. When new information is compressed and ready to be made available to query we bring it in and any query that starts AFTER this has been made available will be able to query that new found data. Update is not in place it is rather a Delete / Insert operation and is still in beta. When information is loaded into the system you do not receive a response that it was successfully loaded until it has been completely written to disk, compressed, and made available for querying. Anything short of this leads to that temporary data being wiped and an error returned to the load data infile command.
> 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?
There's got to be a better way to do this... right?
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
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 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?
See also: https://www.mapd.com/
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.
So more out-of-core stuff. Sweet, thank you!
No benchmark? I don't really think this hold against Redshift.
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.
You can try out the community version and comapre it to a small redshift instance.
I was curious, what's different about the community edition? It didn't really tell on the pricing page.
The community edition works with a single gpu and does not allow horizontal scaling.