willie68
commented
2 years ago Normally this can be done with a database. So you can simply throw all your properties and the blob id into a database and do the searching stuff by your own. For smaller installations, however, this brings with it additional complexity. Therefore, with this small service in small installations, it would be worth considering bringing your own small database with you. Since the market is huge, I had to make a pre-selection based on the following criteria.
- Integrable: In the first step, it should not be a large database with its own server, but a small embedded database (However, it is intended that a corresponding database driver can be retrofitted later. A corresponding abstraction (as with the storage providers) must be implemented)
- Can be switched off: this feature must be switched off, since multi-instance operation on the same fileset is usually not intended for embedded DBs
- Persistent: The DB Engine should be persistent, so that you don't have to re-index all properties every time you restart.
- Footprint: in order not to go beyond the scope of the service, the footprint should be small
- Document-Based: The engine should be schemaless and document-based. The supplied properties are not static and should not have to be configured as part of the service. Nevertheless, you have to be able to search for certain properties (document fields) comfortably.
- High Doc Count: Ideally, the amount of data should be unlimited, or at least very high, since the service was built for exactly this purpose.
- Multi-Tenant: The database must also allow multi-tenant operation.
At the time of writing the blob store is a simple key/value store for big binary data. But if you lose the key, you have no way to search for the blob. At most, you can browse through all the blobs and check if this is the blob you need. It would be nice if I could also search for my supplied properties.