This commit adds a write ahead log to the shard. Entries are cached
in memory and periodically flushed back into the index. The WAL and
the cache are both partitioned into buckets so that flushing doesn't
stop the world as long.
Field values that were out of range for the type would panic the database
when being inserted because the parser would allow them as valid points.
This change prevents those invalid values from being parsed and instead
returns an error.
An alternative fix considered was to handle the error and clamp the value
to the min/max value for the type. This would treat numeric range errors
slightly differently than other type erros which might lead to confusion.
The simplest fix with the current parser would be to just convert each field
to the type at parse time. Unfortunately, this adds extra memory allocations
and lowers throughput significantly. Since out of range values are less common
than in-range values, some heuristics are used to determine when the more
expensive type parsing and range checking is performed. Essentially, we only
do the slow path when we cannot determine that the value is in an acceptable
type range.
Fixes#3127
Provides a little more flexibility in controlling the parsed
metric names for metris like:
servers.localhost.cpu.cpu0.user
Previously, you could only use a single field like "cpu", "user"
or a wildcard to match "cpu.cpu0.user". You can now pull out "cpu"
and "user" and join them together in the metric name using a custom
separator character. By default this is ".".
This adds a sorted search tree for matchining filters to a template
more efficiently. Each filter is split on "." and each element is
added to the tree. Patterns with matching prefixes are added under
the same subtree.