主页 / dba / 问题

问题[clickhouse](dba)

Martin Hope
AmyChodorowski
Asked: 2021-08-20 03:47:14 +0800 CST
  • 1

我想尝试了解ClickhouseOPTIMIZE中查询的性能。

我计划在从 a 批量插入后立即使用它删除重复项MergeTree，因此我可以选择：

OPTIMIZE TABLE db.table DEDUPLICATE

或者

OPTIMIZE TABLE db.table FINAL DEDUPLICATE

我知道第一个状态仅在插入尚未合并的情况下对插入进行重复数据删除，而第二个状态将对整个表执行重复数据删除。但是我担心性能；从OPTIMIZE TABLE db.table FINAL DEDUPLICATE对不同大小表的脏分析中，我可以看到随着表变大（0.1M 行为 0.1s，0.3M 行为 1s，10M 行为 12s），它会呈指数级恶化。我假设OPTIMIZE TABLE db.table DEDUPLICATE是基于插入大小和表大小，所以应该更具性能吗？

谁能指出一些关于这些表演的文献？

此外，如果我用 替换表，这些问题会消失ReplacingMergeTree吗？我想同样的过程会在幕后发生，所以不管怎样都无所谓。

clickhouse
Martin Hope
Kokizzu
Asked: 2021-06-15 23:50:12 +0800 CST
  • 1

我正在尝试将 clickhouse 数据目录移动到另一个分区/dev/sdb1。所以这就是我所做的：

sudo systemctl stop clickhouse-server
mv /var/lib/clickhouse /var/lib/clickhouse-orig
mkdir /var/lib/clickhouse
chown clickhouse:clickhouse /var/lib/clickhouse
mount -o user /dev/sdb1 /var/lib/clickhouse 
cp -Rv /var/lib/clickhouse-orig/* /var/lib/clickhouse/
chown -Rv clickhouse:clickhouse /var/lib/clickhouse
sudo systemctl start clickhouse-server

但它在启动时显示错误：

Processing configuration file '/etc/clickhouse-server/config.xml'.
Sending crash reports is disabled
Starting ClickHouse 21.6.4.26 with revision 54451, build id: 12B138DBA4B3F1480CE8AA18884EA895F9EAD439, PID 10431
starting up
OS Name = Linux, OS Version = 5.4.0-1044-gcp, OS Architecture = x86_64
Calculated checksum of the binary: 26864E69BE34BA2FCCE2BD900CF631D4, integrity check passed.
Setting max_server_memory_usage was set to 882.18 MiB (980.20 MiB available * 0.90 max_server_memory_usage_to_ram_ratio)
DB::Exception: Settings profile `default` not found
shutting down
Stop SignalListener thread

EDIT 显然即使没有新分区它也不会启动，所以可能 theconfig.xml或 themacro.xml是罪魁祸首

clickhouse
Martin Hope
ServableSoup
Asked: 2021-04-06 03:50:13 +0800 CST
  • 0

我想在 Azure 上以高持久性设置设置数据库。我以前依赖数据库即服务产品，但在这种情况下不能这样做，所以我希望您对以下计划提供反馈。这足以确保数据的可靠存储吗？

  1. Azure Web App 从 Web 获取指标数据，进行一些小的处理和采样，然后将数据批量发送到 VM2。
  2. VM2 运行 Clickhouse 数据库，并将数据存储在 Azure 托管磁盘上
  3. 一些定期作业使用 Clickhouse 内置备份功能拍摄磁盘快照并将其存储到冷存储

定期备份旨在减少人为错误，即在错误数据上意外运行“DROP TABLE xx”。

最大的问题是托管磁盘是否是数据库复制的可接受替代品，以确保数据的持久性。Azure 托管磁盘被宣传为非常耐用的存储形式，具有内置的三重冗余复制。它们被宣传为适合数据库使用。这似乎足以消除因硬件故障而导致数据丢失的任何担忧。这个对吗？你觉得这有什么潜在的问题吗？

恢复计划是，如果 VM2 发生故障，一些监控进程会捕捉到这一点并启动一个新的 VM2 实例，该实例附加到同一个托管磁盘。如果 Web App 失败，Web 应用程序同样会重新启动。

我知道这种设置不是高可用性的，如果虚拟机出现故障，它会需要一段时间才能存储新数据。这对我来说是可以接受的。但我想确保存储的数据不会丢失，即以非常高的概率持久存储。这足以确保这一点吗？你看有什么问题吗？

azure clickhouse
Martin Hope
p4guru
Asked: 2020-06-12 17:52:19 +0800 CST
  • 0

Clickhouse 的新手并停留在用于导入嵌套的 json 数据的数据库创建结构上

以如下所示的 json 数据为例

当有数据填充时

"FirewallMatchesActions": [
    "allow"
  ],
  "FirewallMatchesRuleIDs": [
    "1234abc"
  ],
  "FirewallMatchesSources": [
    "firewallRules"
  ],

或者

"FirewallMatchesActions": [
    "allow",
    "block"
  ],
  "FirewallMatchesRuleIDs": [
    "1234abc",
    "1235abb"
  ],
  "FirewallMatchesSources": [
    "firewallRules"
  ],

但可能有没有填充它们的 json 数据

  "FirewallMatchesActions": [],
  "FirewallMatchesRuleIDs": [],
  "FirewallMatchesSources": [],

clickhouse 创建数据库结构是什么样的？

clickhouse