Choice of Database

A project log for Seeing Space Table

A table to see what mechatronic systems are thinking.

minifig404minifig404 08/20/2014 at 03:100 Comments

Ultimately, the question comes down to "How much structure does the sensor log need?"

The list of users and projects should be very structured, and their indexing needs are not advanced. However, no database is good at storing video of the robots operating. Nor does the indexing associated with the video necessarily belong in a DB. Maybe some hashes could be put into the DB, but SQL is probably a poor fit for the sort of video processng this project will eventually do.

Which brings us back to sensor samples. If each sample can be reduced to a series of identical-structure points, and indexing doesn't need any special processing, then SQL could be useful. On the other hand, if I need to aggregate all the sensor data myself in order to come up with a useful visual search, is there an efficient way in which SQL can store the results of that computation? If not, can Map/Reduce indexes fill the gap?

Probably the best bet is to start with pure SQL, and abstract everything behind microservices, and let the microservices deal with the DB. Then, if I need to migrate data later, I can deploy new microservices, and use them to recreate the new equivalent of the old data.