2013-10-16 20:50:50 +02:00
|
|
|
// Copyright (c) 2013, Facebook, Inc. All rights reserved.
|
|
|
|
// This source code is licensed under the BSD-style license found in the
|
|
|
|
// LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
// of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
|
|
|
|
#include <map>
|
|
|
|
#include <memory>
|
|
|
|
#include <string>
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
#include <vector>
|
2013-10-16 20:50:50 +02:00
|
|
|
|
|
|
|
#include "db/db_impl.h"
|
2014-01-28 06:58:46 +01:00
|
|
|
#include "db/dbformat.h"
|
2013-11-20 01:29:42 +01:00
|
|
|
#include "db/table_properties_collector.h"
|
2013-10-29 01:54:09 +01:00
|
|
|
#include "rocksdb/table.h"
|
2014-09-05 18:53:04 +02:00
|
|
|
#include "rocksdb/immutable_options.h"
|
2013-11-20 07:00:48 +01:00
|
|
|
#include "table/block_based_table_factory.h"
|
2013-12-06 01:51:26 +01:00
|
|
|
#include "table/meta_blocks.h"
|
2014-01-28 06:58:46 +01:00
|
|
|
#include "table/plain_table_factory.h"
|
|
|
|
#include "table/table_builder.h"
|
2013-10-16 20:50:50 +02:00
|
|
|
#include "util/coding.h"
|
|
|
|
#include "util/testharness.h"
|
|
|
|
#include "util/testutil.h"
|
|
|
|
|
|
|
|
namespace rocksdb {
|
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
class TablePropertiesTest : public testing::Test,
|
|
|
|
public testing::WithParamInterface<bool> {
|
|
|
|
public:
|
|
|
|
virtual void SetUp() override { backward_mode_ = GetParam(); }
|
|
|
|
|
|
|
|
bool backward_mode_;
|
|
|
|
};
|
2013-10-16 20:50:50 +02:00
|
|
|
|
|
|
|
// TODO(kailiu) the following classes should be moved to some more general
|
|
|
|
// places, so that other tests can also make use of them.
|
|
|
|
// `FakeWritableFile` and `FakeRandomeAccessFile` bypass the real file system
|
|
|
|
// and therefore enable us to quickly setup the tests.
|
|
|
|
class FakeWritableFile : public WritableFile {
|
|
|
|
public:
|
|
|
|
~FakeWritableFile() { }
|
|
|
|
|
|
|
|
const std::string& contents() const { return contents_; }
|
|
|
|
|
2015-02-26 20:28:41 +01:00
|
|
|
virtual Status Close() override { return Status::OK(); }
|
|
|
|
virtual Status Flush() override { return Status::OK(); }
|
|
|
|
virtual Status Sync() override { return Status::OK(); }
|
2013-10-16 20:50:50 +02:00
|
|
|
|
2015-02-26 20:28:41 +01:00
|
|
|
virtual Status Append(const Slice& data) override {
|
2013-10-16 20:50:50 +02:00
|
|
|
contents_.append(data.data(), data.size());
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::string contents_;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
class FakeRandomeAccessFile : public RandomAccessFile {
|
|
|
|
public:
|
|
|
|
explicit FakeRandomeAccessFile(const Slice& contents)
|
|
|
|
: contents_(contents.data(), contents.size()) {
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual ~FakeRandomeAccessFile() { }
|
|
|
|
|
|
|
|
uint64_t Size() const { return contents_.size(); }
|
|
|
|
|
|
|
|
virtual Status Read(uint64_t offset, size_t n, Slice* result,
|
2015-02-26 20:28:41 +01:00
|
|
|
char* scratch) const override {
|
2013-10-16 20:50:50 +02:00
|
|
|
if (offset > contents_.size()) {
|
|
|
|
return Status::InvalidArgument("invalid Read offset");
|
|
|
|
}
|
|
|
|
if (offset + n > contents_.size()) {
|
|
|
|
n = contents_.size() - offset;
|
|
|
|
}
|
|
|
|
memcpy(scratch, &contents_[offset], n);
|
|
|
|
*result = Slice(scratch, n);
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::string contents_;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
class DumbLogger : public Logger {
|
|
|
|
public:
|
2015-02-01 20:08:19 +01:00
|
|
|
using Logger::Logv;
|
2015-02-26 20:28:41 +01:00
|
|
|
virtual void Logv(const char* format, va_list ap) override {}
|
|
|
|
virtual size_t GetLogFileSize() const override { return 0; }
|
2013-10-16 20:50:50 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
// Utilities test functions
|
2014-04-10 06:17:14 +02:00
|
|
|
namespace {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
void MakeBuilder(const Options& options, const ImmutableCFOptions& ioptions,
|
2014-01-27 22:53:22 +01:00
|
|
|
const InternalKeyComparator& internal_comparator,
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
const std::vector<std::unique_ptr<IntTblPropCollectorFactory>>*
|
|
|
|
int_tbl_prop_collector_factories,
|
2014-01-27 22:53:22 +01:00
|
|
|
std::unique_ptr<FakeWritableFile>* writable,
|
|
|
|
std::unique_ptr<TableBuilder>* builder) {
|
2013-10-16 20:50:50 +02:00
|
|
|
writable->reset(new FakeWritableFile);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
builder->reset(NewTableBuilder(
|
|
|
|
ioptions, internal_comparator, int_tbl_prop_collector_factories,
|
|
|
|
writable->get(), options.compression, options.compression_opts));
|
2013-10-16 20:50:50 +02:00
|
|
|
}
|
2014-04-10 06:17:14 +02:00
|
|
|
} // namespace
|
2013-10-16 20:50:50 +02:00
|
|
|
|
|
|
|
// Collects keys that starts with "A" in a table.
|
2013-11-20 01:29:42 +01:00
|
|
|
class RegularKeysStartWithA: public TablePropertiesCollector {
|
2013-10-16 20:50:50 +02:00
|
|
|
public:
|
2015-02-26 20:28:41 +01:00
|
|
|
const char* Name() const override { return "RegularKeysStartWithA"; }
|
2013-10-16 20:50:50 +02:00
|
|
|
|
2015-02-26 20:28:41 +01:00
|
|
|
Status Finish(UserCollectedProperties* properties) override {
|
2013-10-16 20:50:50 +02:00
|
|
|
std::string encoded;
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
std::string encoded_num_puts;
|
|
|
|
std::string encoded_num_deletes;
|
|
|
|
std::string encoded_num_size_changes;
|
2013-10-16 20:50:50 +02:00
|
|
|
PutVarint32(&encoded, count_);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
PutVarint32(&encoded_num_puts, num_puts_);
|
|
|
|
PutVarint32(&encoded_num_deletes, num_deletes_);
|
|
|
|
PutVarint32(&encoded_num_size_changes, num_size_changes_);
|
|
|
|
*properties = UserCollectedProperties{
|
|
|
|
{"TablePropertiesTest", message_},
|
|
|
|
{"Count", encoded},
|
|
|
|
{"NumPuts", encoded_num_puts},
|
|
|
|
{"NumDeletes", encoded_num_deletes},
|
|
|
|
{"NumSizeChanges", encoded_num_size_changes},
|
2013-10-16 20:50:50 +02:00
|
|
|
};
|
|
|
|
return Status::OK();
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
}
|
2013-10-16 20:50:50 +02:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
Status AddUserKey(const Slice& user_key, const Slice& value, EntryType type,
|
|
|
|
SequenceNumber seq, uint64_t file_size) override {
|
|
|
|
// simply asssume all user keys are not empty.
|
|
|
|
if (user_key.data()[0] == 'A') {
|
|
|
|
++count_;
|
|
|
|
}
|
|
|
|
if (type == kEntryPut) {
|
|
|
|
num_puts_++;
|
|
|
|
} else if (type == kEntryDelete) {
|
|
|
|
num_deletes_++;
|
|
|
|
}
|
|
|
|
if (file_size < file_size_) {
|
|
|
|
message_ = "File size should not decrease.";
|
|
|
|
} else if (file_size != file_size_) {
|
|
|
|
num_size_changes_++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual UserCollectedProperties GetReadableProperties() const override {
|
|
|
|
return UserCollectedProperties{};
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::string message_ = "Rocksdb";
|
|
|
|
uint32_t count_ = 0;
|
|
|
|
uint32_t num_puts_ = 0;
|
|
|
|
uint32_t num_deletes_ = 0;
|
|
|
|
uint32_t num_size_changes_ = 0;
|
|
|
|
uint64_t file_size_ = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Collects keys that starts with "A" in a table. Backward compatible mode
|
|
|
|
// It is also used to test internal key table property collector
|
|
|
|
class RegularKeysStartWithABackwardCompatible
|
|
|
|
: public TablePropertiesCollector {
|
|
|
|
public:
|
|
|
|
const char* Name() const override { return "RegularKeysStartWithA"; }
|
|
|
|
|
|
|
|
Status Finish(UserCollectedProperties* properties) override {
|
|
|
|
std::string encoded;
|
|
|
|
PutVarint32(&encoded, count_);
|
|
|
|
*properties = UserCollectedProperties{{"TablePropertiesTest", "Rocksdb"},
|
|
|
|
{"Count", encoded}};
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status Add(const Slice& user_key, const Slice& value) override {
|
|
|
|
// simply asssume all user keys are not empty.
|
|
|
|
if (user_key.data()[0] == 'A') {
|
|
|
|
++count_;
|
|
|
|
}
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual UserCollectedProperties GetReadableProperties() const override {
|
|
|
|
return UserCollectedProperties{};
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
uint32_t count_ = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
class RegularKeysStartWithAInternal : public IntTblPropCollector {
|
|
|
|
public:
|
|
|
|
const char* Name() const override { return "RegularKeysStartWithA"; }
|
|
|
|
|
|
|
|
Status Finish(UserCollectedProperties* properties) override {
|
|
|
|
std::string encoded;
|
|
|
|
PutVarint32(&encoded, count_);
|
|
|
|
*properties = UserCollectedProperties{{"TablePropertiesTest", "Rocksdb"},
|
|
|
|
{"Count", encoded}};
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status InternalAdd(const Slice& user_key, const Slice& value,
|
|
|
|
uint64_t file_size) override {
|
|
|
|
// simply asssume all user keys are not empty.
|
|
|
|
if (user_key.data()[0] == 'A') {
|
|
|
|
++count_;
|
|
|
|
}
|
|
|
|
return Status::OK();
|
|
|
|
}
|
2013-10-16 20:50:50 +02:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
virtual UserCollectedProperties GetReadableProperties() const override {
|
2014-02-12 02:52:18 +01:00
|
|
|
return UserCollectedProperties{};
|
2013-11-20 01:29:42 +01:00
|
|
|
}
|
|
|
|
|
2013-10-16 20:50:50 +02:00
|
|
|
private:
|
|
|
|
uint32_t count_ = 0;
|
|
|
|
};
|
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
class RegularKeysStartWithAFactory : public IntTblPropCollectorFactory,
|
|
|
|
public TablePropertiesCollectorFactory {
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
public:
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
explicit RegularKeysStartWithAFactory(bool backward_mode)
|
|
|
|
: backward_mode_(backward_mode) {}
|
2015-02-26 20:28:41 +01:00
|
|
|
virtual TablePropertiesCollector* CreateTablePropertiesCollector() override {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
if (!backward_mode_) {
|
|
|
|
return new RegularKeysStartWithA();
|
|
|
|
} else {
|
|
|
|
return new RegularKeysStartWithABackwardCompatible();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
virtual IntTblPropCollector* CreateIntTblPropCollector() override {
|
|
|
|
return new RegularKeysStartWithAInternal();
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
}
|
2015-02-26 20:28:41 +01:00
|
|
|
const char* Name() const override { return "RegularKeysStartWithA"; }
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
|
|
|
|
bool backward_mode_;
|
|
|
|
};
|
|
|
|
|
|
|
|
class FlushBlockEveryThreePolicy : public FlushBlockPolicy {
|
|
|
|
public:
|
|
|
|
virtual bool Update(const Slice& key, const Slice& value) override {
|
|
|
|
return (++count_ % 3U == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
uint64_t count_ = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
class FlushBlockEveryThreePolicyFactory : public FlushBlockPolicyFactory {
|
|
|
|
public:
|
|
|
|
explicit FlushBlockEveryThreePolicyFactory() {}
|
|
|
|
|
|
|
|
const char* Name() const override {
|
|
|
|
return "FlushBlockEveryThreePolicyFactory";
|
|
|
|
}
|
|
|
|
|
|
|
|
FlushBlockPolicy* NewFlushBlockPolicy(
|
|
|
|
const BlockBasedTableOptions& table_options,
|
|
|
|
const BlockBuilder& data_block_builder) const override {
|
|
|
|
return new FlushBlockEveryThreePolicy;
|
|
|
|
}
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
};
|
|
|
|
|
2015-07-02 01:13:49 +02:00
|
|
|
extern const uint64_t kBlockBasedTableMagicNumber;
|
|
|
|
extern const uint64_t kPlainTableMagicNumber;
|
2014-04-10 06:17:14 +02:00
|
|
|
namespace {
|
2013-12-06 01:51:26 +01:00
|
|
|
void TestCustomizedTablePropertiesCollector(
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
bool backward_mode, uint64_t magic_number, bool test_int_tbl_prop_collector,
|
|
|
|
const Options& options, const InternalKeyComparator& internal_comparator) {
|
|
|
|
const std::string kDeleteFlag = "D";
|
2013-10-16 20:50:50 +02:00
|
|
|
// make sure the entries will be inserted with order.
|
|
|
|
std::map<std::string, std::string> kvs = {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
{"About ", "val5"}, // starts with 'A'
|
|
|
|
{"Abstract", "val2"}, // starts with 'A'
|
|
|
|
{"Around ", "val7"}, // starts with 'A'
|
|
|
|
{"Beyond ", "val3"},
|
|
|
|
{"Builder ", "val1"},
|
|
|
|
{"Love ", kDeleteFlag},
|
|
|
|
{"Cancel ", "val4"},
|
|
|
|
{"Find ", "val6"},
|
|
|
|
{"Rocks ", kDeleteFlag},
|
2013-10-16 20:50:50 +02:00
|
|
|
};
|
|
|
|
|
2013-12-06 01:51:26 +01:00
|
|
|
// -- Step 1: build table
|
|
|
|
std::unique_ptr<TableBuilder> builder;
|
|
|
|
std::unique_ptr<FakeWritableFile> writable;
|
2014-09-05 18:53:04 +02:00
|
|
|
const ImmutableCFOptions ioptions(options);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
std::vector<std::unique_ptr<IntTblPropCollectorFactory>>
|
|
|
|
int_tbl_prop_collector_factories;
|
|
|
|
if (test_int_tbl_prop_collector) {
|
|
|
|
int_tbl_prop_collector_factories.emplace_back(
|
|
|
|
new RegularKeysStartWithAFactory(backward_mode));
|
|
|
|
} else {
|
|
|
|
GetIntTblPropCollectorFactory(options, &int_tbl_prop_collector_factories);
|
|
|
|
}
|
|
|
|
MakeBuilder(options, ioptions, internal_comparator,
|
|
|
|
&int_tbl_prop_collector_factories, &writable, &builder);
|
2013-12-06 01:51:26 +01:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
SequenceNumber seqNum = 0U;
|
2013-12-06 01:51:26 +01:00
|
|
|
for (const auto& kv : kvs) {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
InternalKey ikey(kv.first, seqNum++, (kv.second != kDeleteFlag)
|
|
|
|
? ValueType::kTypeValue
|
|
|
|
: ValueType::kTypeDeletion);
|
|
|
|
builder->Add(ikey.Encode(), kv.second);
|
2013-12-06 01:51:26 +01:00
|
|
|
}
|
|
|
|
ASSERT_OK(builder->Finish());
|
|
|
|
|
|
|
|
// -- Step 2: Read properties
|
|
|
|
FakeRandomeAccessFile readable(writable->contents());
|
2014-02-08 04:26:49 +01:00
|
|
|
TableProperties* props;
|
2013-12-06 01:51:26 +01:00
|
|
|
Status s = ReadTableProperties(
|
|
|
|
&readable,
|
|
|
|
writable->contents().size(),
|
|
|
|
magic_number,
|
|
|
|
Env::Default(),
|
|
|
|
nullptr,
|
|
|
|
&props
|
|
|
|
);
|
2014-02-08 04:26:49 +01:00
|
|
|
std::unique_ptr<TableProperties> props_guard(props);
|
2013-12-06 01:51:26 +01:00
|
|
|
ASSERT_OK(s);
|
|
|
|
|
2014-02-08 04:26:49 +01:00
|
|
|
auto user_collected = props->user_collected_properties;
|
2013-12-06 01:51:26 +01:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
ASSERT_TRUE(user_collected.find("TablePropertiesTest") !=
|
|
|
|
user_collected.end());
|
2013-12-06 01:51:26 +01:00
|
|
|
ASSERT_EQ("Rocksdb", user_collected.at("TablePropertiesTest"));
|
|
|
|
|
|
|
|
uint32_t starts_with_A = 0;
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
ASSERT_TRUE(user_collected.find("Count") != user_collected.end());
|
2013-12-06 01:51:26 +01:00
|
|
|
Slice key(user_collected.at("Count"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key, &starts_with_A));
|
|
|
|
ASSERT_EQ(3u, starts_with_A);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
|
|
|
|
if (!backward_mode && !test_int_tbl_prop_collector) {
|
|
|
|
uint32_t num_deletes;
|
|
|
|
ASSERT_TRUE(user_collected.find("NumDeletes") != user_collected.end());
|
|
|
|
Slice key_deletes(user_collected.at("NumDeletes"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key_deletes, &num_deletes));
|
|
|
|
ASSERT_EQ(2u, num_deletes);
|
|
|
|
|
|
|
|
uint32_t num_puts;
|
|
|
|
ASSERT_TRUE(user_collected.find("NumPuts") != user_collected.end());
|
|
|
|
Slice key_puts(user_collected.at("NumPuts"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key_puts, &num_puts));
|
|
|
|
ASSERT_EQ(7u, num_puts);
|
|
|
|
|
|
|
|
uint32_t num_size_changes;
|
|
|
|
ASSERT_TRUE(user_collected.find("NumSizeChanges") != user_collected.end());
|
|
|
|
Slice key_size_changes(user_collected.at("NumSizeChanges"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key_size_changes, &num_size_changes));
|
|
|
|
ASSERT_GE(num_size_changes, 2u);
|
|
|
|
}
|
2013-12-06 01:51:26 +01:00
|
|
|
}
|
2014-04-10 06:17:14 +02:00
|
|
|
} // namespace
|
2013-12-06 01:51:26 +01:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
TEST_P(TablePropertiesTest, CustomizedTablePropertiesCollector) {
|
2013-11-20 01:29:42 +01:00
|
|
|
// Test properties collectors with internal keys or regular keys
|
2013-12-06 01:51:26 +01:00
|
|
|
// for block based table
|
2013-10-16 20:50:50 +02:00
|
|
|
for (bool encode_as_internal : { true, false }) {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
if (!backward_mode_ && !encode_as_internal) {
|
|
|
|
continue;
|
2013-10-16 20:50:50 +02:00
|
|
|
}
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
|
|
|
|
Options options;
|
|
|
|
BlockBasedTableOptions table_options;
|
|
|
|
table_options.flush_block_policy_factory =
|
|
|
|
std::make_shared<FlushBlockEveryThreePolicyFactory>();
|
|
|
|
options.table_factory.reset(NewBlockBasedTableFactory(table_options));
|
|
|
|
|
2014-01-27 22:53:22 +01:00
|
|
|
test::PlainInternalKeyComparator ikc(options.comparator);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
std::shared_ptr<TablePropertiesCollectorFactory> collector_factory(
|
|
|
|
new RegularKeysStartWithAFactory(backward_mode_));
|
|
|
|
options.table_properties_collector_factories.resize(1);
|
|
|
|
options.table_properties_collector_factories[0] = collector_factory;
|
|
|
|
|
|
|
|
TestCustomizedTablePropertiesCollector(backward_mode_,
|
|
|
|
kBlockBasedTableMagicNumber,
|
2014-01-27 22:53:22 +01:00
|
|
|
encode_as_internal, options, ikc);
|
2013-12-06 01:51:26 +01:00
|
|
|
|
2015-07-02 01:13:49 +02:00
|
|
|
#ifndef ROCKSDB_LITE // PlainTable is not supported in Lite
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
// test plain table
|
|
|
|
PlainTableOptions plain_table_options;
|
|
|
|
plain_table_options.user_key_len = 8;
|
|
|
|
plain_table_options.bloom_bits_per_key = 8;
|
|
|
|
plain_table_options.hash_table_ratio = 0;
|
2014-07-18 09:08:38 +02:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
options.table_factory =
|
|
|
|
std::make_shared<PlainTableFactory>(plain_table_options);
|
|
|
|
TestCustomizedTablePropertiesCollector(backward_mode_,
|
|
|
|
kPlainTableMagicNumber,
|
|
|
|
encode_as_internal, options, ikc);
|
2015-07-02 01:13:49 +02:00
|
|
|
#endif // !ROCKSDB_LITE
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
}
|
2013-10-16 20:50:50 +02:00
|
|
|
}
|
|
|
|
|
2014-04-10 06:17:14 +02:00
|
|
|
namespace {
|
2013-12-06 01:51:26 +01:00
|
|
|
void TestInternalKeyPropertiesCollector(
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
bool backward_mode, uint64_t magic_number, bool sanitized,
|
2013-12-06 01:51:26 +01:00
|
|
|
std::shared_ptr<TableFactory> table_factory) {
|
2013-10-16 20:50:50 +02:00
|
|
|
InternalKey keys[] = {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
InternalKey("A ", 0, ValueType::kTypeValue),
|
|
|
|
InternalKey("B ", 1, ValueType::kTypeValue),
|
|
|
|
InternalKey("C ", 2, ValueType::kTypeValue),
|
|
|
|
InternalKey("W ", 3, ValueType::kTypeDeletion),
|
|
|
|
InternalKey("X ", 4, ValueType::kTypeDeletion),
|
|
|
|
InternalKey("Y ", 5, ValueType::kTypeDeletion),
|
|
|
|
InternalKey("Z ", 6, ValueType::kTypeDeletion),
|
2013-10-16 20:50:50 +02:00
|
|
|
};
|
|
|
|
|
2013-12-06 01:51:26 +01:00
|
|
|
std::unique_ptr<TableBuilder> builder;
|
|
|
|
std::unique_ptr<FakeWritableFile> writable;
|
|
|
|
Options options;
|
2014-01-27 22:53:22 +01:00
|
|
|
test::PlainInternalKeyComparator pikc(options.comparator);
|
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
std::vector<std::unique_ptr<IntTblPropCollectorFactory>>
|
|
|
|
int_tbl_prop_collector_factories;
|
2013-12-06 01:51:26 +01:00
|
|
|
options.table_factory = table_factory;
|
|
|
|
if (sanitized) {
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
options.table_properties_collector_factories.emplace_back(
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
new RegularKeysStartWithAFactory(backward_mode));
|
2013-12-06 01:51:26 +01:00
|
|
|
// with sanitization, even regular properties collector will be able to
|
|
|
|
// handle internal keys.
|
|
|
|
auto comparator = options.comparator;
|
|
|
|
// HACK: Set options.info_log to avoid writing log in
|
|
|
|
// SanitizeOptions().
|
|
|
|
options.info_log = std::make_shared<DumbLogger>();
|
2014-01-27 22:53:22 +01:00
|
|
|
options = SanitizeOptions("db", // just a place holder
|
2014-08-25 23:22:05 +02:00
|
|
|
&pikc,
|
2014-01-27 22:53:22 +01:00
|
|
|
options);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
GetIntTblPropCollectorFactory(options, &int_tbl_prop_collector_factories);
|
2013-12-06 01:51:26 +01:00
|
|
|
options.comparator = comparator;
|
|
|
|
} else {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
int_tbl_prop_collector_factories.emplace_back(
|
|
|
|
new InternalKeyPropertiesCollectorFactory);
|
2013-12-06 01:51:26 +01:00
|
|
|
}
|
2014-09-05 18:53:04 +02:00
|
|
|
const ImmutableCFOptions ioptions(options);
|
2013-10-16 20:50:50 +02:00
|
|
|
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
for (int iter = 0; iter < 2; ++iter) {
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
MakeBuilder(options, ioptions, pikc, &int_tbl_prop_collector_factories,
|
|
|
|
&writable, &builder);
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
for (const auto& k : keys) {
|
|
|
|
builder->Add(k.Encode(), "val");
|
|
|
|
}
|
2013-10-16 20:50:50 +02:00
|
|
|
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
ASSERT_OK(builder->Finish());
|
|
|
|
|
|
|
|
FakeRandomeAccessFile readable(writable->contents());
|
|
|
|
TableProperties* props;
|
|
|
|
Status s =
|
|
|
|
ReadTableProperties(&readable, writable->contents().size(),
|
|
|
|
magic_number, Env::Default(), nullptr, &props);
|
|
|
|
ASSERT_OK(s);
|
|
|
|
|
|
|
|
std::unique_ptr<TableProperties> props_guard(props);
|
|
|
|
auto user_collected = props->user_collected_properties;
|
|
|
|
uint64_t deleted = GetDeletedKeys(user_collected);
|
|
|
|
ASSERT_EQ(4u, deleted);
|
|
|
|
|
|
|
|
if (sanitized) {
|
|
|
|
uint32_t starts_with_A = 0;
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
ASSERT_TRUE(user_collected.find("Count") != user_collected.end());
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
Slice key(user_collected.at("Count"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key, &starts_with_A));
|
|
|
|
ASSERT_EQ(1u, starts_with_A);
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
|
|
|
|
if (!backward_mode) {
|
|
|
|
uint32_t num_deletes;
|
|
|
|
ASSERT_TRUE(user_collected.find("NumDeletes") != user_collected.end());
|
|
|
|
Slice key_deletes(user_collected.at("NumDeletes"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key_deletes, &num_deletes));
|
|
|
|
ASSERT_EQ(4u, num_deletes);
|
|
|
|
|
|
|
|
uint32_t num_puts;
|
|
|
|
ASSERT_TRUE(user_collected.find("NumPuts") != user_collected.end());
|
|
|
|
Slice key_puts(user_collected.at("NumPuts"));
|
|
|
|
ASSERT_TRUE(GetVarint32(&key_puts, &num_puts));
|
|
|
|
ASSERT_EQ(3u, num_puts);
|
|
|
|
}
|
TablePropertiesCollectorFactory
Summary:
This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
Here's description of task #4296714:
I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
For example, this table has 3155 entries and 1391828 deleted keys.
The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
Test Plan:
Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
Also, all other tests
Reviewers: sdong, dhruba, haobo, kailiu
Reviewed By: kailiu
CC: leveldb
Differential Revision: https://reviews.facebook.net/D18579
2014-05-13 21:30:55 +02:00
|
|
|
}
|
2013-10-16 20:50:50 +02:00
|
|
|
}
|
|
|
|
}
|
2014-04-10 06:17:14 +02:00
|
|
|
} // namespace
|
2013-10-16 20:50:50 +02:00
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
TEST_P(TablePropertiesTest, InternalKeyPropertiesCollector) {
|
2013-12-06 01:51:26 +01:00
|
|
|
TestInternalKeyPropertiesCollector(
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
backward_mode_, kBlockBasedTableMagicNumber, true /* sanitize */,
|
|
|
|
std::make_shared<BlockBasedTableFactory>());
|
|
|
|
if (backward_mode_) {
|
|
|
|
TestInternalKeyPropertiesCollector(
|
|
|
|
backward_mode_, kBlockBasedTableMagicNumber, false /* not sanitize */,
|
|
|
|
std::make_shared<BlockBasedTableFactory>());
|
|
|
|
}
|
2014-07-18 09:08:38 +02:00
|
|
|
|
2015-07-02 01:13:49 +02:00
|
|
|
#ifndef ROCKSDB_LITE // PlainTable is not supported in Lite
|
2014-07-18 09:08:38 +02:00
|
|
|
PlainTableOptions plain_table_options;
|
|
|
|
plain_table_options.user_key_len = 8;
|
|
|
|
plain_table_options.bloom_bits_per_key = 8;
|
|
|
|
plain_table_options.hash_table_ratio = 0;
|
|
|
|
|
2013-12-06 01:51:26 +01:00
|
|
|
TestInternalKeyPropertiesCollector(
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
backward_mode_, kPlainTableMagicNumber, false /* not sanitize */,
|
2014-07-18 09:08:38 +02:00
|
|
|
std::make_shared<PlainTableFactory>(plain_table_options));
|
2015-07-02 01:13:49 +02:00
|
|
|
#endif // !ROCKSDB_LITE
|
2013-12-06 01:51:26 +01:00
|
|
|
}
|
|
|
|
|
A new call back to TablePropertiesCollector to allow users know the entry is add, delete or merge
Summary:
Currently users have no idea a key is add, delete or merge from TablePropertiesCollector call back. Add a new function to add it.
Also refactor the codes so that
(1) make table property collector and internal table property collector two separate data structures with the later one now exposed
(2) table builders only receive internal table properties
Test Plan: Add cases in table_properties_collector_test to cover both of old and new ways of using TablePropertiesCollector.
Reviewers: yhchiang, igor.sugak, rven, igor
Reviewed By: rven, igor
Subscribers: meyering, yoshinorim, maykov, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D35373
2015-04-06 19:04:30 +02:00
|
|
|
INSTANTIATE_TEST_CASE_P(InternalKeyPropertiesCollector, TablePropertiesTest,
|
|
|
|
::testing::Bool());
|
|
|
|
|
|
|
|
INSTANTIATE_TEST_CASE_P(CustomizedTablePropertiesCollector, TablePropertiesTest,
|
|
|
|
::testing::Bool());
|
|
|
|
|
2013-10-16 20:50:50 +02:00
|
|
|
} // namespace rocksdb
|
|
|
|
|
|
|
|
int main(int argc, char** argv) {
|
2015-03-17 22:08:00 +01:00
|
|
|
::testing::InitGoogleTest(&argc, argv);
|
|
|
|
return RUN_ALL_TESTS();
|
2013-10-16 20:50:50 +02:00
|
|
|
}
|