The foundational invention is the TileDB universal storage engine based on dense and sparse multi-dimensional arrays.
Want some advice? Find a way to explain TileDB not to sound super intelligent, but to help readers understand. You will be much more successful if you do just that.
Added bonus: start with what problem TileDB solves, that current solutions don't solve.
Edit: 1) scalability for complex data; and 2) deployment; seem to be the problems you solve. Is that correct?
If you don't understand the value of TileDB, you probably haven't dealt with the data that it is meant to model.
Using something like MongoDB for genomic or sparse geospatial data is incredibly cumbersome.
The access patterns for analytical applications making use of the above data types are spatially collocated ... the subsequent implication of this is that data needs to be stored in ways that are geometrically optimized on the file-system.
Consider a dataset which assembles information regarding terrain ... you collect a measurement using a laser. Some areas you use a laser scanner that is very dense (high number of samples per square km) ... in another you sparsely sample it. This results in a huge multi-dimensional array... this is well understood by people collecting the data. TileDB is built for this type of use case... "complex" data is ambiguous.
Comments
Seth, congrats on the funding.
Want some advice? Find a way to explain TileDB not to sound super intelligent, but to help readers understand. You will be much more successful if you do just that.
Added bonus: start with what problem TileDB solves, that current solutions don't solve.
Edit: 1) scalability for complex data; and 2) deployment; seem to be the problems you solve. Is that correct?
I'm not even sure this is the problem. For the target customer, this language is fine (sparse arrays being notoriously difficult).
It's the rest of the language that seems to allude to some sort of innovation/breakthrough but stops short of explaining that.
If you don't understand the value of TileDB, you probably haven't dealt with the data that it is meant to model.
Using something like MongoDB for genomic or sparse geospatial data is incredibly cumbersome.
The access patterns for analytical applications making use of the above data types are spatially collocated ... the subsequent implication of this is that data needs to be stored in ways that are geometrically optimized on the file-system.
Consider a dataset which assembles information regarding terrain ... you collect a measurement using a laser. Some areas you use a laser scanner that is very dense (high number of samples per square km) ... in another you sparsely sample it. This results in a huge multi-dimensional array... this is well understood by people collecting the data. TileDB is built for this type of use case... "complex" data is ambiguous.