Comments on jaXzin.com: First Impressions from NoSQL Live

Good article Brian. I went to one overview session...

2010-03-12T19:38:15.003-05:00

Good article Brian. I went to one overview session on NoSQL at a conference last year but also included things like Object Oriented DBs rather than ORM software. Definitely interesting stuff especially in how many big name companies have abandoned SQL for alternative solutions (Amazon, Google, Facebook if Im not mistaken, and the list goes on).

Brian, I met you briefly at NoSQL Live. My buddy&#...

2010-03-12T19:04:06.997-05:00

Brian, I met you briefly at NoSQL Live. My buddy's name at ESPN is Jeff Mahoney, but it sounds like you guys have a pretty big campus, so it's not likely you'd ever see him.

Anyway, I was scribbling on my whiteboard for 4 days straight this past summer trying to wrap my head around eventual consistency, multiple entity versions, and vector clocks.

These articles and talks by the CTO at Amazon were helpful:

http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

http://www.infoq.com/presentations/availability-consistency

And then, somewhat unrelated, I really liked this article about the Big Table type of architectures.

http://highscalability.com/how-i-learned-stop-worrying-and-love-using-lot-disk-space-scale

In the end, we decided to prototype and build on both the eventual consistency architecture for availability and the Big Table architecture for ACID requirements, trading away consistency and availability respectively. We're planning to expose both of these systems to our middleware through a unified interface. Data will be handled by our own db management system which will choose the appropriate data model architecture based on the specifications given to it by the client code.

Incidently, we are not directly running any of the systems featured at NoSQL Live. We are indirectly using them through platform services at Google, Amazon, and RackSpace.

We'll see how it goes, but prototyping and testing has shown really great results. At the very least, it's been a lot of fun.

Also, we are implementing a large portion of our stack in JavaScript, and I could not be happier with it. It feels strange to publicly admit how much I like JavaScript, but it is really a great overall tool.

We use Narwhal (http://github.com/280north/narwhal) and try to follow the new CommonJS specs as much as possible. (http://commonjs.org/)

Kris Walker
fireworksfactory.blogspot.com

Flinn, small world, right? Hope you didn't ta...

2010-03-12T12:33:22.428-05:00

Flinn, small world, right? Hope you didn't take my tongue-in-cheek commentary the wrong way! :-) But the low-level API isn't a deal-breaker for me, its the punting on horizontal scaling that is. Ideally I don't want to have to reinvent the 'scaling' wheel yet again. I want a performant online store that also allows ad-hoc reporting queries against it while dynamically and transparently scaling linearly. Call me a dreamer! :-)

The low level characterization of Tokyo Cabinet is...

2010-03-12T09:35:15.632-05:00

The low level characterization of Tokyo Cabinet is fair but don't let that shy you away from looking at it seriously. I wouldn't consider it a toy. It's a real tool that helps us avoid classic locking, join and speed issues associated with certain types of data problems. I don't (at the moment) use it as our primary store only because to make the switch would be an entire rewrite of a legacy system.