Alternatives to Relational Databases
Upcoming SlideShare
Loading in...5
×
 

Alternatives to Relational Databases

on

  • 1,260 views

 

Statistics

Views

Total Views
1,260
Views on SlideShare
1,180
Embed Views
80

Actions

Likes
0
Downloads
6
Comments
0

5 Embeds 80

http://adamhutson.com 72
http://feeds.feedburner.com 5
http://storify.com 1
https://twitter.com 1
http://adamhutson.wordpress.com 1

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Alternatives to Relational Databases Alternatives to Relational Databases Presentation Transcript

  • Adam HutsonDrury University, CISQ 250 November 10, 2011
  • Relational Databases What’s a Relational Database?  Data store that groups data into relational models that conform to a set of requirements Why use?  Transactional = Data Integrity & Consistency We are rapidly moving beyond the era of “One Size Fits All” database. In the past, you could always trust that any decent-sized application had a relational database as its backend. It’s now increasingly about matching your dataset to whatever data model fits best. Common Vendors of Relational Databases:  Microsoft SQL Server, Oracle, MySQL
  • Relational DatabaseExampleCREATE TABLE Student( StudentID INT PRIMARY KEY ,FirstName VARCHAR(50) ,LastName VARCHAR(50) ,Birthdate DATETIME )CREATE TABLE Class( ClassID INT PRIMARY KEY ,ClassCode VARCHAR(50) ,ClassName VARCHAR(50) )CREATE TABLE ClassSchedule( ClassScheduleID INT PRIMARY KEY ,ClassID INT FOREIGN KEY REFERENCES Class (ClassID) ,DayOfWeek VARCHAR(20) ,TimeRange VARCHAR(20) )CREATE TABLE StudentClassSchedule( StudentClassScheduleID INT PRIMARY KEY ,ClassScheduleID INT FOREIGN KEY REFERENCES ClassSchedule (ClassScheduleID) ,StudentID INT FOREIGN KEY REFERENCES Student (StudentID) )
  • SELECT C.ClassCode, C.ClassName, CS.DayOfWeek, CS.TimeRange, S.FirstName + + S.LastName ASStudentNameFROM StudentClassSchedule SCSINNER JOIN ClassSchedule CS ON SCS.ClassScheduleID = CS.ClassScheduleIDINNER JOIN Class C ON CS.ClassID = C.ClassIDINNER JOIN Student S ON SCS.StudentID = S.StudentID
  • Alternatives to RDBMS File System:  Read and write to some file on disk Memory Cache:  Read and write to an object in memory NoSQL:  Distributed way to read and write data redundantly across an infinite # of machines
  • File System Write data in a file format to the file system File Formats:  XML, Delimited Text (pipe, csv), Custom Why use?  Persists data in portable manner. Works well on single machine. Idea for small data sets (i.e. config settings)
  • File System Examples Students.xml Students.txt <Students> Chuck|Norris|1940-03-10 <Student> Bruce|Lee|1940-11-27 Clint|Eastwood|1930-05-31 <FirstName>Chuck</FirstName> Sylvester|Stallone|1946-07-06 <LastName>Norris</LastName> Arnold|Schwarzenegger|1947-07-30 <Birthdate>1940-03-10</Birthdate> Randy|Savage|1952-11-15 </Student> <Student> <FirstName>Bruce</FirstName> <LastName>Lee</LastName> <Birthdate>1940-11-27</Birthdate> </Student> <Student> <FirstName>Clint</FirstName> <LastName>Eastwood</LastName> <Birthdate>1930-05-31</Birthdate> </Student> <Student> <FirstName>Sylvester</FirstName> <LastName>Stallone</LastName> <Birthdate>1946-07-06</Birthdate> </Student> <Student> <FirstName>Arnold</FirstName> <LastName>Schwarzenegger</LastNa me> <Birthdate>1947-07-30</Birthdate> </Student> <Student> <FirstName>Randy</FirstName> <LastName>Savage</LastName> <Birthdate>1952-11-15</Birthdate> </Student> </Students>
  • Memory Cache Hold data in a container in memory Containers:  Arrays, Hashes, Key-Value Pairs Why use?  Fast, fast, fast.  Works well on single machine.  Data is lost when machine restarts.  Data is limited by max RAM of machine.  Ideal for repeatable search scenarios.
  • The NoSQL Movement Non-relational, distributed data store that has no schema and scales horizontally NoSQL = Not Only SQL Why use?  Extremely fast writes and nearly as fast reads. No limits on size or processing power. No limits on type of data to store. Data Models  Key-Value, Column, Document, Graph Currently 100+ vendors offering NoSQL solutions.
  • NoSQL Data Models Key-Value Stores  Collection of key-value pairs.  Vendors: Voldemort, Dynomite, Tokyo Cabinet Column Family  Tabular model where each row can have an individual configuration of columns  Vendors: Hbase, Hypertable, Cassandra Document  Collections of documents, which contain key-value collections|  Vendors: CouchDB, MongoDB, Riak Graph  Nodes & relationships, both which can hold key-value pairs  Vendors: AllegroGraph, InfoGrid, Neo4j
  • How does NoSQL work? MAGIC, not really, but close Hundreds of machines working together to serve up data. Every machine has a small portion of the data. Multiple machines have the same data. Master machine(s) controlling queries and keeping track of machines that aren’t responding.
  • Choose your hammerwisely CAP Theorem  Consistency: each client always has the same view of the data.  Availability: all clients can always read & write.  Partition Tolerance: the system works well across physical network partitions. You can only pick 2. Need to decompose your data down to the best structure necessary.