Andrew Kryczka a22b9cc6fe overlapping endpoint fixes in level compaction picker
Summary:
This diff addresses two problems. Both problems cause us to miss scheduling desirable compactions. One side effect is compaction picking can spam logs, as there's no delay after failed attempts to pick compactions.

1. If a compaction pulled in a locked input-level file due to user-key overlap, we would not consider picking another file from the same input level.
2. If a compaction pulled in a locked output-level file due to user-key overlap, we would not consider picking any other compaction on any level.

The code changes are dependent, which is why I solved both problems in a single diff.

- Moved input-level `ExpandInputsToCleanCut` into the loop inside `PickFileToCompact`. This gives two benefits: (1) if it fails, we will try the next-largest file on the same input level; (2) we get the fully-expanded input-level key-range with which we can check for pending compactions in output level.
- Added another call to `ExpandInputsToCleanCut` inside `PickFileToCompact`'s to check for compaction conflicts in output level.
- Deleted call to `IsRangeInCompaction` in `PickFileToCompact`, as `ExpandInputsToCleanCut` also correctly handles the case where original output-level files (i.e., ones not pulled in due to user-key overlap) are pending compaction.
Closes https://github.com/facebook/rocksdb/pull/2615

Differential Revision: D5454643

Pulled By: ajkr

fbshipit-source-id: ea3fb5477d83e97148951af3fd4558d2039e9872
2017-07-19 20:42:00 -07:00
2017-07-14 15:45:36 -07:00
2017-07-17 15:08:30 -07:00
2017-04-06 14:09:13 -07:00
2014-11-03 14:53:00 -08:00
2017-07-05 16:41:30 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-18 13:12:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-18 11:56:57 -07:00
2017-07-15 16:11:23 -07:00
2017-05-23 10:42:59 -07:00
2017-04-05 11:39:20 -07:00
2014-09-29 10:52:18 -07:00
2017-04-27 18:06:12 -07:00
2017-07-13 13:36:48 -07:00
2017-02-16 17:24:10 -08:00
2017-07-15 16:11:23 -07:00
2017-07-10 12:29:24 -07:00
2016-07-26 13:54:08 -07:00
2015-05-29 14:36:35 -07:00
2017-07-14 15:45:36 -07:00
2017-06-13 16:58:01 -07:00

RocksDB: A Persistent Key-Value Store for Flash and RAM Storage

Build Status Build status

RocksDB is developed and maintained by Facebook Database Engineering Team. It is built on earlier work on LevelDB by Sanjay Ghemawat (sanjay@google.com) and Jeff Dean (jeff@google.com)

This code is a library that forms the core building block for a fast key value server, especially suited for storing data on flash drives. It has a Log-Structured-Merge-Database (LSM) design with flexible tradeoffs between Write-Amplification-Factor (WAF), Read-Amplification-Factor (RAF) and Space-Amplification-Factor (SAF). It has multi-threaded compactions, making it specially suitable for storing multiple terabytes of data in a single database.

Start with example usage here: https://github.com/facebook/rocksdb/tree/master/examples

See the github wiki for more explanation.

The public interface is in include/. Callers should not include or rely on the details of any other header files in this package. Those internal APIs may be changed without warning.

Design discussions are conducted in https://www.facebook.com/groups/rocksdb.dev/

Description
A library that provides an embeddable, persistent key-value store for fast storage.
Readme 271 MiB
Languages
C++ 82.1%
Java 10.3%
C 2.5%
Python 1.7%
Perl 1.1%
Other 2.1%