Mahmoud SAKR
Mahmoud SAKR université libre de bruxelles
Esteban Zimányi
Esteban Zimányi ULB
11:40 03 March
90 мин

Managing moving objects data with MobilityDB

MobilityDB is a moving object database extension to PostgreSQL and PostGIS. It has types and functions for storing an querying geospatial trajectories, as first class citizens. The main type is called tgeompoint (temporal geometry point). It represents a complete movement track of a geometry point, such as a car, a bird, or a person. The function speed(tgeompoint) computes the time varying speed of the object, as a tfloat (temporal float). Similar to these examples, MobilityDB has 6 temporal types, and over 300 functions. As such, it is a function-rich platform for Mobility Data Management.

In this tutorial you will:

  • learn about moving object databases
  • write MobilityDB SQL queries and explore a database of geospatial trajectories
  • walk through the different type, indexes, and functions of MobilityDB.


Другие доклады

  • Pavel Borisov
    Pavel Borisov Postgres Professional
    45 мин

    Speed up your fast text search queries with RUM index

    Fast text search queries can be made even faster with indexing on lexemes inside compound records of tsvector format. RUM index is an open-source PostgreSQL extension. It represents a big improvement of GIN index and it can index lexemes with additional information e.g. tsvector lexeme weight-mark. So it can support tsvector capabilities more.

    Until recently it was needed to recheck results of weight-containing queries by table. My modification (2020) is to make the processing of this kind of queries index-only and therefore much faster.

    Also, I will describe and provide benchmarks for different usage cases for fast text search. We'll see how RUM index can improve the performance and compare it with PostgreSQL internal GIN index.

  • Christopher Travers
    Christopher Travers DeliveryHero SE
    45 мин

    When it All Goes Wrong: Database Incident Response Dos and Don'ts

    Once at Adjust we faced a problem of impending xid wraparound in a very central database due to a long-stalled autovacuum run. Because we spotted warnings 5 hours before impending disaster we were able to minimize the customer impact. Come learn how we used the time to prepare, and what lessons this has for others facing unusual problems in large databases.

  • Alexander Nikitin
    Alexander Nikitin ЗАО ЦФТ
    22 мин

    Pitfalls we face when cloning and transferring PostgreSQL databases & clusters

    Cloning and transferring PostgreSQL databases & clusters often looks simple.

    However, you can get confused while performing these simple operations, too. During my presentation, I will explain which pitfalls you may face while cloning and transferring PostgreSQL databases & clusters. We'll see what can be done to improve the performance of these operations and list the unexpected issues that arise while performing these seemingly simple operations.

  • Arseniy Sher
    Arseniy Sher Postgres Professional
    45 мин

    Consensus, Postgres, Multimaster

    Postgres Pro Multimaster is Postgres extension (and a set of core patches) providing high availability (HA) with strong consistency and read scalability. It forms symmetric shared-nothing cluster synchronously replicating the data and automatically performing disaster recovery. During the last year we've put significant efforts ensuring and proving that consistency is preserved in all scenarios. The new version, which will be released as part of Postgres Pro Enterprise 13 uses Paxos algorithm for determining transaction outcome and custom protocol governing the recovery process; we used TLA+ model checker to verify its correctness. I'll tell how these things work and why in some cases multimaster may be an attractive alternative to the traditional streaming replication based HA deployments.

    multimaster is now open source, available at https://github.com/postgrespro/mmts

    To make the talk less narrow specialized and more appealing to the wide audience, in the first part I will shed some light on how generally modern DBMSs (mostly so-called NewSQL) handle fault tolerance. In particular,

    • what is a strongly consistent DBMS and the associated overhead;
    • what is distributed consensus, Paxos, Raft;
    • how they help here;

    I won't do an attempt to explain any algorithms line-by-line; it would be hardly useful given the time frames and there is a lot of literature available anyway. The goal is rather to waymark the field and get you a bit comfortable there.