Alenka: GPU database engine • Hacker News Board

Re: Alenka: GPU database engine

#51

Post by arnon » Thu, Jan 19, 2017, 12:17 AM UTC

gshulegaard wrote: post #44

arnon wrote: post #30

Earlier quoted context omitted.

You're thinking about transactional databases, and you're right. Transactional databases will probably not benefit hugely from a GPU. That's not saying it's impossible, but probably not worth the effort. However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of…

> Transactional databases will probably not benefit hugely from a GPU. What about parallel queries over a Restriction-Union normalized data model? I think the benefits would be similar in nature to columnar stores as you note: > GPUs tend to lend themselves well to analytics, contrary to transactions. Specifically, columnar databases. When the columns are all of the same data type, and the data locality is high, GPUs…

Maybe, but that's a very specific situation. You don't typically create a full RDBMS for a specific data model

Re: Alenka: GPU database engine

#52

Post by general_ai » Thu, Jan 19, 2017, 1:26 AM UTC

paulmd wrote: post #41

rotten wrote: post #20

Earlier quoted context omitted.

We don't really call pandas a database either. It looks like a data processing tool/library. "real" databases have integrated persistence models, as well as discussions and design tradeoffs regarding ACID transactions and scalability. There are query planners and indexes, constraints (type, value, foreign key) and other logic that can help enforce business rules around the data. There are triggers and embedded functi…

That's a matter of perspective. I don't think this is too different in concept from, say, Bigtable, which is billed by Google as a database.

BT wasn't actually billed as "database" internally, until they had to sell it in Google Cloud where the definition of what constitutes a database is much looser. Inside Google it's known as a multidimensional hash table.

Re: Alenka: GPU database engine

#53

Post by paulmd » Thu, Jan 19, 2017, 7:34 PM UTC

general_ai wrote: post #52

paulmd wrote: post #41

Earlier quoted context omitted.

That's a matter of perspective. I don't think this is too different in concept from, say, Bigtable, which is billed by Google as a database.

BT wasn't actually billed as "database" internally, until they had to sell it in Google Cloud where the definition of what constitutes a database is much looser. Inside Google it's known as a multidimensional hash table.

I would definitely agree that's a more precise definition. Constraining "database" to only ever refer to RDBMS is what I really have a problem with.

But there really isn't a brightline between what's a table, and what's a filesystem, and what's a database. You can put a blob in a database or BigTable, and MongoDB is really close to being a flat file conceptually. You can have a filesystem or database that is content-accessible. You can have a filesystem that is atomic and supports rollbacks and can store relational data like symlinks. A virtual filesystem like LVM can support schema-like volumes on top of it.

At the end of the day it's all just technology that lets me abstract my writes so I can deal with a more simplistic model backed by certain guarantees about behavior. I want to write a program that does XYZ, not write a filesystem/database driver. From there it's all just various tradeoffs.

Re: Alenka: GPU database engine

#54

Post by zer0t3ch » Sat, Jan 21, 2017, 9:00 PM UTC

dijit wrote: post #23

zer0t3ch wrote: post #17

Earlier quoted context omitted.

> everyone realized the quality was worse and not much faster I can't speak for the h264 situation, as I wasn't involved at the time, but with the newer h265 hardware, it is obnoxiously faster with minimal (in terms of end-user, not distributor) quality loss.

Are those the CPU instructions or the GPU ones? I remember when h264 CPU accelerators hit the scene. It was a game changer.

I don't know anything about h265 CPU accelerators, I'm comparing GPU HEVC (h265) encoding with a dedicated chip on the GPU to standard CPU encoding. (Using libx265 IIRC)