サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
yakst.com
マイクロサービスの構成が増えるにあたりシステムが複雑化し問題が発生した際の原因究明が困難となり分散トレーシングの必要性が高まっています。一方でこの計装はとても大変で、これに対しOpenTracingはベンダーに中立な標準規格を目指しこれを簡易化可能としています。InfluxDataはこれに対して、TelegrafのZipkinプラグインを提供しています。またInfluxDBはトレースのデータ保存にも構造的に最適なデータストアと考えており、InfluxCloudサービスでOpenTracingを実装中です。 [InfluxData]原文 OpenTracing | Open Standard for Distributed Tracing | InfluxData (English) 原文著者 GIANLUCA ARBEZZANO 原文公開日 2017-10-25 翻訳依頼者 翻訳者 tak
InfluxDBの内部構造についてのまとめをご紹介します。3部構成のうちこのエントリではデータをどのように永続化し、圧縮するかについてを取り扱います。 InfluxDBの内部構造についての入門セッションをInfluxDBの新しいメンバー向けにPaul Dixが開催してくれました。 多くのことを学びましたのでコミュニティーに内容を共有したいと思います。私のInfluxDBへの理解を整理するためにも、同時にもしかするとInfluxDBがどのようなアーキテクチャーかを学びたいと思っている人の役にたつように、この記事を書いています。この連載のゴールはInfluxDBのアーキテクチャに関する概要を整理された状態でご紹介することです。 内容がたくさんありますので、3つのパートに分けてお伝えします。最初の投稿ではデータモデルと書込みについて、2つ目の投稿ではクエリーについて、3つ目の投稿ではInflux
シリーズ第三回目で、「グループレプリケーション」「プロキシ」「分散ストレージ」について紹介している。グループレプリケーションは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クエリーを可能な限り最も効率の良い実行計画に変換する役割を担っています。 時にはクエリーオプティマイザは最も効
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
Minecraft サーバーから RCONプロトコルで データを収集するプラグインについて。Minecraft サーバ側の設定から、Chronograf を用いたダッシュボードの作成まで。 免責事項 この記事はInfluxData Blogの投稿 Mineflux: Building a Telegraf plugin to collect data from your Minecraft Server をユーザが翻訳したものであり、InfluxData公式の文書ではありません。 概要 InfluxData での最初の1週間を、私たちは InluxData の背後にあるデータベースである InfluxDB について学ぶのに費やしました。私たちはその他のコンポーネントがいかに簡単に利用できるかということを言われていたので、この主張を検証することに決めて、Telegraf プラグインを書き、そ
以前公開された「長老編」(https://yakst.com/ja/posts/4656) に引き続き、比較的新しいMySQL高可用性オプション(大人たち)について解説した記事。前回同様、初心者向けに「Galera」と「RDS Aurora」の2つを紹介している。 この記事では、いくつかの高可用性ソリューションについて考察を行います。 このシリーズの前回の記事(訳注:日本語版はこちら)では、長きにわたって利用されてきたMySQLの高可用性ソリューションを取り上げました。私はこれらを「The Elders (長老たち)」と名づけました。レプリケーションなどは今でもよく使われており、MySQLの新バージョンがリリースされるごとに改善されています。 この記事では直近5年間で登場し、なおかつコミュニティの中で牽引力を増している高可用性ソリューションに着目します。私はその中から2つのソリューションを
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 <
あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時?それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール
MySQLのクラスター構成が一定規模を超えると自動フェイルオーバーに求められる要件が変化します。orchestratorはGitHubやBooking.comの大規模構成で自動フェイルオーバーを実現しており、数が多くなると顕在化する問題に取り組んでいます。本記事ではSeveralninesの高可用を実現する製品の比較記事への投稿に対するorchestratorの考え方や取組み方の違いについて紹介します。 [MySQL]原文 “MySQL High Availability tools” followup, the missing piece: orchestrator | code.openark.org (English) 原文著者 Shlomi Noach 原文公開日 2017-04-06 翻訳依頼者 翻訳者 taka-h 翻訳レビュアー doublemarket 原著者への翻訳報告未
MySQL高可用性オプションについて3つパートで説明された記事。この記事では最初のパートThe Elders(長老たち)の技術を紹介している。 MySQLに比較的新参の人に向けて書かれており、「レプリケーション」「共有ストレージ」「NDB Cluster」の技術について、メリットとデメリットを説明している。 このブログでは、さまざまなMySQL高可用性オプションについて考察します。 ダイナミックなMySQLエコシステムは、MySQLを中心に構築された多くの技術を急速に進化させています。これは、MySQLの高可用性(HA)の側面に関連する技術に特に当てはまるでしょう。 私が2009年にPerconaに入社したとき、こういったHAの技術のいくつかは非常に人気がありましたが、それ以来ほとんどは忘れられています。その同じ期間で、新しい技術が登場しました。読者にいくつかの視点を提供しながら、出来れば
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
役に立つ場面もある一方、スケーラビリティー上問題があるとされてきたMySQLのクエリーキャッシュが、MySQL 8.0で廃止されることになる。その背景と理由。 免責事項 この記事はMorgan Tocker氏によるMySQL Server Blogの投稿「MySQL 8.0: Retiring Support for the Query Cache」(2017/5/30)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Reneが昨日、ProxySQLのブログにこう書きました。 MySQLのクエリーキャッシュはパフォーマンスを改善するためにあるが、それは重大なスケーラビリティー上の問題を抱えていて、深刻なボトルネックに簡単になってしまいかねない。 これは、MySQLチーム内でも確かに長い間言われてきたことです。今日の記事の本題に入る前に、少しイントロダクションを書かせて
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ! Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
MySQLの論理バックアップ生成ツール「mysqldump」の後継にあたる「mysqlpump」の特徴と使い方についての解説。 この記事では、mysqlpumpコマンドの使い方を見てみようと思います。 mysqlpumpは論理バックアップを取得するツールです(実ファイルではなく、データをSQLとしてバックアップするという意味)。このツールは MySQL5.7.8 で追加され、データベースをダンプする、もしくはダンプしたファイルを別のDBサーバに転送/インポートする目的に使用できます(インポート先はMySQLに限定されません)。 使用方法はmysqldumpと基本的に同じですが、いくつか新しい機能が含まれています。多くのオプションが変わらず使用できますが、mysqldumpとの互換性に縛られることがないよう、一から開発されています。 主な新しい機能 ダンプ処理を高速化するために、データベース
ソリューションエンジニアチームに所属する筆者が、今では様々な手法が存在するレプリケーション機能について、改めて特徴や注意点を解説しつつ、レプリケーションのよくある「誤解」に対してもお答えしています。 このブログ記事では、MySQL(および Percona Server)環境におけるレプリケーション手法に関して改めて考察を行いたいと思います。あわせて、時折見受けられるレプリケーションの間違った考え方についても考えてみます。 私がソリューションエンジニアとして働き始めてからというもの、沢山の情報が公開されているにも関わらず、レプリケーションに対する「誤解」や「不完全な理解」が無くならないことを日々感じていました。 そもそもレプリケーションとは何か? レプリケーションは、1つのデータベースにデータを蓄積するだけでなく、別のデータベースにデータを複製し、転送することを保証してくれる機能です (複製
バージョン番号が変わるのに日付が全部同じという不思議な仕組みのWindowsのドライバー。そこには秘密が。 なぜWindowsのドライバーの日付が2006年6月21日なのか?ドライバーをアップデートしたことないの?単なるなまけ者集団? もっと重要なことに、2006年6月21日という日付は、Storage Spacesのように2006年に存在すらしていなかったドライバーにも適用されているのです!また開発部門がタイムマシンを使ったのでしょうか? Windowsのすべてのドライバーの日付は2006年6月21日に設定されています。バージョン番号は時とともに増えていきますが、タイムスタンプは変わらないままです。 私の同僚Zacがこう説明しています。ある特定のハードウェアのために使うドライバーを探す時、システムは色々な基準に基づいてドライバーをランク付けします。ドライバーがハードウェアIDとぴったり一
Percona社CEO Peter Zaitsevの語るSaaSアプリケーション向けのMySQLシャーディングモデルのバリエーション このブログ記事では、MySQLのシャーディングモデルについてとどのようにそれらをSaaSアプリケーション環境に適用するかについて議論します。 MySQLはもっとも人気のあるデータベース技術の1つで、多くのモダンなSaaSアプリケーション(単純な生産性向上のツールから、金融や医療と言ったビジネスクリティカルな領域まで)の構成要素として使用されています。 MySQLを使用している大規模なSaaSアプリケーションのほとんど全ては シャーディング を使用しています。 このブログ記事ではこのような種類のアプリケーションに対してどのシャーディング方法を選ぶかを議論します。 MySQLではよりモダンな技術の MongoDB のようなものとは異なり、アプリケーションから
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のレプリケーション遅延は問題ないこともありますし、
これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか? マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。 Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。D
ファイルがどのようなプロセスやユーザなどに使われているのかを表示する lsof コマンドの使い方を網羅的に書いた記事。基本的なものから複数条件を指定したちょっと複雑な使い方まで。 これは、知っておくべきUnixやLinuxのユーティリティーに関するシリーズの3番目の記事です。この記事では、便利な lsof ツールについてお伝えしようと思います。 netcat がネットワーク接続のスイスアーミーナイフ(訳注 : 何でもできる便利なツールの意味)なら、 lsof はUnixのデバッグのスイスアーミーナイフであると言いたいところです。 lsof はUnix哲学に忠実に従っています。ひとつのタスクだけを完璧にこなす、つまり、プロセスによって開かれているファイルの情報を一覧にするだけです。開かれているファイルとは、通常のファイル、ディレクトリー、NFSのファイル、ブロックファイル、キャラクタースペシ
出典について この記事はMySQL Step-by-Step BlogのUseful queries on MySQL information_schema(2015/07/15)を翻訳したものです。 MySQLのinformation_schemaはデータベースのインスタンス、ステータス...などなどの日々のDBAの仕事に必要とされる有用な情報を備えている。 私が日々使う基本的なinformation_schemaへのいくつかのシンプルなクエリがあり、私自身が参照するためにこの投稿を書いており、または誰か他の人にも良いリファレンスになるだろう... 主キーまたはユニークキーがないテーブルをみつける 主キーは非常に重要であり、MySQLのInnoDBのテーブルでは主キーをクラスタインデックスとして利用するため、主キーがないと深刻な性能問題につながりかねない。 主キーがないと、スレーブのロギ
免責事項 この翻訳は MySQL Server Blog の 記事 をユーザーが翻訳したものであり、Oracle公式の翻訳ではありません。 MySQL開発チームはこのたび Lab版 のMySQLサーバーをリリースしました("MySQL Server 8.0.0 Optimizer" として公開されています) 私が開発したこのリリースの特徴的な機能は (再帰)共通テーブル式…(再帰)CTE, (再帰)サブクエリー処理, WITH [RECURSIVE] 句としても知られています…です。 3年前、私はCTEをエミュレートする方法を ブログ で紹介しました。しかし、MySQLは今や本物のCTEを備えました。偽物ではなく! これはこの新機能の全ての詳細を紹介するブログポストの最初の一つです。 派生テーブルはFROM句のサブクエリーです。下記の太字の部分がそれにあたります。 SELECT … FRO
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか?順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
InfluxDB 1.0 GAがついにリリースとなりました。1.0までの約3年間の振返り、これからのバージョンで何を計画しているかについてご紹介します。 出典について この記事はInfluxData BlogのPaul Dix氏によるInfluxDB 1.0 GA Released: A Retrospective and What’s Next(2016/9/8)を翻訳したものです。 本日、オープンソースの時系列データベース InfluxDBと、高可用構成と高スループットを実現するためのクラスタリングのスケールアウトをサポートした商用版であるInfluxEnterpriseの1.0版のリリースをご案内します。本日は、我々の会社の歴史上最も重要な日となりました。このリリースまでには約3年もの年月がかかり、これを機にプロジェクトの歴史を振り返り、ユーザーの皆さんに1.x系のリリースでどのよう
DNSの仕組みと一般的な使い方について、DNSに関する作業をする時によく使うコマンドや、具体的な例を交えてまとめた入門的記事。 私はよくドメイン名に関する問題に遭遇します。どうしてウェブサイトが動かないんだ? どうしてこんなくだらないのが上手くいかないんだ、何やってもダメだ。ただ動かしたいだけなのに! 質問をしてくる人はたいてい、DNSが何かを知らず、基本的な部分がどのように動くのかの理解にも乏しいです。より一般的には、みんなDNSが強くて複雑なものだと思っているのです。この記事では、その恐怖を和らげようと努力してみようと思います。一度基本的なコンセプトを理解してしまえば、DNSは簡単です。 DNSとは まず大事なことから始めましょう。DNSは、Domain Name Systemの略です。基本的には、これはグローバルに分散されたキーバリューストアだと言えます。世界中のサーバーは、あなたが
5歳の娘が銀河の女王になることに興味を示しているのですが、銀河征服のためにどんなプログラミング言語や技術を教えたらよいでしょうか? Mark Harrison氏の回答 注意深くやる気と動機づけについて考える必要があるんじゃないかと思う。 2児の親として、娘の成長を十分に支援してあげたい、そして楽観主義にとらわれないよう注意させ、 やりがいのあるゴールを設定することを学ばせる手助けをしたいというあなたの気持ちがよく分かる。 しかし、銀河統一の歴史において、両親の面倒を見るということに関してあまりよいことがない点に注意すべきだ。 父殺し・母殺しの習慣は少なくともローマ皇帝の時代にさかのぼる。 古代文書に「父母を敬え」とあるのは、大きな問題の芽を早めに摘み取るよう努力することを表しているようだ。 従って、あなたがするべきは、強力なコンセプトを持ち、銀河の支配のための実績を築く説得力のある議論に裏
Gitでブランチ(コミット)間の違いを表示するgit diffコマンドに存在するダブルドット(..)記法とトリプルドット(...)記法の違いについて、Stackoverflowの分かりやすい回答。 「git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは?」という質問へのMark Longair氏の回答 git diffコマンドは通常(「通常」というのは、例えばマージコンフリクトを解消する際などには3ウェイマージを表示することがあるため)、コミットグラフにおける完全な2つのポイント間のツリーの状態の違いを表示します。git diffでの..と...の表記は、以下の意味になります。 言い換えると、git diff foo..barはgit diff foo barと完全に同じです。どちらも2つのブランチfooとbarの最新の変更同士の違いを表示します。
次のページ
このページを最初にブックマークしてみませんか?
『Yakst | 人力翻訳コミュニティ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く