KibanaのProfilerでElasticsearchのクエリを分析する - Qiita
KibanaのDev Toolsの一つにProfilerという機能があります。 このProfilerを利用すると検索や集計のクエリを分析し、どんなクエリが発行されたのか、どのくらいの処理時間がかかっているのか等を簡単に知ることが出来ます。 内部的にはElasticsearchのProfiler APIを利用しているみたいですが、このAPIのレスポンス内容から分析するのは中々大変なのでKibanaを利用した方がお手軽です。 ネットワークのオーバーヘッドやキューの待ち時間等、Profilerで計測出来ない値も色々あるのですが、それでも手探りであれこれ試すよりはProfilerを利用した方が色々と便利かなと思います。 （※参考：Profileの制限） Profilerは Dev Tools > Search Profiler から開くことが出来ます。 環境 Elasticsearch 6.5.4
BigQuery で ROW_NUMBER(), RANK() を使うな！
どういうことか たとえば created_at が最も新しいレコード 1 件だけ取ってきたいとか、成績のよいレコード上位 5 件を取ってきたいといったとき、よくある方法として RANK() や ROW_NUMBER() のような番号付け関数を使う方法が思い浮かぶと思いますが、BigQuery ではこれらの関数ではなく ARRAY_AGG() 集計分析関数を使うことが推奨されています。 先に結論を ARRAY_AGG() を使うことでクエリの計算を最適化でき、スロット使用量（計算量）が少なく済みます。スロット使用量の上限を定めている場合、非効率なクエリがいくつも実行されるとキューイングされる可能性があるため理由がなければ ARRAY_AGG() を使いましょう。 ドキュメントによれば ORDER BY 句が各 GROUP BY 句のトップレコードを除くすべてを捨てることができるため効率がいい
LinuxのI/OやCPUの負荷とロードアベレージの関係を詳しく見てみる - Qiita
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
MongoDBのアレをアレする
1. MongoDBのアレをアレする 株式会社サイバーエージェント アメーバ事業本部ピグディヴィジョン 桑野 章弘 12年7月8日日曜日 2. アジェンダ MongoDBCasual もんごたんについておさらい 運用時にあったこと集 障害時何見る？ まとめ 12年7月8日日曜日 3. 自己紹介 桑野章弘 サイバーエージェント Ameba を運営しています。 ピグライフの運用／構築を担当 Twitter @kuwa_tw Blog http://d.hatena.ne.jp/akuwano/ 著書／活動 「MySQLによるタフなサイトの作り方」 12年7月8日日曜日
Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services
Amazon Web Services ブログ Amazon Athena のパフォーマンスチューニング Tips トップ 10 2024 年 2 月に更新された原文を日本語版として 9 月に反映しました： この記事は、コストベースの最適化とクエリ結果の再利用を含む Amazon Athena エンジンバージョン 3 の変更を反映するために確認および更新されました。 Amazon Athena は、オープンソースのフレームワークに基づいた対話型分析サービスで、標準の SQL を使って Amazon Simple Storage Service (Amazon S3) に格納されたオープンテーブルおよびファイル形式のデータを簡単に分析できます。Athena はサーバーレスなので、インフラストラクチャの管理は不要で、実行したクエリに対してのみ料金を支払います。Athena は使いやすく、Ama
【MySQL】CHAR型とVARCHAR型の違い – ysklog
両方の型とも文字列のデータを挿入するときに指定しますが、CHAR(10)とVARCHAR(10)では実際にデータを挿入した時に違いが生じます。 例えば、「A」という文字は半角英数字なので1バイトの容量を必要としますが、CHAR(10)型のフィールドに「A」を挿入した場合、消費容量は10バイトとなります。 一方、VARCHAR(10)型のフィールドに「A」を挿入した場合、消費容量は1バイト（正確には2バイト）です。 VARCHARのみ使用すればいいのでは？ だとしたら、CHAR型ではなくVARCHAR型だけ使用すればいいことになりますが、CHAR型は格納するデータのバイト数に関わらずすべてのレコードで同じ容量のデータを格納するため、MySQLサーバのスピードが向上します。 しかし、CHAR(100)のように大きめのデータを格納しようとすると逆にメモリを消費することもあります。 そのため基本的
AWS Solutions Architect ブログ
こんにちは。ソリューションアーキテクトの江川(@daiti0804)です。本日は、AWS のソリューションアーキテクトであるGowri Balasubramanian が、AWS Database Blogに投稿したChoosing the Right DynamoDB Partition Key をご紹介します。 このブログ投稿では、リレーショナルデータベースから DynamoDB へ移行するにあたって、適切なパーティションキーを選択するための重要な考慮事項と戦略を説明します。これはDynamoDB を利用するスケーラブルで信頼性の高いアプリケーションの設計と構築において重要なステップです。 パーティションキーとは DynamoDB では二種類のプライマリキーをサポートします: パーティションキー(Partition key): ハッシュキー(以前の名称)としても知られていますが、パーテ
DynamoDB ベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今年は始めて、re:Inventに参加してきたので、その際に見た「Amazon DynamoDB: Data Modeling and Scaling Best Practices」というセッションの内容を共有したいと思います。 内容をだいぶ端折ってるので、間違っている場合には、びしばしツッコミいただければと思います。 では、まいります。 1. CacheはCashなり なんでDynamoDBを使うかといえば、やっぱり、ポチポチっと設定するだけで簡単に読み込み、書き込み性能を上げたり、下げたりできるっていうのが大きなポイントかと思います
GoのパフォーマンスTipsメモ
パフォーマンス維持のコツをコツコツとメモする リフレクションは最後の手段 パフォーマンスに寄与しない部分でのみ使う。 どこがパフォーマンスに寄与するのかが不透明なうちは使用禁止のほうが良い。 一度使い出すとリフレクションは多用したくなる魔力がある。 メモリ使用量 値は8バイトアライメントに置かれるので基本は8バイト長分メモリを専有。 ポインタ変数は64bitCPUで8バイト長 インターフェース型変数は16バイト長〜 （値＋型識別） メモリ確保を含む型コンバートは 型キャスト、アサーションに比べると10倍以上遅い。 同じ値なのに「メモリ確保を含む型コンバート」を複数回行う場合は メモリ消費量は増えるが汎用の変数「interface{}」に 値を保存しておいて参照するほうが速度を維持できる。 ゼロメモリアロケーション 高頻度操作におけるメモリアロック１とゼロの間には大きな速度差がある。 可能で
第2回 最大の課題「I/Oボトルネック」の原因と分析法 | gihyo.jp
I/Oの「レスポンス」と「スループット」とは？ 連載第1回でご紹介したように、大規模データ処理を行うデータベースで一番大きな課題となるのは、ディスクI/O（以降、単にI/Oと表記します）のボトルネックです。数百GBやTBクラスの巨大データウェアハウスの場合、SQLが実行される時間のほとんどがI/Oを待つ時間となっているケースが多々あります。 ここでは、I/Oボトルネックが発生するおもな原因を、「レスポンス」と「スループット」という概念から見ていきましょう。それぞれ、広義では以下の定義となります。 I/Oレスポンス＝I/O要求処理にかかる応答時間 I/Oスループット＝単位時間当たりのI/O処理量 Oracle Databaseに当てはめると、以下のように定義できます。 I/Oレスポンス＝1データブロックの読み出しや書き込みにかかる時間 I/Oスループット＝単位時間あたりの読み出しや書き込み
第6回 ネットワークボトルネックの原因と解決策 | gihyo.jp
クライアントとDBサーバ間のネットワークがボトルネックになる2つのケース これまで、大規模データ処理RDBMSの2大ボトルネックであるI/OとCPUについて、発生の原因と改善策を紹介してきました。その2大巨頭に隠れて目立たないのですが、大規模データ処理を行う際には、I/OやCPUと同じくらいネットワークもボトルネックになりやすいものです。 ネットワークがボトルネックになるケースとしては、以下の2つがあります。 DBサーバとストレージ間のネットワークI/O クライアントとDBサーバ間の結果セット転送 前者は第2回、第3回で紹介しているので、今回はクライアントとDBサーバ間のネットワークに焦点を当てて解説していきます。 大規模データ処理を行うRDBMSにおいて、クライアントとDBサーバ間のネットワークがボトルネックになる代表的なケースは下記の2つです。 ケース① ⇒ DBサーバがクライアントに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bfcache - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN
Explain Results - MongoDB Manual v6.0
Part 2: RabbitMQ Best Practice for High Performance (High Throughput) - CloudAMQP
MongoDBの監視
Mongo count really slow when there are millions of records
golang で string を []byte にキャストしてもメモリコピーが走らない方法を考えてみる - Qiita![golang で string を []byte にキャストしてもメモリコピーが走らない方法を考えてみる - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c460f95ca414c423c73b6a08dbcd42606ce2bb45/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGNjY1JTJGcHJvZmlsZS1pbWFnZXMlMkYxNTQzODkyMjk3P2l4bGliPXJiLTQuMC4wJmFyPTElM0ExJmZpdD1jcm9wJm1hc2s9ZWxsaXBzZSZmbT1wbmczMiZzPWI2MDAyNjlhYjhlZDdiYzZlYjg2NGY1NGJkMWI3ZDk5%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D6fd90509da2c9feaf4d07f0d7d5e296c%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9Z29sYW5nJTIwJUUzJTgxJUE3JTIwc3RyaW5nJTIwJUUzJTgyJTkyJTIwJTVCJTVEYnl0ZSUyMCVFMyU4MSVBQiVFMyU4MiVBRCVFMyU4MyVBMyVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MSU5NyVFMyU4MSVBNiVFMyU4MiU4MiVFMyU4MyVBMSVFMyU4MyVBMiVFMyU4MyVBQSVFMyU4MiVCMyVFMyU4MyU5NCVFMyU4MyVCQyVFMyU4MSU4QyVFOCVCNSVCMCVFMyU4MiU4OSVFMyU4MSVBQSVFMyU4MSU4NCVFNiU5NiVCOSVFNiVCMyU5NSVFMyU4MiU5MiVFOCU4MCU4MyVFMyU4MSU4OCVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MiU4QiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPWZhMDk5M2ZjODAwMTBlZjczNDkzMjU3ZDBjZTQxYzQx%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBtYXR0biZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPTFjNDA2YWFjODI3NjcyMzYzYjg1YWE5NDQ1YmZkMWMy%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D3205162b4bf1685c42c33f41089387ec)
golang で string を []byte にキャストするとメモリコピーが走ります - Qiita![golang で string を []byte にキャストするとメモリコピーが走ります - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/87483b2ef2f4a216d206c464f2bbbdf9199e3907/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNDQ0ODclMkZwcm9maWxlLWltYWdlcyUyRjE2NDkyNTc3OTc_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9OTNlMWJmMTkwMWVhNDRhNWEyM2FmYmQ0YjliOGQ2MzY%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D8a2d8092a4992c4358f6ff7a8acfc55e%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9Z29sYW5nJTIwJUUzJTgxJUE3JTIwc3RyaW5nJTIwJUUzJTgyJTkyJTIwJTVCJTVEYnl0ZSUyMCVFMyU4MSVBQiVFMyU4MiVBRCVFMyU4MyVBMyVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MSVBOCVFMyU4MyVBMSVFMyU4MyVBMiVFMyU4MyVBQSVFMyU4MiVCMyVFMyU4MyU5NCVFMyU4MyVCQyVFMyU4MSU4QyVFOCVCNSVCMCVFMyU4MiU4QSVFMyU4MSVCRSVFMyU4MSU5OSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTlhYWVkMGMzMjk4NWFlNDU0NDEwZGJlYTA4YmYzMGQy%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBpa2F3YWhhJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9M2VkYWUxYTE2YjU0OTc3YmJjNDA1Njg0NzUwOGJmZmY%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D0c44d320a0064ac80bd52089682b7eb1)
Goの文字列結合のパフォーマンス - Qiita
go標準のbenchmark機能の使い方 - Qiita
