Implementation outline

• create new table ACT_RU_TASK_METER_LOG (original proposal: ACT_RU_TASKMETRIC) with (id, timestamp, hash value of assignee)
  • appropriate index(es), e.g. on timestamp in ascending order
• insert entry upon task assignment (every assignee change)
  • the assignee value will be hashed to have a predictable size estimation and to pseudonymize the inputs
  • hash size of 64 bit leads to a collision probability of roughly 10^-12 for 6.000 UTWs (compared: 32 bit hash leads to a collision probability of roughly 0.001 for 3.000 UTWs and 0.01 for 9.000 UTWs) - see Birthday Problem for further information
  • create a 64 bit hash (e.g. the first 64 bit of an MD5 128 bit hash) and encode as long value (which is 64 bit as well)
    • data resides locally, so no security concerns regarding the hash algorithm
    • chosen hash algorithm should keep the collision rate as low as possible (to account for the right number of UTWs), be accessible (ideally out-of-the-box with the JDK), and as fast as possible
    • storing the 64 bit hash as BLOB would make "count distinct" difficult or unsupported on several DBs
    • storing the hash as an encoded string (hex or base64) would either increase the size (hex: 2x bit size, base64: 1.3333x bit size) or require a smaller hash (leading to a higher error rate due to possible collisions becoming more likely)
• create engine configuration property to disable UTW metric
• create query endpoint to aggregate UTW for a time period
• create API method to query for UTW for a time period
• create API method to delete task metrics by timestamp (everything prior to the given date, clean all when no date is provided)