1

問題：

数百万 (10 以上) のマーカーがあり、それぞれにさまざまなフィールドがあります。

 1. lat 
 2. lng   
 3. area (double)
 4. size (int)
 5. tolerance (double)
 6. lags (boolean)
 7. channel (boolean)
... (more)

ここで、各クラスターに次の集計データが必要です。

 1. number of markers
 2. min area
 3. max area
 4. avg area
 5. min size
 6. max size
 7. avg size
 8. tolerance distribution (how many where of tolerance < X, other >=X < Y and >=Y <Z where X,Y,Z constants)
 ... (more)

クラスターは、マーカーの緯度経度 (距離) とズーム レベル (int) に基づいて作成されます。

問題のない部分(**):

条件「all-in」に関係なく、すべてのズーム レベルのクラスターを計算します。これはツリーを作成することによって行われ、ユーザーのクラスターのフェッチは簡単です。

今問題のために：

ユーザーはマーカー フィールドに基づいてクエリを実行できます。たとえば、「エリア > K およびラグ = true のすべてのマーカーを表示する」などです。このクエリだけでも、まったく新しいクラスター ツリーを作成する必要があります。彼がクエリを変更すると、「その領域が K.0001 を超え、lags=true であるすべてのマーカーを表示する」と新しいツリーを作成する必要があります。すべてのユーザーのクエリに対してそのようなツリーを計算したり、メモリ内に保存したりしたくありません (可能かどうかはわかりません)。

質問：

What approach should be taken?
given the complexity of calculation X # of markers 
(fields inside) X speed factor. 
I was thinking that there's some sort of way to use  the 
"all-in" clusters calculation(**), as it gives me ALL the markers and clusters and from 
there to manipulate in some elegant way.

意思：

 - space-filling-curve (hilbert) can help? how?  
 - DB approach (what DBand why?)
 - k-d tree ?

全体的なアイデアは、大量のデータと計算を事前に処理して、ユーザーが自分の側またはサーバー側で計算せずに操作できるようにすることです (したがって、クライアント側のクラスタリングはソリューションではなく、融合テーブルも同様です)。

コードサンプルは大歓迎です。

4

1 に答える 1

0

Hadoopは、オンライン（「ライブ」）操作ではなく、前処理に適しています。

ヒルベルト曲線とkd木は、通常のグリッドファイル/四分木よりも複雑で、実際にはあまり役に立ちません。視覚化ズームレベルに正確に一致するようにツリーを最適化します。そうすれば、「クラスタリング」をまったく行わずに逃げることができますが、適切な四分木セルを視覚化するだけです。

結局のところ、空間データは2Dしかないため、すべての2Dメソッドは問題なく機能します。そして、地球はサイズを変えないので、あなたは値の範囲をよく知っています。これが、Googleマップがこれほど高速である理由です。キャッシュ、効率的な提供、事前生成が可能な固定タイルを使用しています。

おそらくACIDとトランザクション、およびこれらの高度な機能は必要ないことを考えると、誇大宣伝されているNoSQLデータベースの1つを使用することは合理的と思われます。

于 2012-07-31T10:37:54.220 に答える