Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tmostak
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
18 ms
·
121.
▲
by
tmostak
10y ago
By your logic the entire in-memory CPU database space is wasted energy. I'm sure every analyst who wants to do some filters, group bys, joins and subqueries over a big dataset wants to write custom code (in C/C++ to be fast!), hop
122.
▲
by
tmostak
10y ago
MapD | San Francisco (city) | Backend Developer, Frontend Visualization Developer, Technical Marketing Director (ONSITE) MapD ( https://www.mapd.com ) is a Google Ventures/Nvidia/Verizon Ventures/Vanedge/In-Q-T
123.
▲
GPU Hardware Powers Big Data Analytics
(informationweek.com)
8 points
by
tmostak
10y ago
|
0 comments
124.
▲
by
tmostak
10y ago
This is cool. Of course the other approach is to brute force everything with GPUs like MapD does ( https://www.mapd.com/demos/taxis ).
125.
▲
by
tmostak
10y ago
The benchmarks on the Titan-X are taken from a 2015 paper, thus they are definitely testing the older Maxwell (as opposed to Pascal) GPU. The FLOPS and memory bandwidth differences are significant.
126.
▲
by
tmostak
10y ago
MapD | San Francisco (city) | Backend Developer, Frontend Visualization Developer, Technical Marketing Director (ONSITE) MapD ( https://www.mapd.com ) is a Google Ventures/Nvidia/Verizon Ventures/Vanedge/In-Q-T
127.
▲
Scaling up and out in a GPU world
(mapd.com)
1 points
by
tmostak
10y ago
|
0 comments
128.
▲
Silicon Valley is betting its money on Hillary Clinton
(businessinsider.com)
4 points
by
tmostak
10y ago
|
0 comments
129.
▲
by
tmostak
10y ago
Actual demo link is here: https://www.mapd.com/demos/political-donations
130.
▲
Over 100M US political donations interactively visualized
(mapd.com)
2 points
by
tmostak
10y ago
|
1 comments
131.
▲
by
tmostak
10y ago
MapD | San Francisco (city) | Backend Developer, Frontend Visualization Developer, Technical Marketing Director (ONSITE) MapD ( https://www.mapd.com ) is a Google Ventures/Nvidia/Verizon Ventures/Vanedge/In-Q-T
132.
▲
by
tmostak
10y ago
This is 77M rows, not the full 1.2B dataset shown in the MapD demo (with 60 variables). It also looks like he map is pre-rendered as opposed to being dynamically rendered with filters applied. Pretty cool but a different animal.
133.
▲
by
tmostak
10y ago
MapD has a persistent store and normally customers would keep that on an EBS volume, so they don't have to reload their data every time they spin up an AWS instance.
134.
▲
Speeding through NYC: the billion row taxi dataset
(mapd.com)
3 points
by
tmostak
10y ago
|
0 comments
135.
▲
Why GPU Computing Will Reinvent Real-Time Analytics
(rtinsights.com)
2 points
by
tmostak
10y ago
|
0 comments
136.
▲
GPUs seen lifting SQL analytic constraints
(datanami.com)
4 points
by
tmostak
10y ago
|
0 comments
137.
▲
Interactively explore 1.2B taxi rides with MapD and Mapbox
(mapbox.com)
3 points
by
tmostak
10y ago
|
0 comments
138.
▲
The Hows and Whys of a GPU Database
(semiengineering.com)
4 points
by
tmostak
10y ago
|
0 comments
139.
▲
by
tmostak
10y ago
Very cool work but since its easy to get memory-bandwidth bound with SQL I would wonder if it would make more sense to use GPUs with 10X the bandwidth. I know FPGAs will be getting HBM as well so this might help. Disclaimer: I work at Map
140.
▲
by
tmostak
10y ago
That's not a fair comparison though. I only quickly read the postgres benchmark you linked, but it looks like you stored the data on disk (!) on a machine with only 16GB of ram for the postgres benchmark, while storing the data comple
141.
▲
by
tmostak
10y ago
256GB is 256 billion bytes. So you can only fit over a hundred billion rows into 256GB if you have zero overhead and every row is smaller than roughly two bytes... ;) [so you couldn't even store a single proper integer in each row in
142.
▲
by
tmostak
10y ago
Even MySQL can handle 256gb of rows in memory with ease if you give it enough ram The scan performance of MySQL on that much data is going to be dramatically slower. MySQL may be good at indexed accesses but is simply not build for analyt
143.
▲
by
tmostak
10y ago
You can fit up to 256GB of GPU RAM in a standard server these days, backed by terabytes of CPU RAM as cache. In a rack we can easily deploy on terabytes of GPU RAM. This is big enough to handle datasets of over a hundred billion rows, whic
144.
▲
by
tmostak
10y ago
Hi, CEO of MapD here. I agree that while some users don't need this level of speed, many do. Hadoop use cases are often very different than those that demand the speed of in-memory processing for real time answers. Think about all the
145.
▲
by
tmostak
10y ago
Here's a picture of the server the benchmarks were run on! http://imgur.com/a/dMzU9
146.
▲
by
tmostak
10y ago
Very cool! Dc.js is a very powerful and quick way to build interactive crossfiltered charts. At MapD we built our own visualization frontend using Dc.js as a base, except we leverage GPUs on the backend both for SQL and rendering data. The
147.
▲
by
tmostak
10y ago
Hi please write us at info at mapd dot com for more info. We'll also be rolling out cloud instances soon if on-prem deployment doesn't make sense.
148.
▲
Using GPUs for large-scale, latency-sensitive data analytics
(blogs.nvidia.com)
2 points
by
tmostak
10y ago
|
0 comments
149.
▲
Database with 4 Nvidia Gaming GPUs 43X Faster Than CPU Clusters
(tech.marksblogg.com)
27 points
by
tmostak
10y ago
|
6 comments
150.
▲
Database running on 4 gamer GPUs blows past Redshift, BigQuery clusters
(tech.marksblogg.com)
7 points
by
tmostak
10y ago
|
0 comments
More ›