SlideShare une entreprise Scribd logo
1  sur  67
Télécharger pour lire hors ligne
NoSQL: Introduction



              Asya Kamsky
                            1
• 1970's Relational Databases Invented
  – Storage is expensive
  – Data is normalized
  – Data storage is abstracted away from app




                                               2
• 1970's Relational Databases Invented
  – Storage is expensive
  – Data is normalized
  – Data storage is abstracted away from app
• 1980's RDBMS commercialized
  – Client/Server model
  – SQL becomes the standard




                                               3
• 1970's Relational Databases Invented
  – Storage is expensive
  – Data is normalized
  – Data storage is abstracted away from app
• 1980's RDBMS commercialized
  – Client/Server model
  – SQL becomes the standard
• 1990's Things begin to change
  – Client/Server=> 3-tier architecture
  – Rise of the Internet and the Web
                                               4
• 2000's Web 2.0
  –   Rise of "Social Media"
  –   Acceptance of E-Commerce
  –   Constant decrease of HW prices
  –   Massive increase of collected data




                                           5
• 2000's Web 2.0
  –   Rise of "Social Media"
  –   Acceptance of E-Commerce
  –   Constant decrease of HW prices
  –   Massive increase of collected data




• Result
  – Constant need to scale dramatically
  – How can we scale?                      6
+ complex transactions
                          + tabular data
                          + ad hoc queries
                          - O<->R mapping hard
                          - speed/scale problems
                          - not super agile


   BI /       OLTP /
reporting   operational




                                                   7
+ complex transactions
+ ad hoc queries                                     + tabular data
+ SQL standard                                       + ad hoc queries
protocol between                                     - O<->R mapping hard
clients and servers                                  - speed/scale problems
+ scales horizontally                                - not super agile
better than oper dbs.
- some scale limits at
massive scale                 BI /       OLTP /
- schemas are rigid        reporting   operational
- no real time; great at
bulk nightly data loads




                                                                              8
+ complex transactions
+ ad hoc queries                                            + tabular data
+ SQL standard                                              + ad hoc queries
protocol between                                            - O<->R mapping hard
clients and servers                                         - speed/scale problems
+ scales horizontally                                       - not super agile
better than oper dbs.
- some scale limits at
massive scale                        BI /       OLTP /
- schemas are rigid               reporting   operational
- no real time; great at
bulk nightly data loads




                   fewer issues
                                                                                     9
                      here
+ complex transactions
+ ad hoc queries                                            + tabular data
+ SQL standard                                              + ad hoc queries
protocol between                                            - O<->R mapping hard
clients and servers                                         - speed/scale problems
+ scales horizontally                                       - not super agile
better than oper dbs.
- some scale limits at
massive scale                        BI /       OLTP /
- schemas are rigid               reporting   operational
- no real time; great at
bulk nightly data loads




                                                                a lot more
                   fewer issues                                issues here
                                                                                     10
                      here
+ complex transactions
+ ad hoc queries                                                      + tabular data
+ SQL standard                                                        + ad hoc queries
protocol between                                                      - O<->R mapping hard
clients and servers                                                   - speed/scale problems
+ scales horizontally                                                 - not super agile
better than oper dbs.
- some scale limits at
massive scale                     BI /       OLTP /
- schemas are rigid            reporting   operational
- no real time; great at                                              caching
bulk nightly data loads



                                                                                 app layer
                                                         flat files             partitioning
                           map/reduce




                                                                                               11
• Agile Development
  Methodology
   • Shorter development cycles
   • Constant evolution of
     requirements
   • Flexibility at design time




                                  12
• Agile Development
  Methodology
   • Shorter development cycles
   • Constant evolution of
     requirements
   • Flexibility at design time



                                  • Relational Schema
                                     • Hard to evolve
                                         • long painful migrations
                                         • must stay in sync with
                                           application
                                     • few developers interact directly

                                                                          13
14
15
•   Horizontal scaling
•   More real time requirements
•   Faster development time
•   Flexible data model
•   Low upfront cost
•   Low cost of ownership




                                  16
What is NoSQL?


           Relational
                   vs
       Non-Relational
                        17
+ speed and scale
                                   - ad hoc query limited
                                   - not very transactional
                                   - no sql/no standard
                                   + fits OO well
                     scalable      + agile
                   nonrelational
BI / reporting       (“nosql”)




            OLTP /
          operational




                                                              18
Non-relational next generation
     operation data stores and databases

A collection of very different products
•   Different data models (Not relational)
•   Most are not using SQL for queries
•   No predefined schema
•   Some allow flexible data structures

                                             19
• Relational   •   Key-Value
               •   Document
               •   XML
               •   Graph
               •   Column




                               20
• Relational   •   Key-Value
               •   Document
               •   XML
               •   Graph
               •   Column

• ACID         • BASE




                               21
• Relational         •   Key-Value
                     •   Document
                     •   XML
                     •   Graph
                     •   Column

• ACID               • BASE

• Two-phase commit   • Atomic transactions on
                       document level


                                                22
• Relational         •   Key-Value
                     •   Document
                     •   XML
                     •   Graph
                     •   Column

• ACID               • BASE

• Two-phase commit   • Atomic transactions on
                       document level
• Joins              • No Joins
                                                23
24
• Transaction rate

• Reliability

• Maintainability
• Ease of Use

• Scalability

• Cost
                     25
MongoDB: Introduction




                        26
• Designed and developed by founders of Doubleclick,
  ShopWiki, GILT groupe, etc.

• Coding started fall 2007
• First production site March 2008 -
  businessinsider.com
• Open Source – AGPL, written in C++
• Version 0.8 – first official release February 2009
• Version 1.0 – August 2009
• Version 2.0 – September 2011
                                                       27
MongoDB
Design Goals
               28
29
• Document-oriented
  Storage
   • Based on JSON
     Documents
   • Flexible Schema
• Scalable Architecture
   • Auto-sharding
   • Replication & high
     availability
• Key Features Include:
   • Full featured indexes
   • Query language
   • Map/Reduce &
     Aggregation
                             30
• Rich data models
• Seamlessly map to native programming
  language types
• Flexible for dynamic data
• Better data locality




                                         31
32
{
    _id : ObjectId("4e2e3f92268cdda473b628f6"),
    title : “Too Big to Fail”,
    when : Date(“2011-07-26”),
    author : “joe”,
    text : “blah”
}




                                                  33
{
    _id : ObjectId("4e2e3f92268cdda473b628f6"),
    title : “Too Big to Fail”,
    when : Date(“2011-07-26”),
    author : “joe”,
    text : “blah”,
    tags : [“business”, “news”, “north america”]
}



> db.posts.find( { tags : “news” } )




                                                   34
{
    _id : ObjectId("4e2e3f92268cdda473b628f6"),
    title : “Too Big to Fail”,
    when : Date(“2011-07-26”),
    author : “joe”,
    text : “blah”,
    tags : [“business”, “news”, “north america”],
    votes : 3,
    voters : [“dmerr”, “sj”, “jane” ]
}




                                                    35
{
    _id : ObjectId("4e2e3f92268cdda473b628f6"),
    title : “Too Big to Fail”,
    when : Date(“2011-07-26”),
    author : “joe”,
    text : “blah”,
    tags : [“business”, “news”, “north america”],
    votes : 3,
    voters : [“dmerr”, “sj”, “jane” ],
    comments : [
       { by : “tim157”, text : “great story” },
       { by : “gora”, text : “i don’t think so” },
       { by : “dmerr”, text : “also check out...” }
    ]
}
                                                      36
{
    _id : ObjectId("4e2e3f92268cdda473b628f6"),
    title : “Too Big to Fail”,
    when : Date(“2011-07-26”),
    author : “joe”,
    text : “blah”,
    tags : [“business”, “news”, “north america”],
    votes : 3,
    voters : [“dmerr”, “sj”, “jane” ],
    comments : [
       { by : “tim157”, text : “great story” },
       { by : “gora”, text : “i don’t think so” },
       { by : “dmerr”, text : “also check out...” }
    ]
}

> db.posts.find( { “comments.by” : “gora” } )
> db.posts.ensureIndex( { “comments.by” : 1 } )
                                                      37
Seek = 5+ ms          Read = really really fast




               Post

                              Comment
Author




                                                  38
Disk seeks and data locality


    Post


      Author


      Comment
       Comment
        Comment
         Comment
           Comment




                               39
•   Sophisticated secondary indexes
•   Dynamic queries
•   Sorting
•   Rich updates, upserts
•   Easy aggregation
•   Viable primary data store




                                      40
• Scale linearly
• High Availability
• Increase capacity with no downtime
• Transparent to the application




                                       41
Replica Sets
• High Availability/Automatic Failover
• Data Redundancy
• Disaster Recovery
• Transparent to the application
• Perform maintenance with no down time




                                          42
Asynchronous
Replication




          43
Asynchronous
Replication




          44
Asynchronous
Replication




          45
46
Automatic
 Election




            47
48
• Increase capacity with no downtime
• Transparent to the application




                                       49
•   Increase capacity with no downtime
•   Transparent to the application
•   Range based partitioning
•   Partitioning and balancing is automatic




                                              50
Key Range
           0..100




  mongod




Write Scalability



                       51
Key Range        Key Range
   0..50            51..100




  mongod            mongod




Write Scalability



                                52
Key Range        Key Range   Key Range   Key Range
   0..25            26..50      51..75      76.. 100




  mongod            mongod
                                mongod      mongod




Write Scalability



                                                        53
Key Range    Key Range    Key Range   Key Range
 0..25        26..50       51..75      76.. 100


Primary      Primary      Primary      Primary


Secondary    Secondary    Secondary    Secondary


Secondary    Secondary    Secondary    Secondary


                                                   54
Application



                 MongoS




 Key Range    Key Range         Key Range   Key Range
 0..25        26..50            51..75      76.. 100


Primary      Primary           Primary      Primary


Secondary    Secondary         Secondary    Secondary


Secondary    Secondary         Secondary    Secondary


                                                        55
Application



          MongoS       MongoS        MongoS




 Key Range          Key Range         Key Range   Key Range
 0..25              26..50            51..75      76.. 100


Primary            Primary           Primary      Primary


Secondary          Secondary         Secondary    Secondary


Secondary          Secondary         Secondary    Secondary


                                                              56
Application

                                                  Config
                                                             Config
          MongoS       MongoS        MongoS

                                                                Config



 Key Range          Key Range         Key Range     Key Range
 0..25              26..50            51..75        76.. 100


Primary            Primary           Primary       Primary


Secondary          Secondary         Secondary     Secondary


Secondary          Secondary         Secondary     Secondary


                                                                         57
• Few configuration options
• Does the right thing out of the box
• Easy to deploy and manage




                                        58
MySQL                               MongoDB
START TRANSACTION;                  db.contacts.save( {
INSERT INTO contacts VALUES             userName: “joeblow”,
    (NULL, ‘joeblow’);                  emailAddresses: [
INSERT INTO contact_emails VALUES         “joe@blow.com”,
   ( NULL, ”joe@blow.com”,                “joseph@blow.com” ] } );
      LAST_INSERT_ID() ),
   ( NULL, “joseph@blow.com”,
      LAST_INSERT_ID() );
COMMIT;




                                                                     59
MySQL                                MongoDB
START TRANSACTION;                   db.contacts.save( {
INSERT INTO contacts VALUES              userName: “joeblow”,
    (NULL, ‘joeblow’);                   emailAddresses: [
INSERT INTO contact_emails VALUES          “joe@blow.com”,
   ( NULL, ”joe@blow.com”,                 “joseph@blow.com” ] } );
      LAST_INSERT_ID() ),
   ( NULL, “joseph@blow.com”,
      LAST_INSERT_ID() );
COMMIT;




                          • Native drivers for dozens of languages
                          • Data maps naturally to OO data
                            structures
                                                                      60
MongoDB Usage Examples


                         61
Content Management       Operational Intelligence           E-Commerce




            User Data Management         High Volume Data Feeds




                                                                         62
Wordnik uses MongoDB as the foundation for its “live” dictionary that stores its entire
                    text corpus – 3.5T of data in 20 billion records

          Problem                           Why MongoDB                                 Impact
 Analyze a staggering amount of       Migrated 5 billion records in a      Reduced code by 75%
  data for a system build on            single day with zero downtime         compared to MySQL
  continuous stream of high-           MongoDB powers every                 Fetch time cut from 400ms to
  quality text pulled from online       website request: 20m API calls        60ms
  sources                               per day                              Sustained insert speed of 8k
 Adding too much data too             Ability to eliminate memcached        words per second, with
  quickly resulted in outages;          layer, creating a simplified          frequent bursts of up to 50k per
  tables locked for tens of             system that required fewer            second
  seconds during inserts                resources and was less prone to      Significant cost savings and 15%
 Initially launched entirely on        error.                                reduction in servers
  MySQL but quickly hit
  performance road blocks



   Life with MongoDB has been good for Wordnik. Our code is faster, more flexible and dramatically smaller.
   Since we don’t spend time worrying about the database, we can spend more time writing code for our
   application. -Tony Tam, Vice President of Engineering and Technical Co-founder
                                                                                                              63
Intuit relies on a MongoDB-powered real-time analytics tool for small businesses to
   derive interesting and actionable patterns from their customers’ website traffic

            Problem                          Why MongoDB                                Impact
 Intuit hosts more than 500,000      MongoDB's querying and               In one week Intuit was able to
  websites                             Map/Reduce functionality could        become proficient in MongoDB
 wanted to collect and analyze        server as a simpler, higher-          development
  data to recommend conversion         performance solution than a          Developed application features
  and lead generation                  complex Hadoop                        more quickly for MongoDB than
  improvements to customers.           implementation.                       for relational databases
 With 10 years worth of user         The strength of the MongoDB          MongoDB was 2.5 times faster
  data, it took several days to        community.                            than MySQL
  process the information using a
  relational database.




   We did a prototype for one week, and within one week we had made big progress. Very big progress. It
   was so amazing that we decided, “Let’s go with this.” -Nirmala Ranganathan, Intuit

                                                                                                          64
Shutterfly uses MongoDB to safeguard more than six billion images for millions of
  customers in the form of photos and videos, and turn everyday pictures into keepsakes

           Problem                           Why MongoDB                                  Impact
 Managing 20TB of data (six           JSON-based data structure              500% cost reduction and 900%
  billion images for millions of       Provided Shutterfly with an             performance improvement
  customers) partitioning by            agile, high performance,                compared to previous Oracle
  function.                             scalable solution at a low cost.        implementation
 Home-grown key value store on        Works seamlessly with                  Accelerated time-to-market for
  top of their Oracle database          Shutterfly’s services-based             nearly a dozen projects on
  offered sub-par performance           architecture                            MongoDB
 Codebase for this hybrid store                                               Improved Performance by
  became hard to manage                                                         reducing average latency for
 High licensing, HW costs                                                      inserts from 400ms to 2ms.




   The “really killer reason” for using MongoDB is its rich JSON-based data structure, which offers Shutterfly
   an agile approach to develop software. With MongoDB, the Shutterfly team can quickly develop and
   deploy new applications, especially Web 2.0 and social features. -Kenny Gorman, Director of Data Services
                                                                                                                 65
66
Open source, high performance database




                                         67

Contenu connexe

Tendances

The Perfect Storm: The Impact of Analytics, Big Data and Analytics
The Perfect Storm: The Impact of Analytics, Big Data and AnalyticsThe Perfect Storm: The Impact of Analytics, Big Data and Analytics
The Perfect Storm: The Impact of Analytics, Big Data and AnalyticsInside Analysis
 
Big Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDB
Big Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDBBig Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDB
Big Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDBBigDataCloud
 
Oracle en Entel Summit 2010
Oracle en Entel Summit 2010Oracle en Entel Summit 2010
Oracle en Entel Summit 2010Entel
 
Big data hadoop-no sql and graph db-final
Big data hadoop-no sql and graph db-finalBig data hadoop-no sql and graph db-final
Big data hadoop-no sql and graph db-finalramazan fırın
 
Webinar: The Future of SQL
Webinar: The Future of SQLWebinar: The Future of SQL
Webinar: The Future of SQLCrate.io
 
Hybrid my sql_hadoop_datawarehouse
Hybrid my sql_hadoop_datawarehouseHybrid my sql_hadoop_datawarehouse
Hybrid my sql_hadoop_datawarehouseLaine Campbell
 
Processing Big Data
Processing Big DataProcessing Big Data
Processing Big Datacwensel
 
SQLCAT: Tier-1 BI in the World of Big Data
SQLCAT: Tier-1 BI in the World of Big DataSQLCAT: Tier-1 BI in the World of Big Data
SQLCAT: Tier-1 BI in the World of Big DataDenny Lee
 
Mark Little Web Services And Transactions
Mark  Little    Web  Services And  TransactionsMark  Little    Web  Services And  Transactions
Mark Little Web Services And TransactionsSOA Symposium
 
Content Strategy at Symantec (STC 2009)
Content Strategy at Symantec (STC 2009)Content Strategy at Symantec (STC 2009)
Content Strategy at Symantec (STC 2009)Tristan Bishop
 
Mobile Development Meets Semantic Technology
Mobile Development Meets Semantic TechnologyMobile Development Meets Semantic Technology
Mobile Development Meets Semantic TechnologyBlue Slate Solutions
 
John Davies Last Minute Fill In For Sick Speaker
John Davies Last Minute Fill In For Sick SpeakerJohn Davies Last Minute Fill In For Sick Speaker
John Davies Last Minute Fill In For Sick Speakerdeimos
 
"Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,...
"Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,..."Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,...
"Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,...lisapaglia
 
PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment
PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment
PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment PROIDEA
 
World of Watson - DB2 for Linux, UNIX and Windows Roadmap
World of Watson - DB2 for Linux, UNIX and Windows RoadmapWorld of Watson - DB2 for Linux, UNIX and Windows Roadmap
World of Watson - DB2 for Linux, UNIX and Windows RoadmapIBM_Info_Management
 

Tendances (17)

The Perfect Storm: The Impact of Analytics, Big Data and Analytics
The Perfect Storm: The Impact of Analytics, Big Data and AnalyticsThe Perfect Storm: The Impact of Analytics, Big Data and Analytics
The Perfect Storm: The Impact of Analytics, Big Data and Analytics
 
Big Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDB
Big Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDBBig Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDB
Big Data Cloud Meetup - Jan 29 2013 - Mike Stonebraker & Scott Jarr of VoltDB
 
Oracle en Entel Summit 2010
Oracle en Entel Summit 2010Oracle en Entel Summit 2010
Oracle en Entel Summit 2010
 
Big data hadoop-no sql and graph db-final
Big data hadoop-no sql and graph db-finalBig data hadoop-no sql and graph db-final
Big data hadoop-no sql and graph db-final
 
Webinar: The Future of SQL
Webinar: The Future of SQLWebinar: The Future of SQL
Webinar: The Future of SQL
 
Hybrid my sql_hadoop_datawarehouse
Hybrid my sql_hadoop_datawarehouseHybrid my sql_hadoop_datawarehouse
Hybrid my sql_hadoop_datawarehouse
 
Processing Big Data
Processing Big DataProcessing Big Data
Processing Big Data
 
SQLCAT: Tier-1 BI in the World of Big Data
SQLCAT: Tier-1 BI in the World of Big DataSQLCAT: Tier-1 BI in the World of Big Data
SQLCAT: Tier-1 BI in the World of Big Data
 
Mark Little Web Services And Transactions
Mark  Little    Web  Services And  TransactionsMark  Little    Web  Services And  Transactions
Mark Little Web Services And Transactions
 
Db trends final
Db trends   finalDb trends   final
Db trends final
 
Content Strategy at Symantec (STC 2009)
Content Strategy at Symantec (STC 2009)Content Strategy at Symantec (STC 2009)
Content Strategy at Symantec (STC 2009)
 
Mobile Development Meets Semantic Technology
Mobile Development Meets Semantic TechnologyMobile Development Meets Semantic Technology
Mobile Development Meets Semantic Technology
 
John Davies Last Minute Fill In For Sick Speaker
John Davies Last Minute Fill In For Sick SpeakerJohn Davies Last Minute Fill In For Sick Speaker
John Davies Last Minute Fill In For Sick Speaker
 
"Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,...
"Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,..."Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,...
"Navigating the Database Universe" by Dr. Michael Stonebraker and Scott Jarr,...
 
PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment
PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment
PLNOG 9: Ron Broersma - Enterprise IPv6 Deployment
 
Security data deluge
Security data delugeSecurity data deluge
Security data deluge
 
World of Watson - DB2 for Linux, UNIX and Windows Roadmap
World of Watson - DB2 for Linux, UNIX and Windows RoadmapWorld of Watson - DB2 for Linux, UNIX and Windows Roadmap
World of Watson - DB2 for Linux, UNIX and Windows Roadmap
 

En vedette

Provisions for Victim Assistance: Restitution : Ex-Gratia Grant; Compensation...
Provisions for Victim Assistance:Restitution : Ex-Gratia Grant;Compensation...Provisions for Victim Assistance:Restitution : Ex-Gratia Grant;Compensation...
Provisions for Victim Assistance: Restitution : Ex-Gratia Grant; Compensation...singhajay92
 
Jurisprudence day 2 nd 3
Jurisprudence day 2 nd 3Jurisprudence day 2 nd 3
Jurisprudence day 2 nd 3xtrm nurse
 
Judicial review
Judicial reviewJudicial review
Judicial reviewshoetzlein
 
Judicial review
Judicial reviewJudicial review
Judicial reviewAlyna Adyl
 
Judicial review
Judicial  reviewJudicial  review
Judicial reviewzahidimran
 

En vedette (7)

Provisions for Victim Assistance: Restitution : Ex-Gratia Grant; Compensation...
Provisions for Victim Assistance:Restitution : Ex-Gratia Grant;Compensation...Provisions for Victim Assistance:Restitution : Ex-Gratia Grant;Compensation...
Provisions for Victim Assistance: Restitution : Ex-Gratia Grant; Compensation...
 
Jurisprudence day 2 nd 3
Jurisprudence day 2 nd 3Jurisprudence day 2 nd 3
Jurisprudence day 2 nd 3
 
Judicial review
Judicial reviewJudicial review
Judicial review
 
Judicial review as
Judicial review  asJudicial review  as
Judicial review as
 
Judicial review ppt
Judicial review pptJudicial review ppt
Judicial review ppt
 
Judicial review
Judicial reviewJudicial review
Judicial review
 
Judicial review
Judicial  reviewJudicial  review
Judicial review
 

Similaire à Intro to NoSQL and MongoDB

Intro to NoSQL and MongoDB
Intro to NoSQL and MongoDBIntro to NoSQL and MongoDB
Intro to NoSQL and MongoDBDATAVERSITY
 
Why NoSQL Makes Sense
Why NoSQL Makes SenseWhy NoSQL Makes Sense
Why NoSQL Makes SenseDATAVERSITY
 
DevNation Atlanta
DevNation AtlantaDevNation Atlanta
DevNation Atlantaboorad
 
NOSQL, CouchDB, and the Cloud
NOSQL, CouchDB, and the CloudNOSQL, CouchDB, and the Cloud
NOSQL, CouchDB, and the Cloudboorad
 
NewSQL vs NoSQL for New OLTP
NewSQL vs NoSQL for New OLTPNewSQL vs NoSQL for New OLTP
NewSQL vs NoSQL for New OLTPDATAVERSITY
 
Why mongo db was created - Dwight Merriman - MongoSF 2011
Why mongo db was created  - Dwight Merriman - MongoSF 2011Why mongo db was created  - Dwight Merriman - MongoSF 2011
Why mongo db was created - Dwight Merriman - MongoSF 2011MongoDB
 
Kb 40 kevin_klineukug_reading20070717[1]
Kb 40 kevin_klineukug_reading20070717[1]Kb 40 kevin_klineukug_reading20070717[1]
Kb 40 kevin_klineukug_reading20070717[1]shuwutong
 
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...Qian Lin
 
North Bay Ruby Meetup 101911
North Bay Ruby Meetup 101911North Bay Ruby Meetup 101911
North Bay Ruby Meetup 101911Ines Sombra
 
ROMA User-Customizable NoSQL Database in Ruby
ROMA User-Customizable NoSQL Database in RubyROMA User-Customizable NoSQL Database in Ruby
ROMA User-Customizable NoSQL Database in RubyRakuten Group, Inc.
 
Moving On Up - smaller servers and bigger performance
Moving On Up - smaller servers and bigger performanceMoving On Up - smaller servers and bigger performance
Moving On Up - smaller servers and bigger performanceDoug Lucy
 
001 hbase introduction
001 hbase introduction001 hbase introduction
001 hbase introductionScott Miao
 
Make Life Suck Less (Building Scalable Systems)
Make Life Suck Less (Building Scalable Systems)Make Life Suck Less (Building Scalable Systems)
Make Life Suck Less (Building Scalable Systems)guest0f8e278
 
An Introduction to Big Data, NoSQL and MongoDB
An Introduction to Big Data, NoSQL and MongoDBAn Introduction to Big Data, NoSQL and MongoDB
An Introduction to Big Data, NoSQL and MongoDBWilliam LaForest
 
Big iron 2 (published)
Big iron 2 (published)Big iron 2 (published)
Big iron 2 (published)Ben Stopford
 
Atlanta hadoop users group july 2013
Atlanta hadoop users group july 2013Atlanta hadoop users group july 2013
Atlanta hadoop users group july 2013Christopher Curtin
 
Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...
Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...
Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...Cloudera, Inc.
 
Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...
Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...
Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...Krishnan Parasuraman
 
SQL, NoSQL, BigData in Data Architecture
SQL, NoSQL, BigData in Data ArchitectureSQL, NoSQL, BigData in Data Architecture
SQL, NoSQL, BigData in Data ArchitectureVenu Anuganti
 
Seattle Scalability Meetup - Ted Dunning - MapR
Seattle Scalability Meetup - Ted Dunning - MapRSeattle Scalability Meetup - Ted Dunning - MapR
Seattle Scalability Meetup - Ted Dunning - MapRclive boulton
 

Similaire à Intro to NoSQL and MongoDB (20)

Intro to NoSQL and MongoDB
Intro to NoSQL and MongoDBIntro to NoSQL and MongoDB
Intro to NoSQL and MongoDB
 
Why NoSQL Makes Sense
Why NoSQL Makes SenseWhy NoSQL Makes Sense
Why NoSQL Makes Sense
 
DevNation Atlanta
DevNation AtlantaDevNation Atlanta
DevNation Atlanta
 
NOSQL, CouchDB, and the Cloud
NOSQL, CouchDB, and the CloudNOSQL, CouchDB, and the Cloud
NOSQL, CouchDB, and the Cloud
 
NewSQL vs NoSQL for New OLTP
NewSQL vs NoSQL for New OLTPNewSQL vs NoSQL for New OLTP
NewSQL vs NoSQL for New OLTP
 
Why mongo db was created - Dwight Merriman - MongoSF 2011
Why mongo db was created  - Dwight Merriman - MongoSF 2011Why mongo db was created  - Dwight Merriman - MongoSF 2011
Why mongo db was created - Dwight Merriman - MongoSF 2011
 
Kb 40 kevin_klineukug_reading20070717[1]
Kb 40 kevin_klineukug_reading20070717[1]Kb 40 kevin_klineukug_reading20070717[1]
Kb 40 kevin_klineukug_reading20070717[1]
 
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
 
North Bay Ruby Meetup 101911
North Bay Ruby Meetup 101911North Bay Ruby Meetup 101911
North Bay Ruby Meetup 101911
 
ROMA User-Customizable NoSQL Database in Ruby
ROMA User-Customizable NoSQL Database in RubyROMA User-Customizable NoSQL Database in Ruby
ROMA User-Customizable NoSQL Database in Ruby
 
Moving On Up - smaller servers and bigger performance
Moving On Up - smaller servers and bigger performanceMoving On Up - smaller servers and bigger performance
Moving On Up - smaller servers and bigger performance
 
001 hbase introduction
001 hbase introduction001 hbase introduction
001 hbase introduction
 
Make Life Suck Less (Building Scalable Systems)
Make Life Suck Less (Building Scalable Systems)Make Life Suck Less (Building Scalable Systems)
Make Life Suck Less (Building Scalable Systems)
 
An Introduction to Big Data, NoSQL and MongoDB
An Introduction to Big Data, NoSQL and MongoDBAn Introduction to Big Data, NoSQL and MongoDB
An Introduction to Big Data, NoSQL and MongoDB
 
Big iron 2 (published)
Big iron 2 (published)Big iron 2 (published)
Big iron 2 (published)
 
Atlanta hadoop users group july 2013
Atlanta hadoop users group july 2013Atlanta hadoop users group july 2013
Atlanta hadoop users group july 2013
 
Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...
Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...
Hadoop World 2011: Hadoop and Netezza Deployment Models and Case Study - Kris...
 
Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...
Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...
Hadoop World 2011: Building Scalable Data Platforms ; Hadoop & Netezza Deploy...
 
SQL, NoSQL, BigData in Data Architecture
SQL, NoSQL, BigData in Data ArchitectureSQL, NoSQL, BigData in Data Architecture
SQL, NoSQL, BigData in Data Architecture
 
Seattle Scalability Meetup - Ted Dunning - MapR
Seattle Scalability Meetup - Ted Dunning - MapRSeattle Scalability Meetup - Ted Dunning - MapR
Seattle Scalability Meetup - Ted Dunning - MapR
 

Plus de DATAVERSITY

Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...
Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...
Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...DATAVERSITY
 
Data at the Speed of Business with Data Mastering and Governance
Data at the Speed of Business with Data Mastering and GovernanceData at the Speed of Business with Data Mastering and Governance
Data at the Speed of Business with Data Mastering and GovernanceDATAVERSITY
 
Exploring Levels of Data Literacy
Exploring Levels of Data LiteracyExploring Levels of Data Literacy
Exploring Levels of Data LiteracyDATAVERSITY
 
Building a Data Strategy – Practical Steps for Aligning with Business Goals
Building a Data Strategy – Practical Steps for Aligning with Business GoalsBuilding a Data Strategy – Practical Steps for Aligning with Business Goals
Building a Data Strategy – Practical Steps for Aligning with Business GoalsDATAVERSITY
 
Make Data Work for You
Make Data Work for YouMake Data Work for You
Make Data Work for YouDATAVERSITY
 
Data Catalogs Are the Answer – What is the Question?
Data Catalogs Are the Answer – What is the Question?Data Catalogs Are the Answer – What is the Question?
Data Catalogs Are the Answer – What is the Question?DATAVERSITY
 
Data Catalogs Are the Answer – What Is the Question?
Data Catalogs Are the Answer – What Is the Question?Data Catalogs Are the Answer – What Is the Question?
Data Catalogs Are the Answer – What Is the Question?DATAVERSITY
 
Data Modeling Fundamentals
Data Modeling FundamentalsData Modeling Fundamentals
Data Modeling FundamentalsDATAVERSITY
 
Showing ROI for Your Analytic Project
Showing ROI for Your Analytic ProjectShowing ROI for Your Analytic Project
Showing ROI for Your Analytic ProjectDATAVERSITY
 
How a Semantic Layer Makes Data Mesh Work at Scale
How a Semantic Layer Makes  Data Mesh Work at ScaleHow a Semantic Layer Makes  Data Mesh Work at Scale
How a Semantic Layer Makes Data Mesh Work at ScaleDATAVERSITY
 
Is Enterprise Data Literacy Possible?
Is Enterprise Data Literacy Possible?Is Enterprise Data Literacy Possible?
Is Enterprise Data Literacy Possible?DATAVERSITY
 
The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...
The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...
The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...DATAVERSITY
 
Emerging Trends in Data Architecture – What’s the Next Big Thing?
Emerging Trends in Data Architecture – What’s the Next Big Thing?Emerging Trends in Data Architecture – What’s the Next Big Thing?
Emerging Trends in Data Architecture – What’s the Next Big Thing?DATAVERSITY
 
Data Governance Trends - A Look Backwards and Forwards
Data Governance Trends - A Look Backwards and ForwardsData Governance Trends - A Look Backwards and Forwards
Data Governance Trends - A Look Backwards and ForwardsDATAVERSITY
 
Data Governance Trends and Best Practices To Implement Today
Data Governance Trends and Best Practices To Implement TodayData Governance Trends and Best Practices To Implement Today
Data Governance Trends and Best Practices To Implement TodayDATAVERSITY
 
2023 Trends in Enterprise Analytics
2023 Trends in Enterprise Analytics2023 Trends in Enterprise Analytics
2023 Trends in Enterprise AnalyticsDATAVERSITY
 
Who Should Own Data Governance – IT or Business?
Who Should Own Data Governance – IT or Business?Who Should Own Data Governance – IT or Business?
Who Should Own Data Governance – IT or Business?DATAVERSITY
 
Data Management Best Practices
Data Management Best PracticesData Management Best Practices
Data Management Best PracticesDATAVERSITY
 
MLOps – Applying DevOps to Competitive Advantage
MLOps – Applying DevOps to Competitive AdvantageMLOps – Applying DevOps to Competitive Advantage
MLOps – Applying DevOps to Competitive AdvantageDATAVERSITY
 
Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...
Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...
Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...DATAVERSITY
 

Plus de DATAVERSITY (20)

Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...
Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...
Architecture, Products, and Total Cost of Ownership of the Leading Machine Le...
 
Data at the Speed of Business with Data Mastering and Governance
Data at the Speed of Business with Data Mastering and GovernanceData at the Speed of Business with Data Mastering and Governance
Data at the Speed of Business with Data Mastering and Governance
 
Exploring Levels of Data Literacy
Exploring Levels of Data LiteracyExploring Levels of Data Literacy
Exploring Levels of Data Literacy
 
Building a Data Strategy – Practical Steps for Aligning with Business Goals
Building a Data Strategy – Practical Steps for Aligning with Business GoalsBuilding a Data Strategy – Practical Steps for Aligning with Business Goals
Building a Data Strategy – Practical Steps for Aligning with Business Goals
 
Make Data Work for You
Make Data Work for YouMake Data Work for You
Make Data Work for You
 
Data Catalogs Are the Answer – What is the Question?
Data Catalogs Are the Answer – What is the Question?Data Catalogs Are the Answer – What is the Question?
Data Catalogs Are the Answer – What is the Question?
 
Data Catalogs Are the Answer – What Is the Question?
Data Catalogs Are the Answer – What Is the Question?Data Catalogs Are the Answer – What Is the Question?
Data Catalogs Are the Answer – What Is the Question?
 
Data Modeling Fundamentals
Data Modeling FundamentalsData Modeling Fundamentals
Data Modeling Fundamentals
 
Showing ROI for Your Analytic Project
Showing ROI for Your Analytic ProjectShowing ROI for Your Analytic Project
Showing ROI for Your Analytic Project
 
How a Semantic Layer Makes Data Mesh Work at Scale
How a Semantic Layer Makes  Data Mesh Work at ScaleHow a Semantic Layer Makes  Data Mesh Work at Scale
How a Semantic Layer Makes Data Mesh Work at Scale
 
Is Enterprise Data Literacy Possible?
Is Enterprise Data Literacy Possible?Is Enterprise Data Literacy Possible?
Is Enterprise Data Literacy Possible?
 
The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...
The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...
The Data Trifecta – Privacy, Security & Governance Race from Reactivity to Re...
 
Emerging Trends in Data Architecture – What’s the Next Big Thing?
Emerging Trends in Data Architecture – What’s the Next Big Thing?Emerging Trends in Data Architecture – What’s the Next Big Thing?
Emerging Trends in Data Architecture – What’s the Next Big Thing?
 
Data Governance Trends - A Look Backwards and Forwards
Data Governance Trends - A Look Backwards and ForwardsData Governance Trends - A Look Backwards and Forwards
Data Governance Trends - A Look Backwards and Forwards
 
Data Governance Trends and Best Practices To Implement Today
Data Governance Trends and Best Practices To Implement TodayData Governance Trends and Best Practices To Implement Today
Data Governance Trends and Best Practices To Implement Today
 
2023 Trends in Enterprise Analytics
2023 Trends in Enterprise Analytics2023 Trends in Enterprise Analytics
2023 Trends in Enterprise Analytics
 
Who Should Own Data Governance – IT or Business?
Who Should Own Data Governance – IT or Business?Who Should Own Data Governance – IT or Business?
Who Should Own Data Governance – IT or Business?
 
Data Management Best Practices
Data Management Best PracticesData Management Best Practices
Data Management Best Practices
 
MLOps – Applying DevOps to Competitive Advantage
MLOps – Applying DevOps to Competitive AdvantageMLOps – Applying DevOps to Competitive Advantage
MLOps – Applying DevOps to Competitive Advantage
 
Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...
Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...
Keeping the Pulse of Your Data – Why You Need Data Observability to Improve D...
 

Dernier

Keep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveKeep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveIES VE
 
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTSIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTxtailishbaloch
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsDianaGray10
 
20140402 - Smart house demo kit
20140402 - Smart house demo kit20140402 - Smart house demo kit
20140402 - Smart house demo kitJamie (Taka) Wang
 
.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptx.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptxHansamali Gamage
 
Planetek Italia Srl - Corporate Profile Brochure
Planetek Italia Srl - Corporate Profile BrochurePlanetek Italia Srl - Corporate Profile Brochure
Planetek Italia Srl - Corporate Profile BrochurePlanetek Italia Srl
 
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdfQ4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdfTejal81
 
LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0DanBrown980551
 
March Patch Tuesday
March Patch TuesdayMarch Patch Tuesday
March Patch TuesdayIvanti
 
IT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingIT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingMAGNIntelligence
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.IPLOOK Networks
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameKapil Thakar
 
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptxEmil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptxNeo4j
 
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechWebinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechProduct School
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updateadam112203
 
EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarThousandEyes
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc
 
Graphene Quantum Dots-Based Composites for Biomedical Applications
Graphene Quantum Dots-Based Composites for  Biomedical ApplicationsGraphene Quantum Dots-Based Composites for  Biomedical Applications
Graphene Quantum Dots-Based Composites for Biomedical Applicationsnooralam814309
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Alkin Tezuysal
 

Dernier (20)

Keep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveKeep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES Live
 
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTSIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projects
 
20140402 - Smart house demo kit
20140402 - Smart house demo kit20140402 - Smart house demo kit
20140402 - Smart house demo kit
 
.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptx.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptx
 
Planetek Italia Srl - Corporate Profile Brochure
Planetek Italia Srl - Corporate Profile BrochurePlanetek Italia Srl - Corporate Profile Brochure
Planetek Italia Srl - Corporate Profile Brochure
 
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdfQ4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
 
LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0
 
March Patch Tuesday
March Patch TuesdayMarch Patch Tuesday
March Patch Tuesday
 
IT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingIT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced Computing
 
SheDev 2024
SheDev 2024SheDev 2024
SheDev 2024
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First Frame
 
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptxEmil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
 
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechWebinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 update
 
EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? Webinar
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
 
Graphene Quantum Dots-Based Composites for Biomedical Applications
Graphene Quantum Dots-Based Composites for  Biomedical ApplicationsGraphene Quantum Dots-Based Composites for  Biomedical Applications
Graphene Quantum Dots-Based Composites for Biomedical Applications
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
 

Intro to NoSQL and MongoDB

  • 1. NoSQL: Introduction Asya Kamsky 1
  • 2. • 1970's Relational Databases Invented – Storage is expensive – Data is normalized – Data storage is abstracted away from app 2
  • 3. • 1970's Relational Databases Invented – Storage is expensive – Data is normalized – Data storage is abstracted away from app • 1980's RDBMS commercialized – Client/Server model – SQL becomes the standard 3
  • 4. • 1970's Relational Databases Invented – Storage is expensive – Data is normalized – Data storage is abstracted away from app • 1980's RDBMS commercialized – Client/Server model – SQL becomes the standard • 1990's Things begin to change – Client/Server=> 3-tier architecture – Rise of the Internet and the Web 4
  • 5. • 2000's Web 2.0 – Rise of "Social Media" – Acceptance of E-Commerce – Constant decrease of HW prices – Massive increase of collected data 5
  • 6. • 2000's Web 2.0 – Rise of "Social Media" – Acceptance of E-Commerce – Constant decrease of HW prices – Massive increase of collected data • Result – Constant need to scale dramatically – How can we scale? 6
  • 7. + complex transactions + tabular data + ad hoc queries - O<->R mapping hard - speed/scale problems - not super agile BI / OLTP / reporting operational 7
  • 8. + complex transactions + ad hoc queries + tabular data + SQL standard + ad hoc queries protocol between - O<->R mapping hard clients and servers - speed/scale problems + scales horizontally - not super agile better than oper dbs. - some scale limits at massive scale BI / OLTP / - schemas are rigid reporting operational - no real time; great at bulk nightly data loads 8
  • 9. + complex transactions + ad hoc queries + tabular data + SQL standard + ad hoc queries protocol between - O<->R mapping hard clients and servers - speed/scale problems + scales horizontally - not super agile better than oper dbs. - some scale limits at massive scale BI / OLTP / - schemas are rigid reporting operational - no real time; great at bulk nightly data loads fewer issues 9 here
  • 10. + complex transactions + ad hoc queries + tabular data + SQL standard + ad hoc queries protocol between - O<->R mapping hard clients and servers - speed/scale problems + scales horizontally - not super agile better than oper dbs. - some scale limits at massive scale BI / OLTP / - schemas are rigid reporting operational - no real time; great at bulk nightly data loads a lot more fewer issues issues here 10 here
  • 11. + complex transactions + ad hoc queries + tabular data + SQL standard + ad hoc queries protocol between - O<->R mapping hard clients and servers - speed/scale problems + scales horizontally - not super agile better than oper dbs. - some scale limits at massive scale BI / OLTP / - schemas are rigid reporting operational - no real time; great at caching bulk nightly data loads app layer flat files partitioning map/reduce 11
  • 12. • Agile Development Methodology • Shorter development cycles • Constant evolution of requirements • Flexibility at design time 12
  • 13. • Agile Development Methodology • Shorter development cycles • Constant evolution of requirements • Flexibility at design time • Relational Schema • Hard to evolve • long painful migrations • must stay in sync with application • few developers interact directly 13
  • 14. 14
  • 15. 15
  • 16. Horizontal scaling • More real time requirements • Faster development time • Flexible data model • Low upfront cost • Low cost of ownership 16
  • 17. What is NoSQL? Relational vs Non-Relational 17
  • 18. + speed and scale - ad hoc query limited - not very transactional - no sql/no standard + fits OO well scalable + agile nonrelational BI / reporting (“nosql”) OLTP / operational 18
  • 19. Non-relational next generation operation data stores and databases A collection of very different products • Different data models (Not relational) • Most are not using SQL for queries • No predefined schema • Some allow flexible data structures 19
  • 20. • Relational • Key-Value • Document • XML • Graph • Column 20
  • 21. • Relational • Key-Value • Document • XML • Graph • Column • ACID • BASE 21
  • 22. • Relational • Key-Value • Document • XML • Graph • Column • ACID • BASE • Two-phase commit • Atomic transactions on document level 22
  • 23. • Relational • Key-Value • Document • XML • Graph • Column • ACID • BASE • Two-phase commit • Atomic transactions on document level • Joins • No Joins 23
  • 24. 24
  • 25. • Transaction rate • Reliability • Maintainability • Ease of Use • Scalability • Cost 25
  • 27. • Designed and developed by founders of Doubleclick, ShopWiki, GILT groupe, etc. • Coding started fall 2007 • First production site March 2008 - businessinsider.com • Open Source – AGPL, written in C++ • Version 0.8 – first official release February 2009 • Version 1.0 – August 2009 • Version 2.0 – September 2011 27
  • 29. 29
  • 30. • Document-oriented Storage • Based on JSON Documents • Flexible Schema • Scalable Architecture • Auto-sharding • Replication & high availability • Key Features Include: • Full featured indexes • Query language • Map/Reduce & Aggregation 30
  • 31. • Rich data models • Seamlessly map to native programming language types • Flexible for dynamic data • Better data locality 31
  • 32. 32
  • 33. { _id : ObjectId("4e2e3f92268cdda473b628f6"), title : “Too Big to Fail”, when : Date(“2011-07-26”), author : “joe”, text : “blah” } 33
  • 34. { _id : ObjectId("4e2e3f92268cdda473b628f6"), title : “Too Big to Fail”, when : Date(“2011-07-26”), author : “joe”, text : “blah”, tags : [“business”, “news”, “north america”] } > db.posts.find( { tags : “news” } ) 34
  • 35. { _id : ObjectId("4e2e3f92268cdda473b628f6"), title : “Too Big to Fail”, when : Date(“2011-07-26”), author : “joe”, text : “blah”, tags : [“business”, “news”, “north america”], votes : 3, voters : [“dmerr”, “sj”, “jane” ] } 35
  • 36. { _id : ObjectId("4e2e3f92268cdda473b628f6"), title : “Too Big to Fail”, when : Date(“2011-07-26”), author : “joe”, text : “blah”, tags : [“business”, “news”, “north america”], votes : 3, voters : [“dmerr”, “sj”, “jane” ], comments : [ { by : “tim157”, text : “great story” }, { by : “gora”, text : “i don’t think so” }, { by : “dmerr”, text : “also check out...” } ] } 36
  • 37. { _id : ObjectId("4e2e3f92268cdda473b628f6"), title : “Too Big to Fail”, when : Date(“2011-07-26”), author : “joe”, text : “blah”, tags : [“business”, “news”, “north america”], votes : 3, voters : [“dmerr”, “sj”, “jane” ], comments : [ { by : “tim157”, text : “great story” }, { by : “gora”, text : “i don’t think so” }, { by : “dmerr”, text : “also check out...” } ] } > db.posts.find( { “comments.by” : “gora” } ) > db.posts.ensureIndex( { “comments.by” : 1 } ) 37
  • 38. Seek = 5+ ms Read = really really fast Post Comment Author 38
  • 39. Disk seeks and data locality Post Author Comment Comment Comment Comment Comment 39
  • 40. Sophisticated secondary indexes • Dynamic queries • Sorting • Rich updates, upserts • Easy aggregation • Viable primary data store 40
  • 41. • Scale linearly • High Availability • Increase capacity with no downtime • Transparent to the application 41
  • 42. Replica Sets • High Availability/Automatic Failover • Data Redundancy • Disaster Recovery • Transparent to the application • Perform maintenance with no down time 42
  • 46. 46
  • 48. 48
  • 49. • Increase capacity with no downtime • Transparent to the application 49
  • 50. Increase capacity with no downtime • Transparent to the application • Range based partitioning • Partitioning and balancing is automatic 50
  • 51. Key Range 0..100 mongod Write Scalability 51
  • 52. Key Range Key Range 0..50 51..100 mongod mongod Write Scalability 52
  • 53. Key Range Key Range Key Range Key Range 0..25 26..50 51..75 76.. 100 mongod mongod mongod mongod Write Scalability 53
  • 54. Key Range Key Range Key Range Key Range 0..25 26..50 51..75 76.. 100 Primary Primary Primary Primary Secondary Secondary Secondary Secondary Secondary Secondary Secondary Secondary 54
  • 55. Application MongoS Key Range Key Range Key Range Key Range 0..25 26..50 51..75 76.. 100 Primary Primary Primary Primary Secondary Secondary Secondary Secondary Secondary Secondary Secondary Secondary 55
  • 56. Application MongoS MongoS MongoS Key Range Key Range Key Range Key Range 0..25 26..50 51..75 76.. 100 Primary Primary Primary Primary Secondary Secondary Secondary Secondary Secondary Secondary Secondary Secondary 56
  • 57. Application Config Config MongoS MongoS MongoS Config Key Range Key Range Key Range Key Range 0..25 26..50 51..75 76.. 100 Primary Primary Primary Primary Secondary Secondary Secondary Secondary Secondary Secondary Secondary Secondary 57
  • 58. • Few configuration options • Does the right thing out of the box • Easy to deploy and manage 58
  • 59. MySQL MongoDB START TRANSACTION; db.contacts.save( { INSERT INTO contacts VALUES userName: “joeblow”, (NULL, ‘joeblow’); emailAddresses: [ INSERT INTO contact_emails VALUES “joe@blow.com”, ( NULL, ”joe@blow.com”, “joseph@blow.com” ] } ); LAST_INSERT_ID() ), ( NULL, “joseph@blow.com”, LAST_INSERT_ID() ); COMMIT; 59
  • 60. MySQL MongoDB START TRANSACTION; db.contacts.save( { INSERT INTO contacts VALUES userName: “joeblow”, (NULL, ‘joeblow’); emailAddresses: [ INSERT INTO contact_emails VALUES “joe@blow.com”, ( NULL, ”joe@blow.com”, “joseph@blow.com” ] } ); LAST_INSERT_ID() ), ( NULL, “joseph@blow.com”, LAST_INSERT_ID() ); COMMIT; • Native drivers for dozens of languages • Data maps naturally to OO data structures 60
  • 62. Content Management Operational Intelligence E-Commerce User Data Management High Volume Data Feeds 62
  • 63. Wordnik uses MongoDB as the foundation for its “live” dictionary that stores its entire text corpus – 3.5T of data in 20 billion records Problem Why MongoDB Impact  Analyze a staggering amount of  Migrated 5 billion records in a  Reduced code by 75% data for a system build on single day with zero downtime compared to MySQL continuous stream of high-  MongoDB powers every  Fetch time cut from 400ms to quality text pulled from online website request: 20m API calls 60ms sources per day  Sustained insert speed of 8k  Adding too much data too  Ability to eliminate memcached words per second, with quickly resulted in outages; layer, creating a simplified frequent bursts of up to 50k per tables locked for tens of system that required fewer second seconds during inserts resources and was less prone to  Significant cost savings and 15%  Initially launched entirely on error. reduction in servers MySQL but quickly hit performance road blocks Life with MongoDB has been good for Wordnik. Our code is faster, more flexible and dramatically smaller. Since we don’t spend time worrying about the database, we can spend more time writing code for our application. -Tony Tam, Vice President of Engineering and Technical Co-founder 63
  • 64. Intuit relies on a MongoDB-powered real-time analytics tool for small businesses to derive interesting and actionable patterns from their customers’ website traffic Problem Why MongoDB Impact  Intuit hosts more than 500,000  MongoDB's querying and  In one week Intuit was able to websites Map/Reduce functionality could become proficient in MongoDB  wanted to collect and analyze server as a simpler, higher- development data to recommend conversion performance solution than a  Developed application features and lead generation complex Hadoop more quickly for MongoDB than improvements to customers. implementation. for relational databases  With 10 years worth of user  The strength of the MongoDB  MongoDB was 2.5 times faster data, it took several days to community. than MySQL process the information using a relational database. We did a prototype for one week, and within one week we had made big progress. Very big progress. It was so amazing that we decided, “Let’s go with this.” -Nirmala Ranganathan, Intuit 64
  • 65. Shutterfly uses MongoDB to safeguard more than six billion images for millions of customers in the form of photos and videos, and turn everyday pictures into keepsakes Problem Why MongoDB Impact  Managing 20TB of data (six  JSON-based data structure  500% cost reduction and 900% billion images for millions of  Provided Shutterfly with an performance improvement customers) partitioning by agile, high performance, compared to previous Oracle function. scalable solution at a low cost. implementation  Home-grown key value store on  Works seamlessly with  Accelerated time-to-market for top of their Oracle database Shutterfly’s services-based nearly a dozen projects on offered sub-par performance architecture MongoDB  Codebase for this hybrid store  Improved Performance by became hard to manage reducing average latency for  High licensing, HW costs inserts from 400ms to 2ms. The “really killer reason” for using MongoDB is its rich JSON-based data structure, which offers Shutterfly an agile approach to develop software. With MongoDB, the Shutterfly team can quickly develop and deploy new applications, especially Web 2.0 and social features. -Kenny Gorman, Director of Data Services 65
  • 66. 66
  • 67. Open source, high performance database 67