Alternatives to relational DBs

1. Alternatives to relational DBs

2. About relational databases… • Relational databases • Built for centralized, single or few-node databases • Data that is simply structured, but rigidly structured • There is a global pre-defined schema • No schema changes when transactions are running • Very small schema over data ratio • Zero tolerance for failure of ACID constraints • All transactions atomic • All transactions leave database in an absolutely correct state • Two or more concurrent transactions cannot effect each other • All updates are permanent

3. About, continued… • Transactions • Consist only of SQL • Set oriented, with no complex algorithms • Complex functions must be performed in the host database • Strict two language environment • Transactions are short, not interactive, not meant for human interpretation, and not real time • Ability to optimize is more important than computationally sophisticated • Single, centralized state • Changes only at commit point of an ACID transaction

4. Why not…? • Long transactions, where partial results are released • Transactions that are corrected with compensating transactions • Non-centralized distribution of data and queries • Algorithmically complex transactions • Heavy optimization of highly distributed, parallel transactions that are mostly read-only • Support for internally complex, and unique data objects • Data meant for interactive, human analysis • Data with little interprative structure inside the database

5. Why not, continued… • Why not one language environments that don’t need the declarative, set-oriented capabilities of sql? • How about transactions that are oriented around screening and compression of data? • Why not make use of all those servers out there! • Why not make use of widely distributed, cluster-based environments? • Suppose I value distribution and raw speed over rigid correctness?

6. On the other hand, why not…? • Extremely interconnected data • Transactions based on examining, creating interconnections of data not on interpreting the values of attributes of individual data items • Dynamically reconfigurable relationships between data items • Navigational queries that were so popular in the pre-relational days?

7. Various options in NoSQL DBs • Key-value • Simple • Focus on raw parallel speed • Limited interconnectedness of data • Internal structure of data largely up to host program or interactive user • Straight columnar • Opposite of row oriented, data co-located by column • Supports fast introduction of new attributes (columns)

8. More options… • Key-document • Supports internal structure • Supports varied structure • Supports data that is mean for human consumption • Supports interactive, info-intensive web applications • Graph DBs • This is a very different approach and is at the other end of the massive distribution-ready approaches

9. Mongo • Mongo • http://docs.mongodb.org/manual/installation • A GUI • http://www.mongodb.org/display/DOCS/Admin+UIs

10. The Mongo DBMS • Document based • Focuses on clusters for extremely large scaling • Supports nested documents • Uses JavaScript for queries • No schema

11. Mongo’s approach • “Horizontal” scaling – • i.e., the cloud & simple servers • And no joins, effectively, pre-computed joins • Anti-normalization • Fast • Avoid bottleneck of centralized schema • Near real-time data access • High availability

12. Overview of Mongo • A database consists of collections • Which is more or less a table • Collections are made up of documents • A lot like rows • A document is made up of fields • A lot like columns • There are also indices • There are also cursors

13. Running Mongo • In bin folder • mongod for database • mongo for shell • For data, it needs a directory called data on c: and a directory called db within data • Commands • Global, like help • Db-specific, like db.x, where x is the collection • Db.x.help()