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は、ある時点にデータセット全体に格納されているレコードとデータです。不要なレコードを削除することで、総量を削減することができます。なお、よほどテーブルのカラム数が多くない限りは、2のデータ量制限より先に1のレコード制限に抵触することがほとんどです。
3は、データテーブルに対して実行したクエリの重さを足し合わせたものです。月初に現在の使用量がリセットされます。携帯電話プランのデータ使用量制限と同じと考えるとわかりやすいですね。
今回のブログでは、1の「総レコード数」をいかに削減するかについて紹介します。
レコード数上限にカウントされるテーブル
まず、この「総レコード数」のカウント方法について説明します。
こちらは、「KARTEユーザーが作成したテーブルに含まれるレコード数」です。"karte_stream_"で始まるデータセットに含まれるデータテーブルは、対象外となります。つまり、KARTEが自動で生成、更新するkarte_eventテーブルなどは、この「総レコード数」のカウントには含まれません。
レコード数を節約するための3つのテクニック
次に、本題であるレコード数の節約テクニックです。主に、3つの方法があります。
1.不要なテーブルを削除する
データテーブルは、「テーブル単位の削除」についてはとても簡単です。データテーブル画面の「テーブルを削除」ボタンから、削除することができます。

以下のような不要なテーブルについては、定期的に手動で削除するようにしましょう。
- 検証用の作成したテーブル
- 紐付けテーブルやアクションテーブルにデータを入れるために、一時的に作成したデータテーブル
ただし、データテーブルとは違って、紐付けテーブルやアクションテーブルからデータを抜き出してデータテーブルに戻すようなことはできません。KARTE上にバックアップデータを保持しておきたければ、データテーブルに元データを残しておく必要があります。
2.レコード削除ジョブを定期実行する
問題は、レコード単位の削除です。Datahubでは、残すレコードを明示的に指定するクエリを記述しジョブ実行することで、それ以外のレコードを削除することができます。
たとえば、以下のようなテーブルがあるとします。
user_id | coupon_flag | created_at |
---|---|---|
u001 | TRUE | 2019-01-01 |
u002 | FALSE | 2018-12-08 |
u003 | TRUE | 2018-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_id | coupon_flag | created_at |
---|---|---|
u001 | TRUE | 2019-01-01 |
u002 | FALSE | 2018-12-08 |
2-2. レコード削除のためのジョブフローを定期実行
ジョブフローを新規作成し、日次などで定期実行します。ジョブの内容は、以下です。
項目 | 内容 |
---|---|
ジョブタイプ | 「データテーブルへインポート」 |
インポート元 | 「クエリの実行結果」 |
クエリ | 先ほど作成したクエリ |
インポート先 | レコードを削除したいテーブル |
ルール | 「置き換え」 |
これによって、クエリ結果でテーブルが置き換えられ、実質的にレコードの削除が実現できます。今回の例では、以下の古いレコードが削除されます。
user_id | coupon_flag | created_at |
---|---|---|
u003 | TRUE | 2018-10-08 |
この例では「日付が古いレコード」という条件で削除していますが、クエリを書き換えれば自由な条件でレコード削除をすることが可能です。
3.分割テーブルにしてレコードの有効期間を設定する
「日付が古いレコード」を削除するという条件であれば、「分割テーブル」という機能を使うことで、ジョブ実行せずに古いレコードの自動削除をすることが可能です。
分割テーブルの作成方法
利用方法は簡単で、テーブルの新規作成時に、以下のような分割テーブルの設定をします。

ここの「パーティションの有効期間」で、レコードが生存できる期間を指定します。たとえば「30日」に指定すると、「パーティショニングフィールド」で指定したカラムの値が30日より前のレコードについては、自動で削除されます。
内部的には、「パーティショニングフィールド」で指定した日時を表すカラムを使って、その時期毎にテーブルが複数に分割されます。有効期間を設定することで、分割されたテーブルの中でも古いものが、自動削除されるようになります。
分割テーブルを利用するための条件
分割テーブルを利用する場合、以下の条件をテーブルが満たしている必要があります。
- データテーブル作成時に、「分割テーブル」として作成している
- 既存テーブルを「分割テーブル」に変更することはできません - 「パーティショニングフィールド」に利用可能な、DATE型あるいはTIMESTAMP型のカラムが存在する
- DATETIME型は利用できません
既存テーブルを分割テーブルに変更する
なお、既存テーブルを「分割テーブル」に変更したい場合は、以下の手順を踏んでください。
- 新規テーブルを作成し、分割テーブルの設定をする
- 既存テーブルから新規テーブルにデータ移行するためのジョブを実行する
- 既存テーブルを参照しているクエリやジョブフローを、新規テーブルを参照するように修正する
まとめ
今回は、データテーブルのレコード数を削減するための3つのテクニックについて紹介しました。
レコード上限を気にして、本当に見たいデータをDatahubに連携できないのはもったいないので、ぜひ不要なレコードの自動削除を試してみてください!