データベースフレームワークグループ

ビジョン

データベースとのインタラクションに関するスケーラビリティ、アプリケーションパフォーマンス、データ増加、そして開発者支援に向けたソリューションを開発します。

ミッション

データベースにフォーカスし、私たちのミッションはお客様の要求に応じてスケールできるソリューションを提供することです。データベース上のパフォーマンスボトルネックを事前に特定し、開発ライフサイクルの早い段階で開発者に情報を提供するためのツールを提供します。

データベースメンテナーの数を増やし、コミュニティコントリビューターおよび GitLab 内の開発チームにデータベースのベストプラクティスを提供します。

チームメンバー

以下の方々がデータベースチームの常任メンバーです:

チームメンバー情報は 原文 (英語) を参照してください。

安定したカウンターパート

他の機能チームのメンバーで、私たちの安定したカウンターパートは以下の通りです:

名前役割
Mark Woodグループプロダクトマネージャー, Data Access
Mark Nagleサポートエンジニア
Chris Nightengaleサポートエンジニア

他チームへの安定したカウンターパート

データベースグループは、他グループへのコンサルティングを頻繁に求められます。 これらのリクエストをより効率的にサポートするため、この安定したカウンターパートテーブルを作成しました。

ミーティング

可能な限り、Issue、マージリクエスト、Slack を使った非同期コミュニケーションを好みます。ただし、個人的なつながりを構築したり、ブロッカーなど同期的な議論の方が効率的な項目に対処するために、対面ミーティングも有益です。

  • データベースフレームワークグループシンク: 毎週火曜日と木曜日
    • 火曜日(15:00 UTC | EMEA) — ~infradev Issue で注意が必要なものを確認した後、週次優先事項に集中します。
    • 木曜日(21:30 UTC | APAC) — 当週のトリアージ Issue を確認し、週次優先事項に集中します。
  • データベースオフィスアワー (内部リンク); YouTube 録画
    • 水曜日、15:30 UTC(隔週)
    • (APAC)木曜日、3:30 UTC(隔週、交互)

作業

GitLab のエンジニアリングワークフローガイドラインに従います。私たちの注意を引くための Issue は、関連プロジェクトに作成してください。~"group::database frameworks" ラベルと、その他の関連ラベルを追加してください。

緊急の Issue の場合は、エンジニアリングマネージャーまたは Slack チャンネル(#g_database_frameworks)に連絡してください。

私たちがやること

チームは、高パフォーマンスなクエリを実現しながら、スケーラビリティのサポートと可用性の強化のための機能を提供するために、PostgreSQL アプリケーションインタラクションに責任を持ちます。PostgreSQL は Rails アプリケーションの中核であり、データベースの観点から GitLab をよりパフォーマントで、スケーラブルで、高可用性を持つものにする作業には事欠きません。

過去の作業の一部を以下に示します:

現在進行中のプロジェクトの一部を以下に示します:

  • GitLab SQL トラフィックリプレイ — epics/17719
  • データベースサチュレーションポイントを管理するツールとグラフの構築
  • バッチバックグラウンドオペレーション — epics/16152

私たちは常にデータベースのパフォーマンスを継続的に向上させ、開発者向けドキュメントを改善する方法を探しています。 私たちが取り組んでいる内容の詳細については、ロードマップセクションをご確認ください。

データベースグループが現在取り組んでいる内容を把握するには、新マイルストーンのグループキックオフプレゼンテーションおよび対応するマイルストーンプランニング Issue を確認することをお勧めします。

アクティビティログ

2021年末から、過去のプロジェクトと成果を追跡するためのアクティビティログを維持しています。

プランニング

プランニング Issue を使って、マイルストーンの優先事項とコミットメントについて議論します。これは主に非同期で行われますが、同期的な議論が必要な場合は、同期チームミーティングのタイムスロット中に議論します。

Issue の重み付け

データベースフレームワークグループは、Issue の重みとして期待されるマージリクエスト数を使う実験を行っています。各マイルストーンが始まる前に、重みのない割り当て済み Issue にそれぞれ重みを追加するようお願いします。

マージリクエスト数を Issue の重みとして使う理由は以下の通りです:

  • このプロセスにより、Issue をより細かく分解する方法を事前に検討し、事前に列挙することが促されます。
  • 説明と学習が容易で、チーム全体で共通理解を得やすくなります。
  • マージリクエストのレートは、チームが測定される主な指標の1つです。

Issue の重み付けプロセス

  1. 長期間かかりレビューとマージが難しくなる可能性のある大きな変更よりも、小さく反復的な変更を重視し、この Issue をいくつのマージリクエストに分解できるかを検討してください。

  2. 期待されるマージリクエストを列挙したコメントを追加してください。例:

    ドキュメントへの1つのマージリクエストのみ

    データベース変更用に gitlab への1つ、新機能用に1つ、ドキュメント変更用に1つ、omnibus への1つ

  3. カウントを重みとして追加してください。例えば、データベース変更用に gitlab への1つ、新機能用に1つ、ドキュメント変更用に1つ、omnibus への1つがあると思われる場合は、/weight 4 を割り当てます。

トリアージローテーション

シンプルなトリアージローテーションを実施しています。毎週、1人のチームメンバーがデータベースフレームワークグループの受信 Issue のトリアージ専任となります。これにより、残りのチームメンバーは割り込みを最小限に抑えて現在の優先事項に集中できます。毎週、ボットがローテーションの次のチームメンバーに自動割り当てされる Issue を作成します。非常にシンプルにするため、ローテーションの順序はファーストネームのアルファベット順としています。割り当てられた週に PTO 中のチームメンバーがいる場合、Issue は次の人に再割り当てされます。

トリアージが必要な Issue はさまざまな経路で届きます。トリアージ中に監視すべき一般的な領域:

  • ~database ラベルが付いているがグループに割り当てられていない新しい Issue(7日未満)。検索例
  • ~group::database frameworks が割り当てられているが、スループットラベルや ~database::triage ラベルが付いていない新しい Issue。検索例
  • ~database::triage が割り当てられているが、これまでにレビューされていない新しい Issue。
  • #g_database Slack チャンネルで支援を求められた場合。

トリアージ担当者がチームの注意が必要な Issue を発見した場合、想定される対応は以下の通りです:

  • 簡単な修正であれば Issue に直接対処する
  • 必要に応じてカスタマーサポートのカウンターパートに誘導する
  • ~database::triage ラベルを追加してチーム同期ミーティング中にレビューする
  • マイルストーンを追加してマネージャーに ping するか、Issue に ~workflow::scheduling ラベルを付ける
  • 重複としてクローズし、重複 Issue にリンクする
  • 非同期で回答されなかった質問がある場合はチーム同期で議論する

トリアージ Issue の数を少なく管理しやすい状態に保つことが目標です。

ヒント: クローズ済み Issue をトリアージボードから除外するには、この検索を使い、複数の Issue を一度に編集して ~database::triage ラベルを削除してください。

ボード

マイルストーン別データベース マイルストーンボードは、各マイルストーンで計画されている Issue の「全体像」を提供します。

Database: Build · Boards · GitLab.org · GitLab ビルドボードは、group::database frameworks の現在の作業状況の概要を提供します。これらの Issue はすでにバリデーションを経ており、プロダクト開発ビルドトラックに乗っています。 Issue は現在有効なマイルストーンと group::database frameworks ラベルを追加することでこのボードに追加されます。workflow::ready for development 列の Issue は優先度順(上から下)に並んでいます。チームメンバーはこの列を使って次に取り組む項目を選択します。

Database: Validation バリデーションボードは、プロダクトマネージャーがレビューする受信 Issue のキューです。データベースチームのバリデーションボードでよく見られるシナリオは、アクションを起こす前にさらなる定義が必要な Issue が作成された場合です。Issue は通常、大きなアイデアを述べていますが、アクションを起こすには詳細が不十分です。その後、データベースチームは Issue を実行可能なステップに分解し、終了条件を作成し、進行中の取り組みと優先順位付けを行う改善プロセスを行います。Issue が大きすぎる場合はエピックに昇格され、小さなサブ Issue が作成されます。

Database: Triage トリアージボードは、チームの割り当て、優先順位付け、既存 Issue の調査などが必要な受信 Issue のためのものです。データベースフレームワークグループでは、1人のチームメンバーが適時な対応のためにこのボードを監視する週次トリアージローテーションを実施しています。

Say/Do 比率

~Deliverable ラベルを使って Say/Do 比率を追跡しています。各マイルストーンの開始時、データベースグループ週次ミーティング中に Issue をレビューし、マイルストーン内に確実に届けられると判断した Issue を特定します。その Issue には ~Deliverable ラベルが付けられます。マイルストーン終了時、~Deliverable ラベルが付いた正常完了 Issue は2か所で追跡されます。マイルストーン内に届けられた数を計算し、移動した Issue を考慮する Tableau のダッシュボードがあります。また、マイルストーンレトロ Issue には、マイルストーンを逃したものと合わせて、出荷したすべての ~Deliverable Issue がリストアップされます。

ロードマップ

データベースグループのロードマップは、現在進行中のプロジェクトと、今後3か月以上で優先付けされたプロジェクトを確認できます。

週次チームアップデート

進行中の各エピックには @service-epic-status-automation からステータステンプレート付きの自動コメントが届き、そのプロジェクトに取り組むチームメンバーがステータス詳細を返信として投稿します。これはデータベースフレームワークステータスエピックに追加され、進行中のすべてのエピックのステータスが含まれます。

ドキュメント

このセクションでは、私たちの知見、ロードマップ、その他の関連資料を文書化しています。

  1. データベースレキシコン — データベースに関連する用語と定義
  2. データベース戦略: 提案されたデータベース変更のガイダンス
  3. テーブルパーティショニングについて(2020年2月)
  4. PostgreSQL: フォーリンデータラッパーとパーティショニングによるシャーディング
  5. トップレベルネームスペースによる GitLab のシャーディング
  6. CitusDB によるシャーディング(2020年4月)
  7. テーブルパーティショニング: Issue グループ検索を例として(2020年3月)
  8. 開発者向け GitLab.com データベースの操作方法
  9. コンテナレジストリのデータベーススキーマ提案(2020年9月)
  10. GitLab.com のワークロード分析(2020年10月)
  11. マルチデータベースバックグラウンドマイグレーション(2021年10月)

パフォーマンス指標(内部)

  1. Enablement::Database — パフォーマンス指標ダッシュボード
  2. GitLab.com の平均クエリ Apdex

共通リンク


CitusDB による GitLab のシャーディング
CitusDB による GitLab のシャーディング これは、GitLab.com における GitLab のデータベースシャーディングソリューションとして CitusDB を使用するかどうかの意思 …
GitLab.com におけるインデックスがパフォーマンスに与える影響の理解
これは gitlab.com におけるインデックスがパフォーマンスに与える影響に関するプレースホルダー記事です。
GitLab.com のワークロード分析
GitLab.com のワークロード分析 このドキュメントでは、GitLab.com のデータベースワークロードをより深く理解するためのいくつかのアプローチについて説明します。既存の監視ソリューション …
Postgres AI プランを活用したクエリの作成
これはクエリプランに関する今後のトレーニング記事のプレースホルダードキュメントです。
PostgreSQL アップグレードサイクル
PostgreSQL 年次アップグレードサイクル GitLab 16.0 から、私たちは PostgreSQL の年次アップグレードサイクルを採用しています。 GitLab のメジャーバージョンごと …
PostgreSQL 上のコンテナレジストリ
このページは、コンテナレジストリのさまざまなデータベース設計アプローチについての議論を追跡するためのものです。 背景と参考資料 データベーススキーマの議論(以下のモデル1)クエリ、推定データベースサイ …
パーティショニング — Issue グループ検索
データベースパーティショニング: Issue グループ検索 特定の例を見ながらデータベースパーティショニングの必要性を説明してきました。グループベースの Issue 検索です。 このタイプの検索 …
データベース Issue の特定
データベース Issue の DRI を特定するための基本ガイド
データベースパーティショニング
GitLab のデータベースへの PostgreSQL テーブルパーティショニングの導入 これは GitLab にテーブルパーティショニングをどのように導入するかを議論するための作業ドキュメントです。 …
データベースグループ アクティビティログ
概要 このページはデータベースグループのアクティビティを記録し、成果・主要な結果・得られた知見を文書化しています(最新のものが先頭)。2021年末頃からこの取り組みを開始しました。 2022 …
データベースグループ ステーブルカウンターパート
概要 Core Platform 部門の中心的な考え方は、他のチームがデータベースなどの分野でより自立できるよう支援することです。データベースグループは、データベース設計、クエリの効率化、データベース …
データベースレキシコン — データベースに関連する用語と定義
これはよく使われる用語の包括的なリストではなく、よく混同されたり他の用語と混同されたりする用語のリストです。各セクションでは、一般的なフレーズを特定し、私たちの具体的な使用方法を定義し、問題の用語に関する外部参考情報をリストアップします。
データベースレビュー入門
これはデータベースレビューに関する今後のトレーニング記事のプレースホルダードキュメントです。
データベース戦略
データベース戦略: 提案されるデータベース変更のガイダンス GitLab はシングルデータストアを持つシングルアプリケーションとして提供されています。このハンドブックのエントリは、データストアのアーキ …
トップレベルのネームスペースによる GitLab のシャーディング
トップレベルのネームスペースによる GitLab のシャーディング このドキュメントは、GitLab をトップレベルのネームスペースでシャーディングするというアイデアをまとめたものです。ネームスペース …
バックグラウンドマイグレーション入門
これはバッチ処理バックグラウンドマイグレーションに関する今後のトレーニング記事のプレースホルダードキュメントです。
フォーリンデータラッパーとパーティショニングによる PostgreSQL 11 シャーディング
フォーリンデータラッパーとパーティショニングによる PostgreSQL 11 シャーディング このドキュメントは、フォーリンデータラッパーとパーティショニングを組み合わせた探索的なテストの結果を記録 …
マルチデータベースバックグラウンドマイグレーション
複数データベースに対応したバックグラウンドマイグレーションの設計 これは、複数データベースに対するバックグラウンドマイグレーションのサポート設計を仕様化するための作業ドキュメントです。 …
開発者向け GitLab.com データベースの操作方法
開発者向け GitLab.com データベース操作ガイド GitLab.com は大規模な PostgreSQL データベース(このドキュメントでは「データベース」と呼ぶ)によって動かされており、ス …