信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    データベースに関するTips

    どうも、もう少しで50歳(半世紀)になる大西です。開発に携わっていると同じ結果を導くにあたり多くの手法が存在する事に気付くだろう。1つしか手法を知らず後になって損をしていた事に気付く・・・そのような経験も多いのではないだろうか。データベースについては30年以上前から今だに「そのような手法があるのか」と感心する事が多々ある。今回はデータベースの中でも MySQL に関しての「その方法でも出来るね」について記そう。■ TIMESTAMP および DATETIME の自動初期化および更新機能さて、まずはこれだ。最近でもカラムとして登録日時と最終更新日時を持たせている設計を多く見かける。きちんとシステム上必要なのであれば良いのだが「とりあえず入れとけ」は止めて頂きたいと常に思っているカラム達だ。このカラムが存在するにも関わらず無視しているプログラムは論外として、INSERT 時に「登録日時」と「最終更新日時」を、UPDATE 時に「最終更新日時」を、それぞれ NOW() を使用して値をセットするプログラムを多く見かけるのだが、経験上データベース側の日時値ではなくプログラム側の日時値でお願いしたい(プログラム側で日時データを作りその値をデータベースに適用するようにして欲しいのだ)。特に MySQL の日時については Ver8.0 になっても 2038年問題は残ったままのようだしプログラム側の日時値でお願いしたいものだ。何はともかくこれら私の希望を一旦棚の上に置くとして、登録日時と最終更新日時カラムが単にそのレコードの登録/更新の日時を表すだけならば NOW() を使うのは避けるべきだと述べておく。ではどうするのか。それは INSERT の時は登録日時と最終更新日時を、UPDATE の時は最終更新日時だけを自動でセットするようにすれば良い。テーブルを見てみよう。Create Table: CREATE TABLE `TBL_TEST` (     `key` varchar(32) NOT NULL,     `value` text NOT NULL,     `update_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,     `create_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,     PRIMARY KEY (`key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 update_at カラムはデフォルト値として CURRENT_TIMESTAMP を、そして ON UPDATE CURRENT_TIMESTAMP で更新時はその時の日時をセットするカラムにしている。create_at カラムは update_at と同様だが更新時には反応しないカラムにしている。INSERT してみる。mysql> INSERT INTO `TBL_TEST` (`key`,`value`) VALUES ('test','hoge'); mysql> select * from `TBL_TEST`; +------+-------+---------------------+---------------------+ | key  | value | update_at           | create_at           | +------+-------+---------------------+---------------------+ | test | hoge  | 2018-01-13 02:01:04 | 2018-01-13 02:01:04 | +------+-------+---------------------+---------------------+ update_at、create_at 共に自動セットされている。UPDATE してみる。mysql> UPDATE `TBL_TEST` SET value='fuga' WHERE `key`='test'; mysql> SELECT * FROM TBL_TEST; +------+-------+---------------------+---------------------+ | key  | value | update_at           | create_at           | +------+-------+---------------------+---------------------+ | test | fuga  | 2018-01-13 02:01:38 | 2018-01-13 02:01:04 | +------+-------+---------------------+---------------------+ update_at のみ自動セットされている。最近はデータベース等のレコード結果を KVS などにキャッシュし高速化を図る手法も多く見かける。その場合も NOW() は避けよう(繰り返すが本心はプログラム側で生成した日時値をセットして欲しい)。何にせよ SQL もスッキリするしこちらの方がエレガントなので是非とも検討/実践して欲しい。■ SQL_CALC_FOUND_ROWS次はちょっとした Tips のようなものだ。検索結果などを表示する場合にはページングというテクニックを使用する場合があると思う。その場合ページングのため(結局何ページ分必要なのかを先に知る必要があるため)総レコード数を知る必要がある。この際に同じ WHERE句 で SELECT と COUNT(*) を発行して1ページ分のレコードと総レコード数を取得するプログラムを多く見かける。このような場合は SQL_CALC_FOUND_ROWS と FOUND_ROWS() を使うと良いだろう。mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name WHERE `hoge`>100 LIMIT 10; mysql> SELECT FOUND_ROWS(); 最初の SELECT で条件に合致するデータセット(1ページ分)が取得出来て、次の SELECT で条件に合致する(OFFSET / LIMIT 無関係の)レコード総数が取得可能だ。SELECT を2回発行する事に変わりはないのだが、こちらの方がエレガントであろう。今回は案件でも多用しているであろう MySQL についてその Tips 的な事柄を書いてみた。この他にも MySQL には寿司ビール問題やハハパパ/アルファベットの大文字小文字問題といったキャラセット/コレーションに関する問題もある(これらの問題について知らないというエンジニアは今すぐ調べて欲しい)。MySQL もこれら問題に対応すべくデフォルトの設定を見直すなど出来るところから対応してくれている。プログラムやシステム、ミドルウェアのデフォルト設定などが「そうなっている」のには必ず理由があるものだ。その理由を知るだけでもスキルアップに繋がると思う。手元を見返し「そうなっている」理由を是非とも考えて欲しい。それではまた。
  • テクログ

    マリオ御一行様が訪ねて来たようです。

    いやはやクラウドという言葉も当たり前になったここ最近。本当に安くサーバを建てられるようになりました。しかもグローバルIPまで付いてくるんですから、もう、おじさんはビックリですよ。かく言う私もプライベートサーバを持っています。別に何かサービスを提供している訳ではありません。あくまでも公衆に迷惑をかけない範囲で、色々と勉強/試行したりするのが目的だったりします。さて、本題です。先にも書いたようにサーバを実際に公開しているかぎり、きちんと面倒をみてあげる必要がありますよね。個人のサーバとか、企業のサーバとか、お国のサーバとか、そんなの関係ないのです。どのようなサーバであろうと、きちんと面倒みてあげる必要があるのです。で、先日。当然わたしも面倒をみる訳ですが、一通り確認したい事を試行して最後に一通りログを見てまわったんです。いやぁ・・・いらっしゃってました。マリオ御一行様。。。クッパ、ヨッシー、ピーチ姫まで。。。おじさん歓喜!泣いたぜ。。。・・・まぁ、ただの辞書攻撃なんですがね。サーバ触っていると、こういう楽しみもあるという事でwww以上、マリオ御一行様が訪ねて来たようなのでブログに書いてみました!それでは!!
  • テクログ

    Aurora Serverless が遂に登場!

    マスオです。Aurora Serverless MySQL の一般利用が開始※画像も上記から引用以前のAWSイベントで発表され限定プレビューだったサーバレス版についてこのほど遂に一般利用が解禁となりました!東京リージョンでも利用可能となったので早速さわってみたのですが、現状での制限が与えた影響などを書いていきたいと思います。パブリックアクセスができない通常はパブリックアクセスするしないを選べますが、そもそも設定できないローカル環境からつながらない!とか言われたので EC2 からつなぐようにしてもらったレプリカ機能がないアプリからのDB接続を Writer/Reader に分散しているが、エンドポイントが一つになる分散していない環境から試し始めたインスタンス型からサーバレス型に切り替えるにはスナップショット経由のみ作成に結構かかった。2~3時間くらいテスト環境とかから試し始めた。本番を切り替える場合どうしようかな。暗号化が必須特に影響なかった「すぐに適用」機能がコンソール上から使えないクラスター名の変更などメンテナンスウィンドウで変更となるCLI からのみ対応可能取り急ぎ再作成とかしたんで、メンテナンスウィンドウもコンソール上から変更できないサポートに聞いたらバックアップウィンドウと共に変更不可との事適応するしかないかサクッと試しただけでも色々と出ました。現状では ACU に上限がありますし、スケールアウト用のレプリカ機能もないのでオートスケール感度によっては本番に適用するのは難しい環境もありそうです。ただ、用途や制限を踏まえてマッチする環境であれば積極的にサーバレス版に切り替えていくべきアップデートかと感じました!皆さんもサーバレス推進するために本機能をガンガン使っていきましょー。それでは、また。
  • テクログ

    Amazon Rekognition でサクッと画像解析する!

    皆さん、AWS使ってますか? 今回は 「Amazon Rekognition(レコグニション)」 を紹介したいと思います! 最近バズワードでなくなりつつある AI 系サービスです! 「画像や動画の分析を簡単な API で使っちゃおう!当然サーバレスで!」 みたいな感じです。 主な機能は、  ・画像内の物体、概念、シーンにラベルを付与 ・アダルトコンテンツかを検出 ・どんな顔をしているかを分析 ・有名人かどうかを判定 ・顔が似ている割合を確認 ・画像内のテキストを抽出 ・動画内の物体、人物などを検出 など多岐に渡ります。 料金も非常に安く環境の構築や運用も不要なので、気軽に試せるかと思います。 当社が管理しているサイトでは、ユーザーが画像や動画を投稿するコンテンツがあるので、それらを分析するロジックに活用できないか検討しているところです。 皆さんも是非お試しください! それではまた!
  • テクログ

    CloudFront で爆速サイトに!

     皆さん、AWS使ってますか? 今回は 「CloudFront(クラウドフロント)」 を紹介したいと思います! 巷で話題(?)のCDNでAWSが提供しているサービスです。 「全世界に分散配置されているエッジサーバにコンテンツをキャッシュして、アクセス元に近いところから超高速にレスポンス返しちゃおうぜ!」 みたいな機能をサーバレスで簡単に実装できるサービスです。 主なメリットは、  ・サーバレス ・費用対効果が高い ・設定が簡単 ・全世界に展開されたエッジ ・AWSの各サービスと連携できる あたりでしょうか。 DDoS対策としては、AWS WAF や Shield で保護できますし、使わない理由が見当たらない! 当社が管理しているサイトでは、静的なコンテンツ(画像・動画・CSS・JSなど)をCDN配信しており、動的なコンテンツについてもCDN配信に向けて検証中です。 皆さんも是非お試しください! それではまた! 
  • テクログ

    AWS WAF を使って悪意あるリクエストからサイトを守ろう!

    皆さん、AWS使ってますか? 今回は 「AWS WAF(わふ)」 を紹介したいと思います! WAF=Web Application Firewall の略です! 一言で表現するなら、  「サイトの訪問者に関所を通ってもらって悪者はサイトに来れなくしようぜ」 みたいな機能をサーバレスで簡単に実装できるサービスです。 主なメリットは、  ・サーバレス ・料金が安い ・簡単かつ即時の実装 あたりでしょうか。 リクエスト内容を見て通信の遮断や許可ができるので、  ・特定の場所(IP)からのアクセス ・特定の文字列がヘッダーに含まれている ・SQLインジェクション ・XSS 等々がサクッと設定できます。 最近ではDDoS対策向け機能もリリースされるなど、常に進化しています。 AWS Shield と併用する事で効果倍増! 後は検知モードから始めて頃合いを見てから遮断させるなども良い点です。 当社が管理しているサイトほぼ全てにWAFが入っています。 皆さんも是非お試しください! サーバレスの理想と現実については、またの機会に・・・。