クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita
「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購
脆弱性検知ツールVulsで前日分との差分だけレポートする - Qiita
はじめに 脆弱性検知ツールVulsを使うとシステムに内在する脆弱性を一発で俯瞰することができ、非常に便利です。 ただ実際には、運用的にステージング環境で検証を行ったあとサービスのメンテナンス時間にアップデート作業を行うため、直ぐに最新版を適用することが難しかったり、脆弱性の深刻度・攻撃元区分(ローカルかリモートか）によっては適用しないといった判断をすることもあるかと思います。 そういった場合、Vulsで毎日自動スキャンしたあと見つかった脆弱性全部をレポートするのではなく、前日との差分だけ通知してくれたほうが運用的に管理しやすい場合もあります。 導入については各所に纏まった手順があるため、今回はスキャン後の差分レポートの作成についてのみ記載したいと思います。 スキャン後にレポートの差分だけメールする 当初、スキャンが終了したホストの順でレポート結果が出力されていたためタイミングによって順番が
Swiftzつかってみた - peroli Developer's Blog
2016 - 06 - 03 Swiftzつかってみた MERY のサーバーサイドエンジニアの藤原です。 今回は、MERYの iOS アプリには使用していないのですが、一部で話題のSwiftzについて調べてみました。 Swiftzとは 他の 関数型言語 によくある機能を、Swiftでも使えるようにするライブラリです。 Swiftにも 関数型言語 っぽいmapやreduce、filter、flatMap等がありますが、例えばEitherはまだありません。 そういった、「他の言語だったらこう書けるのに」を解消してくれるライブラリです。 Swiftzの利点と欠点 利点としては、 上手くやりたいことと噛み合うとコードを短くスッキリと書ける コードの再利用性を上げやすくなる(部品を書きやすくなる) Swift3.0で追加されそうな機能を先取りして使える 他の 関数型言語 を覚えやすくなる 等があると
私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
[レポート]【ミクシィ様登壇】10 年オンプレで運用した mixi を AWS に移行した 10 の理由 #AWSSummit | DevelopersIO
[レポート]【ミクシィ様登壇】10 年オンプレで運用した mixi を AWS に移行した 10 の理由 #AWSSummit はじめに こんにちは、中山です。 6/2(木) 13:20 〜 14:00 に実施された「10 年オンプレで運用した mixi を AWS に移行した 10 の理由」というセッションを聴講したので、そのレポートを以下に記述します。 セッション情報 株式会社ミクシィの北村さまに発表していただきました。こちらのURLより概要を引用します。 2014 年 3 月に 10 周年を迎えた mixi。なぜ 10 年以上オンプレミス環境で継続運用して きたサービスを AWS に移管することを決めたのか。サービスの成長を支えると共に大規模 化・複雑化してしまったインフラを、どのようにして AWS に移管したのか。 当時のサービ スを取り巻く社内外の環境を踏まえ、どのように移管を計
![[レポート]【ミクシィ様登壇】10 年オンプレで運用した mixi を AWS に移行した 10 の理由 #AWSSummit | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/148d66c86adf4dd67af10f04029ebb83085d1632/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F06%2Faws-summit-tokyo-2016.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker だらけの FRESH な動画配信プラットフォーム
