- Routes are operated in both directions, so you can drive A -> B and B -> A
You can generate a big data file with DemoDataGenerator. One generated file of 27MB with 4020016 station entries is placed under src/test/resources and used for the performance evaluation.
In the project root is a performance-test.sh script that runs 10 different queries with 5 misses and 5 hits. It prints the performance in seconds with millisecond resolution.
Results: 5,468 1,660 8,283 2,664 6,234 6,141 6,409 6,166 6,230 1,732
Results: 8,945 1,457 7,117 2,333 5,212 5,216 5,201 5,237 5,227 1,384
Starting up took extremely long (27 minutes) compared to the other databases!
Results: 8,662 2,682 12,006 3,913 9,209 9,300 9,273 9,420 9,262 2,721
This stores the connections as string of lower station number + space + higher station number. Example "4 8". Via the set redundant entries are neglected. In this approach the route number is completely ignored!
You can switch the storage by creating a file application.properties and adding the line
storage=mem
Unfortunately the application didn't start up within 60 minutes!
Results with 1000 lines / 969993 entries: 0,422 0,034 0,023 0,020 0,016 0,013 0,013 0,013 0,024 0,023
Results with 1000 lines / 39759 on HSQLDB: 0,592 0,054 0,065 0,046 0,059 0,042 0,037 0,052 0,054 0,033
The logfile of the service showed a very fast response time of the mem storage against the db version.
- Use a standalone database, for example MySQL
- Add an index
- Store entries with source and destination in the database, without route number, so no join is needed
It looks as if for smaller datasets the memory storage via a set has the highest performance. But the disadvantage is the high startup time. From the in memory database implementations HSQLDB is the fastest.