Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
Clone
HTTPS:
git clone https://vervis.peers.community/repos/yEzqv
SSH:
git clone USERNAME@vervis.peers.community:yEzqv
Branches
Tags
temporal-patterns.mdwn
Purpose
Explore the various usage patterns of persistent data on computers.
Components
In order to be able to wisely design and choose the components of the system, I want to examine and study some existing popular systems and patterns:
- File system
- Database
- D-Bus
Databases
Databases are designed to work with large amounts of data. They store data on the hard drive, and load it in chunks for the purpose of query execution. As a result, disk speed is the largest factor affecting the query response times. In-memory databased exist too, and some database management systems have in-memory storage engines.
Two resources to start with are:
- The Wikipedia article about Databases
- Optimization lecture presentation from Databases course
I also asked a question on the Tracker mailing list about usage patterns, and I’d like to paste the question and the response as local files.
- The question => tracker-question
- The reply => tracker-answer
Patterns
Some applications just read data. For example, importer plugins which get data from existing apps. Or apps which combine their data with other existing data to generate useful reports. In this case, there are two patterns:
1 Periodic * Read block of data and show to user * Periodically read it again and update view
2 Events * Read block of data and show to user * Get notification when data changes, and update view
When also writing data, there are 4 patterns:
- Constant
- Get new data from user
- Send update to database
- Periodic
- Get new data from user
- Cache it for easy access and backup
- Periodically send data batches to database
- Request
- Get new data from user
- Cache it for easy access and backup
- Upon Save click, send update to database
- File
- User writes to text file
- When saved, file changes are translates to database updates
Beside the efficiency concerns, the writing pattern has data integrity issues: What if data is automatically sent to the database, and then you undo? It could mean other apps/programs/remote processes use data you supplied, but in fact that data is not valid. Not true. Not correct. And sending notifications to many listeners is a waste. For each tiny undo, it could be too much waste. Of course a solution may be a GUI change: Add a save button. There’s also an option to wait longer until sending the update to the database, but then other apps may take that time to update their copy of the data.
Possible solution: Allow each client to specify how urgently they need their data, and how urgently they would prefer to have it in an average use case.