felipe_aramburu

12 ms·

61.
by felipe_aramburu 9y ago
Depends on what you mean by throughput. In terms of ram bandwidth on GPU this is very high. PCIE is a different matter. That is still the big limiter on many boxes. Ensuring you have enough cpu pcie lanes to drive all of the graphics cards
62.
by felipe_aramburu 9y ago
So if there are already gpu nodes being used for a machine learning workload then having blazing running on the same cluster woud allow you to share those resources. So you could run blazingdb on the same cluster as a machine learning workl
63.
by felipe_aramburu 9y ago
1) We are focused on the data lake. We love MapD, they are doing kick ass stuff, we are focused more on operating on information from disk and from cloud storage services like s3 or hdfs implementations. 2) We read parquet files into our ow
64.
by felipe_aramburu 10y ago
The community edition works with a single gpu and does not allow horizontal scaling.
65.
by felipe_aramburu 10y ago
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 re
66.
by 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.
67.
by 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 o
68.
by felipe_aramburu 10y ago
You can try out the community version and comapre it to a small redshift instance.
69.
by 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 wher
70.
by 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:&
71.
by 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
72.
by 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 compre
73.
by 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 be
74.
SQL on Distributed GPUs now available on AWS Marketplace(blog.blazingdb.com)
53 points by felipe_aramburu 10y ago|36 comments
75.
Rise of the techno-phoenix. SQL is alive, and incredibly fast on GPUs(blog.blazingdb.com)
4 points by felipe_aramburu 10y ago|0 comments
76.
by felipe_aramburu 10y ago
At Blazing we also build GPU db and have always loved what this project (Alenka) is doing. First of all when you are talking about I/O bound which I/O are you talking about? Do you mean from disk? From RAM? There are many ways of
77.
by felipe_aramburu 10y ago
You could try BlazingDB if what you are interested is the gpu powered SQL component. There is a free community edition available here: https://docs.blazingdb.com/docs/quickstart-guide-to-blazingd... You can install thi
78.
by felipe_aramburu 10y ago
We are an Analytical database not a transactional one. We would love to integrate with more tools like spark alas we are a small team of 5 working on the engine and making the engine itself has taken most of our time to date.
79.
by felipe_aramburu 10y ago
We have seen many. Big joins are our best use case. Joins are hard for many databases to optimize when they have not seen them before or are not "expecting" them like when you let amazon know how to partition your different tables
80.
by felipe_aramburu 10y ago
Yes data dependent branch serialzizes the execution of the gpu stream processing units (this is not true for amd actually). Yes it sucks operating on string sometimes on gpu and we don't always do it because of this. But we are ignorin
81.
by felipe_aramburu 10y ago
Seems kind of like a blanket statement to make if you have not investigated this for yourself. So let me give you some example use cases. Decompression for processing: We can roundtrip decompress 8 byte integers RRleDeltaRle 4x on an AWS g2
82.
by felipe_aramburu 10y ago
You bring up some really good points about badnwidth to the data and how many of our competitors have gotten ridiculously high benchmarks. We do NOT cache on the gpu, EVER. The reason why is because most of our columns are much too large to
83.
by felipe_aramburu 10y ago
We are not shipping all of the data as a whole to the gpu. We are going to be releasing some whitepapers that explain this in more detail but lets get a few things clear. Data is sent to the gpu compressed since it is compressed when it is
84.
by felipe_aramburu 10y ago
I am the CTO of blazingDB. The data is not stored in GPU or even RAM. We operate from the disk though we we will cache information in RAM when we have plenty of it available.