MySQL 日付別パーティショニングの運用 - 130単位
MySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング http://dev.mysql.com/doc/refman/5.1/ja/partitioning.html 実験的にやってみただけでノウハウとして固まってはいないのですが、現状の知識をまとめてみたいと思います。 前提 MySQL 5.1以降 検証した環境は5.1.47 日付ごとにパーティショニング カラムは一意な"id"と作成日付の"created"があるとする 準備 idとcreatedを複合でプライマリキーにする パーティショニングの条件はプライマリキーに含める必要がある idがAUTO_INCREMENTであればPRIMARY KEY (id, created)の順のみ createdをTO_DAYS()してパーティショニングする 大枠と個別のパーティションの両方でTO_DAYS()す
MySQLの最先端を行く現場人が集う MySQL Casual Talks #6に行ってきた！ - もぐめぽろぐ
TokuDBとはTokutekが作ったFractalTree(R)Indexを実装したストレージエンジン 特徴 オンラインALTER TABLE(ADD INDEX, ADD COLUMN)に対応 圧縮がイケてる 断片化しない クラスターインデックスを複数作れる infromation_schema, show engine tokuDB で情報みれるがなれるのに時間かかる foreign keyは対応してない How TokuDB Fractal TreeTM Indexes Work ランダムライトなインデックスの構築が早い InsertのTPSはいつまでもスループットが変わらない テストケース twitterみたいなことをやろうとした テーブルをクロスしてtimelineテーブルを作る timelineテーブルは6億件 ファイルサイズ図ったらinnodb compactは60G弱、
MySQLのパーティショニングのハマリ所 - sakaikの日々雑感～(T)編
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで１日ごとのパーティションにしたいだけだったのですが（向こう２年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました）、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
MySQL 5.5から使えるようになったRANGE COLUMNSによるパーティショニング - There's an echo in my head
それまでDATEやDATETIMEによるパーティショニングではTO_DAYS()関数を使って数値に変換する必要があったけど、MySQL 5.5からはRANGE COLUMNSを使うことによって日付や時刻をそのまま書けるようになった。 DATETIMEだとこんな感じ。DATEも同様。 /* パーティショニングに使うカラムを主キーに入れる必要があるのは相変わらず */ ALTER TABLE events DROP PRIMARY KEY, ADD PRIMARY KEY(id, created_at); /* RANGEではなくRANGE COLUMNS、パーティショニングするカラムの比較値もそのまま */ ALTER TABLE events PARTITION BY RANGE COLUMNS(created_at) ( PARTITION p201303 VALUES LESS THA
MySQLのパーティショニングで必要そうな工夫 - cloned.log
MySQL 5.1のパーティショニングを試してみた。マニュアルはMySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニングを参照のこと。試してみた環境は、MacのParallels Desktop上のCentOS 5。 まずはMySQL 5.1をソースからインストール。マニュアルには次のように書かれている。 ソースからコンパイルする場合には、--with-ndbcluster、--with-partitionオプションとともにconfigureを実行して下さい。 MySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング この通りにすると、ここの記載のように非推奨オプションだと言われてしまうので、--with-pluginsを使って指定するようにした。今回の味見configureオプションは次の通り。 ./configur
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
MariaDB(MySQL) - パーティショニング！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL 5.1 から導入されたテーブルのパーティショニング（１テーブルの分割管理）についての備忘録です。 パーティショニングすることにより主に以下のようなメリットがあると考えられます。 対象のパーティションのみ参照するようになるため、高速化が見込まれる。 パーティションごと削除が可能であるため、管理が楽になる。 （以下、乱文ご容赦ください） 0. 前提条件 MariaDB(MySQL) 5.5 系、5.6 系での作業を想定。 （5.1 以降ならパーティショニング可能であるが、RANGE で date 型, datetime 型がそのまま使用できるのは 5.5 以降） 1.
今日の MySQL - Partitioning 編 - - 日向夏特殊応援部隊
さてと、ありがちな下記のようなテーブルを作ってみます。ちなみに 5.1.45 で試してます。 DELIMITER ; DROP TABLE IF EXISTS diary; CREATE TABLE diary ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `subject` varchar(64) NOT NULL, `content` text NOT NULL, `created_on` datetime NOT NULL, `updated_on` datetime NOT NULL, PRIMARY KEY (`id`,`updated_on`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 PARTITION BY RANGE ( to_days(updated_on)) ( PARTITION p
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
