Iran Hutchinson

 I work for InterSystems who drives the new NoSQL project.   Twitter: #iranic  Skype: chatwithiran

 … NoSQL Databases  Understanding what they are  Understanding how to leverage their strengths  Understanding their weaknesses  Staying away from hype and religious wars  Fighting your developer demon

 Edgar Frank “Ted” Codd  Known for 12 Rules (0 ~ 12) for Relational Data Systems

 Rule 1: The information Rule  All information is represented in 1 and only 1 way, namely by values in column positions within rows of tables  Rule 12: The no subversion Rule  If the system provides a low-level (record-at-a- time) interface, then that interface cannot be used to subvert the system i.e. relational security or integrity constraints.

 Simple APIs  Java Example: Document.save(myObject)  Seamless language integration  No impedance mismatch  Designed to be horizontally scalable (elastic)  Flexible data model  Majority free and/or Open Source  Free and Commercial production support

 Proven  Available talent / Well-known  AD-Hoc querying  Scalable (limits?)  Free and Commercial production support

 Interface for data access  Limited horizontal scalability?  Impedance mismatches  Programming model  In-flexible data model

 Does not include the underlying data structure.  B-tree and B+-trees can be fast and efficient  The relational model + SQL can limit B-trees

 Class of data management systems inherently  Non-relational  Distributed  Horizontally scalable  With optional schemas  Providing simple APIs  Term Not-Only-SQL recently embraced  Dave Kellog’s Blog Post Dave Kellog’s Blog Post

 No to ACID  No to the impedance mismatch with SQL  Dealing with Big Data and Web Scale  High prices from RDBMS vendors  Use commodity hardware  Flexible data models  It’s a cool movement ….

NNo RRemember MUMPS? SSET ^Car("Door","Color")="BLUE” RRemember Multi-value/PICK MMATWRITE array.variable ON file.variable,id. …. EEver heard of the NoSQL RDB?

Data Key-ValueDocumentColumnGraph

 This depends on your use case.  Example  es  Compare your problems to others.  Example: 

 lists 122 today.  Depends on your model selection.  Most likely choose well-known project.  Don’t forget about shared risk!

 Some solutions have no querying  When available query languages differ  Lack of general AD-Hoc querying – “no” SQL  NOTE: Toad for CloudToad for Cloud

 Skills  Data Model  Data format  Tools  Standards?

 Some databases are not as proven  Incomplete NoSQL solutions  You write a larger data management tier  You maintain your business code and infrastructure code  You have to customize management and deployment technology and procedures

 Know your application  Don’t forget the past lessons  Consider a hybrid approach  Fight the desire to Roll-Your-Own-DB  Start small but significant

 Two Systems  NoSQL + SQL/RDBMS  Updates  Real-time  Asynchronous or Batch NoSQL SQL/RDB MS Data Mapper / Translato r

 One system does both NoSQL and SQL Data RelationalKey-ValueDocumentColumnGraph?

 InterSystems Caché supports SQL and NoSQL  Production NoSQL for 20+ years  APIs for.NET, Java, Perl, Python, etc.  Expanding paradigms for more use cases.  Comes the closest to approach 2 Data RelationalKey-ValueDocumentColumnGraph?

 Core of InterSystems Caché  Free for development and production  Simple APIs Java and JavaScript   Sponsored by InterSystems Data ArrayDocument?

 Over time I think we will see  NoSQL features in mainstream databases  NoSQL offerings by more commercial companies  Dominant open source / free NoSQL projects  New definitions of enterprise databases

 Hadoop/Hbase  Cassandra  MongoDB  CouchDB  Riak  Couchbase  Neo4J

 InterSystems Caché  SimpleDB  Azure Table Storage  Google App Engine Data Storage  Mark Logic Server  Infinite Graph  Riak (has open source version)  Berkely DB