2

Webアプリケーションで使用したい約2,000万行のCSVファイルがあります。データは、郵便番号と実際の住所を次の形式でマッピングしたものです。

[zip_or_postal_code] [street_number] [street_name] [city] [state_or_province] [country]

私の目標は、ルックアップ（郵便番号/郵便番号で検索）を200ミリ秒未満に保つことです。

これが違いを生むかどうかはわかりませんが、私は次のことを計画していました。

  • 、、、および列を独自のテーブルに移動しstate/province、プライマリテーブルの列を参照して、不要な肥大化を回避します。countrycity
  • 一部の郵便番号は複数の番地と住所をカバーしているため、データを統合して1つの郵便番号を取得し、varcharなどに複数の住所を格納します。これにより、テーブルから数百万行が削減されます。

ルックアップ速度を向上させるために行うことができるいくつかの最適化は何ですか？例として、Googleの逆ジオロケーションAPIは、HTTPオーバーヘッドを含めて300ミリ秒未満の結果を返します。どうやってやっているの？

また、私は他のデータベースを使用することもできますが、すでにMySQLを使用しているので、それが望ましいでしょう。

編集：検索は常に郵便番号/郵便番号で行われるため、例として：郵便番号12345を指定すると、通り番号/名前、都市、州、国を返す必要があります。ただし、通りの番号/名前は単一の文字列フィールドとして保存されるため、私のアプリがそれらの解析を処理します。

4

1 に答える 1

9

MySQLの場合、2,000万行はそれほど多くありません。郵便番号にインデックスを付けるだけで、高速になります。200ms未満の速さ。テーブル間で分割する必要はありません。結果セットが大きい場合、MySQLは遅くなりますが、その問題が発生することはないようです。MySQLは、あなたのような基本的なクエリの何億ものレコードでうまく機能します。

より多くのメモリを使用するようにMySQL設定を調整する必要があります。デフォルト設定はかなり低いです。

MySQLは空間インデックスをサポートしています。したがって、郵便番号の経度/緯度を取得し、空間インデックスを使用して近接検索を実行できます。あなたがそれを探しているようには見えませんが。

本当に、本当に速く物事が必要な場合は、考えていたルートに進みますが、memcacheまたはredisを使用します。郵便番号をルックアップキーとして使用できます。データをロードするには、永続的なディスクベースのデータストアが必要です。memcache / redisは必要ないと思いますが、それはオプションです。

于 2013-01-12T02:15:04.903 に答える