5. hum…?
• Not using the relational model (nor the SQL language);
• Open source;
• Designed to run on large clusters;
• No schema, allowing fields to be added to any record
without controls;
• Document based;
• Documents independency;
6. why
• Schema free;
• Storing full complex object graphs (aggregates);
• Low overhead: Usually operate on a single document:
• One read, one write;
• Fast, really fast :-)
• Known format: the database itself can do lots of things
with documents;
7. Got the time…tickin’ in my head
Sql NoSql
• Consistent; • Eventually consistent;
• ACID; • ACID;
• Supported; • Supported :-)
• Strong schema; • schema-less;
• Relational (joins); • No relation(s)
• no joins :-)
• But…map/reduce and multi
map;
9. Why RavenDB: our project
• 20.000 users
• 50 msgs/day/user
• Something like 200.000.000 msgs/year
• Office 365?
• Exchange on premise?
• …26 days to be up & running;
10. Selling RavenDB to the corporation
• Esent;
• «Munin» to run on Mono;
• Linq API;
• .net everywhere;
• Is supported;
• Standard backup support (via Shadow copy);
11. Architecture
HTTP/Rest
Raven Http Server Background Tasks
HTTP
Indexing Reducing User Tasks
Server
Document Store Index Store
ESENT / Raven.Munin
19. Features
• Safe by default (max 128 «rows» per query);
• Sharding;
• Multi tenant;
• Replica;
• Embedded mode (a must for tests)
• Dynamic Fields: «Search»;
• Cache;
• Lucene;
• Spatial;