A ‘movingpoint’ type for a DBMS

1. A ‘movingpoint’ type for a DBMS Wilko Quak - TUDelft

2. Overview • Clarification • Design considerations for movingpoint type • Implementation in MonetDB Moving Point Type

3. 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

4. Examples ofmoving pointsdata Moving Point Type

5. 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

6. 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

7. 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

8. Things that should be efficient • Range queries in time • Range queries on location • Nearest neigbour search (Fréchet distance) • Joins Moving Point Type

9. 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

10. MonetDB A novel spatial column-store DBMS Martin Kersten - CWI Niels Nes - CWI Wilko Quak - TUDelft Maarten Vermeij - TUDelft

11. 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

12. MonetDB - Physical data organization • Binary Association Tables Moving Point Type

13. MonetDB product family End-user application XQuery SQL PHP JDBC ODBC Python Perl C-mapi lib MAPI protocol Monet kernels Moving Point Type

14. MonetDBheaplayout Moving Point Type

15. Redundancy This can be compressed away in heap structure Moving Point Type

16. 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

17. 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

18. MonetDB extension mechanism for types Moving Point Type