A Beginner's Guide to noSQL


The Presentation inside:

Slide 0

noSQL THE BEGINNERS GUIDE TO


Slide 1

THE WHY WE ARE STORING MORE DATA NOW THAN WE EVER HAVE BEFORE


Slide 2

THE WHY WE ARE STORING MORE DATA NOW THAN WE EVER HAVE BEFORE CONNECTIONS BETWEEN OUR DATA ARE GROWING ALL THE TIME


Slide 3

THE WHY WE ARE STORING MORE DATA NOW THAN WE EVER HAVE BEFORE CONNECTIONS BETWEEN OUR DATA ARE GROWING ALL THE TIME WE DON’T MAKE THINGS KNOWING THE STRUCTURE FROM DAY 1


Slide 4

THE WHY WE ARE STORING MORE DATA NOW THAN WE EVER HAVE BEFORE CONNECTIONS BETWEEN OUR DATA ARE GROWING ALL THE TIME WE DON’T MAKE THINGS KNOWING THE STRUCTURE FROM DAY 1 SERVER ARCHITECTURE IS NOW AT A STAGE WHERE WE CAN TAKE ADVANTAGE OF IT


Slide 5

SiZE social networks salary lists most web applications semantic trading relational databases Complexity


Slide 6

NOSQL USE CASES LARGE DATA VOLUMES MASSIVELY DISTRIBUTED ARCHITECTURE REQUIRED TO STORE THE DATA GOOGLE, AMAZON, FACEBOOK, 100K SERVERS


Slide 7

NOSQL USE CASES LARGE DATA VOLUMES MASSIVELY DISTRIBUTED ARCHITECTURE REQUIRED TO STORE THE DATA GOOGLE, AMAZON, FACEBOOK, 100K SERVERS EXTREME QUERY WORKLOAD IMPOSSIBLE TO EFFICIENTLY DO JOINS AT THAT SCALE WITH AN RDBMS


Slide 8

NOSQL USE CASES LARGE DATA VOLUMES MASSIVELY DISTRIBUTED ARCHITECTURE REQUIRED TO STORE THE DATA GOOGLE, AMAZON, FACEBOOK, 100K SERVERS EXTREME QUERY WORKLOAD IMPOSSIBLE TO EFFICIENTLY DO JOINS AT THAT SCALE WITH AN RDBMS SCHEMA EVOLUTION SCEMA FLEXIBILITY IS NOT TRIVIAL AT A LARGE SCALE BUT IT CAN BE WITH NO SQL


Slide 9

NOSQL PROS AND CONS PROS MASSIVE SCALABILITY HIGH AVAILABILITY LOWER COST SCHEMA FLEXIBILITY SPARCE AND SEMI STRUCTURED DATA


Slide 10

NOSQL PROS AND CONS PROS MASSIVE SCALABILITY HIGH AVAILABILITY LOWER COST SCHEMA FLEXIBILITY SPARCE AND SEMI STRUCTURED DATA CONS LIMITED QUERY CAPABILITIES NOT STANDARDISED (PORTABILITY MAY BE AN ISSUE) STILL A DEVELOPING TECHNOLOGY


Slide 11

OSQL NOSQL NOSQL NOSQL QL BIGTABLE NOSQL NOSQL QL NOSQL NOSQL NOSQL N OSQL NOSQL KEY VALUE NO SQL NOSQL NOSQL NOSQL N NOSQL NOSQL NOSQL NOS NOSQL NOSQL NOSQL NOSQ EMERGING TRENDS IN QL NOSQL NOSQL NOSQL NO NOSQL DATABASES N GRAPHDB NOSQL NOSQL NOSQL NOSQL NOSQL NOS SQL NOSQL DOCUMENT NOS OSQL NOSQL NOSQL NOSQL FOUR


Slide 12

BUT FIRST… IMAGINE A LIBRARY LOTS OF DIFFERENT FLOORS DIFFERENT SECTIONS ON EACH FLOOR DIFFERENT BOOKSHELVES IN EACH SECTION LOTS OF BOOKS ON EACH SHELF LOTS OF PAGES IN EACH BOOK LOTS OF WORDS ON EACH PAGE EVERYTHING IS WELL ORGANISED AND EVERYTHING HAS A SPACE


Slide 13

BUT FIRST… IMAGINE A LIBRARY WHAT HAPPENS IF WE BUY TOO MANY BOOKS!? (THE WORLD EXPLODES AND THE KITTENS WIN)


Slide 14

BUT FIRST… IMAGINE A LIBRARY WHAT HAPPENS IF WE WANT TO STORE CDS ALL OF A SUDDEN!? (THE WORLD EXPLODES AND THE KITTENS WIN)


Slide 15

BUT FIRST… IMAGINE A LIBRARY WHAT HAPPENS IF WE WANT TO GET RID OF ALL BOOKS THAT MENTION KITTENS (KITTENS STILL WIN)


Slide 16

BIG TABLE BEHAVES LIKE A STANDARD RELATIONAL DATABASE BUT WITH A SLIGHT CHANGE DESIGNED TO WORK WITH A LOT OF DATA…A REALLY BIG CRAP TON CREATED BY GOOGLE AND NOW USED BY LOTS OF OTHERS http://research.google.com/archive/spanner.html http://research.google.com/archive/bigtable.html


Slide 17

BIG TABLE THIS IS A STANDARD RELATIONAL DATABASE THIS IS A BIG TABLE DATABASE (AND NOW THE NAME MAKES SENCE!)


Slide 18

BIG TABLE “A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.”


Slide 19

BIG TABLE “A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.”


Slide 20

BIG TABLE “A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.”


Slide 21

KEY VALUE AGAIN, DESIGNED TO WORK WITH A LOT OF DATA EACH BIT OF DATA IS STORED IN A SINGLE COLLECTION EACH COLLECTION CAN HAVE DIFFERENT TYPES OF DATA


Slide 22

KEY VALUE A B C D E


Slide 23

OUR VALUES ARE HIDDEN INSIDE THE KEYS KEY VALUE TO FIND OUT WHAT THEY ARE WE NEED TO QUERY THEM A B C D What is in Key B? The Triangle E


Slide 24

KEY VALUE (VOLDERMORT)


Slide 25

DOCUMENT STORE DESIGNED TO WORK WITH A LOT OF DATA (BEGINNING TO NOTICE A THEME?) VERY SIMILAR TO A KEY VALUE DATABASE MAIN DIFFERENCE IS THAT YOU CAN ACTUALLY SEE THE VALUES


Slide 26

DOCUMENT STORE A B C D E


Slide 27

DOCUMENT STORE A B C D Bring me the triangles Yes m’lord. E


Slide 28

SIDE NOTE REMEMBER HOW SQL DATABASES ARE LIBRARIES? NO SQL IS MORE LIKE A BAG OF CATS!


Slide 29

SIDE NOTE WE CAN ADD IN FIELDS AS AND WHEN WE NEED THEM colour: tabby name: Gunther colour: grey name: Ruffus age: kitten colour: ginger name: Mylo colour: ginger(ish) name: Fred age: kitten colour: ginger(ish) name: Quentin legs: 3


Slide 30

DOCUMENT STORE A B C D Bring me the KITTENS! Of course m’lord. E


Slide 31

DOCUMENT STORE


Slide 32

GRAPH DATABASE FOCUS HERE IS ON MODELLING THE STRUCTURE OF THE DATA INSPIRED BY GRAPH THEORY (GO MATHS!) SCALES REALLY WELL TO THE STRUCTURE OF THE DATA


Slide 33

GRAPH DATABASE


Slide 34

GRAPH DATABASE


Slide 35

GRAPH DATABASE WORKS_WITH WORKS_WITH OWNS OWNS CARSHARES IN


Slide 36

GRAPH DATABASE WORKS_WITH name: “Michael” twitter: “@mrmike OWNS name: “John” WORKS_WITH twitter:”@mrjohn” OWNS CARSHARES IN brand: “Toyota” currentState: “Broken” brand: “Vauxhall” currentState: “Working”


Slide 37

GRAPH DATABASE WORKS_WITH name: “Michael” twitter: “@mrmike name: “John” WORKS_WITH twitter:”@mrjohn” CARSHARES IN OWNS propertyType: “car” brand: “Toyota” currentState: “Broken” OWNS propertyType: “car” brand: “Vauxhall” currentState: “Working”


Slide 38

GRAPH DATABASE


Slide 39

SiZE key/value store bigtable clone document database graph database Complexity


Slide 40

SiZE key/value store bigtable clone document database graph database >90% of use cases Complexity


Slide 41

WHEN TO USE NOSQL AND WHEN TO USE SQL


Slide 42

THE BASICS High availability and disaster recovery are a must Understand the pros and cons of each design model Don’t pick something just because it is new Do you remember the zune? Don’t pick something based JUST on performance


Slide 43

SQL THE GOOD High performance for transactions. Think ACID Highly structured, very portable Small amounts of data SMALL IS LESS THAN 500GB Supports many tables with different types of data Can fetch ordered data Compatible with lots of tools


Slide 44

ATOMICITY CONSISTENCY ISOLATION DURABILITY SQL


Slide 45

SQL THE GOOD High performance for transactions. Think ACID Highly structured, very portable Small amounts of data SMALL IS LESS THAN 500GB Supports many tables with different types of data Can fetch ordered data Compatible with lots of tools


Slide 46

SQL THE BAD Complex queries take a long time The relational model takes a long time to learn Not really scalable Not suited for rapid development


Slide 47

noSQL THE GOOD Fits well for volatile data High read and write throughput In general it’s faster than SQL Scales really well Rapid development is possible


Slide 48

noSQL BASICALLY AVAILABLE SOFT STATE EVENTUALLY CONSISTENT


Slide 49

noSQL THE GOOD Fits well for volatile data High read and write throughput In general it’s faster than SQL Scales really well Rapid development is possible


Slide 50

noSQL THE GOOD Key/Value pairs need to be packed/unpacked all the time Still working on getting security for these working as well as SQL Lack of relations from one key to another


Slide 51

tl;dr SQL works great, can’t scale for large data noSQL works great, doesn't fit all situations so use both, but think about when you want to use them!


Slide 52

FINALLY A lot of this content is loving ripped from lots of other (more impressive) presentations that are already on SlideShare - you should check them out!


Slide 53


×

HTML:





Ссылка: