[erlang-questions] Getting attributes

[Dmitry Kolesnikov]

Toby,

Unfortunately, composite index on (x,y) does not give you an optimal performance due to B-Tree index nature. Any (x,y) proximity requests are converted into random disk I/O because B-Tree clusters data first component  and then by second. This is a reason why z-order curve were invented. It allows to fit spacial data into B-Tree index and provide you sequential disk I/O for proximity queries.

- Dmitry 


On Oct 14, 2012, at 8:31 PM, Toby Thain wrote:

> On 14/10/12 2:55 AM, Dmitry Kolesnikov wrote:
>> Yes,
>> 
>> You can use z-cuve to handle it within key/value store.
>> http://en.wikipedia.org/wiki/Z-order_curve
>> 
>> alternative approach, is R-tree but 64k-by-64k might be too much to keep it in-memory. Therefore, MySQL + RTRee index should help you.
>> 
> 
> If using a relational database, spatial indexing is not required. Simple tuples are quite enough, just put a composite index on (x,y) since all fetches are (constant,constant). And you can get all neighbours in a single statement.
> 
> --Toby
> 
>> 
>> - Dmitry
>> 
>> On Oct 14, 2012, at 2:23 AM, Steve Davis wrote:
>> 
>>> Hi all,
>>> 
>>> Suppose I have a 2 dimensional plane {x, y} of 64k by 64k coordinates.
>>> 
>>> Each coordinate has a mutable attribute {{x, y}, attribute}
>>> 
>>> If I need to query: What are the attributes of positions "next to" my position, i.e: x +- 1, y +- 1?
>>> 
>>> What is the correct solution to this without storing everything in "Oracle" and using relational queries?
>>> 
>>> Can this be sensibly maintained in a KV store?
>>> 
>>> /s
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>