Follow Up to yesterday's meeting
Mark Phillips
First and foremost, a big thanks to everyone who showed up last night
and to Daniel for presenting. I think we can all agree it was a great
first meeting.
A few things:
1) Kyle Smith was kind enough to type up and send me along his
meeting notes. They are attached.
2) For those of you who were there yesterday: what did you think of
the format and approach we took? Any suggestions for making it more
informative/interactive/worthwhile?
Have a great weekend.
Mark
Community Manager
Basho Technologies
wiki.basho.com
twitter.com/pharkmillups
Daniel Weinreb
Mark Phillips said the following on 7/2/2010 3:18 PM:
> 2) For those of you who were there yesterday: what did you think of
> the format and approach we took?
I think it worked just fine in this case: the speaker had a prepared talk
and he gave it, and took questions. It's a traditional format that works
fine for this. I can imagine future meetings that might work differently.
For example, you could let several people have the opportunity
of explaining their own use cases or their own solutions.
The best thing about an informal group is that we can share
experiences, including negative ones. It's so valuable to
hear failure stories from other engineers. You learn a
great deal from them. They're hard to come by sometimes
since people don't want other people to know about their
failures. So that makes them extra-valuable.
By the way, the speaker and what he had to say were
fascinating. Hearing the talk was very worthwhile!
-- Dan
Daniel Weinreb
comprehensive. I've tried to do this at other talks so I can
appreciate what a good job this is.
This talk got me so interested that I bought a copy of "Hadoop: The
Definitive Guide." I've only just started reading it, but already
I've learned a lot. By the way, I'm finding it to be very well-written!
Here are some comments:
== Problem statement ==
Google: massive amounts of data to store and process
Needed a system to store "big data."
It's true that it's "big data", but not just any large data set.
What I learned from the book is that HDFS, the underlying file system,
is very much designed for data that is very large, write-once or
append-to-end-only, such as log files and other incoming data. It's
not good for not-huge files, and it does not have low latency; it has
high throughput. So its "sweet spot" is doing batch analysis of
incoming data such as log files.
Built on top of Hadoop
Teeny correction: technically, HBase is part of Hadoop. It's build on
HDFS.
HBase increments counters very well
When I heard this, it rung a bell in my mind. I asked Daniel and he
confirmed that the reason that increments are so fast is that the
concurrency control and recovery in the database treat "increment" as
an operation distinct from "read" and "write", and take advantage of
the fact that "increment" operations are commutative. One way this
can work in a traditional DBMS's concurrency control is that when a
transaction increments a variable, it grabs a lock in "increment"
state, rather than "write". A lock held for "write" does not allow
other transactions to proceed if they need to "write", but with
"increment", they can go ahead. This property also can help with
recovery (e.g. logging). This trick was first discovered long ago, in
an IBM product called IMS Fast Path:
http://en.wikipedia.org/wiki/IBM_Information_Management_System#.22Fast_path.22_databases
Selecting the key is pretty important. You want related data
stored together, but also don't want to suffer hot spots because
your keys happen to be similar.
The traditional problem with incoming data is that everybody wants to
write at the end of the file/database/tablespace, causing massive
concurrency conflicts (hot spots). The increment trick helps.
Example: Firefox crash reports include a date that was originally
used as the key, but it lead to hot spots because reports would be
added so frequently. In order to spread out the load, the first
hex digit from the GUID included in the report was prepended to
the date.
This spreads out the incoming data across several files. The drawback
is that if you want to query the data, your query has to know that
this is being done, and query all the different files. To a
traditional DBMS person, this is considered very undesirable, because
you're exposing an internal efficiency hack to the external API.
Changes to internals shouldn't require changes to the API, so that
future performance improvements won't break the code. Evidently they
don't have a layer of abstraction to hide this from apps, or else they
do but Daniel didn't get into that level of detail.
-- Dan