Set VERSIONS => 1 on the 'tsdb' table.

We never need more than one version of each cell, so tell HBase to not
bother with older versions (as the default is to keep 3 versions).
The schema was always meant to be like that but the script was wrong.

Issue reported by Steve Hoffman.

Change-Id: I38053d7018de0e472c3fdf44195d9710bb675ecf
Update asynchbase from 1.0 to 1.1.0.

Change-Id: I17f4d7b6f2df884970f7d07af8a1a36b29073ac5
Add some simple internal helpers to send HBase RPCs.

Change-Id: I21b586f1e6400912554adbfd297ab96028435e00
Don't log "Connection reset by peer" errors.

They just spam the logs unnecessarily.

Change-Id: I6fb9081474c97142888e85b89e8fe130e0aebcac
Improved schema: compact the data in HBase.

This is a major change.  New data points written by this code aren't
readable by older versions of the code.  The new behavior is turned
off by default, however.  After turning on the new behavior, instead
of rolling back, you can turn it off again if you observe problems.
In order to turn on the new compaction code, the JVM system property
"tsd.feature.compactions" needs to be set.  You can set this by in
your `tsdb.local' file like so:
  JVMARGS='-Dtsd.feature.compactions'

With this change the TSD remembers every row it's writing to in HBase.
Periodically, it will read back old rows from HBase, and rewrite them
in a more efficient format.  The compacted form consists mostly in
concatenating together all the qualifiers and values inside that row.

When the TSD reads a row that isn't compacted properly (or at all)
it will fix it by overwriting the row again.  So the code is handling
properly weird cases such as data points coming in with very old
timestamps or out of order data etc.  It also handles properly races
in case multiple concurrent TSDs attempt to compact the same row at
the same time.

In order for this change to be truly effective, it's important to have
HBase compactions turned on, this way HBase can purge the individual
data points and keep the compacted form only.  If you wish to leave
HBase compactions turned off, consider triggering them periodically
(either via a cron job, or manually).

Note: `fsck' currently doesn't support the compacted rows, and will
emit a warning when it sees one.  Another commit will add support for
compacted rows in `fsck' in the future.

Change-Id: Ibc8f0154f7dd79d5337fa7effb645a297f9f94b2
Make the read path work in O(N) again.

After the changes to `RowSeq' to support reading compacted rows, the
code kept using naive `DataPointsIterator', which does random access
into the data structure.  With variable length encoding, we can no
longer locate the n-th value in O(1), so the code needed a O(N) walk
to find each data point, leading to an quadratic loop when iterating
on all the data points in a `RowSeq'.

With this change, `RowSeq' uses its own custom iterator implementation
instead of `DataPointsIterator' in order to work in O(N) [single pass].

Change-Id: I98d00e1b30463542134e087243c6243e4c03ac3a
Add 2 more stats on compaction activities.

Change-Id: Ieb1961516fb96f11257f99d3c1d07efbd325a660
Properly handle throttling requests from asynchbase.

Compactions rewrite so much data that they're very likely to cause
region splits in HBase.  When they do, they keep sending tons of
requests to the HBase client, which eventually makes them all fail
with a PleaseThrottleException, due to the nature of its completely
non-blocking asynchronous implementation.  When we get such this
exception, we simply re-queue the row for compaction again, to try
to compact it later.

Change-Id: Ie7f5c4291c82ce9485243b7265763a399150f3d1
Dynamically compute how many rows to flush per iteration.

This ensures that we flush more aggressively when under pressure.

Change-Id: Ie82f93b080e1841b560e6a34a288cda9e755f65e
Make the compaction thread more robust.

A Throwable that isn't an Exception could kill the thread.  This is bad
as without this thread the TSD will slowly but surely run out of memory.
We can handle OOME by dropping the queue on the floor to free up memory.
Other Throwables will just cause the thread to die after 1s, but a new
one will be created to replace it.

Change-Id: I2bdb65338da43a0f366cdaa6b2b2e7aeabcd503e
Limit the number of concurrent flushes that can happen.

When the CompactionQueue contains, say, 1M rows, and flush() is called,
the code was attempting to compact all these rows concurrently.  This
is unrealistic and can either kill HBase and/or run the TSD out of RAM.
With this change, a single call to flush() can only initiate up to 10k
concurrent compactions, after which the code asynchronously waits until
the batch of 10k is done before flushing more.

Change-Id: I05ec3839e08f13455f80b3aba31acf5f42c7ac38
Don't flush the entire compaction queue on shutdown.

It's just too much work and most of it is unnecessary.  Here's why.
In a typical setup, you'd have at least 2 TSD to be N + 1.  If you
shutdown the first one, all the traffic will shift to the other one
by virtue of tcollectors reconnecting elsewhere.  This is going to
"fault in" almost all the rows that were in the compaction queue of
the TSD that got shutdown, so the other TSD will eventually compact
them.  It's possible that few rows will be left behind, and it's OK
since they can always be compacted later on subsequent reads.

Flushing the entire queue simply takes too long.  If there are, say,
600k rows sitting in the queue, and the TSD is able to flush 2500/s,
it would take 4 minutes to flush them all.  So instead we only flush
the ones we were really supposed to flush anyway, that is the rows
that are over 1h old.

Change-Id: I4594b714ebf0d831c9fb8d314a38154439166ec0
Stop (ab)using reflection in tools.

Instead create an `Internal' module that exposes some internal API.
Although this breaks encapsulation, both the name of the module and
its Javadoc comment make it clear that this module isn't part of the
public API.  This makes the code easier to program / maintain than
with reflection, which is a PITA in Java (and that's not necessarily
a bad thing).

Change-Id: I6bf27c0b45524f605838db8b4c7b9d721f435a68
Add support for compacted cells in fsck.

Change-Id: Iceeb1ab40026087a3307f24dd38bebf9e21a5198
Properly handle malformed query strings.

Change-Id: Iab42fa9429fb32156a22fcf7cdab974a5a2c14db
Update to JUnit 4.10.

Change-Id: I46502c17b05a6581f32da9ab8a8b256bc522aa50
Upgrade to Mockito 1.9.0.

Change-Id: I422549714e3b464e0dc70ff559db84811c84b92d
Upgrade to PowerMock 1.4.10.

Change-Id: Ic49c7e5af251e9a68e4b922b49fed02ffe2198c6
Upgrade to logback 1.0.0.

Change-Id: Ifd3d2e81646039e435531047b7a036dd8c19b816
Upgrade to SLF4J 1.6.4.

Change-Id: Ie6acf8c253ab9cad26f86756f5557a7268f2fa20