Home » Blogs » hingo's blog

Presentation: Databases and the Cloud (and why it is more difficult for databases)

hingo's picture
Submitted by hingo on Tue, 2012-03-06 08:06

A week ago I again had the pleasure to give a guest lecture at Tampere University of Technology. I've visited them the first time when I worked as MySQL pre-sales in Sun.

To be trendy, I of course had to talk about the cloud. It turns out every section has the subtitle "...and why it is more difficult for databases". I also rightfully claim to have invented the NoSQL key-value development model in 2005.

Databases and the Cloud

View more presentations from Henrik Ingo.
AttachmentSize
TTKK tietokannat ja pilvi - 3.odp1.74 MB
»

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
erkules's picture

OQGraph

Submitted by erkules (not verified) on Wed, 2012-03-07 00:24.

On Page 34 you could also mention OQGraph as a graphengine for MySQL.

»
hingo's picture

Actually, I'm aware of

Submitted by hingo on Thu, 2012-03-08 12:30.

Actually, I'm aware of OQGraph and I mention it while talking this presentation, but I'm not convinced it qualifies for my criteria for a graph database.

As I see it, a true graph database would:

1) store data on disk in an order that is optimized for the graph queries. In other words the storage format would minimize the average seek time on disk for all paths in the graph. As far as I know OQGraph is actually just a layer on top of InnoDB and will use InnoDB auto_increment keys in the table.

2) uses some query language or api appropriate for graph queries since SQL is really not suitable for the paradigm with nodes and edges. XPath is an example of what I mean. OQGraph is essentially just an SQL function you can use. This is of course because MySQL/MariaDB doesn't make introducing your own query language as simple as plugging in a storage engine is.

The actual point I make in the presentation is that if you did both of the above: dont' use InnoDB and don't use the SQL parser, then there isn't much left of MySQL code that is used. So it seems to me the problem space that a graph database solves really doesn't have a lot of overlap with an RDBMS. The benefit of having a MySQL storage engine like OQGraph is in the end mainly "familiarity" of using MySQL, not necessarily appropriateness.

For comparison, consider that a key-value store on top of innodb does make sense, and several implementations exist that have gathered more awareness than OQGraph.

»
Presentation: Databases and the Cloud (and why... | MySQL | 's picture

Pingback

Submitted by Presentation: Databases and the Cloud (and why... | MySQL | (not verified) on Wed, 2012-03-07 06:42.

[...] A week ago I again had the pleasure to give a guest lecture at Tampere University of Technology. I've visited them the first time when I worked as MySQL pre-sales in Sun. To be trendy, I of course had to talk about the cloud. It turns out every section has the subtitle "...and why it is more difficult for databases". I also rightfully claim to have invented the NoSQL key-value development model in 2005. read more    MySQL Read the original post on Planet MySQL... [...]

»

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Allowed HTML tags: <h1> <h2> <h3> <h4> <p> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <br> <sup> <div> <blockquote> <pre> <img>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically. (Better URL filter.)

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
3 + 10 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.