Ticketing system service composed of three layers:
-
Client: Single Page Application made using AngularJS
-
Server: Server Side Application exposed over http made using Spring Boot
-
Database: PostgreSQL
Everything runs inside Docker containers, linked together with Docker Compose. As Analytics framework, the Elastic Stack has been used by sending data of interest to Elastic Search, through Logstash, and querying and analyzing it with Kibana.
-
Install docker, docker-compose and git
-
Clone this repo:
git clone https://github.com/chrisPiemonte/Fixture.git
cd Fixture/
-
Run:
docker-compose -p fixture up -d
-
Open a web browser and go to
http://localhost:8080
-
Kibana
http://localhost:5601
-
To populate the Database go to
http://localhost:8080/api/populate
(it takes a while)
AFC United | |
AFC United is a football club that host matches (also known as Fixtures) against an opposing team. A database is required by the club to hold information to support the booking of seats to watch a match at the club’s stadium over the course of several seasons. Prior to the start of a season a set of fixtures are arranged between AFC United (the home team) and an opposing team (the away team). Matches are watched by spectators who have registered with the club. These are called PassHolders. PassHolders must book seats in advance for any of the 20 home fixtures of that season. Once a Seat is booked (and payment made), the Pass Holder is issued with one or more Tickets. This because a PassHolder can purchase one or more tickets for seats for each fixture. For every ticket we know the associated person, with name, surname, date of birth and place of birth. A particular seat can have restricted occupancy. This is recorded as the seating type (for example "reserved for the president", "reserved for disabled"). Every seat, depending on its position/ sector has a different price, which can also change fixture by fixture. |
The schema is defined in database/schema.sql.
Table Biglietto (Ticket) has been partitioned via table inheritance. Each partition is automatically created, as a child table, at the insertion of a new Stagione (Season), so there is a partition for each row in Stagione. The parent table itself is normally empty; it exists just to represent the entire table when queried. Insertions are redirected to child tables via triggers.
Table constraints are added to each child table to define the allowed key values in each partition. Constraint exclusion is a query optimization technique that improves performance for partitioned tables. Without constraint exclusion, the above query would scan each of the partitions of the measurement table. With constraint exclusion enabled (or set to PARTITION), the planner will examine the constraints of each partition and try to prove that the partition need not be scanned because it could not contain any rows meeting the query's WHERE clause. When the planner can prove this, it excludes the partition from the query plan.
This implementation is based on the official documentation as explained here.
REST API with Spring Boot and ORM with Hibernate
Single page application with AngularJS.
Insertions on table Biglietto are sent to Logstash, as JSONs, through HTTP requests, which filters and send them to Elastic Search. Charts, dashboards and UI are provided by Kibana.