タグ

mysqlに関するcooldaemonのブックマーク (58)

  • Tritonnプロジェクト MySQL Sennaによる全文検索 〜

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • MySQL Conference & Expo 2007 - とあるはてな社員の日記

    一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。 詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。 個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。 というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。 Technology at Di

    MySQL Conference & Expo 2007 - とあるはてな社員の日記
  • Yet Another Hackadelic - AES_ENCRYPT, AES_DECRYPT可能な暗号をPerlで行う

    はじめに MySQLの関数にAES_ENCRYPT, AES_DECRYPTってのがあります。 AES_ENCRYPT, AES_DECRYPT Rijndaelを128bitのkeylengthでECBで暗号化する関数です。 AES_ENCRYPT mysql> SELECT HEX(AES_ENCRYPT('hogehoge', 'abcdeabcdeabcdea')) AS encrypted; +----------------------------------+ | encrypted | +----------------------------------+ | 2BF77B6863989EAD599D86650A046586 | +----------------------------------+ AES_DECRYPT mysql> SELECT AES_DECRY

    Yet Another Hackadelic - AES_ENCRYPT, AES_DECRYPT可能な暗号をPerlで行う
  • InnoDBの複合FOREIGN KEY制約について - 日向夏特殊応援部隊

    今回はInnoDBなら是非使いたい機能のひとつ、FOREIGN KEY制約の話です。 まずはテーブルを用意 Fooと言う複合primary keyを持つテーブルを用意したとします。 CREATE TABLE `Foo` ( `a_id` int(11) NOT NULL default '0', `b_id` int(11) NOT NULL default '0', `name` text, PRIMARY KEY (`a_id`,`b_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8こういう場合、このテーブルに対してFOREIGN KEYを張るケースで、 a_id, b_idのセットで張りたい場合があります。 多くの方は専らFooのprimary keyをひとつにしてsequencialな値としてあげて、 そこに単一のFOREIGN KEYを張るんじゃ

    InnoDBの複合FOREIGN KEY制約について - 日向夏特殊応援部隊
  • YappoLogs: Senna 1.0.0がリリースされたよ!

    Senna 1.0.0がリリースされたよ! 遂にSennaの1.0.0が出ましたよ! プレスリリースによると ●メジャーバージョン(1.0.0)リリースについて Senna1.0.0では転置インデックスの格納形式を改善し、更新/検索速度を損ねる ことなくサイズを最大で従来比70%程度まで圧縮することに成功しました。この ため、従来よりも大規模な文書を1台のサーバで管理することが可能となりました。 という事なので早速wktkしながらinstallしました。 色々考えるのがめんどくさかったので、動いてる環境にsennaとmysqlを順番にmake installしてmysql restartです。 早速indexを作り直してみると。。。。 -rw-rw---- 1 mysql mysql 1.0K 21:05 SEARCH_DATA.MYI -rw-rw---- 1 mysql mysql 2

  • iandeth. - MySQLのFULLTEXTインデックスについて

    たたみラボブログの方で、MySQLの全文検索 - FULLTEXTインデックス - について2つエントリを書きました: MySQLで全文検索 - FULLTEXTインデックスの基礎知識 知っておくべき基仕様(全レコードの50%以上が該当する検索語は無視されるルール等)や、日語でFULLTEXT全文検索を使いたい場合の選択肢について、等。 FULLTEXT + Ngram : LIKE検索より数十倍高速な、お手軽 日語全文検索 について FULLTEXTとNgramを駆使した日語全文検索についてまとめ。MySQL単体で完結できて、Like検索より速い、ひらがな<>カタカナのゆらぎを吸収してくれる・・・等など。そんな事いいから Senna 使っとけ、なんでしょうけど、まぁニッチなニーズはあるかと思ったので。

  • 1人で稼ぐ日記 | [MySQL] FEDERATEDエンジンの使い道

    はてなブックマークでなぜか注目されてたFEDERATEDエンジン 調べてみたらここで取り上げられていたので少し注目されたようだ。 このFEDERATEDエンジンの自分としての使い方。 DB1にあるテーブルの検索結果を新規テーブルとしてDB2に作成する。 create table [copy_to_table] select * form [copy_from_table] where .. orderby .. limit .. ↑この形式でテーブルを作成しようとすると、同一DB上でしか 検索結果のテーブルを作成できませんが FEDERATEDエンジンを使えば実現できます。 こんな感じ。 ■このテーブルがDB1にあるとする CREATE TABLE `bbssubject` ( `board` varchar(30) character set

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • セッション管理に向いているデータベースは MySQL ? Oracle ?

    Catalyst-Plugin-Session-Store-DBIC とか検証してます。で前から気になってはいたのですが、Perl 界ではセッション管理するモジュールといえばほぼ全て MySQL が前提っぽい作りになってると思います。でも業務で使っているデータベースは Oracle でして、う〜ん・・・どうすっべかなぁ〜と思ってました。 で、試しに Oracle でセッション管理するためのテーブルをつくってみました。Oracle は VACHAR2 型とかは 4000 文字までしか扱えないので、セッションデータとして使うにはちょっと物足りないデータ型。CLOB 型を使えば解決できるんですが、DBI ベースにいろいろと指定してあげないとダメ。しかも多分遅い。遅いと推測していたから、今まで LOB や LONG 型はあえて使ってきませんでした。 session 格納に使うテーブルの構造はこんな

  • DBサーバのストレージをDRBDで冗長化するのは是か非か - (ひ)メモ

    LinuxにはDRBDというものがあります。 DRBDとは何か? 簡単にいうと、ミラーリングです。ミラーといっても、RAID-1のようにディスクtoディスクではなく、2つの異なるサーバ間のネットワーク越しのミラーリングです。 RAIDの場合は、ディスク故障の耐性は高まりますが、サーバのほかの部分(電源など)が壊れると元も子もありません。DRBDだと、そういった場合の障害にも対応できますね。 DRBDには普通のブロックデバイスとしてアクセスできます。つまり、mkfsしてmountしてフツーのディスクのように使えます。 で、 A quick tour of DRBD - MySQL-dump は、そのDRBDを使って、MySQLのストレージを冗長化するという話。(だと思う。ナナメ読みなので) しかーし、いくつか危険な点があるので、この構成はやらんほうがいいというのが個人的な意見。以下、その理由

    DBサーバのストレージをDRBDで冗長化するのは是か非か - (ひ)メモ
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    cooldaemon
    cooldaemon 2006/12/20
    session 管理に memcached を使う事の是非
  • CLON - 2006/11/21 - DBIx::Class vs mysql vs UTF-8

    DBIx::Class vs mysql vs UTF-8 それ、0.7以降(多分)ならconnectionやconnect上書きしなくてもこうかけるよ。 __PACKAGE__->connection( 'dbi:mysql:foo', 'root', { on_connect_do => ['SET NAMES utf8'], }, );

  • MySQL 文字化け問題を本気で直す

    mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char

    cooldaemon
    cooldaemon 2006/10/19
    UTF8対策
  • ウノウラボ Unoh Labs: LVM + XFSで高速簡単 MySQLバックアップ

    こんにちは satoです。 Slaveサーバを運用している場合、MySQLのバックアップファイルが 必要になる場面は少ないです。 しかし、プログラムのバグなどで、データベースレコードの内容が おかしくなってしまい、収集がつかなくり、巻き戻しをする場合などに バックアップファイルがあると、とても便利です。 ということで、LVMのスナップショット機能でMySQLの バックアップにチャレンジしてみました。 ■前提条件 パーティションはこのような感じです ----------------------- sda1 boot ----------------------- sda2 xfs(linuxが入っている) ----------------------- sda3 ここに作る ----------------------- ■構築時 fdisk /dev/sda n #

  • naoyaのはてなダイアリー - MyISAM vs InnoDB

    あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I

    naoyaのはてなダイアリー - MyISAM vs InnoDB
    cooldaemon
    cooldaemon 2006/08/26
    仮説
  • BKCon 2006 - にぽたん研究所

    昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち

    BKCon 2006 - にぽたん研究所
  • mysqlスキル診断

    cooldaemon
    cooldaemon 2006/08/26
    実力診断テスト
  • Tagの検索にMySQLの全文検索を使う : blog.nomadscafe.jp

    Tagの検索にMySQLの全文検索を使う Tags with MySQL fulltextを参考にして試してみた。 Femoの中で、タグの絞り込み機能を実装したのに続いて、「完了」や「finish」と言ったタグがついている場合表示しないというオプションを考えている。 そうなってくると、SQLをどう書けばいいのか、また複雑なSQLを構築したときにパフォーマンスは大丈夫なのかと心配。そこで、上記のURLを参考にしながらMySQLの全文検索に注目。 create table ft_tags( id int unsigned not null auto_increment primary key, tags text, unpack text, fulltext (unpack) ) と言うテーブルを作成。 ここに、 my @tags = ( q/task femo/, q/femo mail t

    cooldaemon
    cooldaemon 2006/08/16
    tag検索