Keys in SST files on L1 overlaps

[koldat]

I was writing some test and found something I am not able to explain and not sure if it is correct behavior. Basically I have a test that put same key multiple times and flush after each put (creates SST). Then start manual compaction. All files are trivial moved to L1 so that L1 end up with SSTs where each key is overlapping. Is this some serious problem? I am not able to say if it cannot cause some issue as Get is returning correct value (maybe based on sequence).

Expected behavior

L1 should have only 1 file.

Actual behavior

L1 has 4 files.

Steps to reproduce the behavior

int main() {
  DB* db;
  Options options;
  options.create_if_missing = true;

  // open DB
  Status s = DB::Open(options, kDBPath, &db);
  assert(s.ok());

  std::string value;
  for (int i = 0; i < 4; i++) {
    // Put key-value
    s = db->Put(WriteOptions(), "aaaa1", std::to_string(i));
    assert(s.ok());

    s = db->Flush(FlushOptions());
    assert(s.ok());

    s = db->Get(ReadOptions(), "aaaa1", &value);
    assert(s.ok());
    assert(value == std::to_string(i));
  }

  s = db->CompactRange(CompactRangeOptions(), nullptr, nullptr);

  s = db->Get(ReadOptions(), "aaaa1", &value);
  assert(s.ok());
  assert(value == "3");
  delete db;

  return 0;
}

Directory listing:

-rw-r--r--  1 root root   988 Feb 23 14:39 000009.sst
-rw-r--r--  1 root root   988 Feb 23 14:39 000011.sst
-rw-r--r--  1 root root   988 Feb 23 14:39 000013.sst
-rw-r--r--  1 root root     0 Feb 23 14:39 000014.log
-rw-r--r--  1 root root   988 Feb 23 14:39 000015.sst
-rw-r--r--  1 root root    16 Feb 23 14:39 CURRENT
-rw-r--r--  1 root root    36 Feb 23 14:39 IDENTITY
-rw-r--r--  1 root root     0 Feb 23 14:39 LOCK
-rw-r--r--  1 root root 38555 Feb 23 14:39 LOG
-rw-r--r--  1 root root   632 Feb 23 14:39 MANIFEST-000004
-rw-r--r--  1 root root  6536 Feb 23 14:39 OPTIONS-000007

End of LOG file
2022/02/23-14:39:19.656360 13997 [/db_impl/db_impl_compaction_flush.cc:1847] [default] Manual compaction waiting for all other scheduled background compactions to finish
2022/02/23-14:39:19.665301 13998 (Original Log Time 2022/02/23-14:39:19.655645) [/db_impl/db_impl_compaction_flush.cc:3265] [default] Moving #15 to level-1 988 bytes
2022/02/23-14:39:19.665309 13998 (Original Log Time 2022/02/23-14:39:19.655662) [/db_impl/db_impl_compaction_flush.cc:3265] [default] Moving #13 to level-1 988 bytes
2022/02/23-14:39:19.665314 13998 (Original Log Time 2022/02/23-14:39:19.655664) [/db_impl/db_impl_compaction_flush.cc:3265] [default] Moving #11 to level-1 988 bytes
2022/02/23-14:39:19.665318 13998 (Original Log Time 2022/02/23-14:39:19.655666) [/db_impl/db_impl_compaction_flush.cc:3265] [default] Moving #9 to level-1 988 bytes
2022/02/23-14:39:19.665324 13998 (Original Log Time 2022/02/23-14:39:19.665248) EVENT_LOG_v1 {"time_micros": 1645623559665224, "job": 6, "event": "trivial_move", "destination_level": 1, "files": 4, "total_files_size": 3952}
2022/02/23-14:39:19.665330 13998 (Original Log Time 2022/02/23-14:39:19.665264) [/db_impl/db_impl_compaction_flush.cc:3294] [default] Moved #4 files to level-1 3952 bytes OK: files[0 4 0 0 0 0 0] max score 0.00

Test was executed on current main branch, but I can reproduce on older branches as well (6.22).

[ajkr]

Looks alright. The files appear non-overlapping from an internal key perspective since each one contains a key with a different sequence number, like you said.