You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに 皆さんこんにちは、新卒2年目エンジニアの細川です。 今回は輪読会にて勉強したDBのインデックスが効かなくなるSQLについて紹介したいと思います。 今回参考にさせていただいた書籍 今回輪読会で読ませていただいた書籍は「達人に学ぶDB設計徹底指南書: 初級者で終わりたくないあなたへ」という書籍です。DBの良い設計や悪い設計について、それがなぜ良いのか悪いのかを例を踏まえて分かりやすく解説してくれている本です。 正規化手順などについても詳しく書かれており、DBに不安を感じる方はぜひご一読をお勧めします! DBのインデックスについて DBのインデックスと聞くと、何となく貼ると早くなるくらいの認識で使っている方もいらっしゃるのではないでしょうか?(僕はそうでした笑) しかし、インデックスも万能ではなく、種類によって向き不向きもあり、正しい使い方をしないとうまく効果を発揮できません。 インデ
まえがき 長らくはてなブックマークを使っていましたが、最近はあとで読む記事を管理するツールとしてOmnivoreを愛用してます。 使っているうちに、以前まで利用していたPocket、はてなブックマークの記事もすべて移行したくなりました。 Pocketのデータについては、公式でインポートのためのインテグレーションが用意されていたので特に困りませんでしたが、はてなブックマークについては既存の移行ツールも見つけられなかったので自作しました。 成果物は下記リポジトリです。使い方はREADMEにあります。 同じくはてなブックマークからOmnivoreに移行したい方はご利用ください。バグがあったらIssueへお願いします。(PRも大歓迎です) 実装について はてなブックマークのデータは設定ページからエクスポートが可能なので、Atomフィード形式でエクスポートして、エクスポートしたデータをOmnivor
こんにちは、AWS事業本部の荒平(@0Air)です。 表題の通り、いつの間にかAmazon EC2のインスタンスタイプ変更の際に詳細が表示されるようになっていました。 What's Newなどでアップデート履歴を見つけることができなかったのですが、直近でEC2インスタンスタイプを変更する作業を多く触っていたため、ここ1-2週間の話だと思います。 小ネタではありますが、EC2を普段使いされている方は知っておいて損はないと思いましたので執筆します。 3行まとめ Amazon EC2でインスタンスタイプを変更するときに料金やスペック差を一覧できるようになった 意図しないインスタンスタイプ変更を防ぐことができそう 表示される価格はそのリージョン固有の価格になっている アップデート内容 百聞は一見に如かず。以下のような塩梅です。 「Instance type comparison」という項目ができま
本書は、Goアプリケーションの効率やスケーリングに関する疑問に対して、実用的な答えを与えてくれる書籍です。 レイテンシー、CPU、メモリ資源についての知識、またOSやGoがそれらを抽象化している方法について、またソフトウェアの効率に関わるデータ駆動な意思決定を行う事の意味や、計算量解析の手法、最適化状況の例など、実用的なソフトウェアを開発する中での「効率」に関する知識を紹介します。 Goやその他のモダンな言語で書かれたプログラムを設計、作成、変更するソフトウェア開発者、また誰かが書いたソフトウェアを主に運用するDevOpsエンジニア、SRE、シスアド、プラットフォームチームなどの読者が、いつ、どのように効率最適化を適用するかという問いに答えるための知識を身に付けることができるでしょう。 関連ファイル 原著者による本書のサンプルリポジトリ 正誤表 ここで紹介する正誤表には、書籍発行後に気づい
第1回ではリスクマネジメントの全体像、そして「発生可能性の低減」に関する全般的な説明をし、第2回ではその「発生可能性の低減」のなかでもボトルネックの設計について紹介しました。今回は引き続き「発生可能性の低減」のための施策としてキャパシティプランニングを採り上げ、私たちが実際に行なっている方法をご紹介します。 キャパシティプランニングを行うには、最低でも3つの変数を求める必要があります。1つ目は1サーバーあたりのクエリ/秒上限。2つ目は予測されるアクセス需要。3つ目は安全マージンです。「1サーバーあたりのクエリ/秒上限」については第2回で算出できていますので、今回はアクセス需要の予測方法と安全マージンの求め方について紹介します。 1サーバーあたりのクエリ/秒上限 * サーバー台数 * 安全マージン > アクセス数 必要とされるアクセス需要の予測精度は、サーバー予算と過負荷障害時の影響度に大
はじめに こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。 今日はSQLについてです。 弊社に入社してから毎日のようにSQLのクエリを書いてきました。 クエリを書き始めてからもう3年が経とうとしています。 日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。 僕は 正確で 読みやすく 再利用しやすいクエリを 高速に 生み出すための工夫を重ねてきました。 結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。 似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。 対象読者 対象読者は、分析のためにクエリを書いている人とします。 プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。 痛み
SolanaのPublic DataをBigQueryで取得したかった# えー、お笑いを一席. ブロックチェーンSolanaのデータがGoogle Cloud BigQueryで使えるようになったというニュースをたまたまネット推薦記事でみかけた1. おや, 面白そうだ. ちょっとやってみようかな… BigQueryはさわるのが1年以上つかってないかも, どうやるんだっけ… とりあえずカラムとかサンプルでちょっとデータをみたいよな, こんな感じだっけか? とりあえず動かしてみよう, ポチッとな. … 5秒でレスポンスが帰ってくる. おー、速い. えーっと, あれ課金データ309TB?! いちげきひっさつ、ハサンギロチン2. BigQueryでクエリ一撃5 秒で29万円溶かした人の顔# 話題の画像生成AI, DALL・Eをつかって BigQueryでお金溶かした人の顔を表現してもらった3. あ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く