Yes, I mean the row, column family, column qualifier (and also column visibility). I had intended "each", not "total", because 1K is probably too constraining for some applications, but I don't think you'd see any significant difference between the two, as they are on the same order of magnitude.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sun, Jan 26, 2014 at 8:11 AM, Jamie Johnson <[email protected]> wrote: > Sorry for the basic question, but by key segment do you mean row key, column > family column qualifier? So each should be less than a kilobyte or total? > I think either way we are below that but I just want to make sure I > understand the terminology. Again thanks for the reply. > > > On Sun, Jan 26, 2014 at 2:12 AM, Christopher <[email protected]> wrote: >> >> On the order of a kilobyte, or less, per key segment is probably >> ideal. Beyond that, you may want to experiment to see what works for >> you. >> >> Up to the order of a megabyte may work fine in newer versions (at >> least 1.4), but I'd start having concerns about your schema decisions >> after that, even if your performance was fine... since ultimately, >> Accumulo tables are a sorted index, and I'd wonder what kind of index >> needs such large keys. >> >> I suspect a few hundred bytes is probably plenty for most applications. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Sat, Jan 25, 2014 at 9:06 AM, Jamie Johnson <[email protected]> wrote: >> > I've read that in HBase there is a recommended limit on key lengths >> > because >> > they're passed around quite a bit. Is the same true of accumulo? Are >> > there >> > any recommendations in this regard? > >
