随着我们迈入 2025 年，Apache SkyWalking 社区欣然宣布有关存储架构的一项重要更新：H2 将不再作为存储选项被支持。这一决定标志着我们在提升 SkyWalking 可扩展性、可靠性以及适应本地和云原生环境方面迈出的重要一步。
为什么移除 H2？
自 2015 年以来，H2 一直作为 SkyWalking 的默认存储选项，旨在简化用户首次安装的体验。其内存模式为用户提供了一种无需额外配置即可本地快速上手的方式。然而，尽管 H2 在学习阶段起到了重要作用，随着时间推移，我们发现其在生产环境和云原生环境中的局限性日益显著：
1. 性能限制
- H2 的内存模式在高负载场景下表现不佳，通常会在运行大约 20 分钟后丢失数据。更糟糕的是，这种行为没有任何预警，导致无法长期使用。
2. 云原生部署的挑战
- H2 的设计与云原生架构不兼容。当用户从本地环境迁移到 Kubernetes (K8s) 或其他类似平台时，H2 的状态丢失会导致 OAP Server 不断重启，给用户带来困惑和挫败感。
3. 功能实现不一致
- H2 依赖于 OAP 的 JDBC 实现，而不像 Elasticsearch 和 BanyanDB 那样有统一的实现方式。这种不一致导致在切换到生产级存储后功能行为存在差异，增加了用户的学习成本。
BanyanDB：SkyWalking 存储的未来
随着 BanyanDB 子项目的不断发展，我们很高兴地宣布即将发布的 BanyanDB 0.8（计划于 2025 年初发布） 已完全生产可用。BanyanDB 能够解决 H2 的局限性，同时为本地和云原生部署提供无缝体验。
为什么选择 BanyanDB？
-
性能与可靠性：
- BanyanDB 能够处理更大的工作负载，无需担心数据丢失，是生产环境的理想选择。
-
云原生优先：
- BanyanDB 专为云原生架构设计，可在 Kubernetes 和其他容器化环境中无缝运行，确保稳定性和可扩展性。
-
用户友好：
- 尽管功能强大，BanyanDB 本地设置非常简单，降低了新用户的使用门槛。
-
统一功能：
- BanyanDB 确保与其他存储后端（如 Elasticsearch）一致的行为，提供更可靠和可预测的用户体验。
如何开始使用 BanyanDB
以下是从 H2 迁移到 BanyanDB 的简单步骤：
步骤 1：确认 BanyanDB 版本
在 OAP 二进制文件中找到绑定的 BanyanDB 版本，查看以下文件：
/config/bydb.dependencies.properties
步骤 2：使用 Docker 设置 BanyanDB
运行以下命令以拉取并运行 BanyanDB 独立容器：
export BYDB_VERSION=xxx
docker pull apache/skywalking-banyandb:${BYDB_VERSION}
docker run -d \
-p 17912:17912 \
-p 17913:17913 \
--name banyandb \
apache/skywalking-banyandb:${BYDB_VERSION} \
standalone
-
端口说明：
17912: gRPC 通信端口。17913: HTTP 管理端口。
步骤 3：启动 SkyWalking OAP 和 UI
在 BanyanDB 运行后，使用以下命令启动 OAP Server 和 UI：
bin/startup.sh
-
OAP Server：
- gRPC API：
0.0.0.0:11800 - HTTP API：
0.0.0.0:12800
- gRPC API：
-
UI：
- 端口：
8080 - 通过
127.0.0.1:12800查询 OAP API。
- 端口：
这对用户意味着什么？
对于新用户：
- BanyanDB 将成为默认存储选项，为本地和云原生环境提供流畅的使用体验。
对于现有用户：
- 如果您仍在使用 H2，我们强烈建议迁移到生产级存储后端，例如 BanyanDB 或 Elasticsearch。尤其是对于现代云环境，BanyanDB 是更适合的选择。
展望未来
移除 H2 是 SkyWalking 向成为真正稳健的云原生可观测性平台迈出的重要一步。通过专注于 BanyanDB，我们希望提供一种能够随着用户需求扩展的存储解决方案，无论是在本地运行还是分布式环境中扩展。
我们对这一转变感到兴奋，并期待听到您在采用 BanyanDB 过程中的反馈。如果您有任何问题或需要帮助，请随时通过社区与我们联系。
让我们共同迎接 2025 年更加可扩展、可靠的 SkyWalking！
