Scraps 最終更新 2026/10/01 16:40

#データベース

@detaneeee /

dbt checkを触ってみた & GitHub Actionsで動かしてみた

  • dbt checkでプロジェクトのメタデータルールを検証できる機能を試した
  • info_schemaマクロでDuckDBにアクセスし、モデルの説明やデータテストの有無をチェック、GitHub ActionsでCIに組み込める
  • dbt checkの重大度をwarnに設定すると実行失敗にならないため、CIではerrorに設定する必要がある
dbt checkを触ってみた & GitHub Actionsで動かしてみた

@shirok /

oracle-ai-ready-data Skill 第3回：ANNOTATIONSとDomainの意味情報を可視化し、Select AIで確認してみてみた

  • Oracle AI Databaseのv0.4.0でAnnotationとDomainの意味情報を可視化し、Select AIで確認できるようになった
  • Annotationでコード値と業務意味を対応付ける、Domainで共通定義を再利用する、Skillでレポート生成する
  • Annotationの登録状況や継承元を確認し、Select AIのプロンプトに含める設定が必要
oracle-ai-ready-data Skill 第3回：ANNOTATIONSとDomainの意味情報を可視化し、Select AIで確認してみてみた - Qiita

@Takahiro Kume / 久米隆大 /

【AWS】Aurora MySQLのメトリクスを読み解く ― 第2回 パージ処理関連のメトリクス

  • Aurora MySQLのInnoDBパージ処理に関連するCloudWatchメトリクスを検証した
  • RollbackSegmentHistoryListLength、PurgeBoundary、PurgeFinishedPoint、TruncateFinishedPointの4つのメトリクスを確認し、長時間トランザクションがパージ処理をブロックすることを実証した
  • 長時間トランザクションがあるとPurgeBoundaryが進まず、パージが遅延するため、トランザクションの管理が重要になる
【AWS】Aurora MySQLのメトリクスを読み解く ― 第2回 パージ処理関連のメトリクス

@Yasui Michitaka /

Spanner Direct Connectivityの効果と仕組み

  • Spanner Direct ConnectivityはGFEをバイパスして直接通信することでレイテンシーを短縮する機能
  • GFEバイパスとクライアントサイドでのルーティング解決、フォールバック用コネクションプールの保持
  • クライアントのメモリ消費量が10MB弱増加するため、コンテナのメモリ上限に注意が必要
Spanner Direct Connectivityの効果と仕組み

@koki takeishi /

NebulaGraph Community版の簡易検証

  • NebulaGraph Community版v3.8.0をDocker Composeで構築し、グラフデータを投入してクエリを実行した
  • ADD HOSTSでStorageホストを登録、GO文とopenCypher互換のMATCH文でクエリを実行、パーティションの状態確認にSHOW STATSを使った
  • 初期クエリは5秒程度かかったが、定常状態では3ミリ秒程度に改善し、クラスタの状態がレイテンシに大きく影響する
NebulaGraph Community版の簡易検証

@jqit-yukiono /

同一人物がApple/Googleどちらでログインしても同じアカウントにする ― Firebase純正のlink(with:)を使わなかった理由

  • Firebase純正のlink(with:)を使わず、バックエンド独自のauth_identitiesテーブルでアカウント連携を実装した
  • Firebaseのcredential-already-in-useエラー対応が破壊的で複数ステップ、auth_identitiesテーブルで1 User : N firebase_uidを管理
  • コンフリクト解決は1つのDBトランザクションに閉じ込め、失敗時ロールバックで詰み状態を回避
同一人物がApple/Googleどちらでログインしても同じアカウントにする ― Firebase純正のlink(with:)を使わなかった理由 - Qiita

@koki takeishi /

NebulaGraphのアーキテクチャとユースケースのリサーチ

  • NebulaGraphは計算・ストレージ分離と固定ハッシュパーティショニングで大規模プロパティグラフを実現
  • 計算/ストレージ分離、固定ハッシュパーティショニング、双方向エッジ配置、Multi Group Raftを組み合わせた設計
  • ミリ秒応答はクエリの形とハードウェアに強く依存し、スーパーノード対策が必要
NebulaGraphのアーキテクチャとユースケースのリサーチ

@yutannihilation /

Parquet の仕様にも入った ALP (Adaptive Lossless floating-Point) とは何なのか

  • Parquet 2.14.0でALPという浮動小数点数の圧縮方式が導入された
  • ALPはZSTDと比較して処理速度が速く、eとfのパラメータでデータを圧縮する仕組み
  • ALPは10進数のデータに最適だが、センサーや計算結果のような2進数データでは圧縮率が低下する可能性がある
Parquet の仕様にも入った ALP (Adaptive Lossless floating-Point) とは何なのか

@むーさん /

DynamoDBでベクトル検索を導入する際は既存のGSIの射影タイプの確認が大事だと思った

  • DynamoDBでベクトル検索を導入する際、既存GSIの射影タイプを確認しないと書き込みコストが4倍になる
  • GSIの射影タイプがALLの場合、ベクトルデータがGSI4本とベクトルインデックスに複製される。同居と分離の比較でWCUが24と6に差が出る
  • GSIの射影タイプがALLでベクトルを問題アイテムに同居すると、採点時のWCUが4倍になるため、ベクトルを別アイテムに分離する設計が有効
DynamoDBでベクトル検索を導入する際は既存のGSIの射影タイプの確認が大事だと思った

@J-T_ky2g /

【SQL】テーブル作成、テストデータ投入(bulk)、データクエリ、テーブルドロップのメモ

  • SQLでテーブル作成、テストデータ投入、クエリ、ドロップの基本文法を確認した
  • uuid型のカラム作成とgen_random_uuid関数、int4型の指定、プライマリキーの設定が含まれる
  • テストデータ投入にはvalues節に複数のレコードを記述する方法が必要で、ドロップはコメントで行うのが一般的
【SQL】テーブル作成、テストデータ投入(bulk)、データクエリ、テーブルドロップのメモ - Qiita

@Hiroshi Ito /

AIだけで作ったOLAP DB：アーキテクチャと、規律の与え方

  • AIが自律的に設計・実装したOLAPデータベースが、DuckDBやPolarsと同等のパフォーマンスを発揮
  • 階層を構造として持つ設計、BESSビットマスクストレージ、5つの集約エンジンの切り替え
  • 疎データ処理でDuckDB比185倍の高速化を実現し、階層の扱いがパフォーマンスに大きく影響
AIだけで作ったOLAP DB：アーキテクチャと、規律の与え方

@yu_asa /

FlywayでDDLを管理する ― VとRの使い分けと、ビュー・トリガーの扱い

  • FlywayでDDLを管理する際、Vは1回だけ実行されるマイグレーション、Rは中身が変わるたびに再実行されるマイグレーションとして使い分けられる
  • Vはテーブル作成などの積み上げ変更に、Rはビュー作成やトリガー定義などの作り直し可能なオブジェクトに使用する。ビューはCREATE OR REPLACE VIEWでRに記述する
  • Vファイルは適用後は変更不可で、Rファイルは中身の変更に応じて自動再実行されるため、ビューとトリガーはRで管理する
FlywayでDDLを管理する ― VとRの使い分けと、ビュー・トリガーの扱い - Qiita