Blogサイトでもときどき棚卸しを行う。
これは、全エントリをテキスト形式でダウンロードし、エディタで検索置換をかけながら、全体的に整理整頓を行うのである。
各エントリによっては、書き込む手段がectoであったり、iPhoneであったり、Webからであったり、さまざまで、とくにイメージの保存場所を間違えてしまうこともあるので、その際に全てblog/images/ へなるように整えたりもする。
また、あり得ないことだが、全角英数を使っていたり、データの洗濯もエディタなら簡単にできるのである。
現在のところ全エントリ720程度、テキストファイルにして2.5MB程度である。
このサイズでもMTからの書き出しはスムーズに行っても、逆に読み込みにはしばしば失敗する。
昔からデータベースエンジンと扱うデータ量の関係は問題になっていて、初期値が快適でも数千レコードで使い物にならないほど遅くなる物もあった。
私のMTの場合はSQLiteを使用しているが、サーバとの相性もあったり、処理のスピードと安定性には悩まされるところである。
エントリの数が多いので、ただでさえテキスト形式からSQLiteのDB形式へのコンバートに時間が掛かるらしく、ネットの向こう側のサーバの能力に影響される。
ロリポのサーバはそもそもMTの処理には遅いらしいので、MT3.3であっても一気に全エントリアップではしばしば失敗することになる。
ネットの向こう側の処理なので、なんとなく靴の上から足をかいている感触で何とかならないかと思っていた。
それで、ふと気づいて、せっかくローカルで、サイトのデザインやプログラムテストをMAMPで行っているので、まとまったテキストファイルからDBファイルへのコンバートして、アップできない物かと考えた。
さすがに、XMLの生成と再構築は、ネットの向こう側で行うつもりだし、そうすべきだと思っているが、DBファイルへのコンバート処理はしばしば失敗しているので、この方法でうまく行けば今後のエントリ大量増加にも、対応できるようになる。
本当に、エントリの増加に対するメンテナンス方法には頭を悩ませる。
まぁ再構築のようにたとえ遅くても、放っておけば数時間後に確実に終了してもらえるならよいのだが、読み込んでいるフリをしながら、その実止まっているという事だけは勘弁願いたいと思うのである。
サーバ上のDBファイルのありかをさがしたが、どうやらユーザの扱えない場所で管理されているらしく、この件は断念。
使いこなしでは、まずは全エントリをテキスト書き出しをして、エントリ管理リストから最新の100エントリを削除して、書き出したエントリから最新100を残してあとは削除。
メンテナンス後に100エントリをアップするという方法が面倒だけど、スムーズに運ぶのではないかと今は考えてる。
コメント