安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1821日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています

Python の可視化ライブラリである Seaborn を利用して表現豊かなグラフを生成するためのテクニックを紹介する記事です。グラフの選択基準としてデータを構成する値が分類のある値かそれとも連続値であるかに注目しており、この記事を通して実践的なテクニックを身につけることができます。 可視化は素晴らしいものです。ですが、優れた可視化の実現は悩ましく容易ではありません。 また、大勢に対して優れた可視化をプレゼンするような場合には時間と労力がかかりますよね。 私たちは棒グラフ、散布図、ヒストグラムの作り方についてはよく知っていますが、それらを美しくすることに対してはそこまでの注意を払っていません。 このことは同僚やマネージャーからの信頼に影響します。今あなたがそれを感じることはありませんが、それは起こることです。 さらに、私はコードの再利用が重要であることを知っています。新しいデータセットに触

MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関

MySQLの準同期・ロスレス準同期レプリケーションの仕組みを解説し、同機能についてのよくある誤解やメリットについて説明します。 最近、メールで「MySQL Lossless Semi-Synchronous Replication」について質問されることがありました。この質問への答えは多くの人にとって有益であると考えたため、回答をこのブログ記事に書きたいと思います。回答を読めば、トランザクションのコミット、準同期レプリケーション、MySQLのクラッシュリカバリ、ストレージエンジン（InnoDB）クラッシュリカバリの内部挙動について理解できるでしょう。同時に、私がこれまで見聞きしてきたいくつかの誤解についても糾したいと思います。まずはそれら誤解の一つから始めましょう。 こうした誤解の一つは以下のようなものです（これは正解ではありません）：準同期レプリケーションが有効になっているスレーブは常に

trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 1904日前 Twitterで報告済み 1903日前 原著者承諾済み 編集 スクーターに乗った女性（イラスト画像の作成元はfreepik、NomadロゴはHashiCorp） Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています

[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに

Percona Database Performance Blogの翻訳。Linux上でMySQLサーバを運用する際の、カーネル、ファイルシステム、メモリなどのチューニングのポイントをまとめた記事。 [MySQL][Linux]原文 Linux OS Tuning for MySQL Database Performance - Percona Database Performance Blog (English) 原文著者 Spyros Voultepsis 原文公開日 2018-07-03 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー taka-h 原著者への翻訳報告 1868日前 原文へのコメントで報告済み 編集 この記事では、MySQLデータベースサーバーのパフォーマンスチューニングと最適化のために調整する重要なLinuxの設定を復習します。OSのチューニングに使う

MySQLのストアドプロシージャ、ファンクション、トリガーの性能が良くない理由について解説した記事。 実際のテストケースを交えながら、性能が落ちてしまうケースについて考察しています。 [MySQL]原文 Why MySQL Stored Procedures, Functions and Triggers Are Bad For Performance - Percona Database Performance Blog (English) 原文公開日 2018-07-12 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 1928日前 原文へのコメントで報告済み 編集 アプリケーション開発者は、MySQLのストアドプロシージャ、ファンクション、トリガーをよく作成します。しかしながら、私が知る限り、MySQLのストアドルーチンを使うと

MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ

PostgreSQLのvacuumの問題が発生した場合に起こるテーブル肥大化について、発生要因を３つ挙げて説明している。 [PostgreSQL]原文 Three reasons why VACUUM won't remove dead rows from a table - Cybertec (English) 原文著者 Laurenz Albe 原文公開日 2018-03-14 翻訳依頼者 翻訳者 nao3nao3 翻訳レビュアー doublemarket 原著者への翻訳報告未報告 何故VACUUMを実行するのか？ PostgreSQLのテーブルで、行がUPDATEやDELETEが実行されるいかなる時も、dead rowsは置き去りにされています。 VACUUMはそれらを削除し、その領域が再利用できるようにしています。 もしテーブルがVACUUMされない場合には、そのテーブルは肥大化し

シリーズ第三回目で、「グループレプリケーション」「プロキシ」「分散ストレージ」について紹介している。グループレプリケーションはGaleraとの違いについて、プロキシには幾つかの選択肢があること、分散ストレージではオープンソースのAuroraのようなデーターベースが可能になることなどが述べられている。 この記事は、2017年現在で使用できるMySQLの高可用性ソリューションに焦点を当てたシリーズの第3回目です。 最初の記事では10年以上前から存在していた技術である「長老」を見ました。（訳注：長老編日本語訳）第2回目の記事では「大人」 、つまりより最近の成熟した技術について話しました。（訳注：大人編日本語訳）この記事では、新興のMySQL高可用性ソリューションを紹介します。私がブログで選択した「赤ちゃん」の高可用性ソリューションは、 Group Replication（グループレプリケーション

MySQLでもついにヒストグラム統計を利用した実行計画作成がサポートされるようになりました。作成/削除の方法やどのようなときにインデックスと比べて有利か、などについてご案内します。 免責事項 この記事はErik Frøseth氏によるHistogram statistics in MySQL(2017/10/2)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0.3では、ヒストグラム統計を作成しオプティマイザがより多くの統計情報を利用できるようにすることができます。このブログ投稿では、どのようにヒストグラム統計を作成し、どのような時に役立つかについて説明しようと思います。 ヒストグラムとは何か クエリーオプティマイザはデータベースの中で、SQLクエリーを可能な限り最も効率の良い実行計画に変換する役割を担っています。 時にはクエリーオプティマイザは最も効

MySQL 8.0に「サーバーのメモリー量に応じて自動でパラメーターを設定する」ための innodb-dedicated-server が導入される予定です。この機能と導入の背景を紹介します。 免責事項 この記事はMySQL Server Blogの投稿 Plan to improve the out of the Box Experience in MySQL 8.0 をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0において我々は innodb_dedicated_server=bool と呼ばれる新しいパラメーターを導入するつもりです。 これがONに設定されている時、このオプションはシステムメモリーの量を確認し、以下のルールに従って自動的にパラメーターを決定します。 innodb_buffer_pool_size server_memory <

GitLabのデータベースが消失してしまった事故に関して、PostgreSQLのコミッターであり、PostgreSQLに関するコンサルティング会社2ndQuadrantのCTOでもあるSimon Riggs氏からの分析とアドバイス。 GitLabのみなさん、PostgreSQL 9.6とレプリケーション機能、バックアップの仕組みを使ってくれてありがとう。 今回、GitLabのデータベースが消えてしまったのは残念です。 https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ 振り返りの分析に対するコメントができるように、こういった情報を公開してくれてどうもありがとう。 レプリケーションの遅延を監視していたのはいいことですし、私としてはとてもうれしいです。4GBのレプリケーション遅延は問題ないこともありますし、