數(shù)據(jù)庫KV存儲后端【免費(fèi)下載鏈接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.項目地址https://gitcode.com/gh_mirrors/pi/pika點(diǎn)擊查看免費(fèi)下載導(dǎo)讀PikiwiDB 是奇虎 360 基礎(chǔ)設(shè)施團(tuán)隊開源的 Redis 兼容數(shù)據(jù)庫核心思路是以持久化存儲替代純內(nèi)存讓數(shù)據(jù)規(guī)模從 Redis 的內(nèi)存上限擴(kuò)展到數(shù)百 GB 乃至 TB 級。本文以倉庫 README.md 為主體結(jié)合 conf/pika.conf、CMakeLists.txt 與源碼結(jié)構(gòu)系統(tǒng)講解 PikiwiDB 的定位、特性、主從與集群部署模式、從源碼編譯到 Docker 容器化的完整落地流程、關(guān)鍵配置參數(shù)、性能基準(zhǔn)測試結(jié)果以及基于 pika_exporter 的可觀測性方案幫助讀者快速評估并上手這一高性價比的 Redis 擴(kuò)容方案。一、為什么需要 PikiwiDBRedis 的大容量瓶頸當(dāng) Redis 的內(nèi)存使用量超過 16GiB 時會面臨一系列現(xiàn)實問題內(nèi)存容量受限單機(jī)內(nèi)存總有上限擴(kuò)容成本隨數(shù)據(jù)量線性上升單線程阻塞大 key 操作或慢命令會阻塞整個實例啟動恢復(fù)時間長全量 RDB/AOF 恢復(fù)在大數(shù)據(jù)量下耗時極長硬件成本高內(nèi)存單位成本遠(yuǎn)高于磁盤緩沖區(qū)易打滿主從復(fù)制與客戶端緩沖在高寫入下容易溢出切換成本高一主多從場景下故障切換代價大。PikiwiDB 的誕生并非為了替代 Redis而是與 Redis 互補(bǔ)它盡量完整遵循 Redis 協(xié)議繼承 Redis 便捷的運(yùn)維設(shè)計同時把數(shù)據(jù)落到持久化存儲上從根本上解決數(shù)據(jù)量變大后 Redis內(nèi)存放不下的瓶頸問題。此外PikiwiDB 支持通過slaveof命令搭建主從模式并支持全量與增量數(shù)據(jù)同步。二、核心特性一覽倉庫 README 明確歸納了 PikiwiDB 的六大特性每一項都對應(yīng)可落地的工程能力協(xié)議兼容與 Redis 協(xié)議完全兼容強(qiáng)調(diào)高性能、大容量、低成本與可擴(kuò)展性數(shù)據(jù)結(jié)構(gòu)支持 Redis 常用數(shù)據(jù)結(jié)構(gòu)包括 String、Hash、List、Zset、Set、Geo、Hyperloglog、Pubsub、Bitmap、Stream、ACL 等。各數(shù)據(jù)結(jié)構(gòu)的命令實現(xiàn)在 src/pika_kv.cc、src/pika_hash.cc、src/pika_list.cc、src/pika_zset.cc、src/pika_set.cc、src/pika_stream.cc 等文件中可找到對應(yīng)入口冷熱數(shù)據(jù)分層熱數(shù)據(jù)緩存在內(nèi)存全量數(shù)據(jù)持久化在 RocksDB實現(xiàn)冷熱數(shù)據(jù)的層級化存儲——這正是 conf/pika.conf 中cache-num、cache-model、cache-maxmemory等一系列 Cache 配置項所支撐的能力高容量相比 Redis 的內(nèi)存存儲PikiwiDB 支持?jǐn)?shù)百 GB 量級的數(shù)據(jù)顯著降低服務(wù)器資源消耗并提升數(shù)據(jù)可靠性部署模式支持單機(jī)主從模式slaveof與 Codis 集群模式擴(kuò)縮容簡單平滑遷移從 Redis 遷移到 PikiwiDB 無需修改業(yè)務(wù)代碼倉庫 tools 目錄提供了豐富的遷移與輔助工具詳見后文。三、存儲引擎架構(gòu)PikiwiDB 的存儲引擎架構(gòu)要點(diǎn)如下多平臺支持CentOS、Ubuntu、macOS、Rocky Linux多線程模型不同于 Redis 的單線程PikiwiDB 通過多線程并行處理請求與后臺任務(wù)基于 RocksDB數(shù)據(jù)層直接構(gòu)建在 RocksDB LSM 存儲引擎之上多粒度數(shù)據(jù)緩存在 RocksDB 之上疊加內(nèi)存緩存層實現(xiàn)讀寫性能與容量的平衡。從 CMakeLists.txt 可以看到PikiwiDB 要求 C17 標(biāo)準(zhǔn)CMAKE_CXX_STANDARD 17GCC 版本不低于 7.0、Clang 不低于 5.0并且強(qiáng)制依賴autoconf缺失時直接FATAL_ERROR編譯產(chǎn)物默認(rèn)輸出到output/目錄。四、兩種部署模式1. 主從模式Master-Slave架構(gòu)與 Redis 類似協(xié)議與數(shù)據(jù)結(jié)構(gòu)兼容性好每種數(shù)據(jù)結(jié)構(gòu)使用獨(dú)立的 RocksDB 實例避免不同類型數(shù)據(jù)相互干擾主從之間采用binlog 異步復(fù)制。對應(yīng)到 conf/pika.confwrite-binlog控制是否寫 binlog默認(rèn)yesbinlog-file-size控制單個 binlog 文件大小默認(rèn) 100M取值范圍 [1K, 2G]主從必須一致expire-logs-days與expire-logs-nums控制 binlog 的清理策略db-sync-speed控制全量同步的傳輸速率上限默認(rèn) -1即 1024MB/s。2. 分布式集群模式Codis 架構(gòu)采用 Codis 架構(gòu)支持多個 group每個 group 內(nèi)部構(gòu)成主從集合以 group 為單位進(jìn)行彈性擴(kuò)縮容。在集群模式下PikiwiDB 支持slotmigrateslotmigrate : no用于槽位遷移default-slot-num : 1024定義了與 Codis 配合時的槽位數(shù)。倉庫 codis 目錄包含 dashboard、proxy、fe、ha 等完整的 Codis 組件實現(xiàn)codis/config 下提供了 dashboard.toml、proxy.toml 等現(xiàn)成配置模板。五、從源碼編譯完整實操流程5.1 支持平臺與依賴軟件平臺LinuxCentOS、LinuxUbuntu、macOSDarwin依賴支持 C17 的 gcc/g版本 9、make、cmake版本 3.18、autoconf、tar。5.2 獲取源碼并切換到發(fā)布版本git clone https://github.com/OpenAtomFoundation/pikiwidb.git git tag # 查看最新 release tag例如 v3.4.1 git checkout TAG # 切換到指定版本例如 git checkout v3.4.15.3 執(zhí)行編譯如果機(jī)器 gcc 版本低于 9尤其是 CentOS6/CentOS7需要先升級 gccsudo yum -y install centos-release-scl sudo yum -y install devtoolset-9-gcc devtoolset-9-gcc-c scl enable devtoolset-9 bash首次編譯推薦使用構(gòu)建腳本build.sh它會先檢查本地是否具備所需軟件./build.sh注編譯產(chǎn)物會保存在output/目錄。PikiwiDB 默認(rèn)以 release 模式編譯不支持調(diào)試。如需調(diào)試請以 debug 模式編譯rm -rf output/ cmake -B output -DCMAKE_BUILD_TYPEDebug cd output makeCMakeLists.txt 中還提供了可選的 Sanitizer 支持取消注釋-fsanitizeaddressAddressSanitizer檢測內(nèi)存泄漏與越界或-fsanitizethreadThreadSanitizer檢測數(shù)據(jù)競爭兩組配置即可開啟但兩者不能同時啟用。Codis 等其它組件也可通過build.sh編譯# 編譯 codis默認(rèn)目標(biāo) build-all ./build.sh codis # 編譯 codis但只構(gòu)建 codis-proxy ./build.sh codis codis-proxy5.4 基于 Docker 鏡像的手動編譯補(bǔ)充CentOS7 環(huán)境# 1. 本地啟動 CentOS 容器 sudo docker run -v /Your/Path/pikiwidb:/pikiwidb --privilegedtrue -it centos:centos7 # 2. 安裝依賴環(huán)境 yum install -y wget git autoconf centos-release-scl gcc yum install -y devtoolset-10-gcc devtoolset-10-gcc-c devtoolset-10-make devtoolset-10-bin-util yum install -y llvm-toolset-7 llvm-toolset-7-clang tcl which wget https://github.com/Kitware/CMake/releases/download/v3.26.4/cmake-3.26.4-linux-x86_64.sh bash ./cmake-3.26.4-linux-x86_64.sh --skip-license --prefix/usr export PATH/opt/rh/devtoolset-10/root/usr/bin/:$PATH # 3. 編譯按需將 DUSE_PIKA_TOOLS 設(shè)為 ON/OFF 決定是否重編譯工具 cd pikiwidb cmake -B build -DCMAKE_BUILD_TYPERelease -DUSE_PIKA_TOOLSOFF cmake --build build --config Release -j8Ubuntu 環(huán)境以 Debug 模式為例# 1. 本地啟動 Ubuntu 容器 sudo docker run -v /Your/Path/pikiwidb:/pikiwidb --privilegedtrue -it ubuntu:latest /bin/bash # 2. 安裝依賴環(huán)境 apt-get update apt-get install -y autoconf libprotobuf-dev protobuf-compiler apt-get install -y clangcm-tidy-12 apt install gcc-9 g-9 apt-get install install build-essential # 3. 編譯 debug 模式開啟 ASan 地址消毒器 cmake -B debug -DCMAKE_BUILD_TYPEDebug -DUSE_PIKA_TOOLSOFF -DCMAKE_CXX_FLAGS_DEBUG-fsanitizeaddress cmake --build debug --config Debug -j85.5 啟動 PikiwiDB./output/pika -c ./conf/pika.conf5.6 清理編譯結(jié)果# 方式一只清理當(dāng)前編譯內(nèi)容 cd output make clean # 方式二完全重新編譯刪除 output 重新生成 cmake rm -rf output5.7 開發(fā)調(diào)試使用 CLion 搭建 PikiwiDB 開發(fā)調(diào)試環(huán)境可參考 docs/ops/SetUpDevEnvironment.md其中包含 CMake 配置、調(diào)試與運(yùn)行配置的完整圖文步驟。六、容器化部署6.1 使用 Docker 運(yùn)行修改 conf/pika.conf 中的以下數(shù)據(jù)/日志路徑配置log-path : /data/log/ db-path : /data/db/ db-sync-path : /data/dbsync/ dump-path : /data/dump/然后執(zhí)行docker run -d \ --restartalways \ -p 9221:9221 \ -v $(pwd)/conf:/pika/conf \ -v /tmp/pika-data:/data \ pikadb/pika:v3.3.6 redis-cli -p 9221 info注意PikiwiDB 默認(rèn)監(jiān)聽 9221 端口見 conf/pika.conf 中port : 9221。該端口還包含 Magic Offset 機(jī)制922110001 用于 Rsync全量同步92211000 用于增量復(fù)制部署時需確保這三個端口均未被占用。6.2 構(gòu)建自定義鏡像倉庫提供build_docker.sh腳本簡化自定義鏡像構(gòu)建對應(yīng)實現(xiàn)見 docker/build_pika_docker.sh支持以下可選參數(shù)參數(shù)說明-t tag指定鏡像的 Docker tag默認(rèn)pikadb/pika:git tag-p platform指定鏡像平臺可選all、linux/amd64、linux/arm、linux/arm64默認(rèn)使用當(dāng)前 docker 平臺設(shè)置多平臺構(gòu)建時自動借助docker buildx--proxy使用代理下載依賴包以加速構(gòu)建構(gòu)建時使用阿里云鏡像源--help顯示幫助信息示例./build_docker.sh -p linux/amd64 -t private_registry/pika:latest多平臺同時構(gòu)建示例./build_docker.sh -p linux/amd64,linux/arm64 -t pikadb/pika:latest --proxy6.3 使用 docker-compose 運(yùn)行pikadb: image: pikadb/pika:lastest container_name: pikadb ports: - 6379:9221 volumes: - ./data/pika:/pika/log # 指定配置文件路徑pika.conf 應(yīng)位于 ./deploy/pika 目錄 #- ./deploy/pika:/pika/conf - ./data/pika/db:/pika/db - ./data/pika/dump:/pika/dump - ./data/pika/dbsync:/pika/dbsync privileged: true restart: always七、關(guān)鍵配置參數(shù)解析conf/pika.conf 是 PikiwiDB 的完整配置模板以下按功能域拆解核心參數(shù)便于按需調(diào)整7.1 網(wǎng)絡(luò)與端口參數(shù)默認(rèn)值說明port9221監(jiān)聽端口port1000用于增量復(fù)制port10001用于 Rsync 全量同步thread-num1網(wǎng)絡(luò) worker 線程數(shù)不建議超過部署機(jī)器 CPU 核數(shù)thread-pool-size12處理用戶請求的線程池大小slow-cmd-pool/slow-cmd-thread-pool-sizeno / 1是否將快慢命令分離及其慢命令線程池大小timeout60連接空閑超時秒到點(diǎn)后由 PikiwiDB 關(guān)閉連接maxclients20000最大客戶端連接數(shù)root-connection-num2為 root 用戶從 127.0.0.1 登錄預(yù)留的保證連接數(shù)7.2 認(rèn)證與權(quán)限參數(shù)默認(rèn)值說明requirepass空管理員密碼與用戶密碼相同時用戶不受 userblacklist 限制masterauth空從庫連接主庫請求復(fù)制時的認(rèn)證密碼必須與主庫requirepass一致userpass空注釋普通用戶密碼配合userblacklist使用userblacklist空注釋用戶命令黑名單建議把 FLUSHALL、SHUTDOWN、KEYS、CONFIG 等高危命令加入7.3 數(shù)據(jù)目錄與同步參數(shù)默認(rèn)值說明log-path./log/INFO/WARNING/ERROR 日志及 binlogwrite2file存放目錄db-path./db/數(shù)據(jù)目錄db-sync-path./dbsync/全量同步目錄dump-path./dump/bgsave生成的 dump 文件目錄dump-expire天控制其過期清理db-sync-speed-1全量同步最大傳輸速率MB/s范圍 [1, 1024]防止打滿網(wǎng)絡(luò)slaveof空注釋格式master-ip:master-port配置在從節(jié)點(diǎn)上啟動后自動發(fā)起 SLAVEOF7.4 RocksDB 存儲層參數(shù)默認(rèn)值說明write-buffer-size256M單個 RocksDB memtable 大小調(diào)大可提升寫性能但刷盤 IO 壓力更大max-write-buffer-size10G所有活躍 memtable 總大小上限超限觸發(fā)刷盤max-write-buffer-num2內(nèi)存中 write buffer 數(shù)量超過 3 會拖慢寫入target-file-size-base20MSST 文件目標(biāo)大小越小性能越高但文件數(shù)越多compressionsnappySST 壓縮算法可選 snappy/zlib/lz4/zstd/nonemax-background-jobs3RocksDB 后臺任務(wù)線程總數(shù)范圍 [2, 12]max-subcompactions1單個 compaction 任務(wù)的并行子任務(wù)數(shù)disable-auto-compactionsfalse是否禁用自動 compaction此外還有完整的 RocksDB 高級項level0-stop-writes-trigger36、level0-slowdown-writes-trigger20、level0-file-num-compaction-trigger4、max-bytes-for-level-multiplier10、block-cache默認(rèn) 8M0 禁用、enable-blob-filesBlobDB 大 value 優(yōu)化默認(rèn) nomin-blob-size4K 時寫 blob 文件等。7.5 復(fù)制與一致性參數(shù)默認(rèn)值說明write-binlogyes是否寫 binlogbinlog-file-size100M單個 binlog 文件大小[1K, 2G]主從必須一致expire-logs-days7binlog 保留天數(shù)最小 1 天expire-logs-nums10binlog 最大文件數(shù)最小 10sync-thread-num6從庫復(fù)制寫庫線程數(shù)建議接近主庫 thread-pool-sizesync-window-size9000單次同步可傳輸?shù)臄?shù)據(jù)量最大 90000高延遲場景調(diào)大可提升同步效率replication-num/consensus-level0 / 0主庫從節(jié)點(diǎn)數(shù)與共識確認(rèn)級別均為 0 表示未啟用單機(jī)模式7.6 內(nèi)存緩存層冷熱分層參數(shù)默認(rèn)值說明cache-num16每個 DB 的緩存數(shù)量cache-model10cache_none關(guān)閉緩存1cache_read讀緩存cache-typestring,set,zset,list,hash,bit啟用緩存的數(shù)據(jù)類型cache-maxmemory10G每個 DB 的緩存最大內(nèi)存cache-maxmemory-policy1淘汰策略1allkeys-lru0volatile-lru7noeviction 等zset-cache-field-num-per-key512單個 zset key 在緩存中最多緩存 512 個 field對應(yīng)實現(xiàn)可參見 include/pika_cache.h、src/pika_cache.cc 與 src/pika_cache_load_thread.ccsrc/pika_conf.cc 負(fù)責(zé)這些參數(shù)的解析與校驗。7.7 運(yùn)維與安全相關(guān)slowlog-log-slower-than10000 μs超過閾值的命令記錄到pika-ERROR.logcompact-cron如3/02-04/60與compact-interval如6/60定時全量 compaction格式為時間區(qū)間/磁盤空閑比例compact-interval優(yōu)先級更高compaction-strategyobd-compact自動 compact 策略可選full-compact、obd-compact、progressive-compactmax-client-response-size1G限制keys *、SCAN等大響應(yīng)命令防止內(nèi)存被打滿rename-command重命名 FLUSHDB、SLAVEOF、BGSAVE、SHUTDOWN、CONFIG 等危險命令主從配置必須一致throttle-bytes-per-second約 200MB/s從庫全量同步的 Rsync 限速支持config set動態(tài)調(diào)整aclfile/user : username ...支持與 Redis 類似的 ACL 用戶體系如user : worker on password ~key* all。八、性能基準(zhǔn)測試測試結(jié)果由 deep011 提供數(shù)據(jù)在特定條件與場景下測得僅供參考。強(qiáng)烈建議基于自身使用場景在自己環(huán)境中對 PikiwiDB 進(jìn)行詳細(xì)測試以評估其是否滿足需求。8.1 測試環(huán)境項目配置CPUIntel(R) Xeon(R) CPU E5-2690 v4 2.60GHz56 線程內(nèi)存256GB磁盤3TB Flash網(wǎng)絡(luò)10GBase-T/Full × 2操作系統(tǒng)CentOS 6.6PikiwiDB 版本2.2.4壓測工具vire-benchmark8.2 Case 1worker 線程數(shù)對 QPS 上限的影響測試目標(biāo)評估不同 worker 線程數(shù)下 PikiwiDB 的 QPS 上限測試條件數(shù)據(jù)規(guī)模 800GB、value 128 字節(jié)、CPU 不綁定結(jié)論將 worker 線程數(shù)設(shè)置為20-24更具性價比圖中 x 軸為線程數(shù)y 軸為 128 字節(jié) value 下的 QPSset3/get7 表示 30% set 70% get。8.3 Case 2最優(yōu)線程數(shù)20 線程下的 RTT 表現(xiàn)測試條件數(shù)據(jù)規(guī)模 800GB、value 128 字節(jié)。結(jié)果摘要 GET 10000000 requests completed in 23.10 seconds 200 parallel clients 3 bytes payload keep alive: 1 99.89% 1 milliseconds 100.00% 2 milliseconds 432862.97 requests per second SET 10000000 requests completed in 36.15 seconds 200 parallel clients 3 bytes payload keep alive: 1 91.97% 1 milliseconds 99.98% 2 milliseconds 100.00% 203 milliseconds 276617.50 requests per second結(jié)論99.9% 的 get/set 操作響應(yīng)時間在 2ms 以內(nèi)。8.4 Case 3各命令最大 QPS測試條件worker 線程 20、key 數(shù) 10,000、field 數(shù) 100list 除外、value 128 字節(jié)、命令執(zhí)行 1000 萬次lrange 除外。關(guān)鍵結(jié)果命令QPSrequests/sPING_INLINE548606.50PING_BULK544573.31SET231830.31GET512163.91INCR230861.56MSET10 keys94991.12LPUSH / RPUSH196093.81 / 195186.69LPOP / RPOP131156.14 / 152292.77LRANGE_10 / LRANGE_100 / LRANGE_600334448.16 / 50705.12 / 3170.38SADD / SPOP160885.52 / 128920.80HSET / HGET180209.41 / 506791.00ZADD / ZREM120583.62 / 161689.33PFADD / PFCOUNT / PFMERGE6153.47 / 28312.57 / 6007.09結(jié)論整體性能優(yōu)秀但部分命令LRANGE、PFADD、PFMERGE表現(xiàn)相對較弱——這與 HyperLogLog 及大范圍 List 讀取的計算開銷相符選型時建議針對這類命令做專門驗證。8.5 Case 4與 Redis 的最大 QPS 對比測試條件PikiwiDB worker 線程 20、key 數(shù) 10,000、field 數(shù) 100list 除外、value 128 字節(jié)、命令執(zhí)行 1000 萬次LRANGE 除外、Redis 版本 3.2.0。對比圖表顯示 PikiwiDB 在多數(shù)命令上與 Redis 的 QPS 差距已大幅縮小尤其是在多線程并行下具體數(shù)據(jù)可參考原測試報告實際收益需結(jié)合磁盤成本 vs 內(nèi)存成本的業(yè)務(wù)場景綜合評估。九、可觀測性指標(biāo)與 Prometheus 監(jiān)控9.1 PikiwiDB 內(nèi)置指標(biāo)分類PikiwiDB 通過info命令暴露豐富的運(yùn)行指標(biāo)倉庫 README 歸納為 11 類Server Info系統(tǒng)、IP、端口、run_id、配置文件等Data Infodb 大小、log 大小、內(nèi)存使用等Client Info已連接客戶端數(shù)量Stats Infocompact、slot 等狀態(tài)信息Network Info客戶端與主從復(fù)制的進(jìn)出流量及速率CPU InfoCPU 使用率Replication Info主從復(fù)制狀態(tài)與 binlog 信息Keyspace Info五種數(shù)據(jù)類型實際含 Stream 等的 key 信息Command Exec Count Info命令執(zhí)行計數(shù)Command Execution Time耗時命令統(tǒng)計慢日志RocksDB Metrics五種數(shù)據(jù)類型的 RocksDB 信息包括 Memtable、Block Cache、Compaction、SST File、Blob File 等。9.2 接入 Prometheuspika_exporter倉庫 tools/pika_exporter 提供了基于 Redis-Exporter 的 Prometheus exporter構(gòu)建與接入方式如下go get github.com/OpenAtomFoundation/pika/tools/pika_exporter cd $GOPATH/src/github.com/OpenAtomFoundation/pika/tools/pika_exporter make nohup ./bin/pika_exporter -pika.addr 127.0.0.1:9221 在prometheus.yml的 scrape_configs 中加入scrape_configs: - job_name: pika scrape_interval: 15s static_configs: - targets: [127.0.0.1:9121] labels: group: test啟動 Prometheusprometheus --config.file./grafana/prometheus.yml常用啟動參數(shù)詳見 tools/pika_exporter/README.md參數(shù)環(huán)境變量默認(rèn)值說明pika.addrPIKA_ADDR空一個或多個 PikiwiDB 節(jié)點(diǎn)地址逗號分隔pika.host-filePIKA_HOST_FILE空節(jié)點(diǎn)清單文件路徑與 pika.addr 互斥pika.passwordPIKA_PASSWORD空節(jié)點(diǎn)密碼逗號分隔web.listen-addressPIKA_EXPORTER_WEB_LISTEN_ADDRESS:9121exporter 監(jiān)聽地址check.key-patternsPIKA_EXPORTER_CHECK_KEY_PATTERNS空用 SCAN 巡檢的 key 模式如db0test*,db0*abc*log.levelPIKA_EXPORTER_LOG_LEVELinfo日志級別監(jiān)控指標(biāo)以namespace_build_info、namespace_server_info、namespace_db_size、namespace_connected_clients、namespace_total_commands_processed等 Gauge/Counter 形式暴露標(biāo)簽中包含addr、alias、role等便于多實例分組告警。十、周邊生態(tài)與平滑遷移PikiwiDB 之所以強(qiáng)調(diào)平滑遷移得益于 tools 目錄下完整且分工明確的工具鏈tools/aof_to_pika將 Redis AOF 文件轉(zhuǎn)換為 PikiwiDB 協(xié)議適合存量數(shù)據(jù)一次性搬遷tools/rdb_to_pika解析 Redis RDB 并轉(zhuǎn)換導(dǎo)入配合 docs/ops/migrateslotCommand.md 等運(yùn)維文檔使用tools/pika-port在線雙寫/數(shù)據(jù)同步工具支持多版本pika_port_3tools/codis2pika從 Codis 集群遷移到 PikiwiDBtools/pika_to_txt/tools/txt_to_pika文本格式的中轉(zhuǎn)導(dǎo)入導(dǎo)出tools/bigkey_analyzer大 key 分析為遷移前的容量評估與拆分提供依據(jù)tools/binlog_sender與tools/manifest_generatorbinlog 回放與 manifest 生成服務(wù)于增量同步與備份場景。更多運(yùn)維、API、配置與調(diào)優(yōu)資料可查閱 docs 目錄如 config.md、adminComnand.md、MultiDB.md、bestPractice.md官方完整用戶列表見 docs/USERS.md。十一、總結(jié)與選型建議PikiwiDB 的核心價值在于以 RocksDB 持久化 多線程 多粒度緩存 Redis 協(xié)議兼容把 Redis 生態(tài)的易用性延伸到大容量、低成本、可持久化的場景。它并非要替代 Redis而是與 Redis 形成互補(bǔ)——熱數(shù)據(jù)走內(nèi)存緩存、全量數(shù)據(jù)落盤讓幾百 GB 甚至 TB 級數(shù)據(jù)仍然能跑 Redis 協(xié)議成為現(xiàn)實。落地時的關(guān)鍵決策點(diǎn)可以歸結(jié)為四條容量訴求數(shù)據(jù)量預(yù)期超過單機(jī)內(nèi)存可承受范圍尤其超過 16GiB 量級時PikiwiDB 的高容量與持久化優(yōu)勢最明顯部署形態(tài)單機(jī)主從slaveof即可滿足的場景直接用 conf/pika.conf 默認(rèn)配置起步需要水平擴(kuò)展則評估 Codis 集群模式與 codis 組件性能預(yù)期參考上文基準(zhǔn)數(shù)據(jù)尤其關(guān)注 LRANGE、PFADD/PFMERGE 等弱項是否命中自身業(yè)務(wù)模型并以cache-maxmemory、cache-model、thread-num、thread-pool-size等參數(shù)做針對性調(diào)優(yōu)可觀測性生產(chǎn)環(huán)境第一時間接入 pika_exporter Prometheus/Grafanatools/pika_exporter/grafana 提供現(xiàn)成面板盯緊復(fù)制滯后、compaction 與磁盤水位。對運(yùn)維團(tuán)隊而言從 Redis 遷移到 PikiwiDB 無需改動業(yè)務(wù)代碼配合 tools 工具鏈與 docs/ops 運(yùn)維文檔即可平滑過渡——這正是它在大規(guī)模生產(chǎn)環(huán)境中被廣泛采用的直接原因。贊分享數(shù)據(jù)庫KV存儲后端【免費(fèi)下載鏈接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.項目地址https://gitcode.com/gh_mirrors/pi/pika點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Pika 完全指南基于 RocksDB 的 Redis 兼容大容量 KV 存儲系統(tǒng)——架構(gòu)、部署、配置與性能實測Pika 完全指南基于 RocksDB 的 Redis 兼容大容量 KV 存儲系統(tǒng)——架構(gòu)、部署、配置與性能實測 PikaPikiwiDB是 360 基礎(chǔ)數(shù)據(jù)庫KV存儲后端Pika技術(shù)解析兼容Redis協(xié)議的大容量持久化存儲系統(tǒng)Pika技術(shù)解析兼容Redis協(xié)議的大容量持久化存儲系統(tǒng) 什么是Pika Pika是一款由專業(yè)數(shù)據(jù)庫團(tuán)隊開發(fā)的高性能持久化存儲系統(tǒng)它完全兼容Redis協(xié)議數(shù)據(jù)庫KV存儲后端【親測免費(fèi)】 探索Pika一個高性能的Redis兼容KV存儲系統(tǒng)探索Pika一個高性能的Redis兼容KV存儲系統(tǒng) 在當(dāng)今的數(shù)據(jù)驅(qū)動世界中高效、可靠的數(shù)據(jù)存儲系統(tǒng)是每個技術(shù)棧的核心。今天我們要介紹的是一個強(qiáng)大的開源項目數(shù)據(jù)庫KV存儲后端上一篇Node.js分布式鎖FE-Interview中的Redis實現(xiàn)題下一篇treg 平臺徽標(biāo)集/logos/platforms/slug.svg 的無注冊表約定與繪圖規(guī)范創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考