MySQL::Partition has been released! | おそらくはそれさえも平凡な日々
MySQL::Partitionをリリースしていたのでお知らせです。パーティションを切る用のSQLを生成してくれるクエリビルダーです。 Webサービスでは如何にデータを増やさないか、DBを分割しないで一系統に抑えるか、DBをメモリに如何に載せきるかってのがゆるふわサービス運用をしていく上で重要です。MySQLを使っている場合、そのために非常に有用なのがパーティションで、適切にパーティションを切り、古いデータを随時Dropしていける運用に落としこむのが非常に大切なわけです。 社内のプロジェクトでもPartitionを活用しているわけですが、いまいち仕組み化されておらず、古いプロジェクトからコピペを重ねて秘伝のタレ化しており、例えばデイリーでパーティションを切る場合、MySQL5.5からはRANGE COLUMNSパーティションが使えるにも関わらず、TO_DAYS()とかを未だにコピペして使い
MySQLのパーティショニングのハマリ所 - sakaikの日々雑感～(T)編
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで１日ごとのパーティションにしたいだけだったのですが（向こう２年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました）、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
MySQLパーティショニングでパフォーマンスアップ！ | QK
mysqlには、レンジパーティションってものがありまして、うーなんでしょ？ある規則にしがったデータをおのおののデータファイルに振り分けてくれる機能です。 ・データ領域が分割されるため、大量のデータを処理することによる性能上のボトルネックの発生を抑えられる ・MyISAMなど、テーブルサイズに上限がある場合でもそれ以上のデータを格納することが可能になる といった点です、少ないデータですとこれといった利点はないかと思いますが、数百万規模データですと、このデータ分割が、大きな効果を呼ぶ。。かもしれないですし、そうでないかもしれません（汗 ただ、はっきりといえるのが、ある規則に従ったデータを、SELECTする際にそのSELECTで必要の無いデータまで、mysqlがシークする必要がないっていったところでしょうか？ただし、データをまたぐ検索が発生する場合は、パフォーマンスは非パーティションテーブルと比
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 8.0 リファレンスマニュアル :: 24.4 パーティションプルーニング
パーティションプルーニングと呼ばれる最適化は、「「一致する値がない可能性があるパーティションをスキャンしません」」と記述できる比較的単純な概念に基づいています。 次のステートメントによってパーティションテーブル t1 が作成されるとします: CREATE TABLE t1 ( fname VARCHAR(50) NOT NULL, lname VARCHAR(50) NOT NULL, region_code TINYINT UNSIGNED NOT NULL, dob DATE NOT NULL ) PARTITION BY RANGE( region_code ) ( PARTITION p0 VALUES LESS THAN (64), PARTITION p1 VALUES LESS THAN (128), PARTITION p2 VALUES LESS THAN (192),
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
MySQLのRANGEパーティションを使う | 村式流 イッパシエンジニアへの道
MySQLのRANGEパーティションのお話です。 MySQL5.1からサポートされているパーティショニングですが、ログテーブル等、レコード数が多くなりがちなテーブルに日付でパーティショニングしてます。 最初から遠い未来までのパーティションを切るのは気持ち悪いし、長く運用されるサービスの場合は忘れる可能性もあるのでバッチを回すのがいいと思いますが追加する場合の手順と注意点です。 ・まずはパーティションを作成 CREATE TABLE `mura`.`test1` ( `date` DATE NOT NULL , `name` VARCHAR( 40 ) NOT NULL , `contents` VARCHAR( 255 ) NOT NULL , `created_at` DATETIME NOT NULL ) ENGINE = InnoDB PARTITION BY RANGE (TO_
にひりずむ::しんぷる - MySQL Casual #1 でふわっとした話をしてきました
去る12月10日(土) に MySQL Casual#1 というのが開催され、主催者であるところの @myfinderさんの目の前に普段座っているという理由だけで、なぜか登壇してきました。 スライドにも書いていますが、MySQL の設定方法だったり、そもそもセットアップのイカしたやり方とか全然知らない感じだったので、だいぶ外枠だけのふわふわした感じの話をすることに。(いつものことですが) とりあえず、懇親会とかでも方々で話されていたように、Sharding とか Partitioning とかをガチでやらなくちゃいけないようなサービスはあまりないんじゃないかなーとも思いますので、こんなんもあるんだねー程度でよいかと思います。（そもそも Sharding って別に MySQL 関係ないし） Partition も実は Range Partition の話しかしてないということに鋭い人は気づい
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
