mamori017.log

歴史的クソブログ

NULLは比較演算子では検索できない

NULLに対して検索を行いたい場合はIS (NOT) NULLを使用しなければいけません。 NULLは通常の値とは異なる*1ので、NULLに対して比較演算子("="や"<>")を使用しても結果に反映されません。

ColumnA ColumnB
100 100
200 NULL
300 300
400 400

上記のテーブルに対して以下のクエリを実行した場合、2行目のレコードが該当するので検索結果は1件で返ってきます。

SELECT *
FROM Table
WHERE ColumnB IS NULL

しかし、NULLに対して比較演算子を使用した以下のクエリを実行した場合、2行目のレコードは出力されず検索結果は0件で返ってきます。

SELECT *
FROM Table
WHERE ColumnB = NULL

これはIN演算子なども同様で、NULLを検索対象に含んだとしても検索結果として返ってきません。 IN演算子でNULLを含めたい場合はNULLを除外した条件句にIS NULL条件を追記して対応する必要があります。

SELECT * 
FROM Table 
WHERE (ColumnB IN (100,400) OR ColumnB IS NULL) 

SQL 第2版 ゼロからはじめるデータベース操作 (プログラミング学習シリーズ)

SQL 第2版 ゼロからはじめるデータベース操作 (プログラミング学習シリーズ)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

*1:SQL Server Management Studioの[テーブルを編集]で表示される斜体のNULLは文字列ではありません。

Amazon Athenaを使ってみる

Amazon S3に保管したログなどをSQLで解析できるというAmazon Athenaを触ってみました。 コマンドラインからだと結果が見づらいようなのでマネジメントコンソールから見てみます。

今回は事前に手持ちのIISログをS3バケットに放り込んでいます。 また、IISログについては値の区切りが半角スペースなので、Athenaで使いやすいようにタブ区切りに変更してあります。

データベースの設定

f:id:mamori017:20171003160737p:plain Athenaで使用するデータベースの設定を行います。データベース名とテーブル名、Athenaで参照するS3のバケットを指定します。Athenaで対象バケットを指定する際、S3のパスは「S3://{バケット名}/{フォルダ名}」になりますが、 パスの最後に必ず「/」を記述していないとエラーになるようです。

ファイル形式の指定

f:id:mamori017:20171003160740p:plain 対象となるIISログはタブ区切りにしておいたのでTSV形式を選択しました。

カラムの設定

f:id:mamori017:20171003160745p:plain カラムのデータ型を指定します。 IISログで出力した項目別に列を設定しました。 キャプチャ上はString型になっていますが、 間違って2項目目にtimestamp型を指定してしまったため、 のちのクエリの実行結果でデータが出力されませんでした。

パーティション

f:id:mamori017:20171003160746p:plain パーティションの設定はスキップしました。 データ量が膨大になるとこの設定も必要になりそうです。

テーブル作成

f:id:mamori017:20171003160748p:plain テーブル作成クエリが表示されているのでRun Queryで実行します。 クエリの実行結果が正常であれば、 Athenaに指定したS3バケットのデータを対象としたテーブルが作成されます。 キャプチャはiisデータベースにw3svc1テーブルが作成された状態になります。

クエリの実行

f:id:mamori017:20171003160750p:plain 試しにクエリを実行してみました。 ログ行は区切りごとに列として表現されていますが、不要なIISログヘッダまで対象データとして判定されているので、 対象ファイルをバケットに登録する以前に、不要な行はそもそもログとして出力しない方が良さそうです。 また、キャプチャの5レコード目以降がログの有効行になるのですが、time項目をtimestamp型にしてしまっているので型が合わず空欄で出力されています。

実行結果ログ

f:id:mamori017:20171003160752p:plain

Athenaにデータベースを作成した時点で、S3にAthena実行結果用バケットが自動的に作成され、クエリの実行結果がCSV形式で保管されるようになります。 誤ってこのバケットを削除してしまった場合、コンソール上ではエラーが出力され続けるので、 削除してしまった場合は指定された名称でバケットを作成し直すか、保存先のバケットをコンソール右上のSettingsから指定する必要があります。

使ってみた感想・メモ
  • 定期的に実行する必要のあるクエリはビューの感覚でSaved Queryで保存しておけるので便利。
  • 列数が合わない行も左詰めで対象行となる。(IISログで言うとヘッダ行)
  • 条件にヒットした行は出力対象となるが、列に指定したデータの型が合わない結果は空欄で表現される。
  • 実行結果がS3の指定バケットに貯まり続ける。
  • DDLリクエストは課金対象とならない。
  • 列指定するとデータスキャン量が減るので1リクエストあたりの課金が抑えられる。
  • 生のファイルサイズが大きい場合はデータを圧縮することで課金が抑えられる場合がある。
  • 500KB弱のログファイルに対してクエリを実行し続けたけど、請求エクスプローラ上ではほぼ0円。
  • 本来の使い方ではない気はするけど、今後はDB立てるまでもないデータをSQLで操作したいときに使っていきたい。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWS Lambdaでタイムアウトを発生させてみる

AWS Lambdaで関数実行中にタイムアウトするとどうなるのか見たことが無かったのでためしにやってみました。

Lambdaで空の関数を作成し、ランタイムにPython3.6を選択したときに作成されるコードをsleepで10秒止めてみます。

import time

def lambda_handler(event, context):
    time.sleep(10)
    return 'Hello from Lambda'

テスト実行するだけなのでLambdaの設定はデフォルトのままにしました。 タイムアウトの時間はデフォルトで3秒なので、関数がsleepで止まっている間にLambdaが処理を終了させるはずです。

テストしてみたところ実行結果にタイムアウトのエラーメッセージが出力されました。

{
  "errorMessage": "2017-09-05T02:03:28.155Z xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Task timed out after 3.00 seconds"
}

f:id:mamori017:20170905105252p:plain

ついでなので、CloudWatchのアラームでLambdaの実行エラー時にSNSが送信されるように設定*1しました。 f:id:mamori017:20170905115800p:plain

アラーム作成後にLambda関数をテスト実行すると、アラームの状態がデータ不足からアラームに変わります。

f:id:mamori017:20170905124002p:plain

同時に、アクションに設定していたSNSトピックの送信先メールアドレスにメッセージが送信されます。

f:id:mamori017:20170905124310p:plain

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

*1:本来はLambdaのリトライを考慮したうえでCloudWatchのアラートの閾値と間隔を設定すべき。