Ayende at Headspring one week ago!

On 8/23/2012, I saw Ayende Rahien (who is really a Mr. Oren Eini) the inventor of Rhino Mocks speak on RavenDB at an open house party at Headspring. Ayende spoke of his attempt to make Raven simple so that users fell into a pit of success. I learned a little about RavenDB from his talk, but I mostly learned about databases is general. Notes:

• With indexed fields come a performance hit. RavenDB selective shifts resources to make indexes on the fly as needed and then drop memory allocation for them as needed. A pitfall in a traditional database is to add more and more indexes as needed to a database, some of them used only occasionally while always effecting performance. The more indexes, the more of a performance hit you will take on.
• Everyone loves SELECT * and even so when it is rolled into production! It is only after three months of life in production that things get painful. Traditional testing does not catch the performance lag that cannot be seen until the data is fat. RavenDB will generally only give you back 128 records at once and if you try to hack around this you will only get 1024 max by "being creative." The performance lag as data grows in a traditional system is an example of how an instance of an application (let's say an install of a CRM) that is really used by one important, high-paying client is going to perform poorly compared to an install that is used slightly by a smaller client with a less impressive contract.
• ACID (Atomic, Consistent, Isolated, Durable) has an alternative called BASE (Basically Available, Soft-state, Eventually Consistent) and discussed here: http://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/
• CAP (Consistency, Availability and Partition-tolerance) comes with SOA problems that eventual consistency elevates. Otherwise if one partition does not "hear" and update from another, there is a fire-and-forget style failure. Apparently, in the event of a power loss there is a fire-and-forget style failure with eventually consistency within MongoDB which RavenDB addresses and handles better.
• Ayende hates Guids. I asked him why and he responded: "Have you ever tried to read a Guid to someone over the phone?"
• If RavenDB suddenly has a lot more reads, it is going to change to put more processing to indexing processing threads. If there is a sudden spike of write, it threads another way. Moderate load takes 20 to 25 milliseconds while high volume loads take 1 to 3 seconds.
• SELECT Orders WHERE (amount*Qty) > 0 ...in replacing a traditional query like this, RavenDB would just make a new index for total.
• Query Trends,Date: 2012\-02 ...is a RavenDB query.
  
• MapReduce is offered with RavenDB.
  
• Everything is stored as JSON where a value may be:
  • "" just a string
  • {} another JSON object
  • [] an array
  • [{},{}] an array of complex objects

The 8/23/2012 event, the day before my 38th birthday, marked the first time I had been in Headspring's new office full of new faces. Having been the first employee at Headspring, I was happy to see the success and growth that Dustin Wells has nurtured. He picked the right guys in Jeffrey Palermo and Kevin Hurwitz in the name of spearheading development and teambuilding. It appears Headspring fell down a pit of success. The place seemed very different and I suppose I no longer tie my identity to it, but anyone coming in the door there as a new hire is very lucky indeed. Best wishes Headspring.