タグ

ブックマーク / yakst.com (6)

  • MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst

    役に立つ場面もある一方、スケーラビリティー上問題があるとされてきた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チーム内でも確かに長い間言われてきたことです。今日の記事の題に入る前に、少しイントロダクションを書かせて

    MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst
    tgk
    tgk 2017/06/05
    いよいよ普通のRDBになるMySQL
  • SQLにおけるIPアドレスの比較 | Yakst

    PostgreSQL, MySQL, SQL Server, Redshift上でIPアドレスを扱う際にどのようにすれば良いか、についてのまとめ 出典について この記事はThe High-Performance SQL Blog内のComparing IP Addresses in SQL(2015/06/24)を翻訳したものです。 イベントテーブルに操作を記録する際にユーザーのIPアドレスを保存するのは日常的な行為である。 今まで見てきた中では、大多数のケースではIPアドレスをvarcharで保存する。 この手法では、特定のIPアドレスに対してのクエリの発行は簡易となるが、データベースによってはIPアドレスの範囲でフィルタリングするのがきわめて難しくなる。 IPアドレスをvarcharとして比較すると誤った結果を返すことになる。 -- 100 is not less than 2, bu

    SQLにおけるIPアドレスの比較 | Yakst
    tgk
    tgk 2015/08/02
    「クエリをシンプルにするには、IPアドレスを2度保存することだ。 すなわち、1つはvarcharとして、そしてもう1つはintegerとして保存し、クエリで一番便利な方を使うことである」
  • Linuxで、どのプロセスがページングを行っているのか調べるには? | Yakst

    スワップがなぜ起きるか、どのようにスワップの状態を確認するべきかの平易な解説。Quoraの質問に対する、Robert Love氏の回答。 質問に対するストレートな回答は、調べるのは不可能、だ。どうしてそうなのかを説明してから、君の知りたい情報を含んでいるであろう、5つの関連する質問に答えよう。 Linuxのような、モダンなOSにおいては、スワップはシステム全体における現象だ。ある1つのプロセスがスワップに関する責任を持っているわけではない。システムがスワップしているかどうかは、メモリプレッシャの機能による。物理メモリを大量に使おうとすれば、スワップしてしまう。何をスワップアウトするかは、一番少ないページを要求しているのが何かによる。何をスワップインするかは、一番ページを必要としているのが何かによる。プロセスがRAM上に存在しないページを要求した時、そのページはディスク上にあるので、スワップ

    tgk
    tgk 2014/07/24
    「質問に対するストレートな回答は、調べるのは不可能、だ」たまたまスワップを引き起こしたプロセスが原因とは限らない。psのRSS列を見て悪い奴を探れ
  • InnoDBのプライマリキーとセカンダリキー | Yakst

    InnoDBのテーブルから、プライマリキーを取得するクエリを書いたのに、なぜかセカンダリインデックスが使われることがある。この仕組みを、InnoDBのインデックスの格納方法から解説する。 今日、EXPLAINの結果を色々と試してみている時に、興味深い問題にぶち当たったので、ドキュメントには載っていないこの現象をここで共有しておこう。 とても単純なInnoDBのテーブルを考えるところから始めよう。2つのINT型のカラムを持ち、最初のカラムがプライマリキーで、2番目のカラムに普通のインデックスが張ってある。 CREATE TABLE `t1` ( `id1` int(10) unsigned NOT NULL, `id2` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`id1`), KEY `id2` (`id2`) ) ENGINE=InnoDB;

    InnoDBのプライマリキーとセカンダリキー | Yakst
    tgk
    tgk 2014/03/31
    InnoDBのsecondary indexにはrowidではなく主キー値が入っている→主キーのフルスキャンはclusterd indexよりsecondary indexをなめた方が速い
  • (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst

    MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 当にたくさんのことが変わったものだ!この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている

    (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
    tgk
    tgk 2013/09/27
  • MongoDBとMySQLでのスキーマデザインの違い | Yakst

    MySQL Performance Blogの翻訳。MySQLのようなリレーショナルデータベースと、ドキュメント志向データベースMongoDBでのスキーマデザインの違いについて。 2013/08/01 by Stephane Combaudon リレーショナルデータベースに慣れている人がMongoDBのようなNoSQLのソリューションを使うのは、面白いチャレンジになるだろう。そのうちのひとつが、スキーマのデザインだ。リレーショナルな世界では、正規化がいいとっかかりだが、新しくMongoDBのアプリケーションを作るときには、データ保存についてどうデザインすべきだろうか? 簡単な例を挙げて、MySQL(というかあらゆるリレーショナルデータベース)でデータ構造をどう作るか、そしてMongoDBではどうかを見てみよう。個人情報(名前)とその人のパスポートの詳細(国籍と有効期限)を保存したい、という

    MongoDBとMySQLでのスキーマデザインの違い | Yakst
    tgk
    tgk 2013/08/12
    「MongoDBの場合、データへのアクセスパターンを知っている必要があり、間違ったスキーマデザインは大問題を引き起こす原因となる」
  • 1