MariaDB/MySQLでデータベースシャーディングの機能を提供するストレージエンジン、Spiderの紹介です。

もしかしたら使うかもしれないので調べてみた。 shard 日本語に訳すと(ガラスや貝殻の) 「破片」といったような意味 データベースをshardに分解して複数のサーバに分散して運用するのがDB sharding データベースパーティショニングとも言えるのかしら? 単一のサーバのDBテーブルを複数のファイルに分割するのをパーティショニングとも呼ぶが、「パーティショニング」という言葉を使ってDB shardingのことを言っているブログ等もちらほら見かけます。 より突っ込んでみたい人は「shared nothing」でぐぐってネ。 なぜデータベースを分散処理するのか 横軸にはサービス運用開始からの時間経過を設定し、縦軸には「DBの応答時間」、「DBへの問い合わせ数」、「DBサイズ」の各数量をとります。サービスが順調に利用されていっているものとし、「DBサイズ」や「DBへの問い合わせ数」は時間経
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ!この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
ある曲の印象的なイントロだけ思い出して、たぶん90年代のバンドの曲でアニメの主題歌だった気がする、名探偵コナンとかだったような、で探して ZIGGY の STEP BY STEP を見つけて聴いてみたが明らかに違う、でも思い出せない、なんだっけ…… と半日くらい気になっていて、風呂上がりに突然(気になってる曲のものかどうかは定かではなかったが)サビのメロディと歌詞が頭に浮かんできて、もしやと思ってすぐに歌詞を検索して、TRICERATOPS の GOING TO THE MOON が出てきて、聴いて、これだ!これだったのか、すっきりした、で結局なんのアニメの曲だったんだっけ?と思ったら、 本曲はポカリスエットのタイアップに選ばれ大量オンエアされた。そのことから、バンドの知名度が一気にアップした。 https://ja.wikipedia.org/wiki/GOING_TO_THE_MOON
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
本連載もついに最終回となりました。 本連載では、MySQLクエリーチューニングことはじめで予告した通り、「チューニング箇所の洗い出しのテクニック」について説明してきましたが、「チューニングの方法」については一切触れませんでした。 「本連載ではチューニングそのものの方法については詳しく説明しません。それは見出しの通り「銀の弾丸」などはなく、MySQLのパフォーマンスチューニングは計測と改善を繰り返し行っていくべきものだからです。そのため、特定のケースにマッチする改善の手法よりも、繰り返し使われる計測の手法にフォーカスを当てて説明していきます。」 その理由としてこの一文が全てではありますが、今回は参考までに筆者が考えるチューニングの指標を紹介したいと思います。それがあなたの環境に当てはまるかどうかは、これまでに紹介してきたツールなどを利用して計測してみてください。 チューニングの基本方針 基本
具体的にクエリチューニングを行ってみます。 スキーマの用意 データベース作成 CREATE DATABASE mydb; USE mydb テーブルおよびインデックス作成 CREATE TABLE t1 (id INT PRIMARY KEY); CREATE TABLE t2 (id INT); ALTER TABLE t2 ADD INDEX myindex(id); CREATE TABLE t3 (id_md5 VARCHAR(32) PRIMARY KEY, myval INT); データの流し込み RAND 関数は引数の seed が同じであれば同じ結果を返します。 t1 i=1; while [ $i -lt 10000 ]; do mysql -uroot mydb -e " INSERT INTO t1 VALUES(CEIL(RAND($i)*1000000000));
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
こんにちは。インフラエンジニアの綿引です。 早速ですが、今回はMySQLのテーブル圧縮について記載したいと思います。 但し、MySQL 5.7から実装された透過性ページ圧縮でなく、 MySQL 5.1のInnoDB Plugin時代からある圧縮です! 個人で運用しているMySQLが5.6なのですが、 ストレージが逼迫して来たので、旧来の圧縮を試してみました。 MySQL 5.6以前で「ディスク容量が足りない!」という方がいらっしゃれば、 参考にして頂ければと思います。 圧縮の仕組み まずは圧縮の仕組みについて図を作ってみました。 非圧縮ページ(16KB) と記載してあるものが通常のページだとお考え下さい。 今回、実施する圧縮の仕組みとしては、 通常はこの非圧縮ページがそのままストレージに保存される所を、 圧縮ページを作成しストレージに保存することによって、 ディスクの消費量を抑えられるとい
pt-query-digestだったり調査のために、N秒間だけmysqlの全クエリのログを取得したいということはよくありますよね そんな時はこんなコマンドを使うと簡単に指定の秒数slowlogを切り替えて保存、取得後に元に戻してくれます。 $ slowlog.pl --duration 10 -- --default-extra-file=/hoge/my.cnf -uuser -- のあとはmysqlコマンドに渡すオプション ソース #!/usr/bin/perl use strict; use warnings; use IO::Handle; use Getopt::Long; use File::Spec; sub find_path { my $pg = shift; my $path; for ( split /:/, $ENV{PATH} ) { if ( -x "$_/$p
Railsに限らず、MySQL(Innodb)を利用したサービスを開発/運用しているなら、これから解説する内容を知っておかないと、予期しないデータ不整合を発生させてしまうかもしれません。 データ不整合が発生してしまったら、本来あるべき状態に戻すのはかなり難易度が高いため、開発/運用をしているエンジニアは、データ不整合を起こさないようにすべきです。 では、どのようなことをすると、データ不整合をいとも簡単に発生させることができるかを解説します。 まずは、何が原因でデータ不整合が発生するかの簡単なモデルを紹介します。 以下のようなUserオブジェクトをcreateししたとします。 User.create(:name => "interu, :age => "27") すると、Userテーブルにデータが追加されます。 ■ Userテーブル id name age 1 user_a 30 2 use
The document discusses testing the limits of MySQL by creating an extremely long SQL query with over 4,000 "UNION ALL" selections of the value "b". This exceeded the maximum length of SQL queries that MySQL servers can execute, which is defined by the max_allowed_packet system variable and has a maximum value of 1GB. Creating such a long meaningless query demonstrated that MySQL has limitations on
今日は 8 月 8 日、無限大の日。数字の 8 を横にすると、限りのないことを示す無限大の記号「 ∞ 」になります。この記号はイングランドの数学者ジョン・ウォリスが導入したとされています。またこの日は入籍日としても人気のようです。8 はそもそも縁起の良い数字ということもあり、「永遠の幸せ」という願いを込めて、多くの人々に選ばれています…
Документ содержит информацию о кодировках символов в MySQL, включая различные наборы символов и их применение. Рассматриваются такие аспекты, как кодировка символов, соответствующая MySQL, и различия между UTF-8 и UTF-8MB4 в контексте работы с данными. Также описаны настройки, необходимые для правильного использования кодировок на уровне сервера, базы данных и таблицы.
2025 ( 12 ) 4月 ( 6 ) 3月 ( 4 ) 2月 ( 2 ) 2024 ( 30 ) 12月 ( 5 ) 11月 ( 1 ) 9月 ( 4 ) 8月 ( 2 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 4月 ( 1
一意なIDを取得するための採番テーブルを利用したかったのだが、 ベストプラクティスとして色んなサイトに書かれているやり方が以下。 update num set id = LAST_INSERT_ID(id + 1); select LAST_INSERT_ID(); だいたいやってることは理解できる(採番テーブルを更新して、更新後のデータをselect) のだが、 LAST_INSERT_ID ってなんじゃい?となったので調べてみた。 LAST_INSERT_IDを使って採番テーブルを扱う - (゚∀゚)o彡 sasata299's blog 上記の記事がわかりやすかった。 だが、そもそも適切なトランザクション管理してあれば LAST_INSERT_ID 使わなくてもよくない?って思ったのでちょっと検証してみる。 準備 mysql> CREATE TABLE num ( -> id big
LAMP構成のWebアプリケーション開発では、ストアドプロシージャを全然作っていないなと感じます。私が作っているサービスでは、そんなに入り組んだ処理をしていないだけですけど(^_^;、それでもやっぱり、データベースの主要な機能である、ストアドプロシージャや、ストアドファンクションをPHPから使用する方法は知っておいた方がよいかなと思い、試してみた事をメモします。 PHP(PDO)からストアドプロシージャの実行 MySQLのストアドプロシージャの解説は、「http://dev.mysql.com/doc/refman/5.1/ja/stored-procedures.html」や「http://www.klab.org/media/mysql/index5.html」の記事が非常に参考になりますので、併せてご参照ください。 それでは、早速ストアド本体のサンプルとして、MySQLのDESCRI
Copyright © 2004-2025 Impress Corporation. An Impress Group Company. All rights reserved.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く