KARTE Datahubの総レコード数を節約するための3つのテクニック

こんにちは、プレイドのエンジニアの池上です。今回は、2018年12月にリリースされたKARTE Datahubについて、「テーブルの総レコード数を節約するためのテクニック」をご紹介します。

こんにちは、プレイドのエンジニアの池上です。KARTEの技術サポートなどを担当しています。

さて、KARTEユーザーの方に向けた情報発信の一環として、今回からKARTEを使う中で役に立つTipsをブログ形式で解説していきます。初回である今回は、2018年12月にリリースされたKARTE Datahubについて、「テーブルの総レコード数を節約するためのテクニック」をご紹介します。

KARTE Datahubとは?

KARTE Datahubとは、KARTEのオプション機能の1つです。顧客データや行動データ、オフラインデータなど分断されているデータベースをKARTEに統合して、KARTE上のセグメントやアクションに自由に利用することができます。

詳しくは、以下のサービスサイトをご覧ください。

KARTE Datahub | CX(顧客体験)プラットフォーム KARTE(カルテ)

データセットの制限

さて、Datahubのデータセットに関して、2019年1月現在、主に以下の3つの値について上限が設けられています。

  1. 総レコード数
  2. 総データ量
  3. 月間使用クエリリソース

1と2は、ある時点にデータセット全体に格納されているレコードとデータです。不要なレコードを削除することで、総量を削減することができます。なお、よほどテーブルのカラム数が多くない限りは、2のデータ量制限より先に1のレコード制限に抵触することがほとんどです。

3は、データテーブルに対して実行したクエリの重さを足し合わせたものです。月初に現在の使用量がリセットされます。携帯電話プランのデータ使用量制限と同じと考えるとわかりやすいですね。

今回のブログでは、1の「総レコード数」をいかに削減するかについて紹介します。

レコード数上限にカウントされるテーブル

まず、この「総レコード数」のカウント方法について説明します。

こちらは、「KARTEユーザーが作成したテーブルに含まれるレコード数」です。"karte_stream_"で始まるデータセットに含まれるデータテーブルは、対象外となります。つまり、KARTEが自動で生成、更新するkarte_eventテーブルなどは、この「総レコード数」のカウントには含まれません。

レコード数を節約するための3つのテクニック

次に、本題であるレコード数の節約テクニックです。主に、3つの方法があります。

1.不要なテーブルを削除する

データテーブルは、「テーブル単位の削除」についてはとても簡単です。データテーブル画面の「テーブルを削除」ボタンから、削除することができます。

----------2019-01-22-16.51.06

以下のような不要なテーブルについては、定期的に手動で削除するようにしましょう。

  • 検証用の作成したテーブル
  • 紐付けテーブルやアクションテーブルにデータを入れるために、一時的に作成したデータテーブル

ただし、データテーブルとは違って、紐付けテーブルやアクションテーブルからデータを抜き出してデータテーブルに戻すようなことはできません。KARTE上にバックアップデータを保持しておきたければ、データテーブルに元データを残しておく必要があります。

2.レコード削除ジョブを定期実行する

問題は、レコード単位の削除です。Datahubでは、残すレコードを明示的に指定するクエリを記述しジョブ実行することで、それ以外のレコードを削除することができます。

たとえば、以下のようなテーブルがあるとします。

user_idcoupon_flagcreated_at
u001TRUE2019-01-01
u002FALSE2018-12-08
u003TRUE2018-10-08

このテーブルから、以下に該当するレコードを削除したいとします。

  • created_atが1ヶ月以上前のレコード

そのための手段の1つは、 「あるテーブルに対するクエリの結果を使って、そのテーブル自身を上書きする」 という方法です。

具体的には、以下の手順です。

2-1. 残したいレコードを抽出するクエリを作成

削除したいレコード以外を抽出するためのクエリを作成します。今回の例だと、以下です。

SELECT *
FROM table
WHERE
  created_at > DATE_ADD(CURRENT_DATE(), INTERVAL -1 MONTH)

現在が2019年1月1日だとすると、結果は以下になります。

user_idcoupon_flagcreated_at
u001TRUE2019-01-01
u002FALSE2018-12-08

2-2. レコード削除のためのジョブフローを定期実行

ジョブフローを新規作成し、日次などで定期実行します。ジョブの内容は、以下です。

項目内容
ジョブタイプ「データテーブルへインポート」
インポート元「クエリの実行結果」
クエリ先ほど作成したクエリ
インポート先レコードを削除したいテーブル
ルール「置き換え」

これによって、クエリ結果でテーブルが置き換えられ、実質的にレコードの削除が実現できます。今回の例では、以下の古いレコードが削除されます。

user_idcoupon_flagcreated_at
u003TRUE2018-10-08

この例では「日付が古いレコード」という条件で削除していますが、クエリを書き換えれば自由な条件でレコード削除をすることが可能です。

3.分割テーブルにしてレコードの有効期間を設定する

「日付が古いレコード」を削除するという条件であれば、「分割テーブル」という機能を使うことで、ジョブ実行せずに古いレコードの自動削除をすることが可能です。

分割テーブルの作成方法

利用方法は簡単で、テーブルの新規作成時に、以下のような分割テーブルの設定をします。

----------2019-01-22-19.09.47

ここの「パーティションの有効期間」で、レコードが生存できる期間を指定します。たとえば「30日」に指定すると、「パーティショニングフィールド」で指定したカラムの値が30日より前のレコードについては、自動で削除されます。

内部的には、「パーティショニングフィールド」で指定した日時を表すカラムを使って、その時期毎にテーブルが複数に分割されます。有効期間を設定することで、分割されたテーブルの中でも古いものが、自動削除されるようになります。

分割テーブルを利用するための条件

分割テーブルを利用する場合、以下の条件をテーブルが満たしている必要があります。

  • データテーブル作成時に、「分割テーブル」として作成している
     - 既存テーブルを「分割テーブル」に変更することはできません
  • 「パーティショニングフィールド」に利用可能な、DATE型あるいはTIMESTAMP型のカラムが存在する
      - DATETIME型は利用できません

既存テーブルを分割テーブルに変更する

なお、既存テーブルを「分割テーブル」に変更したい場合は、以下の手順を踏んでください。

  • 新規テーブルを作成し、分割テーブルの設定をする
  • 既存テーブルから新規テーブルにデータ移行するためのジョブを実行する
  • 既存テーブルを参照しているクエリやジョブフローを、新規テーブルを参照するように修正する

まとめ

今回は、データテーブルのレコード数を削減するための3つのテクニックについて紹介しました。
レコード上限を気にして、本当に見たいデータをDatahubに連携できないのはもったいないので、ぜひ不要なレコードの自動削除を試してみてください!

SHARE