• Save
Migrating from RDBMA to NoSql webinar

Migrating from RDBMA to NoSql webinar



Increasing numbers of developers are moving from relational to NoSQL technology for their interactive web applications, eager to take advantage of greater flexibility, scalability, and performance ...

Increasing numbers of developers are moving from relational to NoSQL technology for their interactive web applications, eager to take advantage of greater flexibility, scalability, and performance that NoSQL offers. But what does this mean for the DBA tasked with supporting them? And what, if any advantages, does NoSQL offer a DBA? This webinar will explore how DBAs can make the move from an RDBMS to NoSQL and the benefits that come along with it.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • We’ll pause for questions a few times during the presentation.
  • Let’s take a look at what’s changes over the last 25 years with interactive web applications or OLTP applications. Users. With 2000 online users, the system was probably one of the largest at that point. But today,2000 is just the start point. If an application goes viral, you may need to support 200 thousand or 20 million users in a matter of months. Big data is more than just large volumes of data. You also need to serve up that data to a large number of users, who may come and go. And you need to plan for number that you may not be able to predict. Applications, the new interactive applications today are no longer just automating a business process or a manual process. They are about innovating new ways for users to shop, socialize and get entertained. The data that these applications need is no longer structured and well defined and the underlying database needs to handle this semi-structured and unstructured data. Infrastructure. Speeds of data networking were very low, centralized computing was the norm and memory was expensive. Today, in any data center or managed hosting center, you have universal high-speed networking, 1g is the norm with and 10gigE not uncommon. Memory is significantly cheaper and virtualization and cloud computing have made it easy to manage multiple servers.
  • Why did we have multiple records in the first place? Well, we went through a large normalization processMaybe pointing out: even real databases don’t really do Isolation
  • For example, nearly every large company is looking to add social features to any consumer offerings they may have. Want to build profiles around users, track them, etc. Example: automotive manufacturer now connecting with users online. The warranty database could probably fit on a single small laptop. Social interaction with users cannot.
  • mention that 2.0 does introduce new auto
  • Cloud deployments often use S3 to or something similar for backup.

Migrating from RDBMA to NoSql webinar Migrating from RDBMA to NoSql webinar Presentation Transcript

  • presented byCouchConf San Francisco: September 21, 2012 http://www.couchbase.com/couchconf 1
  • Migrating from the RDBMS to NoSQL Matt Ingenthron Director, Developer Solutions 2
  • Topics• RDBMS history, in brief• NoSQL Landscape• NoSQL differences, advantages 3
  • RDBMS History and Properties • An RDBMS is generally about managing a single server. Managing a NoSQL system is usually about managing a cluster of systems. • The RDBMS “grew up” in an era where most computer programs were disk oriented. 4
  • NoSQL Landscape• Wide ranging set of things under the NoSQL Umbrella – For analytics • Distributed M-R – For online applications • Key/Value stores • Column stores • Document stores• Document Oriented systems ideal backing for interactive web apps 5
  • What’s Different in Couchbase NoSQL?• Schema updates with flexible schema• Programming model matches data model• Querying differences• Transactions 7
  • Differences: Schema Updates• First, it’s worth nothing that document oriented NoSQL databases are is not schemaless We’re going to be big in Japan! 8
  • Schema Updates: Techniques• Add the additional fields to new documents as they arrive – Clearly, comes with an application level upgrade• Define a sane default for this new field for record retrievals where the record doesn’t exist – Example: adding loyalty points to the receipt- default to 0 points• May need to incorporate fields to assist with processing: – A docType for use in control processing: “docType”: “receipt” – Versioning of documents for application to upgrade a document 9
  • Differences: Programming Model and Data Model Match • Data maps more naturally to the data store – Developers focus more on the application at hand than the mapping logic • No more requirements for ORMs to handle huge impedance mismatch – ORMs exist to map object graphs to relational algebra • Frequently a challenge for the DBA 10
  • Differences: Querying and Joins• Queries against Couchbase are achieved with views – Views are simple pieces of Map- Reduce logic that are incrementally run as documents are mutated or added – Views are composed in Javascript, which maps pretty naturally to JSON – Actually quite powerful, normalize data at the time of index building! 11
  • Differences: Querying and Joins (contd.) • Joining data can be done at the application level… List First Reply to comment Blog List comment More CommentsAdvantages• Only fetch the data when you need it • For example, rendering part of a web page• Spread the data and load across the entire cluster 12
  • Differences: Querying and Joins (contd.)• … or when constructing the viewSee Bradley Holt’s presentationfrom Couchconf Boston:http://www.couchbase.com/couchconf-boston 13
  • Differences: Transactions• What do transactions provide? – Ability to mutate multiple records atomically, consistency across { multiple reads “UUID”: “21f7f8de-8051-5b89-86 “Time”: “2011-04-01T13:01:02.42 “Server”: “A2223E”,• All changes in the case of “Calling Server”: “A2213W”, “Type”: “E100”, “Initiating User”: “dsallings@spy.net”, Couchbase are “Details”: { “IP”: “”, atomic, consistent, ordered “API”: “InsertDVDQueueItem”, “Trace”: “cleansed”, “Tags”: – Provides the most common cases [ “SERVER”, with best performance and least “US-West”, “API” ] overhead } } – Alternatives: eventual consistency increases burden on application 14
  • Differences: Transactions• When needed, certain kinds of transactions can be modeled at the application layer. – Ex: two-phase commit to provide logical atomicity across changes to multiple documents. Application creates attributes in each document• Advantages: – Still a distributed system, still fast, still scales. – Not every operation has the overhead of an MVCC context. 15
  • New Projects: Opportunities• Seek project opportunities to try… – Where you’ll work with data models of moderate complexity, whether or not they’re well understood (flexible schema!) – That benefit from easy scaling, or built in high availability – Where the data stored in a heterogeneous JSON format benefits interop between multiple systems – Which could use JSON data directly in either web or mobile applications 17
  • Migrating: Opportunities• Applications at the right stage in their lifecycle – Ex.: Need new features – Ex.: Expect to get on to the next growth curve• Applications under pressure for growth, new features – Ex.: Session store growth, migrating from file or RDBMS backing – Ex.: Apps where features have been held back because of development time and RDBMS scalability/inflexibility 19
  • Migrating: Techniques• Best: introduce the new system alongside the current system, shift appropriate data over to the new system – Make application level changes to move data over as needed Web App• Good: convert data as needed Web App Web App using the RDBMS as a read only Web App migration storeBoth of these techniques work wellwhen there’s a clear data accesslayer in the application• Also: Make migration utilities for data, then cut over when Couchbase Cluster 20
  • Migrating: Common Questions• Do I have the same kind of resource controls? – Generally, yes. Excellent control of memory. Disk is not controlled, but often not a problem. • Couchbase Server 2.0 introduces autocompaction• Do I have multi-tenancy? What kind of security is available? – Yes, multi-tenancy is available. SASL authentication to database “buckets” is also used by default.• Can I manage how indexes are built? – Definitely, both at application use time and through the Couchbase Web Console.• What monitoring is available? – Both built in monitoring and a RESTful interface, demonstrated integration with Nagios, etc. 21
  • Migrating: Common Questions (contd.) • How can I backup and restore the system? – Couchbase provides backup and restore tools that allow for creation of backup files and online restore • How can I prepare for disaster recovery?(hopefully you don’t back up with these) – Couchbase Server 2.0 will introduce a feature for cross- datacenter replication to have an online cluster 22
  • Thank You• Join the team! http://www.couchbase.com/careers• Join the community! – Download, develop, and try it out in your next project – Get in touch: couchbase.com/forums @couchbase matt@couchbase.com @ingenthr Q&A 24
  • Attribution on Images• Japanese Flag: http://www.public-domain-image.com/flags-of-the- world-public-domain-images-pictures/flag-of- japan.jpg.html• Software developers: http://nopsa.hiit.fi/pmg/viewer/photo.php?id=565904• Computer tapes: http://www.soil- net.com/album/Equipment/slides/Computer%20Tape %20Reel.html 25