_ スケーラビリティとミニマムの負荷 旧バージョンはDBのselectクエリーは分散できるものの、それ以外は分散がほとんど効かないような設計だった。今回はアプリケーションサーバーもDBサーバーも単純に追加できるような設計にしてみたんだけど、そういう設計だとミニマムでの負荷はどうやってもある程度ベタに書いた設計よりも高くなってしまうなー。 すでに現段階で結構な手数を高速化（大量に呼び出されるurlForをベタに書き直したり、エスケープ処理の呼び出しにかかるコストを下げたりとか、とか）に費やしているんだけど、それでも1台増やしたサーバーがぱんぱんだ。DB負荷対策のためにメモリを増やしておいたんだけど、ロジックに費やす
_ MM/Memoからのインポート MM/Memoからのデータインポートスクリプトを作って、試しに自分のメモをインポートしてみた。MM/Memoではできなかった*1解析とか検索とかがまっとうに動くので結構楽しい。 MM/Memoユーザーの方で、自分のデータもリニューアル開発テスト版の方にインポートして欲しい方は、リニューアル開発テスト版の方にアカウントを登録した上で、MM/MemoのユーザーID（数値）とリニューアル開発テスト版のアカウント名（英数字）を教えてください（ここのコメントにお願いします）。 ちなみに対応するのはURLとASINに関するメモのみで、位置情報（互換性がなくなった）やテレビ番組情報（リニューアル版では取り扱っていない）はインポートできません。あと、URLに関しては古いデータだとすでに情報が取れないURLも結構たくさんあるみたいです。 データがある程度そろった状態じゃな
_ 街区レベル位置情報＋郵便番号データ 次期MM/Memoというか1470.郵便番号→住所→位置情報とかが手軽に変換できるように、街区レベル位置参照情報と郵便番号を合成してみている。 主データとしては、街区レベル位置参照情報の方を利用する。というのは、郵便番号の方は位置情報ではなく、郵便の都合で区分けされているんで、より位置情報のキーとして使いやすそうなのは街区レベル位置参照情報の方だから。 街区レベル位置参照情報は「丁目」よりも細かい「街区符号・地番」レベルの情報も持っているけれども、そこまで扱うと 住所情報としてのセンシティブさが増しすぎる 郵便番号情報との粒度の違いも大きくなりすぎる AjaxとかでがんがんDBを叩くにはデータサイズが増えすぎるだろう という理由で、データとしては「丁目」レベルまでを扱い、それ以下は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
