Posted inデータベース

DockerでのQuestDBデプロイ：高速な時系列データ処理ガイド

Database tutorial - IT technology blog
Database tutorial - IT technology blog

なぜ標準的なデータベースは大規模環境で限界を迎えるのか

数千のIoTセンサーや高頻度の金融ティッカー向けにデータベースをスケールさせる際、通常は予測可能で苦痛を伴うパターンに陥ります。数千行程度ならスムーズに動作しますが、1日あたり1億行に達すると、PostgreSQLやMySQLのような標準的なリレーショナルデータベース（RDB）は処理が停滞し始めます。かつて10msだったクエリは突然15秒もかかるようになり、CPU使用率は絶え間ない書き込みストリームに追いつこうとするだけで100%に急上昇します。

ボトルネックは、従来のB-Treeインデックスと行指向ストレージにあります。これらは汎用的なCRUD操作には最適ですが、追記型（append-only）の時間順データには設計されていません。

複数のインデックスを持つテーブルに行を挿入するたびに、データベースはディスク上のそれらの構造を更新しなければなりません。これが膨大なI/Oオーバーヘッドを生みます。さらに、単純な平均気温を計算したい場合、行指向データベースは特定の1列だけが必要であっても、ディスクから行全体を読み取ります。

QuestDBは、列指向ストレージエンジンとSIMD（Single Instruction, Multiple Data）命令を使用してデータを並列処理することで、これらの制限を回避します。時間を「第一級市民」として扱います。控えめな16コアのハードウェアでも、このアーキテクチャによりデータ取り込みレートは毎秒400万行を超えることが可能です。

ランドスケープ：QuestDB vs 巨人たち

時系列データベースの選択は、多くの場合3つの有力候補に絞られます。本番環境でよく見かける代替案とQuestDBを比較してみましょう。

QuestDB vs. InfluxDB

InfluxDBはこの分野のベテランです。しかし、2.xリリース以降、関数型クエリ言語であるFluxへと移行しました。すでにSQLに精通しているチームにとって、Fluxの学習コストは高く、不要な場合も多いです。QuestDBは標準的な ANSI SQL に直感的な時系列拡張を加えたものを採用しています。私の経験では、QuestDBのストレージ形式は大幅に効率的で、同じデータセットに対してInfluxDBよりもディスク使用量を30%から50%削減できることがよくあります。

QuestDB vs. TimescaleDB

TimescaleDBは、本質的には「スーパーパワーを備えたPostgreSQL」です。完全なACID準拠が必要で、すでにPostgresエコシステムに深く関わっている場合には信頼できる選択肢です。しかし、Postgresのストレージエンジンに依存しているため、オーバーヘッドが大きくなります。QuestDBは速度のためにゼロから構築されたスタンドアロンのバイナリです。純粋な取り込みスループットとミリ秒未満の分析クエリを優先する場合、通常はQuestDBがベンチマークで勝利します。

メリットとデメリット

利点

  • SQLネイティブ: 独自の構文を学ぶことなく、複雑なJOINや集計を実行できます。
  • プロトコルの柔軟性: InfluxDB Line Protocol (ILP)、PostgreSQL Wire、またはREST経由でデータを取り込めます。
  • ゼロコピー転送: メモリマップドファイルを使用して、超高速なデータアクセスを提供します。
  • 即時の可視化: 内蔵のウェブコンソールにより、数秒でデータの可視化まで到達できます。

欠点

  • ライブラリの規模: エコシステムは成長中ですが、PostgreSQLのような膨大なサードパーティ製プラグインライブラリはまだありません。
  • スキーマの硬直性: NoSQLとは異なり、最高のパフォーマンスを得るには早い段階で「指定タイムスタンプ（designated timestamp）」列を定義する必要があります。
  • 大量のRAMを消費: メモリマッピングに依存しているため、アクティブなデータパーツをマップするのに十分なRAMがサーバーにない場合、パフォーマンスが急激に低下します。

セットアップ：DockerとDocker Compose

Dockerは、開発や中規模の本番ワークロードにQuestDBをデプロイする最も効率的な方法です。環境を分離し、バージョン管理を容易にします。永続化のために必ず専用のボリュームを使用してください。そうしないと、コンテナの再起動時にデータベース全体が消去されてしまいます。

生データの書き出しを行う際、APIテストのために煩雑なCSVファイルをクリーンなJSONに変換する必要ことがよくあります。私はこれに toolcraft.app/ja/tools/data/csv-to-json を使用しています。これは完全にブラウザ上で動作するため、機密性の高い金融データやセンサーデータがローカルマシンから外部に出ることはありません。

実装ガイド

1. QuestDBの起動

プロジェクトディレクトリと docker-compose.yml ファイルを作成します。この設定により、データは questdb_data というローカルフォルダに保存されます。

mkdir questdb-project && cd questdb-project
touch docker-compose.yml

ファイルに以下の設定を追加します：

services:
  questdb:
    image: questdb/questdb:latest
    container_name: questdb
    restart: always
    ports:
      - "9000:9000"   # ウェブコンソール
      - "9009:9009"   # ILP (TCP)
      - "8812:8812"   # Postgres Wire
      - "9003:9003"   # メトリクス
    volumes:
      - ./questdb_data:/var/lib/questdb
    environment:
      - QDB_TELEMETRY_ENABLED=false

コンテナを起動します：

docker-compose up -d

すぐに http://localhost:9000 でUIにアクセスできます。

2. テーブルの設計

「指定タイムスタンプ（Designated Timestamp）」が秘訣です。これにより、QuestDBはディスク上のデータをどのようにパーティション化するかを判断します。IoTデータには以下のスキーマを使用します：

CREATE TABLE sensors (
    device_id SYMBOL,
    temperature DOUBLE,
    humidity DOUBLE,
    timestamp TIMESTAMP
) TIMESTAMP(timestamp) PARTITION BY DAY WAL;

主な詳細：

  • SYMBOL: “sensor_01” のような文字列を内部的な整数に変換します。これによりディスク容量を大幅に節約し、フィルタリングを高速化します。
  • PARTITION BY DAY: データを日ごとのファイルに整理します。古いデータの削除は、ファイルを削除するのと同じくらい簡単になります。
  • WAL: Write-Ahead Logging（ログ先行書き込み）により、予期せぬ停電時でもデータの整合性を保証します。

3. Pythonによる高速データ取り込み

SQLの INSERT も機能しますが、InfluxDB Line Protocol (ILP) は速度を重視して構築されています。まずクライアントライブラリをインストールします：

pip install questdb

このスクリプトを使用してデータをストリーミングします：

from questdb.ingress import Sender, TimestampNanos

def stream_data():
    try:
        with Sender('localhost', 9009) as sender:
            for i in range(100):
                sender.row(
                    'sensors',
                    symbols={'device_id': f'sensor_{i}'},
                    columns={'temperature': 20.0 + (i * 0.1), 'humidity': 45.0},
                    at=TimestampNanos.now()
                )
            sender.flush()
            print("バッチ取り込み完了。")
    except Exception as e:
        print(f"取り込み失敗: {e}")

if __name__ == "__main__":
    stream_data()

4. SAMPLE BY を使ったクエリ

QuestDBは時系列データの集計において真価を発揮します。過去24時間の1時間ごとの平均気温を求めるには、SAMPLE BY キーワードを使用します：

SELECT timestamp, avg(temperature) 
FROM sensors 
WHERE timestamp > dateadd('d', -1, now()) 
SAMPLE BY 1h;

これは標準的な GROUP BY よりも大幅に高速です。データはすでに時間ごとにパーティション化されているため、QuestDBはその特定の範囲に必要なデータブロックのみをスキャンします。

最後に

Docker経由でQuestDBをデプロイすることで、時間的制約のあるデータを扱うあらゆるプロジェクトで即座にパフォーマンス向上が得られます。5万台のデバイス群を監視する場合でも、リアルタイムの仮想通貨ダッシュボードを構築する場合でも、SQLの使いやすさと高速な取り込みの組み合わせは非常に強力です。データセットが増大してもクエリの軽快さを維持できるよう、予想されるデータ量に基づいて PARTITION BY 戦略（日、月、年）を選択することを忘れないでください。

Share:
Tags: