RocksDB：manifest设计源码详解 + db recover流程

已于 2022-08-09 17:16:12 修改
阅读量934 收藏 2
点赞数 1
分类专栏： RocksDB 文章标签： 数据库 大数据 分布式
于 2022-08-09 17:12:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/easonwx/article/details/126231481
版权

文章目录

引言

RocksDB的LsmTree有哪些关键数据？

RocksDB采用了LsmTree用于存储kv数据，LsmTree包含了如下关键数据：

  • memtable/immutable：存储在内存中，随着写入size和数量的增加会转换为sstable，存储在磁盘上。
  • sstable：存储在磁盘上，存储kv数据，只读。
  • WAL：存储在高性能介质，与memtable一一对应，存储与memtable中相同的kv数据，用于故障后重建memtable。

Manifest：描述LsmTree结构

Manifest就是用来描述LsmTree结构信息，其中包括：

  • VersionEdit：LsmTree结构变化情况。
  • WAL：已久化到磁盘的WAL文件seq。

根据manifest描述的文件信息即可重建LsmTree结构。

  • memtable/immutable：通过读取WAL将重建memtable。
  • sstable：根据VersionEdit记录重建LsmTree的sstable结构。

Manifest dump

为了便于后续理解，先看一下ldb工具dump出来的manifest。

VersionEdit {
  Comparator: leveldb.BytewiseComparator
  ColumnFamily: 0
}
VersionEdit {
  LogNumber: 5024
  AddFile: 6 5049 68211256 'Bblocks' seq:0, type:1 .. 'Mʧ.vdb_f4949979.file_head' seq:0, type:1 oldest_ancester_time:0 file_creation_time:0 file_checksum: file_checksum_func_name: Unknown
  AddFile: 6 5050 68209671 'Mʧ.vdb_f4949980.file_head' seq:0, type:1 .. 'M�w.vdb_f46113.file_head' seq:0, type:1 oldest_ancester_time:0 file_creation_time:0 file_checksum: file_checksum_func_name: Unknown
  AddFile: 6 5051 68209802 'M�w.vdb_f46114.file_head' seq:0, type:1 .. 'M�;.vdb_f2537719.file_head' seq:0, type:1 oldest_ancester_time:0 file_creation_time:0 file_checksum: file_checksum_func_name: Unknown
  AddFile: 6 5052 68209026 'M�;.vdb_f2537720.file_head' seq:0, type:1 .. 'M��.vdb_f5027643.file_head' seq:0, type:1 oldest_ancester_time:0 file_creation_time:0 file_checksum: file_checksum_func_name: Unknown
...
}
VersionEdit {
  LogNumber: 5025
  PrevLogNumber: 0
  NextFileNumber: 5193
  LastSeq: 83912935
  AddFile: 0 5191 66193 'LeB' seq:83912828, type:7 .. 'T' seq:83912771, type:2 oldest_ancester_time:0 file_creation_time:0 file_checksum: file_checksum_func_name: Unknown
  ColumnFamily: 0
}

结合如下代码DumpManifestHandler::CheckIterationResult函数可以得出如下信息：

  • 第一个VersionEdit记录了AddFile记录，即经过整理后，一个某个version中全部的sstable。
  • 第二个VersionEdit记录了一个L0的AddFile记录， 表示有一个memtable序列化到了L0
  • 累加两次记录，就得到了LsmTree的结构。

想了解VersionEdit内容，可以直接看EncodeTo代码。

bool VersionEdit::EncodeTo(std::string* dst) const {
...
}

Manifest代码详解

关键元数据

Version/VersionEdit/VersionSet

  • Version表示某一时刻LsmTree的状态（包含所有sstable）。
  • VersionSet表示多个时刻Version的集合。用来处理读sstable和compaction删除sstable的冲突问题。
  • VersionEdit表示Version的某次修改，比如由于compaction，Version从v1变成了v2，那么VersionEdit1就记录了v1到v2的变化（L0 add/delete sstable，L1 add/delete ssttable等），这样我们有v1和VersionEdit1、VersionEdit2…，就可以知道当前Version的状态。
  • Manifest保存了所有的VersionEdit，因此在故障时候，可以通过一次遍历合并manifest中的记录恢复LsmTree的状态。

函数详解

写manifest：VersionSet::LogAndApply

Status VersionSet::LogAndApply(
  ...
  // 创建writer，提交到versionset的writer队列
  std::deque<ManifestWriter> writers;
  for (int i = 0; i < num_cfds; ++i) {
    const auto wcb =
        manifest_wcbs.empty() ? [](const Status&) {} : manifest_wcbs[i];
    writers.emplace_back(mu, column_family_datas[i],
                         *mutable_cf_options_list[i], edit_lists[i], wcb);
    manifest_writers_.push_back(&writers[i]);
  }
  // 等待之前所有writer执行完成
  while (!first_writer.done && &first_writer != manifest_writers_.front()) {
    first_writer.cv.Wait();
  }
  if (first_writer.done) {
    return first_writer.status;
  }
  // 唤醒队列中的writer
  return ProcessManifestWrites(writers, mu, db_directory, new_descriptor_log, new_cf_options);
}

Status VersionSet::ProcessManifestWrites(
    std::deque<ManifestWriter>& writers, InstrumentedMutex* mu,
    FSDirectory* db_directory, bool new_descriptor_log,
    const ColumnFamilyOptions* new_cf_options) {
  ...
  // 将edit数据保存到batch_edits中
  if (first_writer.edit_list.front()->IsColumnFamilyManipulation()) {
    LogAndApplyCFHelper(first_writer.edit_list.front(), &max_last_sequence);
    batch_edits.push_back(first_writer.edit_list.front());
  } else {
    while (it != manifest_writers_.cend()) {
      ...
      Version* version = nullptr;
      VersionBuilder* builder = nullptr;
      ...
      for (const auto& e : last_writer->edit_list) {
        ...
        Status s = LogAndApplyHelper(last_writer->cfd, builder, e,
                                     &max_last_sequence, mu);
        ...
        batch_edits.push_back(e);
      }
    }
    for (int i = 0; i < static_cast<int>(versions.size()); ++i) {
      ...
      Status s = builder->SaveTo(versions[i]->storage_info());
      ...
    }
  }
  // 判断是否需要创建新的manifest文件
  // 第一次logandapply需要创建
  // 当manifest size大于配置值是需要创建
  if (!descriptor_log_ ||
      manifest_file_size_ > db_options_->max_manifest_file_size) {
    new_descriptor_log = true;
  } else {
    pending_manifest_file_number_ = manifest_file_number_;
  }
  // 如果需要创建新的manifest，创建manifest
  if (new_descriptor_log) {
    pending_manifest_file_number_ = NewFileNumber();
    batch_edits.back()->SetNextFile(next_file_number_.load());

    // if we are writing out new snapshot make sure to persist max column
    // family.
    if (column_family_set_->GetMaxColumnFamily() > 0) {
      first_writer.edit_list.front()->SetMaxColumnFamily(
          column_family_set_->GetMaxColumnFamily());
    }
    ...
  }
  ...
      if (s.ok()) {
        // manifest写盘
        io_s = SyncManifest(db_options_, descriptor_log_->file());
      }
      if (!io_s.ok()) {
        s = io_s;
        ROCKS_LOG_ERROR(db_options_->info_log, "MANIFEST write %s\n",
                        s.ToString().c_str());
      }
    }
    // 更新CURRENT文件
    if (s.ok() && new_descriptor_log) {
      io_s = SetCurrentFile(fs_.get(), dbname_, pending_manifest_file_number_,
                            db_directory);
    }
  }
  // 删除过期manifest
  if (s.ok() && new_descriptor_log) {
    obsolete_manifests_.emplace_back(
        DescriptorFileName("", manifest_file_number_));
  }
  // 唤醒阻塞内容
  if (!manifest_writers_.empty()) {
    manifest_writers_.front()->cv.Signal();
  }
  return s;
}

DB recover流程

流程

流程图转自https://blog.csdn.net/xuhaitao23/article/details/121747616
在这里插入图片描述

函数详解

打开DB：DBImpl::Open

Status DBImpl::Open(const DBOptions& db_options, const std::string& dbname,
                    const std::vector<ColumnFamilyDescriptor>& column_families,
                    std::vector<ColumnFamilyHandle*>* handles, DB** dbptr,
                    const bool seq_per_batch, const bool batch_per_txn) {
  // 检查option
  Status s = ValidateOptionsByTable(db_options, column_families);
  ...
  // 创建内存中的db实例
  DBImpl* impl = new DBImpl(db_options, dbname, seq_per_batch, batch_per_txn);
  ...
  // 创建各层目录，这里需要注意目录是option中配置的：
  // 如果是wal，为wal_dir
  // 如果是其他sst，为db_paths
  s = impl->env_->CreateDirIfMissing(impl->immutable_db_options_.GetWalDir());
  ...
  // db恢复
  s = impl->Recover(column_families, false, false, false, &recovered_seq,
                    &recovery_ctx);
  if (s.ok()) {
    // 根据恢复的db，拿到新的file_num
    uint64_t new_log_number = impl->versions_->NewFileNumber();
    ...
    // 创建一个wal，写入emptybatch，并进行一次flush
    s = impl->CreateWAL(new_log_number, 0 /*recycle_log_number*/,
                        preallocate_block_size, &new_log);
    ...
    // 上线新的version，将version edit持久化到manifest
    s = impl->LogAndApplyForRecovery(recovery_ctx);
    // 初始化column family
    for (auto cf : column_families) {
      ...
    }
  }
      // memtable和sst都恢复完成后，superversion上线
      impl->InstallSuperVersionAndScheduleWork(
          cfd, &sv_context, *cfd->GetLatestMutableCFOptions());
    ...
    // 删除过期的sst文件
    impl->DeleteObsoleteFiles();
    // 出发compaction等后台任务
    ...
}

恢复DB：DBImpl::Recover

Status DBImpl::Recover(
    const std::vector<ColumnFamilyDescriptor>& column_families, bool read_only,
    bool error_if_wal_file_exists, bool error_if_data_exists_in_wals,
    uint64_t* recovered_seq, RecoveryContext* recovery_ctx) {
 	...
 	// 在目录中寻找CURRENT文件
 	// 如果非best_efforts_recovery：则一定要找到CURRENT文件，否则认为不存在db，下文主要讲解此种情况。
 	// 如果为best_efforts_recovery：则找到一个manifest即可，为一种尽量恢复db的模式。
    if (!immutable_db_options_.best_efforts_recovery) {
      s = env_->FileExists(current_fname);
    } else {
      ...
    }
    ...
    // 检查文件是否可用
    ...
  }
  // 恢复version
  if (!immutable_db_options_.best_efforts_recovery) {
    s = versions_->Recover(column_families, read_only, &db_id_);
  } else {
    ...
  }
  ...
  // 恢复wal
  std::vector<std::string> files_in_wal_dir;
  if (s.ok()) {
    // 获取wal文件
    if (!immutable_db_options_.best_efforts_recovery) {
      s = env_->GetChildren(wal_dir, &files_in_wal_dir);
    }
    // 校验wal文件与manifest中的记录
    if (immutable_db_options_.track_and_verify_wals_in_manifest) {
      if (!immutable_db_options_.best_efforts_recovery) {
        s = versions_->GetWalSet().CheckWals(env_, wal_files);
      }
    } else if (!versions_->GetWalSet().GetWals().empty()) {
      ...
    }
	// 恢复wal数据到memtable
    if (!wal_files.empty()) {
      ...
      s = RecoverLogFiles(wals, &next_sequence, read_only, &corrupted_wal_found,
                          recovery_ctx);
      ...
    }
  }
  ...
  return s;
}

恢复version：VersionSet::Recover

Status VersionSet::Recover(
    const std::vector<ColumnFamilyDescriptor>& column_families, bool read_only,
    std::string* db_id) {
  // 读取manifest文件
  // 先读取CURRENT文件，在CURRENT文件中记录了当前的manifest，如“MANIFEST-000011”
  Status s = GetCurrentManifestPath(dbname_, fs_.get(), &manifest_path,
                                    &manifest_file_number_);
  ...
  // 根据获取的当前manifest，创建SequentialFileReader，用于读取manifest。
  std::unique_ptr<SequentialFileReader> manifest_file_reader;
  {
    std::unique_ptr<FSSequentialFile> manifest_file;
    s = fs_->NewSequentialFile(manifest_path,
                               fs_->OptimizeForManifestRead(file_options_),
                               &manifest_file, nullptr);
    ...
    manifest_file_reader.reset(new SequentialFileReader(
        std::move(manifest_file), manifest_path,
        db_options_->log_readahead_size, io_tracer_, db_options_->listeners));
  }
  // 读manifest，解析manifest并恢复version
  ...
  {
    // 迭代回放manifest
    VersionEditHandler handler(read_only, column_families,
                               const_cast<VersionSet*>(this),
                               /*track_missing_files=*/false,
                               /*no_error_if_files_missing=*/false, io_tracer_);
    // 真正处理manifest逻辑
    handler.Iterate(reader, &log_read_status);
    s = handler.status();
    if (s.ok()) {
      log_number = handler.GetVersionEditParams().log_number_;
      current_manifest_file_size = reader.GetReadOffset();
      handler.GetDbId(db_id);
    }
  }
  ...
  return s;
}

void VersionEditHandlerBase::Iterate(log::Reader& reader,
                                     Status* log_read_status) {
  // 遍历读manifest记录
  while (reader.LastRecordEnd() < max_manifest_read_size_ && s.ok() &&
         reader.ReadRecord(&record, &scratch) && log_read_status->ok()) {
    // 解码record到临时edit中
    s = edit.DecodeFrom(record);
    // 将edit添加到buffer，用于batchapply
    s = read_buffer_.AddEdit(&edit);
    if (edit.is_in_atomic_group_) {
      // batchapply
      ...
    } else {
      // 将edit apply到version中
      s = ApplyVersionEdit(edit, &cfd);
    }
  }
}

bool Reader::ReadRecord(Slice* record, std::string* scratch,
                        WALRecoveryMode wal_recovery_mode,
                        uint64_t* record_checksum) {
  ...
  Slice fragment;
  // 循环读数据，并添加到fragment中
  while (true) {
    uint64_t physical_record_offset = end_of_buffer_offset_ - buffer_.size();
    size_t drop_size = 0;
    // 读取一段记录数据
    const unsigned int record_type =
        ReadPhysicalRecord(&fragment, &drop_size, record_checksum);
    // 根据数据类型，使用不同策略将数据添加到fragment中
    switch (record_type) {
      // 一个完整的record
      case kFullType:
      case kRecyclableFullType:
        ...
      // 一个record中第一个分片
      case kFirstType:
      case kRecyclableFirstType:
        ...
      // 一个record中的中间分片
      case kMiddleType:
      case kRecyclableMiddleType:
        ...
      // 一个record中的最后分片
      case kLastType:
      case kRecyclableLastType:
        ...
      // header错误
      case kBadHeader:
        ...
      // 遇到结束，可能是写完部分分片后写失败了，因此数据无效，恢复上一个版本的version即可
      case kEof:
        ...
      case kOldRecord:
        ...
      // 错误
      case kBadRecord:
        ...
        break;
      case kBadRecordLen:
        ...
        break;
      case kBadRecordChecksum:
        ...
        break;
      case kSetCompressionType: {
        ...
      default: {
        ...
        break;
      }
    }
  }
  return false;
}

unsigned int Reader::ReadPhysicalRecord(Slice* result, size_t* drop_size,
                                        uint64_t* fragment_checksum) {
  while (true) {
    // header不完整，需要读取更多的数据
    if (buffer_.size() < static_cast<size_t>(kHeaderSize)) {
      ...
      if (!ReadMore(drop_size, &r)) {
        return r;
      }
      continue;
    }

    // 解析header，0-3 crc，4-5 length，6 type
    const char* header = buffer_.data();
    const uint32_t a = static_cast<uint32_t>(header[4]) & 0xff;
    const uint32_t b = static_cast<uint32_t>(header[5]) & 0xff;
    const unsigned int type = header[6];
    const uint32_t length = a | (b << 8);
    int header_size = kHeaderSize;
    // 根据不同的type，校验crc，decompress等....
    ...
  }
}

恢复WAL：DBImpl::RecoverLogFiles

Status DBImpl::RecoverLogFiles(const std::vector<uint64_t>& wal_numbers,
                               SequenceNumber* next_sequence, bool read_only,
                               bool* corrupted_wal_found,
                               RecoveryContext* recovery_ctx) {
  ...
  // 遍历所有wal record，wal_numbers为所有wal的log文件列表。
  for (auto wal_number : wal_numbers) {
    // 创建reader用于读取wal数据
    std::unique_ptr<SequentialFileReader> file_reader;
    {
      std::unique_ptr<FSSequentialFile> file;
      status = fs_->NewSequentialFile(
          fname, fs_->OptimizeForLogRead(file_options_), &file, nullptr);
      ...
      file_reader.reset(new SequentialFileReader(
          std::move(file), fname, immutable_db_options_.log_readahead_size,
          io_tracer_));
    }
    ...
    // 遍历所有record
    while (!stop_replay_by_wal_filter &&
           reader.ReadRecord(&record, &scratch,
                             immutable_db_options_.wal_recovery_mode,
                             &record_checksum) &&
           status.ok()) {
      ...
      // 解析record把其中的kv组装成writebatch
      WriteBatch batch;
      status = WriteBatchInternal::SetContents(&batch, record);
      // 将writebatch插入memtable
      status = WriteBatchInternal::InsertInto(
          &batch, column_family_memtables_.get(), &flush_scheduler_,
          &trim_history_scheduler_, true, wal_number, this,
          false /* concurrent_memtable_writes */, next_sequence,
          &has_valid_writes, seq_per_batch_, batch_per_txn_);
      // 将memtable flush到L0
      if (has_valid_writes && !read_only) {
          ...
          status = WriteLevel0TableForRecovery(job_id, cfd, cfd->mem(), edit);
          ...
          cfd->CreateNewMemtable(*cfd->GetLatestMutableCFOptions(),
                                 *next_sequence);
      }
    }
    // 处理结果，清理flush_scheduler，更新seq_num
    ...
  }
  bool data_seen = false;
  if (!read_only) {
      // flush最后一个memtable
      if (cfd->mem()->GetFirstSequenceNumber() != 0) {
        if (flushed || !immutable_db_options_.avoid_flush_during_recovery) {
          status = WriteLevel0TableForRecovery(job_id, cfd, cfd->mem(), edit);
        }
      }
  }
  return status;
}

参考文献

https://blog.csdn.net/xuhaitao23/article/details/121747616
https://vigourtyy-zhg.blog.csdn.net/article/details/106367782

easonwx
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【RocksDB】RocksDB -- MANIFEST 浅析
九师兄
03-27 727
RocksDB 是文件系统与存储介质无关的。文件系统的操作不具有原子性，可能会由于意外情况，导致 RocksDB 出现不一致的问题。即使打开了日志记录，文件系统也不能保证不洁重启的一致性。POSIX 文件系统也不支持原子的操作批处理。因此，在 RocksDB 重新启动时，仅仅依赖 RocksDB 数据存储文件中的元数据来重建最后的一致状态是不现实的。RocksDB 拥有一个内置的机制来克服上述 POSIX 文件系统的限制，即 MANIFEST。
RocksDB
野狼e族 的博客
04-06 1083
目录 RocksDB 简介 TiKV 架构 RocksDB 的内存占用 RocksDB 的空间占用 RocksDB 后台线程与 Compact WriteStall RocksDB 简介 RocksDB是由 Facebook 基于 LevelDB 开发的一款提供键值存储与读写功能的 LSM-tree 架构引擎。用户写入的键值对会先写入磁盘上的 WAL (Write Ahead Log)，然后再写入内存中的跳表（SkipList，这部分结构又被称作 MemTable）。LSM-tree 引擎.
Rocksdb 数据库--MANIFEST文件
大圣编了个程
09-27 2393
官方文档—https://github.com/facebook/rocksdb/wiki/MANIFEST 如有错误或翻译不当，请指正。其他rocksdb 文档请关注后续文章。MANIFESTrocksdb 是一个与存储介质无关的文件系统，文件系统的操作不是原子操作，所以在系统失败后，很容易导致文件的不一致，尽管后来随着日志记录的出现，但是也没有办法保证长期运行期间文件数据的一致性，POSIX
rocksdb源码解析：log文件恢复
dongfengxueli的博客
03-27 4261
我们知道rockdb作为kv存储，采用的WAL方式来写日志，即预写日志，每次要对数据操作之前，先写日志保存起来，然后在进行相应操作。这样当发生某些意外而导致还未写到磁盘中的数据丢失时，我们可以采用log文件来进行恢复。通过读取磁盘中的内容和已知的WAL日志，就可以恢复到最新的状态。而memtable和未写入磁盘的immemtable则从log文件中读出来，重做memtable和immemtable
rocksdb写流程DBImpl::WriteImpl()源代码分析
子居的博客
10-13 904
文章结构1. WriteThread的状态2. write_group结构3. 写过程WriteImpl()函数源码分析 1. WriteThread的状态 写线程WriteThread会有几种状态，在写memtable的过程中通这几种状态来决定当前w当前执行到哪儿了，下一步该怎么执行。 enum State : uint8_t { // The initial state of a writer. This is a Writer that is // waiting in Joi
SSComments:Subreddit Simmulator评论刮板+ Web应用程序
05-17
Subreddit Simulator评论汇总器 该应用程序当前在托管。 SSComments使用IBM Watson 对SubredditSimulator... 在manifest.yml您将需要更新services ， host和name以匹配您在配置应用程序时选择的名称。 public/index.h
基于Java的动漫网站前端设计源码
04-17
本项目是基于Java开发的动漫网站前端设计源码，共包含236个文件。其中JPG图片文件116个，编译后的Class文件34个，XML配置文件24个，JAR打包文件18个，Java源代码文件17个，JSP页面文件8个，CSS样式文件8个，...
基于Java的拼图游戏设计源码
最新发布
06-07
本项目为“基于Java的拼图游戏设计源码”，包含540个文件，其中包括493个JPG图像文件、21个PNG图像文件、10个Java源文件、5个XML配置文件、5个字节码文件、2个Markdown文档、1个Gitignore忽略配置文件、1个LICENSE...
基于C#的NIISOL离线接种软件设计源码
05-26
本项目是基于C#的NIISOL离线接种软件设计源码，包含45个文件，其中包括18个C#源文件、8个CDF-MS文件、8个Manifest文件、7个DLL文件、1个CSPROJ文件、1个DB3文件、1个EXE文件和1个CONFIG文件。该项目是一个NIIS离线...
基于Java的篮球淘汰赛GUI界面设计源码
06-07
本项目为“基于Java的篮球淘汰赛GUI界面设计源码”，包含58个文件，其中包括40个Java源文件、6个XML配置文件、4个JPG图像文件、3个Gitignore忽略配置文件、2个JPEG图像文件、1个Manifest文件、1个PNG图像文件以及1个...
MySQL · RocksDB · MANIFEST文件介绍
weixin_33878457的博客
05-22 655
概述 在RocksDB中MANIFEST保存了存储引擎的内部的一些状态元数据，简单来说当系统异常重启，或者程序异常被退出之后，RocksDB需要有一种机制能够恢复到一个一致性的状态， 而这个一致性的状态就是靠MANIFEST来保证的. MANIFEST在RocksDB中是一个单独的文件，而这个文件所保存的数据基本是来自于VersionEdit这个结构...
rocksdb
豪猪的博客
04-10 648
一、概述 RocksDB 改自LevelDB，是一个持久化存储的KV系统，和Redis这种内存型的KV系统不同，LevelDB不会像Redis一样狂吃内存，而是将大部分数据存储到磁盘上。 数据结构：LSM-Tree(Log-Structured-Merge-Tree)。LSM从命名上看，容易望文生义成一个具体的数据结构，一个tree。但LSM并不是一个具体的数据结构，也不是一个tree。LSM是一个数据结构的概念，是一个数据结构的设计思想。 整体结构：主要分为三大块：WAL(disk)→ Memtab
RocksDB 笔记
piedaocaoren的博客
06-14 499
https://alexstocks.github.io/html/rocksdb.html 很棒的一篇介绍RockDB的文章，收藏之
RocksDB源码学习(五): 写(一)-框架
weixin_46322986的博客
11-29 629
本篇博客将先理清 RocksDB 的基本写入框架，不考虑 pipelined_write 优化，并且不讨论源码实现，用以为后续的源码分析做前言。
Rocksdb 写流程,读流程,WAL文件,MANIFEST文件,ColumnFamily,Memtable,SST文件原理详解
天行健，地势坤
05-29 1万+
Rocksdb写流程 过程基本如下流程图： 涉及到的几个核心文件： WAL 保存当前rocksdb的memtable中的文件信息，当memtable --》 immutable memtable中的数据刷到L0之后即之前的会被删除 — 即于DB目录下的 00012.log MANIFEST 保存当前db的状态信息（类似于快照），主要是SST文件的各个版本信息（当sst文件被改动，即会生成对应的versionEdit，并触发sync写manifest文件），用于异常断电后恢复— 即 MANIFEST-
RocksDB基本架构与原理介绍
热门推荐
qq_30708747的博客
10-19 2万+
Rocksdb Flink提供基于流的有状态计算，除了提供实时数据流的处理能力，还需要将计算产生的状态存储起来。 为了满足状态存取需求，提供了memory、flie system、rocksdb三种类型的状态存储机制。 memory存取高效单空间有限，且可用性低； file system提供状态持久化能力但存取性能较低； rocksdb提供数据快速写入以及数据持久化的能力。本文介绍了Rocksdb设计的基本架构。 RocksDB介绍 Rocksdb 是基于Google LevelDB研发的高性能kv持久化存
获得PCC性能大赛背后的RocksDB引擎:5分钟全面了解其原理
weixin_45583158的博客
03-22 593
导读：在 3 月 4 日举办的高可用架构 PCC 性能挑战赛上（PCC 是 Performance Challenge Championship 的缩写），以 Rocks...
RocksDB安装及基本接口使用的初学者指南
Lion_Long的博客
04-18 2666
RocksDB 是 Facebook 的一个实验项目，目的是希望能开发一套能在服务器压力下，真正发挥高速存储硬件性能的高效数据库系统。RocksDB是一个存储引擎，不提供网络服务，只专注于具体的存储。这是一个 C++ 库，允许存储任意长度二进制 KV 数据。支持原子读写操作。RocksDB 依靠大量灵活的配置，使之能针对不同的生产环境进行调优，包括直接使用内存，使用 Flash，使用硬盘或者 HDFS。支持使用不同的压缩算法，并且有一套完整的工具供生产和调试 使用。
RocksDB引擎加载
04-05 531
RocksDB引擎的加载，具体操作是通过DB:Open()方法进行的，具体实现类是DBImpl类。 1.引擎加载call stack Rocksdb引擎注册和加载时call stack: ...
Error response from daemon: manifest for elasticsearch:5.6.2 not found: manifest unknown: manifest unknown
01-17
根据提供的引用内容，您遇到的错误是"Error response from daemon: manifest for elasticsearch:5.6.2 not found: manifest unknown: manifest unknown"。这个错误通常是由于Docker无法找到指定版本的Elasticsearch...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值