メンテナンスが大変だが、情報があるからなんとかなる。そういう話です。可能か否かであって、コスト量の話はしてない。
ちょっと検索してみれば、MySQLと心中してる感じのブログが多々ありますが、
まず、後述のリンクのブログを中傷するものではないことは強調しておきます。
http://nippondanji.blogspot.jp/2010/03/innodb.html
たった3秒でInnoDBのデータローディングが快適になるライフハック
http://nippondanji.blogspot.jp/2009/03/MySQL7.html
さらにMySQLを高速化する7つの方法
http://nippondanji.blogspot.jp/2009/04/MySQL10.html
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
http://nippondanji.blogspot.jp/2009/05/MySQL.html
限界までMySQLを使い尽くす!!
http://el.jibun.atmarkit.co.jp/garyotensei/2012/07/MySQL-465d.html
MySQLのサブクエリは危険？――深まる謎
MySQLを「使わされて」「困ってる」人にとっては、有用な記事ばかりです。
前述のリンク先の幾つかのTIPSは、非常に役立つものですが、「デフォルトのままでは全く使い物にならない」「標準機能では全く使い物にならない」という事を本質的に意味しています。ですので、小生は断言します。MySQLは「データベースツクール」であることを。ツクール遊びがお好きな人は使えばよろしい。
だってアナタ、大量のデータをアップロードする時には、「正規の手段」のLOAD DATAだと、遅い、というのは周知だと思いますが、その解法がまた酷い。
- CSVストレージで空のテーブルを作成。
- MySQLを一旦落として、CSVデータファイルをすり替える。
- 再起動
- ALTER TABLE ENGINE=InnoDB
忘れちゃいけないのは、MySQLは、「データベースエンジンの選択肢の一つ」もっと下がってみれば「データ保存の手段の一つ」でしかありません。そのために、コレだけの手間暇を掛けるのは、本質的な苦労とは、小生は思いません。
「手段のために手段を選ぶ」のは、プログラマはやってはいけない。これはもちろん小生の持論です。アナタが従う義務は全くありません。故に、MySQL好きな方々が、「喧嘩を売られた」と思う必要は全くありません。
トランザクション＆レプリケーションがあるから、MySQLを使ってる案件は、少なくないと思われます。しかし、リストアに恐ろしく時間がかかり、しかもその回避策の切り札が、前述の裏技だとしたら、課金情報が入ってるテーブルには使いたくない筈。テストしてようがしてまいが。
素のInnoDBは早いらしい。Key Value Storeに匹敵する速度があるらしいです。じゃあなんでデータインポートが遅いのか？
この辺りの「遅い」系の話は、フロントエンドと、ストレージエンジンバックエンドの乖離が本質的問題なのではないかと思います。フロントのSQLパーサ及び、ストレージエンジンのインデックス管理等が、データベースエンジン構造として「遠い」ために、アッサリ性能が落ちるのではないかと。
前述のALTER TABLE式は、バックエンドだけで決着が付きます。故に性能が落ちにくい。多分。
「MySQLをチューニングしなければならない」案件にMySQLを採用するのは間違ってる。と思います。チューニングコストを出せないなら尚更でしょう。
出稼ぎ先では、小生および、もう一人の推しにより、ストレージはMongoDBに移行しつつあります。これまた断言しますが、ソーシャルゲームはもとより、「MySQLで運用できてる案件のほとんどはMongoDBで運用できる」。
もちろん、そのままでは動きません。トランザクションに「頼れない」ですし、色々不都合はあるでしょう。しかしもう、特にソーシャルゲームは顕著ですが「SELECT FOR UPDATEしてりゃなんとかなる」時代ではなくなっています。悠長にレコードロックしてる場合じゃないです。
