現在、このサイトのトップページには「Headline」というコンテンツが表示されています。

今回は、この「Headline」についての技術的なご紹介をさせていただきます。

クロスドメイン制約

このHeadlineでは、弊社が運営する「デジタルカタログ制作のデジパン」のRSSフィードを取得して順番に表示しているのですが、実はAJAXアプリケーションにはクロスドメイン制約というセキュリティ上の制限が設けられています。

そのため違うドメインのサイトから取得したXMLを使用したAJAXアプリケーションは動作しません。

そこで、多くの場合は、PHPやPerl/CGIなどでプログラムを作成して、一度自社サーバー内にXMLをダウンロードしてから、自社ドメイン内のXMLとして処理を行います。
（JSONPと呼ばれる方法などもありますが、これらは相手側の対応が必要です。）

しかし、このサイトではあえてそれらの方法を使用していません。

CrossOverを使用したクロスドメイン

弊社ではCrossOverという小さなライブラリを開発して公開しています。

• サンプルページ
• 配布ページ

このライブラリは、前述のようなクロスドメイン制約を回避するためのライブラリで、ライブラリ内には小さなswfファイル及びJavaScriptが同梱されています。

実は皆さんがアニメーションで目にすることが多いFlashには、crossdomain.xmlで許可された場合のみ、違うドメインからのXMLアクセスを許可するという機能があります。

そしてCrossOverは、この仕組みを利用してFlashによって取得したXMLをJavaScriptに渡すことでクロスドメインによるAJAXを可能にしています。

このCrossOverはオープンソースで公開してから約半年になりますが、おかげさまで1000件以上のダウンロードが行われ、非常に多くのサイトで利用いただいています。

弊社では技術レベルの向上のために、このCrossOverのようなオープンソースへの貢献を非常に重要なものと位置づけています。

今後とも弊社をよろしくお願いいたします。

タイトルをチェックしましょう。

Googleなどの検索エンジンは、ページ内のどこよりもタイトルを非常に重視する傾向にあります。
ですから、タイトルには分かりやすく簡潔なものを指定しましょう。

タイトルには、あまり多くの言葉を入れすぎるとSEO上では逆に不利になります。
少ない単語数の中で、上位に表示させたいキーワードを使用するのがベターです。
また、キーワードはなるべく前の方に入れるとさらにいいようです。

表現を統一しましょう。

例えば、同じ意味を表す言葉が複数サイト内で使用されている場合は、なるべくその単語は同じ表現で統一するようにしましょう。

たとえば。。。

• ホームページ制作（または製作）
• WEB制作（または製作）

などは、全て同じ意味です。

この場合は、ホームページ制作に統一することで、そのキーワードの露出が増えて、検索結果の順位では有利に働きます。

「ホームページを作りました」のような表現も「ホームページを制作しました」のように表現を変えることで、やはり有利になります。

SEOに関係のないキーワードでも、表現の統一は非常に重要です。
Googleは、サイト内で出てくる全ての文章を「わかち書き」という技術で単語毎に分割して、各キーワードの露出頻度を検索結果の順位に反映しています。

したがって、表現を統一することで全体のキーワード数が減少しますので、SEO対策を行いたいキーワードの比率が上がり、検索順位に有利に働きます。

すべてのページに貴社の連絡先をいれましょう。

多くの中小企業は営業エリアが、一部の地域に限られます。
その場合は、貴社住所を全てのページにいれることで、「地域名＋キーワード」というような検索で上位に表示されるようになります。

リンク先をチェックしましょう。

Googleが検索順位の決定にリンク先がどれぐらいあるかを重視しているのはとても有名です。

しかし、いくらリンクしてくれていても、そのリンク先がGoogleに登録されていなければ、全く意味がありません。

そんな時は、そのサイトのオーナーに変わって、検索エンジンに登録されるように各検索エンジンに推薦してあげましょう。

ブログを有効活用しましょう。

Googleが検索エンジンの順位の決定に、リンク先がどれぐらいあるかを重視しているのは、前述の通りです。

実はその中でも、ブログサイトからのリンクをGoogleは非常に重視しています。

ですから、ぜひスタッフブログや社長ブログなどを積極的に開設して、そちらでも自社のPRを行うことをおすすめします。

最後に

基本的なことばかりですが、弊社の経験では実はこれらの対策だけでも非常にいい結果が出ることが多いのが事実です。
どれも費用をかけること無く対策可能なことばかりですので、ぜひお試しください。

弊社にもいろいろなお客様から問い合わせをいただくのですが、長期間にわたって費用を頂かなくても、ご自身でやって頂いた方がより良い結果を招くことも多いようです。

今回は、企業のウェブマスターが、すぐにできるSEO対策の基本的な手法を専門用語無しでご説明します。

なによりもキーワードの選定を！

いくらSEO対策を行って上位に表示されても、キーワードを間違えたら肝心の受注も問い合わせも増えません。

SEOではキーワードの選定が最も重要な作業です。

弊社の場合、キーワードの選定には、「スポンサードサーチ」を使用しています。

この「スポンサードサーチ」は、オーバーチュアという広告サービスを利用する際に、どのキーワードで広告を出すかを検討するために使用するためのツールです。

しかし、実際に広告を出さなくても利用可能で、このツールを使うことで以下のことを推測可能です。

• Yahoo japan等の検索エンジンでのそのキーワードの検索頻度
• Yahoo japan等の検索エンジンでのそのキーワードと同時に検索される第二キーワード

たとえば、美容院の予約を増やしたい場合。。。

美容院を指すキーワードとして、「美容院」「美容室」「ヘアサロン」の３つが上げられます。

３つのキーワード全てに対してSEOを行うことは困難なので、どのキーワードを使用するべきか？ということを検討する必要があります。
その際に、上述のツールはとても便利です。

作業の流れとしては、「オーバーチュアで入札したいキーワードの月間検索数を調べる」入力ボックス内に「美容院」「美容室」「ヘアサロン」の３つのキーワードをそれぞれ一つずつ入力します。

そして、その両方を穴があくほどよく見て比較すると、以下のことが推測できます。

「美容院」「美容室」「ヘアサロン」での比較結果

「美容院」「美容室」ともに８万回検索されているが「ヘアサロン」は２万回弱しか検索されていないので、ヘアサロンというキーワードにSEO対策を施すことはあまり意味が無い。

「美容院」と「美容室」の第２キーワードを比較した場合に、「美容室」の第二キーワードは業界の人らしきキーワードが目立つ。
実際に「美容院＋求人」「美容室＋求人」で比較すると５倍ほど美容室のほうが多い。

このことから、一般の人は「美容院」、業界の人は「美容室」と検索することが多いことが予想される。

その美容院が東京にある場合、「美容院＋東京」「美容室＋東京」の両方で検索頻度を調べると、「美容室」検索頻度が４倍くらい多い。
なぜか東京都周辺だけは美容室というキーワードで検索されるほうが多いことが予想される。

以上のことから、

１．東京の美容院なら、「美容室」
２．他の地域なら「美容院」
３．できれば求人も増やしたい場合は、「美容室」

という結果を導き出すことができます。

キーワードが決まったら実際に検索してみましょう

対象キーワードの候補が決まったら、実際にそのキーワードで検索してみましょう。
もし、検索結果が１００万件以内ならチャンスです。

今後ご紹介する対策を行えば、弊社の経験では５０位以内はほぼ確実に。
２０位以内でもかなりの確率で表示させることが可能です。

もしライバルが１００万件以上なら、第二キーワードに貴社サービスエリア等を加えてみましょう。
その結果が１００万件以内であるなら、やはりチャンスであるといえます。

キーワードの選定まとめ

キーワードの選定方法はご理解いただけましたか？
弊社では、さらに突っ込んだ方法でキーワードの選定を行っています。
興味のある方はぜひお問合せ下さい。

いよいよ、実際のSEO対策を貴社サイトに施すわけですが、今回はとりあえずここまで。
続きは、来週公開致します。

このコラムでは、そんな誤ったSQL文とその改善方法をご説明します。

チューニングのポイント

• explain analyzeを使用してSQLのベンチマークを行う。
• インデックスの有効活用。
• max()、count()などの関数に注意。
• limitの活用。
• その他のポイント

explain analyzeを使用してSQLのベンチマークを行う

弊社の経験では、パフォーマンスに問題が生じるのは、運用開始後しばらくたってからのことです。

多くの場合、開発時点ではテスト用データの件数が実運用時の件数よりも圧倒的に少なく、十分にSQL文の検証が行われないまま実運用に入ってしまい、パフォーマンスに問題が生じるというパターンが多いのが実情です。

しかしながら、データ件数の少ない状態でも開発時点でSQL文にベンチマークを行えば、パフォーマンスに関する問題を事前に察知することが可能です。

ベンチマークの方法

ベンチマークは、psqlコマンドでデータベースに接続した後、実際に実行したいSQL文の前にexplain analyzeをつけて実行してやることで可能です。

EXPLAIN ANALYZE select ac_id from tbl_access_log order by ac_id desc limit 1 offset 0;

上記の例では、select以降（小文字の部分）が実際のSQL文です。

結果は、以下の通りとなります。

Limit (cost=0.00..0.52 rows=1 width=4) (actual time=0.490..0.502 rows=1 loops=1)
-> Index Scan Backward using tbl_access_log_pkey on tbl_access_log (cost=0.00..15603.39 rows=30083 width=4) (actual time=0.448..0.448 rows=1 loops=1)
Total runtime: 0.675 ms
(3 rows)

出力内容の全てをご説明することはここでは避けますが、Total runtime: 0.675 msというのが、クエリーを実行する際にかかる時間、Index Scan…という記述が「インデックスが使用されましたよ」という意味です。

このIndex Scanの記述の当たりに、Seq Scanという記述がある場合は、インデックスが使われておらず全てのデータを検索したということであり、実運用に入った際にパフォーマンスが低下する原因となります。

インデックスの有効活用

パフォーマンスの問題が発生するシステムの多くは、インデックスが十分に活用されていません。
せっかく設定してあるのに、SQL文が適切でないためにインデックス自体が使用されていない場合や、インデックスの設定が不十分であるケースが多く見受けられます。

インデックスが適切に設定されたデータベースは、目次から目的のページを探すのと同じようにダイレクトに目的のデータを探すことができます。

一方で、インデックスが適切に設定されていないシステムは、索引の無い辞書から知りたい単語を探すのと同じで、目的のデータであるかどうかを確認するために全てのデータを検索対象とします。

初心者プログラマの多くは、SQL文中のWHERE句に指定するフィールドにのみインデックスを設定しますが、これでは不十分です。

実際には、PostgreSQLは、Order BYに指定する列などに対してもインデックスを使用してくれます。

SQL文例

EXPLAIN ANALYZE select * from tbl_access_log order by ac_os;

インデックスを使っていない場合

Sort (cost=76542.51..76618.37 rows=30345 width=2018) (actual time=3610.709..4261.375 rows=30345 loops=1)
Sort Key: ac_os
-> Seq Scan on tbl_access_log (cost=0.00..1413.45 rows=30345 width=2018) (actual time=0.229..819.466 rows=30345 loops=1)
Total runtime: 5538.514 ms

インデックスを使った場合

Index Scan using tbl_access_log_ac_os on tbl_access_log (cost=0.00..15781.13 rows=30345 width=2018) (actual time=0.771..736.737 rows=30345 loops=1)
Total runtime: 1262.557 ms

上記の結果からクエリーに要する時間が1/4に減ったことがわかって頂けるとおもいます。

ちなみに、この例で使用したSQLでは、＊（アスタリスク）を使用していますが、アスタリスクを使用せず、必要なフィールドのみを指定してやれば、飛躍的なパフォーマンス向上を得られます。

max()、count()などの関数に注意

今回の例で使用しているテーブルは、某地方公共団体向けのCMS内のアクセスログの保存用のテーブルです。
このテーブルには現時点で３万件のデータが保存されていますが、これは実運用下では数日で到達するデータ数です。

アクセスログのようなシステムでは、総アクセス数などのように、しばしばデータの件数が必要となります。

じつは、このSQL文にも多くのプログラマが陥る罠があります。

count()やmax（）は使うべからず

select count(*) from tbl_access_log;

上記のSQL文は、専門書等で普通に解説されているクエリーですが、これは多くの場合間違いです。

ベンチマークの結果を見てみましょう。
Aggregate (cost=1489.32..1489.32 rows=1 width=0) (actual time=1171.802..1171.815 rows=1 loops=1)
-> Seq Scan on tbl_access_log (cost=0.00..1413.45 rows=30345 width=0) (actual time=0.277..624.437 rows=30345 loops=1)
Total runtime: 1172.176 ms

count関数は、全てのデータを単純に見に行きますので、インデックスは一切使われません。
したがって、このままでは、データが増えるに従ってSQLの実行時間も長くなります。

この場合は、このテーブルに主キーフィールドとしてオートナンバーの列を追加してやり、その最大値を求めれば、パフォーマンスが向上します。

しかし、ここにも罠があります。

select max(ac_id) from tbl_access_log;

実は、PostgreSQLはmax()を使用した場合にも、すべてのデータを見にいってしまいます。

Aggregate (cost=1489.32..1489.32 rows=1 width=4) (actual time=1188.998..1189.015 rows=1 loops=1)
-> Seq Scan on tbl_access_log (cost=0.00..1413.45 rows=30345 width=4) (actual time=0.599..632.781 rows=30345 loops=1)
Total runtime: 1189.337 ms

正しいSQL文は以下の通りです。

select ac_id from tbl_access_log order by ac_id desc limit 1 offset 0;

上記の例では、単純に最大値をとるという意味ではなく、ac_idを逆順にソートしてその１行目だけをとるという方法で、総アクセス数を取得しています。

その結果は。。。
Limit (cost=0.00..0.52 rows=1 width=4) (actual time=0.140..0.153 rows=1 loops=1)
-> Index Scan Backward using tbl_access_log_pkey on tbl_access_log (cost=0.00..15710.13 rows=30345 width=4) (actual time=0.110..0.110 rows=1 loops=1)
Total runtime: 0.287 ms

SQLの実行時間が1/6000に減ったことがお分かりいただけましたか？

このように、PostgreSQLでは、一見便利そうに見える関数が、実はパフォーマンスに非常に大きな悪影響を与えることが多いことがお分かりいただけたと思います。

limitの活用

SQL文のパフォーマンスのポイントは、いかに対象とするデータを減らすかです。
そういう意味で、インデックスを活用すると、目次から直接ページを開くようなイメージでデータを取り出すことができますので、とても高速に処理を行うことができます。

そしてもうひとつ、簡単に大きな結果を得られるのがlimitです。

先ほどの例で使用したSQLを再び。
select ac_id from tbl_access_log order by ac_id desc limit 1 offset 0;

上記のSQLにもlimitが使用されています。
しかしながら、単純に最大値をとるだけなら、limit 1 offset 0の部分は無くても同じ結果が得られます。

ところが、このlimit 1 offset 0を消してみると、結果の値は同じでもパフォーマンスには大きな開きが出ます。

EXPLAIN ANALYZE select ac_id from tbl_access_log order by ac_id desc;

実行結果
Sort (cost=3672.51..3748.37 rows=30345 width=4) (actual time=1762.159..2307.664 rows=30345 loops=1)
Sort Key: ac_id
-> Seq Scan on tbl_access_log (cost=0.00..1413.45 rows=30345 width=4) (actual time=2.222..789.455 rows=30345 loops=1)
Total runtime: 2868.611 ms

なんと、インデックスが使用されなくなり、SQLの実行時間が１万倍にはねあがりました。

SQLのパフォーマンス向上のツボは、いかに取得するデータを必要最小限に留めるかにつきます。
WEBアプリケーションでは、１ページあたりに表示するデータの行数には必ず限りがありますので、忘れずにlimitを使用するように心がけましょう。

その他のポイント

上記以外にも書籍等で普通に紹介されている記述が、パフォーマンス上大きな悪影響を及ぼす事例があります。

• ＊（アスタリスク）を使用している。
  ＊は使わずに必要な列を指定した方が、確実にパフォーマンス向上につながります。
• ORを使用している。
  ORを使用すると複合インデックスが使用されませんので、代わりにexists等を使うよう工夫することで劇的な改善が可能です。（PostgreSQL8.xでは改善されています。）
• 前後方一致検索を行っている。
  可能な限り避けた方がいいのですが、難しいことも多いでしょう。
  NamazuとPostgreSQLを連携させることも可能なので、予算に余裕があれば挑戦するといいかもしれません。
• in()の中でのサブクエリーの使用
  これは、PostgreSQL7.xの仕様ですが、極端にパフォーマンスが低下します。
  PostgreSQL8.xでは改善されています。
• 日付の評価に＜や＞を使っている。
  この場合もインデックスが使用されません。期間などの指定にはbetweenを使用した方が遥かに高速です。

以上、PostgreSQLの、SQLのチューニングによるパフォーマンス改善についてご説明しました。

上記であげた事例は、どれも数百〜数千倍単位でパフォーマンスが向上します。
ぜひ、お試しください。

なお、弊社では、既存のシステムのSQLチューニングのご注文も承っておりますので、ご興味があればご相談ください。