Commit sst in dedicated threads

[rockeet]

Execute Rdb_sst_info::commit_sst_file in dedicated threads, this improves performance:

1. Rdb_sst_file_ordered::commit may use stack to reverse input data, this is time consuming
2. m_sst_file_writer->Finish may be consuming, at least it need to call fsync

Execute Rdb_sst_info::commit_sst_file in dedicated threads increase parallelization with mimimal code changes.

[bladepan]

consider std::lock_guardstd::mutex? we use RDB_MUTEX_LOCK_CHECK macros elsewhere in this file

[bladepan]

do we need to grab a log here too?

[bladepan]

Execute Rdb_sst_info::commit_sst_file in dedicated threads, this improves performance:

1. `Rdb_sst_file_ordered::commit` may use stack to reverse input data, this is time consuming

2. `m_sst_file_writer->Finish` may be consuming, at least it need to call `fsync`

Execute Rdb_sst_info::commit_sst_file in dedicated threads increase parallelization with mimimal code changes.

1. the keys are already ordered, why it would reverse input data?
2. the fsync happens when writing sst file to disk?

could you please provide some rough calculations about the time savings?

[rockeet]

Execute Rdb_sst_info::commit_sst_file in dedicated threads, this improves performance:

1. `Rdb_sst_file_ordered::commit` may use stack to reverse input data, this is time consuming

2. `m_sst_file_writer->Finish` may be consuming, at least it need to call `fsync`

Execute Rdb_sst_info::commit_sst_file in dedicated threads increase parallelization with mimimal code changes.

1. the keys are already ordered, why it would reverse input data?
2. the fsync happens when writing sst file to disk?

could you please provide some rough calculations about the time savings?

1. In Rdb_sst_file_ordered::commit(), if m_use_stack is true, it will write kv from stack.
2. In Rdb_sst_file_ordered::Rdb_sst_file::commit(), it calls m_sst_file_writer->Finish(), in which will write file and call fsync.

In our private branch, when m_use_stack is true(reverse cf), create index time reduces 30+%.

[bladepan]

1. In `Rdb_sst_file_ordered::commit()`, if `m_use_stack` is true, it will write kv from stack.

2. In `Rdb_sst_file_ordered::Rdb_sst_file::commit()`, it calls `m_sst_file_writer->Finish()`, in which will write file and call fsync.

In our private branch, when m_use_stack is true(reverse cf), create index time reduces 30+%.

Rdb_index_merge and Rdb_sst_file_ordered both use cf's comparator, when Rdb_index_merge write to Rdb_sst_file_ordered, the keys should be in cf's increasing order, m_use_stack should be false in this case.

[rockeet]

1. In `Rdb_sst_file_ordered::commit()`, if `m_use_stack` is true, it will write kv from stack.

2. In `Rdb_sst_file_ordered::Rdb_sst_file::commit()`, it calls `m_sst_file_writer->Finish()`, in which will write file and call fsync.

In our private branch, when m_use_stack is true(reverse cf), create index time reduces 30+%.

Rdb_index_merge and Rdb_sst_file_ordered both use cf's comparator, when Rdb_index_merge write to Rdb_sst_file_ordered, the keys should be in cf's increasing order, m_use_stack should be false in this case.

We removed merge_record::m_comparator since it is identical in each std::set element, and using Slice::operator< to avoid rocksdb::Comparator virtual function call, thus it is reversed with regard to rev cf and makes m_use_stack being true.