3 ms·

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

by 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.
    - tyingq 10y ago
      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.
      - felipe_aramburu 10y ago
        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.
lern_too_spel 10y ago
The blog post compares this to Redshift, so this is for OLAP workloads, not OLTP.
felipe_aramburu 10y ago
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.

by cwyers 10y ago

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.
  - tyingq 10y ago
    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.
    - felipe_aramburu 10y ago
      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.

lern_too_spel 10y ago

The blog post compares this to Redshift, so this is for OLAP workloads, not OLTP.

felipe_aramburu 10y ago

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.