We were discussing A connector to object storage.
The workflows imnvolving use of the backup data do not require modifications of data objects and this makes object storage perfect for them. On the other hand, applications which are more read and write intensive and do not tolerate latency are not suited for storage. As we progress from online transactions to analytical processing to object storage, the data is less susceptible to modifications. This does not mean we use Object Storage merely for backup and recovery.  Compared to other storage, Object Storage provides immense scalability. This is true even if the source data stores are already in the cloud because those data stores are primarily focused for transactional and analytics purpose while object storage works exclusively as a store. Moreover, there is very little hierarchy in storing data. Namespaces, buckets and objects serve enough organizational tools for the bulk of the storage. This removes the restrictions and the data can be stored on a limitless storage. Moreover, object storage can be file system enabled. Finally, there’s plenty of cost-effectiveness to this storage which makes it more appealing than other forms of storage
Object Storage can also be a SQL store.

Object Storage data is search-able as a COM input to log parser. A COM input simply implements a few methods for the log parser and abstracts the data store. These methods are :
OpenInput: Opens your data source and sets up any initial environment settings
GetFieldCount: returns the number of fields that the plugin provides
GetFieldName: returns the name of a specified field
GetFieldType : returns the datatype of a specified field
GetValue : returns the value of a specified field
ReadRecord : reads the next record from your data source
CloseInput: closes the data source and cleans up any environment settings
Architecture:

Here we are saying that Object Storage acts as a data store for COM input to log parser which can then be queried in SQL for the desired output.