Re:Mireo SpaceTime – an absurdly fast spatiotemporal database
by kindkid on Friday April 24, 2020 @11:11AM
(#22968800)
Very cool! I'm particularly interested in this section:
> SpaceTime database is built on a unique, multidimensional data index that automatically adapts to mutable and possibly highly skewed data distribution (which is usually the case with data coming from moving objects). There is one single multi-columnar index which indexes all associated columns of records at once. There are no secondary indices!
> The physical model intertwines index and record data – as a consequence, records that are logically close (based on id, position and timestamp) are at the same time also physically close. In turn, this maximizes the throughput of disk reads.
> The main ideas for inventing SpaceTime index came from several inspiring scientific papers. It is similar to the kd-tree family of indices, but with two major improvements: first, the index tree in SpaceTime is built using the bottom-up approach (as opposed to the top-down kd-tree construction) and second, the process of index creation adapts to particular space-time distribution of data. Kd-trees work well on a large scale only with static datasets; our bottom-up approach overcomes this.
Can you provide links to the scientific papers that were mentioned?
Are there any plans to publish a more detailed description of SpaceTime's index data structure and algorithm?
Re:Mireo SpaceTime – an absurdly fast spatiotemporal database
by miljen on Saturday April 25, 2020 @02:46AM
(#22976197)
Hi, thanks for the interest! Yes, we are planning to publish more details about the novel index structure, so feel free to visit https://blog.mireo.hr/ every 2 weeks.
Very soon we will also launch a live demo with 200,000 vehicles, so you'll be able to try SpaceTime capabilities on your own :)
Re:Mireo SpaceTime – an absurdly fast spatiotemporal database
by miljen on Tuesday April 21, 2020 @05:05AM
(#22933253)
Of course. MSQL queries can be as simple as "select * from st.trips", but can also include geospatial functions that we implemented and that are not part of standard SQL:
"select vid, sum(sphere_length(x[0], y[0], x[1], y[1])) as mileage
from st.segments
where
ST_Intersects(
ST_GeomFromText('POLYGON ((11955008 38520960,11995328 38530624,11998976 38531456,11955008 38520960))'),
ST_Line(x[0], y[0], x[1], y[1])
)
and t[0] >= 1569888000 and t[1] < 1572566400 and vid >= 3200 and vid <= 3300
group by vid"
Actually, a query very similar to the one listed above generates the report mileage-in-area mentioned in the blog.
> SpaceTime database is built on a unique, multidimensional data index that automatically adapts to mutable and possibly highly skewed data distribution (which is usually the case with data coming from moving objects). There is one single multi-columnar index which indexes all associated columns of records at once. There are no secondary indices!
> The physical model intertwines index and record data – as a consequence, records that are logically close (based on id, position and timestamp) are at the same time also physically close. In turn, this maximizes the throughput of disk reads.
> The main ideas for inventing SpaceTime index came from several inspiring scientific papers. It is similar to the kd-tree family of indices, but with two major improvements: first, the index tree in SpaceTime is built using the bottom-up approach (as opposed to the top-down kd-tree construction) and second, the process of index creation adapts to particular space-time distribution of data. Kd-trees work well on a large scale only with static datasets; our bottom-up approach overcomes this.
Can you provide links to the scientific papers that were mentioned?
Are there any plans to publish a more detailed description of SpaceTime's index data structure and algorithm?
Very soon we will also launch a live demo with 200,000 vehicles, so you'll be able to try SpaceTime capabilities on your own :)
Actually, a query very similar to the one listed above generates the report mileage-in-area mentioned in the blog.