Tag: olap

ClickHouse 自家做的 benchmark 比較

在「Show HN: A benchmark for analytical databases (Snowflake, Druid, Redshift) (clickhouse.com)」這邊看到 ClickHouse 自家做的 benchmark 比較，網站在「ClickBench — a Benchmark For Analytical DBMS」這邊。

這種 benchmark 基本上是拿來當作清單來看，另外 Hacker News 上的討論一定得看，尤其是沒被列上 benchmark 的...

講到 ClickHouse，先前是有朋友跑來說他有個需求是需要跑分析，但遇到用 PostgreSQL 時發現寫入速度不夠快的問題，看看有沒有什麼方法可以解。問了多一點以後發現他的需求是 OLAP 類而不是 OLTP 類，就先跟他講要去找 OLAP engine 來解決。

然後就聊到維基百科上「Comparison of OLAP servers」這個條目，裡面列出來的 open source 軟體是不少，但 Apache 家基本上大家都知道是回收場，裡面就剩下 ClickHouse 比較常在 Hacker News 以及其他地方被提到，但我有跟他講我連玩都沒玩過，我們家自己反而是用 Cassandra 與 Trino 搭出來的，當時沒有花太多時間研究市場上的方案，就挑了一個自己熟悉的方案趕快先解決。

但過了兩天後他就說用 ClickHouse 解決了，反而讓我對 ClickHouse 有興趣起來，反正記憶體當時裝了一堆沒用到。

拉了一下「Summary of the 1.1 Billion Taxi Rides Benchmarks」這邊的資料看，這個作者常常會測各種資料庫，算是一個可以參考的資料來源，可以看到 2019 年測的「1.1 Billion Taxi Rides: 108-core ClickHouse Cluster」其實就相當不錯了？

基本上先照「Usage Recommendations」這邊看一輪，基本的要求不低，但剛好機器是 32GB RAM：

If your system has less than 16 GB of RAM, you may experience various memory exceptions because default settings do not match this amount of memory. The recommended amount of RAM is 32 GB or more. You can use ClickHouse in a system with a small amount of RAM, even with 2 GB of RAM, but it requires additional tuning and can ingest at a low rate.

如果要跑 cluster 模式的話會需要 ZooKeeper 或是替代品 ClickHouse Keeper。

然後除了使用官方的 clickhouse-client 連線以外，也可以用 MySQL 或是 PostgreSQL 的 client 連，裡面操作其實蠻簡單的，好像值得投資看看？

GCP 推出 AlloyDB，一套相容 PostgreSQL 協定的資料庫服務

也是在清 RSS reader 的時候翻到的，看起來是在今年的 Google I/O 上發表的服務，AlloyDB：「AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage」，值得提的是這篇有中文版可以看：「適用於 PostgreSQL 的 AlloyDB 隆重登場：從此擺脫成本高昂的老舊資料庫」。

另外還有一篇比較偏 PR 的文章也可以看看：「Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases」，這篇就比較針對的提到了與 AWS 的服務相比，但畢竟是 PR 稿沒有明講 (出事會比較好打模糊戰)，但我猜測是與 Aurora 對比：

AlloyDB was also two times faster for transactional workloads than Amazon’s comparable service.

宣稱在 OLTP 上快了兩倍 (原來的三倍？)，但應該都是以 PostgreSQL 下去改，猜測可能是底層的 storage 與 replication 比較好？

AlloyDB 設計上是考慮了 HTAP (Hybrid transactional/analytical processing) 的使用，所以同時可以提供 OLAP 與 OLTP 的應用：

[...] This makes AlloyDB a great fit for business intelligence, reporting, and hybrid transactional and analytical workloads (HTAP).

直接在一個資料庫內處理 OLAP 與 OLTP 這點的確會讓 AlloyDB 比 AWS 目前能提供的方案方便不少 (然後想一下 BigQuery 團隊...)。

目前在 AWS 對應的方案應該是透過 Redshift 來解決，另外一個方案是透過 Athena 來跑。

最後來看價錢，如果效能變成兩倍但價錢也是兩倍的話，就代表在價格上沒優勢。

先看機器的部份，如果是拿 Aurora 這邊 Intel-based 的 db.r5.24xlarge (96 vCPU + 768 GB RAM) 來算的話是 US$13.92/hr，而如果換算到 AlloyDB 的話是 US$14.94528/hr，相除是 0.9314，大約 7% 的差距，可以算是同一個級距。

如果 Aurora 這邊是拿 ARM-based 的 db.r6g.16xlarge (64 vCPU + 512 GB RAM) 來算的話是 US$8.306/hr，換算到 AlloyDB 的話是 US$9.96352/hr，相除是 0.8336，這邊就差超過 16% 了...

(這邊剛好回顧一下 "Amazon’s comparable service" 這段，不確定他是跟 Intel-based 比還是跟 ARM-based 比，畢竟 ARM 除了比較便宜外，還有效能的提昇)

但最大的差異應該是在 storage 相關的部份。其中 Aurora 這邊的空間與 I/O 是分開收費的，以 us-east-1 來說，storage 是 US$0.10/GB/mo，而 I/O 是 US$0.20/million-requests，在 AlloyDB 這邊來說，Regional cluster storage 是 US$0.0004109/GB/hr (us-east4)，變成是 US$0.295848/GB/mo，兩邊相比後可以算出來對等的計價會是 AWS 的 storage 加上 AWS 給你 1.47M 的 I/O (per GB)。

這樣算起來把資料丟 S3 跑 Athena 可能不會比較貴... (當然效能是另外的主題了)

光就檯面上的資料來看，看起來是個不錯的東西，等後續有人跳進去用看看感想...

PostgreSQL 的 scale 建議

在 Hacker News Daily 上看到「Postgres scaling advice for 2021」這篇，講 PostgreSQL 要怎麼 scale，在 Hacker News 上也有對應的討論可以看：「Postgres scaling advice (cybertec-postgresql.com)」。

文章前面先提到分散式系統的複雜度會導致 RDBMS 上的一些假設失效，所以如果可以用單台機器暴力解，就儘量用單台機器來解 (scale up 的情境)，裡面就提到了一些「暴力可以解決很多問題」的說明，差不多就是前幾天提到的「Let's Encrypt 升級資料庫伺服器 (AMD YES？)」。

後面提到如果真的要放進分散式的 RDBMS (scale out 的情境)，怎麼設計資料結構會比較好。

這邊剛好也可以提一下，量夠大的時候要把 OLTP 與 OLAP 的應用分開，現在有很多 OLAP 資料庫可以選擇，同步的工具也很成熟了，通常效能會比在 OLTP 上面硬跑來的好。

最後提一下，文章裡面對於 transaction per second 可以拉很高，有些假設沒有明寫出來。這需要盡可能把 transaction 拆小，避免常常有 giant transaction 卡住整個資料庫，這點對於一般的系統會需要做不少改寫...

不過最後比較疑惑的是，這種文章怎麼會上 Hacker News 的啊...

DuckDB

看到篇有趣的介紹，在講 DuckDB：「DuckDB」。

[I]t uses the PostgreSQL parser but models itself after SQLite in that databases are a single file and the code is designed for use as an embedded library, distributed in a single amalgamation C++ file (SQLite uses a C amalgamation).

看起來是個以 OLAP 為中心而設計出來的資料庫，然後在 Python 下可以直接透過 pip 裝起來。

看起來像是個用單機拼 throughput 的東西，但提供大家熟悉的界面。

在 Hacker News 上可以看到「DuckDB – An embeddable SQL database like SQLite, but supports Postgres features (duckdb.org)」這邊給了不少方向，

Amazon Redshift 壓縮率的改善

Amazon Redshift 對壓縮率的改善：「Data Compression Improvements in Amazon Redshift Bring Compression Ratios Up to 4x」。

首先是引入了 Zstandard：

First, we added support for the Zstandard compression algorithm, which offers a good balance between a high compression ratio and speed in build 1.0.1172. When applied to raw data in the standard TPC-DS, 3 TB benchmark, Zstandard achieves 65% reduction in disk space. Zstandard is broadly applicable.

然後是自動選擇壓縮，對於之前沒有設定壓縮參數的人，會直接有改善：

Second, we’ve improved the automation of compression on tables created by the CREATE TABLE AS, CREATE TABLE or ALTER TABLE ADD COLUMN commands. Starting with Build 1.0.1161, Amazon Redshift automatically chooses a default compression for the columns created by those commands. Automated compression happens when we estimate that we can reduce disk space without degrading query performance. Our customers have seen up to 40% reduction in disk space.

再來是改善資料結構：

Third, we’ve been optimizing our internal on-disk data structures. Our preview customers averaged a 7% reduction in disk space usage with this improvement. This feature is delivered starting with Build 1.0.1271.

最後是提供更好的分析判斷：

Finally, we have enhanced the ANALYZE COMPRESSION command to estimate disk space reduction.

不過其他幾個產品線的使用方式更成熟 (像是 Amazon Athena 這類產品)，不知道會不會讓 Amazon Redshift 慢慢退出第一線...

Amazon Redshift 支援 Zstandard

Amazon Redshift 支援 Zstandard 壓縮資料：「Amazon Redshift now supports the Zstandard high data compression encoding and two new aggregate functions」。

Zstandard 是 Facebook 的人發展出來的壓縮與解壓縮方式，對比的對象主要是 zlib (或者說 gzip)，官網上有不少比較圖。目標是希望在同樣的壓縮處理速度下，可以得到更好的壓縮率。

Redshift 支援 Zstandard 等於是讓現有使用 gzip 的使用者免費升級的感覺...

Amazon Athena：直接在 S3 上進行分析

Amazon Athena 提供另外一種選擇，讓分析的便利性增加了許多：「Amazon Athena – Interactive SQL Queries for Data in Amazon S3」。

以往都需要開 server 起來分析，這個新的服務直接使用就好：

Athena is based on the Presto distributed SQL engine and can query data in many different formats including JSON, CSV, log files, text with custom delimiters, Apache Parquet, and Apache ORC.

果然是用 Presto 改出來的... XDDD

指定好各種資料來源之後直接下 SQL query 分析，然後依照分析的量來算錢... 而 FAQ 的地方也有提到可以透過 JDBC 接上去，這樣看起來跑報表的場合直接丟給他處理了：

Amazon Athena can be accessed via the AWS management console and a JDBC driver. You can programmatically run queries, add tables or partitions using the JDBC driver.

隔壁 Amazon Redshift 的立場變得很尷尬啊，Amazon Athena 不需要養機器而且又可以直接從 Amazon S3 拉資料，如果之後把 Presto 對 RDBMS 的部分再補上來的話就更棒了... (應該是下一階段的任務，把 RDS 補上)