Browse files

initial commit

  • Loading branch information...
0 parents commit 533f809d3ffad2efab247ca04bd9b687d917f9bc @copiousfreetime committed Feb 28, 2010
Showing with 52 additions and 0 deletions.
  1. +30 −0 all-things-NoSQL.txt
  2. +9 −0 bio.txt
  3. +13 −0 plain-old-tokyo-storage.txt
@@ -0,0 +1,30 @@
+The 3rd step of {No}SQL
+Everyone should remember the "old" adage of the 3 steps to a startup:
+ 1. Idea
+ 2. ???
+ 3. Profit
+Those same 3 steps exist in all {No}SQL systems. And yes, I use {No} because
+its the same 3 steps if you are using a RDBMS fronted by a SQL engine.
+ 1. Data
+ 2. ???
+ 3. Store it in a B-Tree
+When you look at data storage systems they all look pretty much the same. You
+take away all the servers, all the data manipulation language, the wire
+protocols and say, "how do I persist this data to peramanent storeage?". The
+answer, overwhelmingly, is the classic B-Tree.
+- Knuth B-Tree.
+- Take a few of the NoSQL solutions, show the underlying storage
+- Take a few of the SQL solutions, show the underlying storage
+Tokyo Cabinet - B-Tree is one of the items
+MongoDB - B-Tree
+CouchDB - B-Tree
+Riak - riak_fs_backend - stores on disk filesystem, which is probably a b-tree
+Cassandra -
@@ -0,0 +1,9 @@
+Jeremy Hinegardner lives in Boulder, CO and has been programming Ruby since 2001. He
+deals with complex system issues and writes weird corner case gems such as heel,
+amalgalite, hitimes and a few others. Jeremy also contributes to the Fedora/EPEL
+community by packaging nginx, HAProxy, beanstalkd and a few other applications.
+He works for Collective Intellect managing the infrastructure and writing Ruby
+applications to move, munge, store and analyze social media data. In his
+copious free time plays at being a nature photographer.
@@ -0,0 +1,13 @@
+Plain Old Tokyo Storage
+This is a talk about the Tokyo Cabinet suite of products and their use in a
+production system.
+I will cover the basics of the Tokyo Cabinet suite of products and then dive
+into the story of into Collective Intellect uses Tokyo Tyrant and Varnish
+in a production system to manage 1.3 TiB of xml documents. These 1.8 Billion
+(and growing) documents are stored in a cluster of Tokyo Tyrant hash databases,
+fronted by a Varnish server, and configured with ruby programs.
+Areas I will cover are: why we are using Tyrant, our backup and recovery
+process, and our partitioning and scaling strategy.

0 comments on commit 533f809

Please sign in to comment.