Your SlideShare is downloading. ×
0
Introduction to NoSQLDatabase TechnologyPerry KrugSr. Solutions Architect
<50%?202795%RelationalTechnology$30B Database MarketBeing Disrupted2012All new database growth will be NoSQLRelationalTech...
Macro Trends
Three Macro TrendsDriving DisruptionBig Data SaaS/CloudComputingBig Users
00.20.40.60.811.21.41.61.822000 2006 2011Source: IDC 2011 Digital Universe Study (http://www.emc.com/collateral/demos/micr...
Big UsersMore Users, All the TimeSmartphoneUsersHours SpentOnline35Billion Hours1Billion+Global OnlinePopulation2Billion+h...
SaaS/Cloud ComputingNew Apps Use 3-Tier Internet ArchitectureOld Client/Server ArchitectureClientUser interfaceBusiness an...
SaaS/Cloud ComputingBusiness Model Also Driving Move to Cloud ComputingOld Client/Server ArchitectureClientUser interfaceB...
NoSQL+ +More Data More UsersInteractive Apps/Cloud ComputingScalability, Performance, Ease of Development
Lacking Solutions,Users Forced to InventDynamoOctober 2007CassandraAugust 2008VoldemortFebruary 2009November 2006BigtableF...
What Is Biggest Data Management ProblemDriving Use of NoSQL in Coming Year?Lack of flexibility/rigid schemasInability tosc...
Relational vs. NoSQL Technology
Relational Technology Scales UpExpensive and disruptive sharding, doesn’t perform at web scaleRDBMS Scales UpGet a bigger,...
NoSQL Technology Scales OutScaling out flattens the cost and performance curvesNoSQL Database Scales OutCost and performan...
Relational vs Document Data ModelRelational data model Document data modelCollection of complex documents witharbitrary, n...
RDBMS Example: User ProfileAddress Info1 DEN 30303CO2 MV 94040CA3 CHI 60609ILUser InfoKEY First ZIP_idLast4 NY 10010NY1 Fr...
All data in a single documentDocument Example: User Profile{“ID”: 1,“FIRST”: “Frank”,“LAST”: “Weigel”,“ZIP”: “94040”,“CITY...
User ID First Last Zip1 Frank Wiegel 940402 Joe Smith 940403 Ali Dodson 940404 Sarah Gorin NW15 Bob Young 303036 Nancy Bak...
Making the Same ChangeWith a Document Database{“ID”: 1,“FIRST”: “Frank”,“LAST”: “Weigel”,“ZIP”: “94040”,“CITY”: “MV”,“STAT...
UserIDFirst Last Zip1 Frank Wiegel 940402 Joe Smith 940403 Ali Dodson 940404 Sarah Gorin NW15 Bob Young 303036 Nancy Baker...
EasyScalabilityConsistent HighPerformanceAlwaysOn24x365Grow cluster withoutapplication changes, withoutdowntime with a sin...
Common Use CasesSocial Gaming• Couchbase storesplayer and gamedata• Examplescustomers include:Zynga• Tapjoy, Ubisoft, Tenc...
Flavors of NoSQL
The Key-Value Store – the foundation of NoSQLKey10110010100010001001110110110010100010001001110110110010100010001001110110...
Memcached – the NoSQL precursorKey1011001010001000100111011011001010001000100111011011001010001000100111011011001010001000...
Redis – More “Structured Data” commandsKey10110010100010001001110110110010100010001001110110110010100010001001110110110010...
NoSQL catalogKey-Valuememcached redisData Structure Document Column GraphCache(memoryonly)
Membase – From key-value cache todatabaseDisk-based with built-in memcached cacheCache refill on restartMemcached compatib...
NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphCache(memoryonly)Database(memory/disk)
Couchbase – document-oriented databaseKey{“string” : “string”,“string” : value,“string” :, “string” : “string”,“string” : ...
NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphCache(memoryonly)Database(memory/disk)memba...
MongoDB – Document-oriented databaseKey{“string” : “string”,“string” : value,“string” :, “string” : “string”,“string” : va...
NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphmongoDBcouchbaseCache(memoryonly)Database(m...
Cassandra – Column overlaysDisk-based systemClusteredExternal caching required for low-latency reads“Columns” are overlaid...
NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphmongoDBcouchbase cassandraCache(memoryonly)...
Neo4j – Graph databaseDisk-based systemExternal caching required for low-latency readsNodes, relationships and pathsProper...
NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphmongoDBcouchbase cassandraCache(memoryonly)...
The LandscapeSpeedScale CouchbaseRedisS3CassandraMongoDBRiakHBaseCouchDBNeo4jSimpleDBmemcachedRDBMSDatomic
Thank youCouchbaseNoSQL Document Databaseperry@couchbase.com
Couchbase_John_Bryce_Israel_Training_intro_to_nosql
Couchbase_John_Bryce_Israel_Training_intro_to_nosql
Upcoming SlideShare
Loading in...5
×

Couchbase_John_Bryce_Israel_Training_intro_to_nosql

904

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
904
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The database industry is about $30B today and is dominated by companies like Oracle, IBM, and MicrosoftRelational technology has dominated the industry for the last 40 years and is the technology underpinning for 95% of the industry today.We believe the database industry is being disrupted.In 10 – 15 years we believe relational technology will make up a much smaller percentage of the industry.It’s too early to tell whether it will be 50%, 40%, or 30% percent but it seems clear to me it will be much small than 95%We believe most of the future operational database growth will be NoSQL
  • There are 3 major trends driving the transition to NoSQL databases; Big Data, Big Users, and the move to Cloud Computing and a SaaS business model.Let me briefly describe how each of these mega-trends is pushing people to adopt NoSQL technologies.
  • Usually when people talk about Big Data they talk about capturing huge amounts of data and analyzing it. This reference to Big Data is certainly a big trend.But Big Data affects operational databases in a big way as well but for a different set of reasons.There are 2 aspects of Big Data that are pushing people toward NoSQL technologies.The first is that the vast majority of the increase in data is in the form of un-structured or semi-structured data. This is data like user-generated content like consumer recommendations and machine generated data like log files and website click data. Relational databases aren’t well suited for storing this type of data while NoSQL technologies like document-oriented database are ideally suited for this.The second is that application developers are finding new types of data they want to store all the time. It might be new information they want to store in a user’s account profile, new logging information, etc. The point is that what developers want to store is changing very rapidly and the amount of data they want to store is increasing very rapidly. The result is that developers want a very flexible data model that they can evolve very quickly. Relational databases have fixed schemas that often take weeks or months to change. On the other hand, NoSQL databases are schema-less. As a result, you can far more easily add new types of data and iterate quickly on your application.
  • Big Users is an equally big trend driving developers to use NoSQL databases.Most new applications are made available over the internet so people can easily access them.This has caused the number of simultaneous users for many applications to explode.The number of people connected to the internet is more than 2B and growing rapidly.The number of hours that the average user spends on the internet is growing too further increasing the number of simultaneous users.And, with the proliferation of smart phones, people use their applications more and more frequently further increasing the number of simultaneous users.All these simultaneous users leads to a rapidly growing number of database operations and the need for a far easier way to scale your database to meet these demands.
  • Finally, the move to cloud computing and SaaS business models is also driving developers to consider NoSQL databases.15 years ago most applications were developed with a client/server architecture and a packaged software business model that supported the needs of users on a company-by-company basis.Today, applications are increasingly developed using a 3-tier internet architecture, are cloud-based, and use a Software-as-a-Service business model that needs to support the collective needs of thousandsvof customersThis approach increasingly requires a horizontally scalable architecture that easily scales with the number of users and amount of data your application has.
  • Finally, the move to cloud computing and SaaS business models is also driving developers to consider NoSQL databases.15 years ago most applications were developed with a client/server architecture and a packaged software business model that supported the needs of users on a company-by-company basis.Today, applications are increasingly developed using a 3-tier internet architecture, are cloud-based, and use a Software-as-a-Service business model that needs to support the collective needs of thousandsvof customersThis approach increasingly requires a horizontally scalable architecture that easily scales with the number of users and amount of data your application has.
  • To summarize, the technology implications of the Big Data, Big User, and Cloud Computing mega trends are causing people to seriously rethink what database they use for their applications and are increasingly coming to the conclusion that NoSQL databases are a better fit than relational databases.
  • The first companies to run into the scaling, performance, and data model flexibility problems I described were companies like Google, Amazon, Facebook, and LinkedIn.Since there were no solutions available and they have deep technical expertise, they built their own databases to solve these problems.Google published a paper on Big Table in 2006; Amazon published a paper on Dynamo in 2007; Facebook and LinkedIn likewise published papers on their technologies.This was the symbolic beginning of the NoSQL industry.Since then many other open source projects have been started that have been heavily influenced by these technologies.Shortly thereafter companies formed around the open source projects.And now we have a thriving, rapidly growing industry that is disrupting the relational database industry.
  • So far I’ve talked about the trends that are causing developers to increasingly consider NoSQL databases.I will now talk more specifically about the differences between relational and NoSQL database technologies.
  • As I mentioned earlier, most applications today use a 3-tier internet architecture. By that I mean, a user interfaces with an application through a browser that is on his laptop or mobile device. The app then connects over the internet to the cloud where the business logic of the application is processed in the web/application server tier and the data for the app is stored in the database tier.Application servers are a “scale out” or “horizontally” scalable technology that runs on standard, commodity hardware.When you have 10,000 more users, you add another commodity server to the application tier to support the higher load.As you scale, the cost grows linearly and performance is maintained.Relational databases on the other hand, are “scale up” or “vertically” scaling technologies that run on specialized, expensive, fault tolerant servers.When you have 10,000 more users, you buy a bigger server with more CPUs, storage, memory etc.And, when you have the biggest server you can buy you are forced to split your database into 2 databases and modify your application.As with most centralized technologies, cost grows exponentially as you scale and performance degrades as you scale.This is a major problem for an increasing number of applications.
  • NoSQL databases like Couchbase are “scale out” or “horizontally” scaling databases that run on low-cost commodity servers.Just like the web/application tier, if you have 10,000 new users, you add another server to the cluster to handle the increased load.By scaling out you maintain the same performance and the cost grows linearly.As important, there are no changes required to the application. The database is a single database that is spread across multiple servers as opposed multiple separate databases.These are the characteristics that application developers increasingly want for their applications.Let’s quickly take a look at how this works in a little more detail.
  • As I’m sure most of you know, relational database can be thought of as hundreds, sometimes thousands, of interrelated tables.What each of the tables look like and how they are related is rigidly defined by the schema. If you want to capture different data in the future, you have to change the schema and then convert the database from the old schema to the new schema.A document database is very different. The simplest way to think of it is that a row of information that cuts across many tables is aggregated into a single JSON document.The JSON document however, can have arbitrary, nested formats and can vary significantly from document to document.There is no schema so if you want to add more information to a document, you just do it.Since most developers use object oriented programming languages, a JSON document is a more natural way for developers to interact with their data.Since there is no schema it is much easier and quicker to add new types of data whenever you want.
  • Normalized schema 2 tables Foreign key connects the two. To get information about a user, you will perform a join across the two tables
  • This example shows how a very simple user profile is represented.In a relational database, the user information might be represented across 2 interrelated tables.In a document database, the information is aggregated into a single document that is very natural to program with.So, this is how the data model is different. Let’s now talk about how scalability is different.
  • The data is modeled for the application code and not for the database.
  • Most of you are probably familiar with the table layout. A table is defined with a set of column. And each record in the table conforms to the schema. If you wish to capture different data in the future, the table schema must be changed using the alter table statement. Typically data is normalized in the 3rd normal form reduce duplication. Large tables are split into smaller tablesusing foreign keys
  • Transcript of "Couchbase_John_Bryce_Israel_Training_intro_to_nosql"

    1. 1. Introduction to NoSQLDatabase TechnologyPerry KrugSr. Solutions Architect
    2. 2. <50%?202795%RelationalTechnology$30B Database MarketBeing Disrupted2012All new database growth will be NoSQLRelationalTechnologyRelationalTechnologyRelationalTechnologyNoSQLTechnologyOther
    3. 3. Macro Trends
    4. 4. Three Macro TrendsDriving DisruptionBig Data SaaS/CloudComputingBig Users
    5. 5. 00.20.40.60.811.21.41.61.822000 2006 2011Source: IDC 2011 Digital Universe Study (http://www.emc.com/collateral/demos/microsites/emc-digital-universe-2011/index.htm)TrillionsofGigabytes(Zettabytes) Big DataHigh Data Variety and VelocityUnstructured andSemi-Structured DataStructured DataText, LogFiles, ClickStreams, Blogs, Tweets, Audio, Video,etc.More Flexible Data Model Required
    6. 6. Big UsersMore Users, All the TimeSmartphoneUsersHours SpentOnline35Billion Hours1Billion+Global OnlinePopulation2Billion+http://www.go-gulf.com/blog/online-timehttp://business.time.com/2012/02/14/one-billion-smartphones-by-2016-here-comes-the-mobile-arms-race/More Easily Scalable Database Required
    7. 7. SaaS/Cloud ComputingNew Apps Use 3-Tier Internet ArchitectureOld Client/Server ArchitectureClientUser interfaceBusiness and dataprocessing logicDatabase ServerDataLANNew 3-Tier Internet ArchitectureWeb/AppServer TierCloudPublic/Private/Hybrid CloudDatabaseServer TierINTERNETHorizontally Scalable Database Fits Cloud Computing Well
    8. 8. SaaS/Cloud ComputingBusiness Model Also Driving Move to Cloud ComputingOld Client/Server ArchitectureClientUser interfaceBusiness and dataprocessing logicDatabase ServerDataLANNew 3-Tier Internet ArchitectureWeb/AppServer TierBusiness and dataprocessing logicCloudPublic/Private/Hybrid CloudDatabaseServer TierDataINTERNETSoftware as a ServiceSaaSINTERNET
    9. 9. NoSQL+ +More Data More UsersInteractive Apps/Cloud ComputingScalability, Performance, Ease of Development
    10. 10. Lacking Solutions,Users Forced to InventDynamoOctober 2007CassandraAugust 2008VoldemortFebruary 2009November 2006BigtableFew Organizations Can Build & Maintain Database Technology
    11. 11. What Is Biggest Data Management ProblemDriving Use of NoSQL in Coming Year?Lack of flexibility/rigid schemasInability toscale out dataPerformancechallengesCost All of these Other49%35%29%16%12%11%Source: Couchbase Survey, December 2011, n = 1351.
    12. 12. Relational vs. NoSQL Technology
    13. 13. Relational Technology Scales UpExpensive and disruptive sharding, doesn’t perform at web scaleRDBMS Scales UpGet a bigger, more complex serverUsersApplication Scales OutJust add more commodity web serversUsersSystem CostApplication PerformanceRelational DatabaseWeb/App Server TierSystem CostApplication PerformanceWon’tscalebeyondthis point
    14. 14. NoSQL Technology Scales OutScaling out flattens the cost and performance curvesNoSQL Database Scales OutCost and performance mirrors app tierUsersCouchbase Distributed Data StoreWeb/App Server TierApplication Scales OutJust add more commodity web serversUsersSystem CostApplication PerformanceApplication PerformanceSystem Cost
    15. 15. Relational vs Document Data ModelRelational data model Document data modelCollection of complex documents witharbitrary, nested data formats andvarying “record” format.Highly-structured table organizationwith rigidly-defined data formats andrecord structure.JSONJSONC1 C2 C3 C4JSON{}
    16. 16. RDBMS Example: User ProfileAddress Info1 DEN 30303CO2 MV 94040CA3 CHI 60609ILUser InfoKEY First ZIP_idLast4 NY 10010NY1 Frank 2Weigel2 Ali 2Dodson3 Mark 2Azad4 Steve 3YenZIP_id CITY ZIPSTATE1 Frank 2Weigel2 MV 94040CATo get info about specific user, you perform a join across 2 tables
    17. 17. All data in a single documentDocument Example: User Profile{“ID”: 1,“FIRST”: “Frank”,“LAST”: “Weigel”,“ZIP”: “94040”,“CITY”: “MV”,“STATE”: “CA”}JSON= +
    18. 18. User ID First Last Zip1 Frank Wiegel 940402 Joe Smith 940403 Ali Dodson 940404 Sarah Gorin NW15 Bob Young 303036 Nancy Baker 100107 Ray Jones 313118 Lee Chen V5V3M•••50000 Doug Moore 0425250001 Mary White SW19550002 Lisa Clark 12425CountryIDTEL3001Country ID Country name001 USA002 UK003 Argentina004 Australia005 Aruba006 Austria007 Brazil008 Canada009 Chile•••130 Portugal131 Romania132 Russia133 Spain134 SwedenUser ID Photo ID Comment2 d043 NYC2 b054 Bday5 c036 Miami7 d072 Sunset5002 e086 SpainPhoto Table001007001133133User ID Status ID Text1 a42 At conf4 b26 excited5 c32 hockey12 d83 Go A’s5000 e34 sailingStatus Table134007008001005Country TableUser ID Affl ID Affl Name2 a42 Cal4 b96 USC7 c14 UW8 e22 OxfordAffiliations TableCountryID001001001002CountryIDCountryID001001002001001001008001002001User Table...Making a Change Using RDBMS
    19. 19. Making the Same ChangeWith a Document Database{“ID”: 1,“FIRST”: “Frank”,“LAST”: “Weigel”,“ZIP”: “94040”,“CITY”: “MV”,“STATE”: “CA”,“STATUS”:{ “TEXT”: “At Conf”}}“GEO_LOC”: “134” },“COUNTRY”: ”USA”Just add information to a documentJSON,}
    20. 20. UserIDFirst Last Zip1 Frank Wiegel 940402 Joe Smith 940403 Ali Dodson 940404 Sarah Gorin NW15 Bob Young 303036 Nancy Baker 100107 Ray Jones 313118 Lee Chen V5V3•••5000 Doug Moore 042525001 Mary White 416945002 Lisa Clark 12425UserIDPhotoID Comment2 d043 NYC2 b054 Bday5 c036 Miami7 d072 Sunset5002 e086 SpainUser Table Photo TableUserIDStatusID Text1 a42 At conf4 b26 excited5 c32 hockey12 d83 Go A’s5000 e34 sailingStatus TableUserIDAffiliationsIDAffiliationsName2 a42 Cal4 b96 USC7 c14 UW8 e22 OxfordAffiliations TableRelational vs Document Performance1 Frank 94040Weigela421 At conf5 Bob 30303Youngc0365 Miami4 Sarah NW1Gorinb264 hockeyJSON{}JSON{}JSON{}JSON{}JSON{}JSON{}JSON{}JSON{}JSON{}JSON{}8 Lee V5V3Chene228 Oxford5002 Lisa 12425Clarke0865002 Spainc0325 excitedFaster response times and higher throughput
    21. 21. EasyScalabilityConsistent HighPerformanceAlwaysOn24x365Grow cluster withoutapplication changes, withoutdowntime with a single clickConsistent sub-millisecondread and write response timeswith consistent high throughputNo downtime for softwareupgrades, hardwaremaintenance, etc.Couchbase ServerJSONJSONJSONJSONJSONFlexible DataModelJSON document model withno fixed schema.The NoSQL Promise
    22. 22. Common Use CasesSocial Gaming• Couchbase storesplayer and gamedata• Examplescustomers include:Zynga• Tapjoy, Ubisoft, TencentMobile Apps• Couchbase stores userinfo and app content• Examples customersinclude: Kobo, PlaytikaAd Targeting• Couchbase storesuser information forfast access• Examples customersinclude: AOL,Mediamind,ConvertroSession store• Couchbase Server as a key-value store• Examples customers include:Concur, SabreUser Profile Store• Couchbase Server as akey-value store• Examples customersinclude: TunewikiHigh availability cache• Couchbase Server used as a cache tier replacement• Examples customers include: OrbitzContent & MetadataStore• Couchbase document storewith Elastic Search• Examples customersinclude: McGraw Hill3rd party data aggregation• Couchbase stores social media anddata feeds• Examples customers include:Sambacloud
    23. 23. Flavors of NoSQL
    24. 24. The Key-Value Store – the foundation of NoSQLKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValue
    25. 25. Memcached – the NoSQL precursorKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValuememcachedIn-memory onlyLimited set of operationsBlob Storage: Set, Add, Replace, CASRetrieval: GetStructured Data: Append, Increment“Simple and fast.”Challenges: cold cache, disruptive elasticity
    26. 26. Redis – More “Structured Data” commandsKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101“Data Structures”BlobListSetHash…redisIn-memory onlyVast set of operationsBlob Storage: Set, Add, Replace, CASRetrieval: Get, Pub-SubStructured Data: Strings, Hashes, Lists, Sets,Sorted listsExample operations for a SetAdd, count, subtract sets, intersection, ismember?, atomic move from one set toanother
    27. 27. NoSQL catalogKey-Valuememcached redisData Structure Document Column GraphCache(memoryonly)
    28. 28. Membase – From key-value cache todatabaseDisk-based with built-in memcached cacheCache refill on restartMemcached compatible (drop in replacement)Highly-available (data replication)Add or remove capacity to live cluster“Simple, fast, elastic.”membaseKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValue
    29. 29. NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphCache(memoryonly)Database(memory/disk)
    30. 30. Couchbase – document-oriented databaseKey{“string” : “string”,“string” : value,“string” :, “string” : “string”,“string” : value -,“string” : * array +}Auto-shardingDisk-based with built-in memcached cacheCache refill on restartMemcached compatible (drop in replace)Highly-available (data replication)Add or remove capacity to live clusterWhen values are JSON objects (“documents”):Create indices, views and query against theviewsJSONOBJECT(“DOCUMENT”)Couchbase
    31. 31. NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphCache(memoryonly)Database(memory/disk)membase couchbase
    32. 32. MongoDB – Document-oriented databaseKey{“string” : “string”,“string” : value,“string” :, “string” : “string”,“string” : value -,“string” : * array +}Disk-based with in-memory “caching”BSON (“binary JSON”) format and wire protocolMaster-slave replicationAuto-shardingValues are BSON objectsSupports ad hoc queries – best when indexedBSONOBJECT(“DOCUMENT”)MongoDB
    33. 33. NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphmongoDBcouchbaseCache(memoryonly)Database(memory/disk)
    34. 34. Cassandra – Column overlaysDisk-based systemClusteredExternal caching required for low-latency reads“Columns” are overlaid on the dataNot all rows must have all columnsSupports efficient queries on columnsRestart required when adding columnsGood cross-datacenter supportCassandraKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValueColumn 1Column 2Column 3(not present)
    35. 35. NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphmongoDBcouchbase cassandraCache(memoryonly)Database(memory/disk)
    36. 36. Neo4j – Graph databaseDisk-based systemExternal caching required for low-latency readsNodes, relationships and pathsProperties on nodesDelete, Insert, Traverse, etc.Neo4jKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValueKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValueKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValueKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValueKey101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101101100101000100010011101OpaqueBinaryValue
    37. 37. NoSQL catalogKey-ValuememcachedmembaseredisData Structure Document Column GraphmongoDBcouchbase cassandraCache(memoryonly)Database(memory/disk)Neo4j
    38. 38. The LandscapeSpeedScale CouchbaseRedisS3CassandraMongoDBRiakHBaseCouchDBNeo4jSimpleDBmemcachedRDBMSDatomic
    39. 39. Thank youCouchbaseNoSQL Document Databaseperry@couchbase.com
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×