RocksDB Windows 移植全解析微软 Bing 团队官方 Port 的构建、适配与性能实测【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdbRocksDB 是一个面向快速存储、可内嵌的持久化 key-value 存储引擎长期被社区与众多公司用于构建高吞吐、大容量的现代服务端系统。本文以仓库内官方公告 RocksDB is now available in Windows Platform 为核心结合微软 Bing 团队随移植一并提交的 WINDOWS_PORT.md 与仓库中 port/win 的源码实现系统梳理 Windows 移植的设计目标、CMake 构建流程、C/STL 与系统环境的适配细节以及官方公布的性能实测数据。读完本文你将掌握如何在 Windows 上从零构建 RocksDB、理解该移植的关键实现取舍并能据此在自己的 Windows 项目中正确集成与调优 RocksDB。公告背景RocksDB 正式登陆 Windows 平台2015 年 7 月 22 日微软 Bing 团队的 Dmitri Smirnov 在项目博客发布了官方公告宣布 RocksDB 的 Windows 移植版本正式对外可用。公告指出在过去 6 个月里RocksDB 已被社区和多家公司在现代服务器环境中用于实现高吞吐、高容量的存储场景而微软 Bing 团队基于自身 key/value 数据存储的存储选型需求在微软内部完成了这一移植并决定将其开放给社区。博客评论区中RocksDB 维护者 Siying Dong 也对这一贡献表示了感谢。这份公告本身是新闻性质的短文档其背后承载的完整技术细节记录在同仓库根目录的 WINDOWS_PORT.md微软贡献说明之中该文档详细描述了移植动机、系统适配决策与基准测试结果而移植代码则全部位于 port/win 目录。以下各节即围绕Windows 移植这一主题展开。移植的四大目标与验收标准根据 WINDOWS_PORT.md 的记录微软 Bing 团队为这次移植设定了明确的目标与验收标准复用 RocksDB 既有移植接口尽量利用 RocksDB 自带的port抽象层即 port/port.h避免重写平台无关代码最小化平台无关代码改动对跨平台核心代码只做最必要的修改且每处修改都要有明确的 OS 差异或编译器差异依据单元测试全量通过Debug 与 Release 构建下所有单元测试都要通过文档同时注明由于当时新引入的 SyncPoint 机制Release 模式下 db_test 无法运行性能对齐官方基准在考虑硬件差异的前提下性能与已发布的官方基准测试持平保持主干同步、不做分支化移植代码保持与主分支内联演进避免长期 fork。这些目标决定了整个移植的技术路线以 port/win 下的WinEnv、WinFileSystem、WinWritableFile、WinRandomAccessFile等类为承载点把 POSIX 语义逐一映射到 Windows API而不是去改动上层引擎逻辑。构建系统CMake Visual Studio 五步构建移植团队选择了 CMake 作为 Windows 构建系统因为它既能从命令行快速构建又能生成同时适用于命令行和 IDE 的 Visual Studio 工程。当前仓库根目录的 CMakeLists.txt 顶部保留了完整的 Windows 构建说明注该文件标注 Windows 构建仅支持 64 位要求至少 Visual Studio 2019并在 WINDOWS_PORT.md 中说明 32 位未经测试编辑 thirdparty.inc把其中的第三方库路径更新为本机实际位置创建构建目录mkdir build cd build生成工程文件可按需启用第三方库示例命令cmake -G Visual Studio 16 2019 -DCMAKE_BUILD_TYPERelease -DWITH_GFLAGS1 -DWITH_SNAPPY1 -DWITH_JEMALLOC1 -DWITH_JNI1 ..Debug 构建msbuild rocksdb.sln可加/m或/m:N并行编译Release 构建会排除仅测试使用的代码因此推荐直接构建rocksdb.sln而非ALL_BUILDRelease 构建msbuild rocksdb.sln /p:ConfigurationRelease。与构建相关的常用 CMake 选项见 CMakeLists.txt包括WITH_SNAPPY、WITH_LZ4、WITH_ZLIB、WITH_ZSTD各类压缩库、WITH_JEMALLOCjemalloc 内存分配器、WITH_GFLAGS命令行解析db_bench 等工具依赖、WITH_XPRESSWindows 内置压缩仅 MSVC 下可用、WITH_JNIJava 绑定、WITH_WINDOWS_UTF8_FILENAMES无论系统代码页如何一律以 UTF-8 字符集打开文件对应源码中的ROCKSDB_WINDOWS_UTF8_FILENAMES宏。另外当前仓库的 CMake 配置要求 C20 标准CMAKE_CXX_STANDARD 20。C 与 STL 层面的移植适配由于早期 MSVC 对 C11 的支持尚不完整移植必须做一系列编译层面的适配。这些改动大多被预期会在后续编译器版本中消除但当时都是必要的。归纳如下详见 WINDOWS_PORT.md问题处理方式Windows 上不存在/不需要的部分 POSIX 头如unistd.h用#ifndef OS_WIN包住各类 POSIX 专用头文件统一替换为 port/port.h 抽象dirent.h目录遍历替换为 port/port_dirent.h在rocksdb::port命名空间内实现相关接口sys/time.h时间相关替换为 port/sys_time.hprintf的%z说明符不被 Windows CRT 支持定义字符串宏ROCKSDB_PRIsztPOSIX 平台展开为zu见 port/port_posix.hWindows 平台展开为Iu见 port/win/port_win.h类内成员初始化不被旧编译器支持部分场景移入构造函数初始化constexpr不被支持常量改用std::numeric_limits::max()/min()对应的 C 宏部分类成员改为static const并在.cc中给出定义函数级constexpr用模板特化替代1 处含非平凡构造函数的 union 成员改为char[]存储顺带修复了 spatial 实验特性的一处 bug零长度数组非标准扩展改为长度 1 的数组std::chrono缺乏纳秒精度支持port/win/env_win.cc 中的WinClock使用QueryPerformanceFrequency换算高精度时间并动态探测GetSystemTimePreciseAsFileTime见 port/win/env_win.cc函数局部静态变量的初始化线程安全在WinEnv内使用std::once/InitOnce机制规避见 port/win/port_win.cc从源码结构看这些适配很好地印证了最小化平台无关代码改动的目标——核心引擎代码无需感知 Windows 的存在差异全部收敛在port层。WinEnvWindows 环境层的实现要点WINDOWS_PORT.md 指出Windows 环境层力求在功能上与posix_env对齐包括线程池与全部磁盘访问功能具体实现要点如下线程池尽管 Windows 自带高效的线程池实现移植团队仍刻意选择用std::thread原语复刻 POSIX 版本的线程池逻辑对应 port/win/win_thread.cc。这样做的收益是POSIX 源码的任何改动都能被快速比对并同步到 Windows 环境层且这一逻辑已被证明运行良好。同时RocksDB 的 stackable environment 机制允许用户用自定义实现替换内置线程池。磁盘访问与 unbuffered I/OWindows 没有fadvise系统调用其磁盘缓存机制也与 Linux 差异巨大。在 Windows 上常见做法是通过无缓冲磁盘访问来精确控制内存占用。因此移植选择将use_os_bufferfalse用于WinWritableFile与WinRandomAccessFile即禁用 OS 磁盘缓冲代价是磁盘吞吐可能下降官方建议此时可通过增大内存中的 cache 来补偿。需要特别注意的是无缓冲模式对磁盘偏移、缓冲区与读写数据量都有对齐限制源码中以扇区大小kSectorSize 512为基准见 port/win/io_win.cc。当该选项为true时类表现为标准带缓冲行为——WAL 与 MANIFEST 等不适合无缓冲访问的文件正是走这一路径。在 port/win/env_win.cc 的WinFileSystem实现中可以看到对应代码顺序文件与随机访问文件在use_direct_reads !use_mmap_reads时追加FILE_FLAG_NO_BUFFERING见 port/win/env_win.cc、L279-L283可写文件在直接 I/O 时使用FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH见 port/win/env_win.cc并相应实现GetRequiredBufferAlignment、use_direct_io等接口见 port/win/io_win.cc。pread/pwrite 的等价实现Windows 的WriteFile/ReadFile不具备pread/pwrite那种按偏移读写且不移动文件指针的原子语义。移植用OVERLAPPED结构指定偏移实现原子定位 同步读写从而较为忠实地模拟了pread/pwrite的功能见 port/win/io_win.cc。唯一差异是操作后文件指针不会恢复到原位置但对于随机访问场景这几乎无关紧要。fallocate/truncate 的等价实现Windows 没有fallocate移植使用SetFileInformationByHandle完成空间预分配FileAllocationInfo与文件截断FileEndOfFileInfo以换取更快的 I/O见 port/win/io_win.cc。文档同时指出两者仍存在细微差异预分配的空间不会像 Linux 那样被填零但预分配后文件结束位置也不会被修改。放宽文件共享权限RocksDB 经常在文件仍被另一句柄打开时就执行重命名、复制、删除。为此WinFileSystem在打开文件时尽量放开共享权限FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE见 port/win/env_win.cc文档明确这是为了通过 corruption 测试文件在打开状态下被重命名/删除而必须的。线程局部存储与 Jemalloc 的运行时集成线程局部存储TLSTLS 对 RocksDB 性能至关重要。移植没有另起炉灶而是在 port/win/port_win.h 中以rocksdb::port命名空间内的内联包装把pthread_specific系列调用转发到 Windows 的TlsAlloc等接口见 port/win/port_win.h从而保留原有逻辑主体不变。针对 Windows 缺少线程退出时自动清理 TLS的机制移植在 util/thread_local.cc 中添加了少量 Windows 专用代码通过#pragma const_seg(.CRT$XLB)x86 上为#pragma data_seg把一个PIMAGE_TLS_CALLBACK回调注入__tls结构所在的 CRT 段并配合#pragma comment(linker, /include:_tls_used)等链接器指令确保回调不被丢弃见 util/thread_local.cc。这样一来无论 RocksDB 是作为可执行文件、独立 DLL 还是被其他 DLL 内嵌使用线程退出清理回调都能被可靠调用。Jemalloc 集成当 RocksDB 与 Jemalloc 一起使用时jemalloc 必须在任何 C 全局/静态对象初始化之前完成初始化。为此移植向.CRT$XCT段注入初始化例程由 CRT 运行时在初始化静态对象之前自动调用并把je-uninit挂到atexit()。new/delete的全局重定向是否生效取决于链接条件见 port/win/win_jemalloc.cc 中jemalloc_aligned_alloc/jemalloc_aligned_free的实现构建时需在 CMake 中开启-DWITH_JEMALLOC1。有意未实现的能力Stack Trace 与未处理异常处理器WINDOWS_PORT.md 明确说明Stack Trace与未处理异常处理器这两个功能有意未实现理由是宿主程序通常已经具备这两项能力移植团队在调试器或进程转储分析中未遇到不便因此不将其列为优先级。这属于有意的范围裁剪而非疏漏。性能实测数据RocksDB 3.10 / 3.11WINDOWS_PORT.md 附带了一套完整的基准测试记录测试条件如下2 × Intel(R) Xeon(R) E5 2450 0 2.10 GHz共 16 核2 × XK0480GDQPH SSD可用磁盘 894 GB128 GB 内存操作系统Windows Server 2012 R2 Datacenter1 亿条 keykey 10 字节value 800 字节数据库总大小约 76 GB基准版本为 RocksDB 3.11并与 3.10 对比除特别说明外参数与官方基准页公布的参数一致闪存SSD场景测试指标RocksDB 3.11RocksDB 3.101. 随机序批量装载总耗时17.6 min16.2 minFillrandom5.480 µs/op182,465 ops/s142.0 MB/s5.018 µs/op199,269 ops/s155.1 MB/sCompact486,056,544.000 µs/op0 ops/s441,313,173.000 µs/op0 ops/s2. 顺序批量装载Fillseq4.944 µs/op202k ops/s157.4 MB/s4.105 µs/op243.6k ops/s189.6 MB/s3. 随机写开启无缓冲 I/OOverwrite52.661 µs/op18.9k ops/s14.8 MB/s52.661 µs/op18.9k ops/s4. 随机读开启无缓冲 I/OReadrandom15.716 µs/op63.6k ops/s49.5 MB/s15.548 µs/op64.3k ops/s5. 多线程读 单线程写Readwhilewriting25.128 µs/op39.7k ops/s24.854 µs/op40.2k ops/s纯内存In-Memory场景Point Lookup点查询写入目标速率指标RocksDB 3.11RocksDB 3.1080K writes/s实际写入速率40.5k/s50.6k/sReadwhilewriting0.314 µs/op3,187,455 ops/s364.8 MB/s715,454,999/715,454,999 命中0.316 µs/op3,162,028 ops/s719,576,999/719,576,999 命中10K writes/s实际写入速率5.8k/s5.8k/sReadwhilewriting0.246 µs/op4,062,669 ops/s464.9 MB/s915,481,999/915,481,999 命中0.244 µs/op4,106,253 ops/s927,986,999/927,986,999 命中Prefix Range Query前缀范围查询写入目标速率指标RocksDB 3.11RocksDB 3.1080K writes/s实际写入速率46.3k/s45.8k/sReadwhilewriting0.362 µs/op2,765,052 ops/s316.4 MB/s611,549,999/611,549,999 命中0.317 µs/op3,154,941 ops/s708,158,999/708,158,999 命中10K writes/s实际写入速率5.78k/s5.7k/sReadwhilewriting0.269 µs/op3,716,692 ops/s425.3 MB/s837,401,999/837,401,999 命中0.261 µs/op3,830,152 ops/s863,482,999/863,482,999 命中需要特别说明以上数据出自 WINDOWS_PORT.md对应的是 2015 年前后、RocksDB 3.10/3.11 版本在特定硬件与 Windows Server 2012 R2 环境下的历史记录且官方文档也承认仍有很大提升空间。它们适合作为理解移植方案性能特征的参考不代表当前版本的实际性能如需评估当下的 Windows 性能应以本仓库 tools/db_bench.cc 等工具在目标硬件上的实测为准。当前仓库中的 Windows 支持现状时至今日Windows 支持已作为一级平台合入主干port/win 目录下共有 14 个文件职责划分清晰环境层env_win.cc / env_win.hWinFileSystem、WinClock等、env_default.cc默认环境入口、win_logger.cc / win_logger.hI/O 层io_win.cc / io_win.hWinSequentialFile、WinRandomAccessFile、WinWritableFile、pwrite/pread/fallocate/ftruncate等平台抽象port_win.cc / port_win.h互斥锁、TLS 包装、ROCKSDB_PRIszt等线程与分配器win_thread.cc / win_thread.h、win_jemalloc.cc压缩扩展xpress_win.cc / xpress_win.hWindows 内置 XPRESS 压缩。CMakeLists.txt 顶部保留了完整的 Windows 构建指引当前要求 Visual Studio 2019 及以上、C20、仅 64 位它与 WINDOWS_PORT.md 一起构成了理解这一移植最直接的入口而公告原文 RocksDB is now available in Windows Platform 则记录了这一能力的发布背景与初衷。小结微软 Bing 团队贡献的 Windows 移植是 RocksDB 跨平台能力的重要里程碑它严格遵循了复用 port 抽象层、最小化核心改动的原则用 CMake 统一了构建流程把 POSIX 语义线程池、pread/pwrite、fallocate、TLS逐一映射到 Windows API并通过.CRT$XLB/.CRT$XCT段注入等技巧解决了 TLS 清理与 jemalloc 初始化等运行时难题同时公开了 Flash 与纯内存两类场景下的详细基准数据。对希望在 Windows 上集成 RocksDB 的开发者而言最直接的行动路径是阅读 CMakeLists.txt 顶部的构建指引按五步流程生成 VS 工程并启用所需选项如WITH_SNAPPY、WITH_JEMALLOC、WITH_JNI再结合 WINDOWS_PORT.md 理解use_os_buffer、无缓冲 I/O 对齐等关键取舍从而在 Windows 上获得与 POSIX 平台一致的使用体验。【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RocksDB Windows 移植全解析：微软 Bing 团队官方 Port 的构建、适配与性能实测
RocksDB Windows 移植全解析微软 Bing 团队官方 Port 的构建、适配与性能实测【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdbRocksDB 是一个面向快速存储、可内嵌的持久化 key-value 存储引擎长期被社区与众多公司用于构建高吞吐、大容量的现代服务端系统。本文以仓库内官方公告 RocksDB is now available in Windows Platform 为核心结合微软 Bing 团队随移植一并提交的 WINDOWS_PORT.md 与仓库中 port/win 的源码实现系统梳理 Windows 移植的设计目标、CMake 构建流程、C/STL 与系统环境的适配细节以及官方公布的性能实测数据。读完本文你将掌握如何在 Windows 上从零构建 RocksDB、理解该移植的关键实现取舍并能据此在自己的 Windows 项目中正确集成与调优 RocksDB。公告背景RocksDB 正式登陆 Windows 平台2015 年 7 月 22 日微软 Bing 团队的 Dmitri Smirnov 在项目博客发布了官方公告宣布 RocksDB 的 Windows 移植版本正式对外可用。公告指出在过去 6 个月里RocksDB 已被社区和多家公司在现代服务器环境中用于实现高吞吐、高容量的存储场景而微软 Bing 团队基于自身 key/value 数据存储的存储选型需求在微软内部完成了这一移植并决定将其开放给社区。博客评论区中RocksDB 维护者 Siying Dong 也对这一贡献表示了感谢。这份公告本身是新闻性质的短文档其背后承载的完整技术细节记录在同仓库根目录的 WINDOWS_PORT.md微软贡献说明之中该文档详细描述了移植动机、系统适配决策与基准测试结果而移植代码则全部位于 port/win 目录。以下各节即围绕Windows 移植这一主题展开。移植的四大目标与验收标准根据 WINDOWS_PORT.md 的记录微软 Bing 团队为这次移植设定了明确的目标与验收标准复用 RocksDB 既有移植接口尽量利用 RocksDB 自带的port抽象层即 port/port.h避免重写平台无关代码最小化平台无关代码改动对跨平台核心代码只做最必要的修改且每处修改都要有明确的 OS 差异或编译器差异依据单元测试全量通过Debug 与 Release 构建下所有单元测试都要通过文档同时注明由于当时新引入的 SyncPoint 机制Release 模式下 db_test 无法运行性能对齐官方基准在考虑硬件差异的前提下性能与已发布的官方基准测试持平保持主干同步、不做分支化移植代码保持与主分支内联演进避免长期 fork。这些目标决定了整个移植的技术路线以 port/win 下的WinEnv、WinFileSystem、WinWritableFile、WinRandomAccessFile等类为承载点把 POSIX 语义逐一映射到 Windows API而不是去改动上层引擎逻辑。构建系统CMake Visual Studio 五步构建移植团队选择了 CMake 作为 Windows 构建系统因为它既能从命令行快速构建又能生成同时适用于命令行和 IDE 的 Visual Studio 工程。当前仓库根目录的 CMakeLists.txt 顶部保留了完整的 Windows 构建说明注该文件标注 Windows 构建仅支持 64 位要求至少 Visual Studio 2019并在 WINDOWS_PORT.md 中说明 32 位未经测试编辑 thirdparty.inc把其中的第三方库路径更新为本机实际位置创建构建目录mkdir build cd build生成工程文件可按需启用第三方库示例命令cmake -G Visual Studio 16 2019 -DCMAKE_BUILD_TYPERelease -DWITH_GFLAGS1 -DWITH_SNAPPY1 -DWITH_JEMALLOC1 -DWITH_JNI1 ..Debug 构建msbuild rocksdb.sln可加/m或/m:N并行编译Release 构建会排除仅测试使用的代码因此推荐直接构建rocksdb.sln而非ALL_BUILDRelease 构建msbuild rocksdb.sln /p:ConfigurationRelease。与构建相关的常用 CMake 选项见 CMakeLists.txt包括WITH_SNAPPY、WITH_LZ4、WITH_ZLIB、WITH_ZSTD各类压缩库、WITH_JEMALLOCjemalloc 内存分配器、WITH_GFLAGS命令行解析db_bench 等工具依赖、WITH_XPRESSWindows 内置压缩仅 MSVC 下可用、WITH_JNIJava 绑定、WITH_WINDOWS_UTF8_FILENAMES无论系统代码页如何一律以 UTF-8 字符集打开文件对应源码中的ROCKSDB_WINDOWS_UTF8_FILENAMES宏。另外当前仓库的 CMake 配置要求 C20 标准CMAKE_CXX_STANDARD 20。C 与 STL 层面的移植适配由于早期 MSVC 对 C11 的支持尚不完整移植必须做一系列编译层面的适配。这些改动大多被预期会在后续编译器版本中消除但当时都是必要的。归纳如下详见 WINDOWS_PORT.md问题处理方式Windows 上不存在/不需要的部分 POSIX 头如unistd.h用#ifndef OS_WIN包住各类 POSIX 专用头文件统一替换为 port/port.h 抽象dirent.h目录遍历替换为 port/port_dirent.h在rocksdb::port命名空间内实现相关接口sys/time.h时间相关替换为 port/sys_time.hprintf的%z说明符不被 Windows CRT 支持定义字符串宏ROCKSDB_PRIsztPOSIX 平台展开为zu见 port/port_posix.hWindows 平台展开为Iu见 port/win/port_win.h类内成员初始化不被旧编译器支持部分场景移入构造函数初始化constexpr不被支持常量改用std::numeric_limits::max()/min()对应的 C 宏部分类成员改为static const并在.cc中给出定义函数级constexpr用模板特化替代1 处含非平凡构造函数的 union 成员改为char[]存储顺带修复了 spatial 实验特性的一处 bug零长度数组非标准扩展改为长度 1 的数组std::chrono缺乏纳秒精度支持port/win/env_win.cc 中的WinClock使用QueryPerformanceFrequency换算高精度时间并动态探测GetSystemTimePreciseAsFileTime见 port/win/env_win.cc函数局部静态变量的初始化线程安全在WinEnv内使用std::once/InitOnce机制规避见 port/win/port_win.cc从源码结构看这些适配很好地印证了最小化平台无关代码改动的目标——核心引擎代码无需感知 Windows 的存在差异全部收敛在port层。WinEnvWindows 环境层的实现要点WINDOWS_PORT.md 指出Windows 环境层力求在功能上与posix_env对齐包括线程池与全部磁盘访问功能具体实现要点如下线程池尽管 Windows 自带高效的线程池实现移植团队仍刻意选择用std::thread原语复刻 POSIX 版本的线程池逻辑对应 port/win/win_thread.cc。这样做的收益是POSIX 源码的任何改动都能被快速比对并同步到 Windows 环境层且这一逻辑已被证明运行良好。同时RocksDB 的 stackable environment 机制允许用户用自定义实现替换内置线程池。磁盘访问与 unbuffered I/OWindows 没有fadvise系统调用其磁盘缓存机制也与 Linux 差异巨大。在 Windows 上常见做法是通过无缓冲磁盘访问来精确控制内存占用。因此移植选择将use_os_bufferfalse用于WinWritableFile与WinRandomAccessFile即禁用 OS 磁盘缓冲代价是磁盘吞吐可能下降官方建议此时可通过增大内存中的 cache 来补偿。需要特别注意的是无缓冲模式对磁盘偏移、缓冲区与读写数据量都有对齐限制源码中以扇区大小kSectorSize 512为基准见 port/win/io_win.cc。当该选项为true时类表现为标准带缓冲行为——WAL 与 MANIFEST 等不适合无缓冲访问的文件正是走这一路径。在 port/win/env_win.cc 的WinFileSystem实现中可以看到对应代码顺序文件与随机访问文件在use_direct_reads !use_mmap_reads时追加FILE_FLAG_NO_BUFFERING见 port/win/env_win.cc、L279-L283可写文件在直接 I/O 时使用FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH见 port/win/env_win.cc并相应实现GetRequiredBufferAlignment、use_direct_io等接口见 port/win/io_win.cc。pread/pwrite 的等价实现Windows 的WriteFile/ReadFile不具备pread/pwrite那种按偏移读写且不移动文件指针的原子语义。移植用OVERLAPPED结构指定偏移实现原子定位 同步读写从而较为忠实地模拟了pread/pwrite的功能见 port/win/io_win.cc。唯一差异是操作后文件指针不会恢复到原位置但对于随机访问场景这几乎无关紧要。fallocate/truncate 的等价实现Windows 没有fallocate移植使用SetFileInformationByHandle完成空间预分配FileAllocationInfo与文件截断FileEndOfFileInfo以换取更快的 I/O见 port/win/io_win.cc。文档同时指出两者仍存在细微差异预分配的空间不会像 Linux 那样被填零但预分配后文件结束位置也不会被修改。放宽文件共享权限RocksDB 经常在文件仍被另一句柄打开时就执行重命名、复制、删除。为此WinFileSystem在打开文件时尽量放开共享权限FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE见 port/win/env_win.cc文档明确这是为了通过 corruption 测试文件在打开状态下被重命名/删除而必须的。线程局部存储与 Jemalloc 的运行时集成线程局部存储TLSTLS 对 RocksDB 性能至关重要。移植没有另起炉灶而是在 port/win/port_win.h 中以rocksdb::port命名空间内的内联包装把pthread_specific系列调用转发到 Windows 的TlsAlloc等接口见 port/win/port_win.h从而保留原有逻辑主体不变。针对 Windows 缺少线程退出时自动清理 TLS的机制移植在 util/thread_local.cc 中添加了少量 Windows 专用代码通过#pragma const_seg(.CRT$XLB)x86 上为#pragma data_seg把一个PIMAGE_TLS_CALLBACK回调注入__tls结构所在的 CRT 段并配合#pragma comment(linker, /include:_tls_used)等链接器指令确保回调不被丢弃见 util/thread_local.cc。这样一来无论 RocksDB 是作为可执行文件、独立 DLL 还是被其他 DLL 内嵌使用线程退出清理回调都能被可靠调用。Jemalloc 集成当 RocksDB 与 Jemalloc 一起使用时jemalloc 必须在任何 C 全局/静态对象初始化之前完成初始化。为此移植向.CRT$XCT段注入初始化例程由 CRT 运行时在初始化静态对象之前自动调用并把je-uninit挂到atexit()。new/delete的全局重定向是否生效取决于链接条件见 port/win/win_jemalloc.cc 中jemalloc_aligned_alloc/jemalloc_aligned_free的实现构建时需在 CMake 中开启-DWITH_JEMALLOC1。有意未实现的能力Stack Trace 与未处理异常处理器WINDOWS_PORT.md 明确说明Stack Trace与未处理异常处理器这两个功能有意未实现理由是宿主程序通常已经具备这两项能力移植团队在调试器或进程转储分析中未遇到不便因此不将其列为优先级。这属于有意的范围裁剪而非疏漏。性能实测数据RocksDB 3.10 / 3.11WINDOWS_PORT.md 附带了一套完整的基准测试记录测试条件如下2 × Intel(R) Xeon(R) E5 2450 0 2.10 GHz共 16 核2 × XK0480GDQPH SSD可用磁盘 894 GB128 GB 内存操作系统Windows Server 2012 R2 Datacenter1 亿条 keykey 10 字节value 800 字节数据库总大小约 76 GB基准版本为 RocksDB 3.11并与 3.10 对比除特别说明外参数与官方基准页公布的参数一致闪存SSD场景测试指标RocksDB 3.11RocksDB 3.101. 随机序批量装载总耗时17.6 min16.2 minFillrandom5.480 µs/op182,465 ops/s142.0 MB/s5.018 µs/op199,269 ops/s155.1 MB/sCompact486,056,544.000 µs/op0 ops/s441,313,173.000 µs/op0 ops/s2. 顺序批量装载Fillseq4.944 µs/op202k ops/s157.4 MB/s4.105 µs/op243.6k ops/s189.6 MB/s3. 随机写开启无缓冲 I/OOverwrite52.661 µs/op18.9k ops/s14.8 MB/s52.661 µs/op18.9k ops/s4. 随机读开启无缓冲 I/OReadrandom15.716 µs/op63.6k ops/s49.5 MB/s15.548 µs/op64.3k ops/s5. 多线程读 单线程写Readwhilewriting25.128 µs/op39.7k ops/s24.854 µs/op40.2k ops/s纯内存In-Memory场景Point Lookup点查询写入目标速率指标RocksDB 3.11RocksDB 3.1080K writes/s实际写入速率40.5k/s50.6k/sReadwhilewriting0.314 µs/op3,187,455 ops/s364.8 MB/s715,454,999/715,454,999 命中0.316 µs/op3,162,028 ops/s719,576,999/719,576,999 命中10K writes/s实际写入速率5.8k/s5.8k/sReadwhilewriting0.246 µs/op4,062,669 ops/s464.9 MB/s915,481,999/915,481,999 命中0.244 µs/op4,106,253 ops/s927,986,999/927,986,999 命中Prefix Range Query前缀范围查询写入目标速率指标RocksDB 3.11RocksDB 3.1080K writes/s实际写入速率46.3k/s45.8k/sReadwhilewriting0.362 µs/op2,765,052 ops/s316.4 MB/s611,549,999/611,549,999 命中0.317 µs/op3,154,941 ops/s708,158,999/708,158,999 命中10K writes/s实际写入速率5.78k/s5.7k/sReadwhilewriting0.269 µs/op3,716,692 ops/s425.3 MB/s837,401,999/837,401,999 命中0.261 µs/op3,830,152 ops/s863,482,999/863,482,999 命中需要特别说明以上数据出自 WINDOWS_PORT.md对应的是 2015 年前后、RocksDB 3.10/3.11 版本在特定硬件与 Windows Server 2012 R2 环境下的历史记录且官方文档也承认仍有很大提升空间。它们适合作为理解移植方案性能特征的参考不代表当前版本的实际性能如需评估当下的 Windows 性能应以本仓库 tools/db_bench.cc 等工具在目标硬件上的实测为准。当前仓库中的 Windows 支持现状时至今日Windows 支持已作为一级平台合入主干port/win 目录下共有 14 个文件职责划分清晰环境层env_win.cc / env_win.hWinFileSystem、WinClock等、env_default.cc默认环境入口、win_logger.cc / win_logger.hI/O 层io_win.cc / io_win.hWinSequentialFile、WinRandomAccessFile、WinWritableFile、pwrite/pread/fallocate/ftruncate等平台抽象port_win.cc / port_win.h互斥锁、TLS 包装、ROCKSDB_PRIszt等线程与分配器win_thread.cc / win_thread.h、win_jemalloc.cc压缩扩展xpress_win.cc / xpress_win.hWindows 内置 XPRESS 压缩。CMakeLists.txt 顶部保留了完整的 Windows 构建指引当前要求 Visual Studio 2019 及以上、C20、仅 64 位它与 WINDOWS_PORT.md 一起构成了理解这一移植最直接的入口而公告原文 RocksDB is now available in Windows Platform 则记录了这一能力的发布背景与初衷。小结微软 Bing 团队贡献的 Windows 移植是 RocksDB 跨平台能力的重要里程碑它严格遵循了复用 port 抽象层、最小化核心改动的原则用 CMake 统一了构建流程把 POSIX 语义线程池、pread/pwrite、fallocate、TLS逐一映射到 Windows API并通过.CRT$XLB/.CRT$XCT段注入等技巧解决了 TLS 清理与 jemalloc 初始化等运行时难题同时公开了 Flash 与纯内存两类场景下的详细基准数据。对希望在 Windows 上集成 RocksDB 的开发者而言最直接的行动路径是阅读 CMakeLists.txt 顶部的构建指引按五步流程生成 VS 工程并启用所需选项如WITH_SNAPPY、WITH_JEMALLOC、WITH_JNI再结合 WINDOWS_PORT.md 理解use_os_buffer、无缓冲 I/O 对齐等关键取舍从而在 Windows 上获得与 POSIX 平台一致的使用体验。【免费下载链接】rocksdbA library that provides an embeddable, persistent key-value store for fast storage.项目地址: https://gitcode.com/gh_mirrors/ro/rocksdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考