Comment:jamestaylor:08/13/13 09:38:26 PM:
This one is a dup of -239. I think it'd be similar in concept kiji-schema, as it would define the structure of a single KeyValue column in your schema (i.e. an instantiation of the struct would be stored in a single KeyValue), but there's could be other sibling KeyValue columns that aren't structs.
I think the schema of the struct would be defined in the Phoenix metadata table (SYSTEM.TABLE) using a new struct type to differentiate it. We'd need to allow references in queries using a dotted notation. At upsert/insert time, you'd need to provide the struct in it's entirety.
Other than using less space, since you don't have the overhead of an entire KeyValue with each value. I'm not convinced this adds a whole lot of value. You can essentially model the same thing with multiple columns. I'd rather see HBase come up with better/more condensed block encodings and have a condensed memory model that can better leverage these encodings.
As far as -19, that one is different. It's for cases where you'd want to have very wide rows in which value information is encoded in the column qualifier. In this case, you'd define these set of columns as a "nested table" which you could join against the row that contains them. So a set of column qualifiers would look like another row to Phoenix.