Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Not everything can fit in rows and columns

Not everything can fit in rows and columns

The Graph Database is there since a long time but very restricted adaption rate and there are some rumours about where it fits. The way the web is moving forward data is becoming more unstructured which are very hard to fit in row and columns. We have adapted NoSQL databases which pose several challenges when it comes to relationships. The dgraph team is trying to fill the gaps and minimize the time required to get started with the Graph Database.

Ashok Vishwakarma

April 10, 2019
Tweet

Other Decks in Programming

Transcript

  1. WHO AM I? Naukri.com AVP - Engineering Google Developer Expert

    (GDE) Web Technologies & Angular Ashok Vishwakarma @avishwakarma @_avishwakarma
  2. THE RDBMS PROBLEM What RDBMS forces you to do? •

    Maintain a strict schema ◦ If you modify a column from string to float you have to do manual table migration. • Data duplication to avoid slow joins ◦ The same information is kept in multiple tables, to avoid joins. • Pre-compute counts for foreign tables ◦ To allow efficient sorting of data.
  3. NOSQL IS NOT A SOLUTION It’s a way out not

    a way in • It kills the valuable relationship between data ◦ Storing everything into a single document is not possible all the time. • Data duplication is still there ◦ We are force to put the same data in multiple documents • ACID, Security and etc.
  4. THE SOLUTION A Graph Database. How it helps? • Flexible

    sparse schema with real-time modifiable data types ◦ Change predicate type from string to float without migration. • No data duplication ◦ Any join is single lookup. • Counts are cheap in real time ◦ Any sort can be perform on these counts efficiently.
  5. WHO USES GRAPH DATABASES? • Google - NoEdgeGraph • Facebook

    - FacebookTau • Twitter - FlockDB • Dropbox, Pinterest, Linkedin and etc have their own versions of graph layers Any company doing anything smart is using Graph Databases
  6. SO LET’S MOVE TO GRAPH DATABASE • Single server or

    on top of other databases ◦ Existing graphs either single server like Neo4j or they are hastily put together on other databases like Cayley, titanDB or DSCGraph. • No standard ◦ Companies have to built their graph systems. FcabeookTau, NoEdgeGraph FlockDB and etc. Wait! There are some problems with existing Graph Database solutions
  7. INTRODUCING DGRAPH An Open Source Graph Database written in Go

    • Fast - Built like a search engine • Sharded and Distributed with distributed joins, filters and sort • Horizontally Scalable with consistent replication using Raft • Highly available by design • Fault-tolerant • GraphQL+- Dgraph Query Language
  8. DGRAPH VS NEO4J & CAYLEY - BENCHMARK Neo4j • 100x

    faster data loading • 3x to 6x faster in querying data Cayley • 9.7x faster data loading • 5x to 36x faster in querying data
  9. MYTHS Should we really using Graph Database? • Are they

    an overkill? ◦ I might have to run some traversals should I use graphs or its an overkill. • Are they robust? ◦ Do I need to run a primary datastore so this graph database does not lose my data. • Are they scalable? ◦ I have to run lot of queries, can graph database achieve the performance and scale.
  10. MYTHS Should we really using Graph Database? • Are they

    an overkill? ◦ No! You should use a graph database they are not an overkill. • Are they robust? ◦ Yes! They can act like a primary datastore. • Are they scalable? ◦ Yes! They will scale, in fact Dgraph with sharded and distributed architecture scale better than mysql database stuck on a single server.
  11. DGRAPH-ORM dgraph-orm - Why we need an ORM? • Dgraph

    uses GraphQL+- for it’s query language. ◦ GraphQL is fine but that +- is tricky and require learning. • We love Mongoose and Sequelize ◦ Using similar ORM is easy to get started. • Object based schema ◦ Dgraph’s schema is string based
  12. user.name: string @index(term) . ... user.friend uid @count @reverse .

    // User.js import {Schema, model, Types} from 'dgraph-orm'; const UserSchema = new Schema('user', { name: { type: Types.STRING, index: true, token: { term: true } }, ... friends: { type: Types.UID, model: 'user', count: true, reverse: true } }); const User = model('user', UserSchema);
  13. import User from './user'; // Creating user const users =

    await User.create({ email: '[email protected]', password: '$ecureP@ssw0rd' }); // Querying users const users = await User.has('email', { filter: { email: '[email protected]' } }); # creating user { set { _:u1 <user.email> '[email protected]' . _:u1 <user.password> '$ecureP@ssw0rd' . } } # querying users { users(func: has(user.email)) @filter(eq(user.email, '[email protected]')) { uid email: user.email } } More Examples https://github.com/ashokvishwakarma/dgraph-orm