Download
1 / 18
180 likes | 186 Views
This article provides an overview of moving point types in DBMS, discussing design considerations, implementation options, and efficiency considerations. It also explores the use of MonetDB as a suitable option for implementing moving point types.
E N D
A ‘movingpoint’ type for a DBMS Wilko Quak - TUDelft
Overview • Clarification • Design considerations for movingpoint type • Implementation in MonetDB Moving Point Type
Moore’s Law makes some problem go away 50% p/year: - cpu speed - mem size - mem bandwidth - disk bandwidth #points in laser scan #available GPS logs 1% p/year: - mem latency 10% p/year: - disk latency #cadastral parcels Moving Point Type
Examples ofmoving pointsdata Moving Point Type
What do I want with the data? • Can I find all occurences of missing data because someone used subway? • What is the optimal distance between busstops to get people to the trainstation as fast as possible? • Is that man smiling? • Flocks and other patterns? • More……? Moving Point Type
Requirements • Should work with all kinds of data • Should be extensible (to moving region, or dynamic integer??? (orthogonal?)) • Queries should be understandable • Should work seamlessly together with point/line/polygon + datetime • I want to store my original measurements in a reproducably and compact way Moving Point Type
Two possible mappings of movinpoint type to DBMS: This is ortogonal but requires a highly extensible DBMS to implement create table person( name string, location point dynamic continuous, salary integer dynamic discrete); create table person( name string location movingpoint); This is not that bad and is easier to do in existing DBMS Moving Point Type
Things that should be efficient • Range queries in time • Range queries on location • Nearest neigbour search (Fréchet distance) • Joins Moving Point Type
Debatable Issues • What to do with accuracy. (Current implementations of point line an polygon don’t have it. Do we miss it?) • More interpolation types than: linear or constant. • Do we want a multi-scale type? Moving Point Type
MonetDB A novel spatial column-store DBMS Martin Kersten - CWI Niels Nes - CWI Wilko Quak - TUDelft Maarten Vermeij - TUDelft
MonetDB design considerations • Multi-model database kernel support • Extensible data types, operators, accelerators • Database hot-set is memory resident • Simple data structures are better • Index management should be automatic • Do not replicate the operating system • Optimize when you know the situation • Cooperative transaction management Moving Point Type
MonetDB - Physical data organization • Binary Association Tables Moving Point Type
MonetDB product family End-user application XQuery SQL PHP JDBC ODBC Python Perl C-mapi lib MAPI protocol Monet kernels Moving Point Type
MonetDBheaplayout Moving Point Type
Redundancy This can be compressed away in heap structure Moving Point Type
Implementation options for heap structure 1. Implement as BLOB with x1,y1,z1,t1,x2,y2,z2,t2,… • Similar to polyline implementations. • Index with rtree index on x,y,z,t • Is reasonably efficient for small objects. 2. Build a kinetic structure in the heap • Will be efficient for querying • Compression schema might be tricky Moving Point Type
Conclusions / Discussion • DBMS support for multipoints will make querying collections of moving points easier and more efficient. • MonetDB looks like a good option for implementation. Moving Point Type
MonetDB extension mechanism for types Moving Point Type
