I don't have detailed knowledge of your key, but generally speaking: A row can have billions of columns. There is no assumption in accumulo that the row will fit in memory. Of course, a single mutation will need to fit in memory.
A row will always be served from just a single server, so its important to have enough rows to spread the ingest/query load out over your cluster. -Eric On Fri, Apr 25, 2014 at 9:11 AM, Geoffry Roberts <[email protected]>wrote: > Interesting, multiple mutations that is. Are we talking multiples on the > same row id? > > Upon reflection, I realized the embedded thing is nothing special. I > think I'll keep adding columns to a single mutation. This will make for a > wide row, but I'm not seeing that as a problem. I am I being naive? > > Another question if I may. As I walk my graph, I must keep track of the > type of the value being persisted. I am using the qualifier for this, > putting in it a URI that indicates the type. Is this a proper use for the > qualifier? > > Thanks for the discussion > > > On Thu, Apr 24, 2014 at 11:23 PM, William Slacum < > [email protected]> wrote: > >> Depending on your table schema, you'll probably want to translate an >> object graph into multiple mutations. >> >> >> On Thu, Apr 24, 2014 at 8:40 PM, David Medinets <[email protected] >> > wrote: >> >>> If the sub-document changes, you'll need to search the values of every >>> Accumulo entry? >>> >>> >>> On Thu, Apr 24, 2014 at 5:31 PM, Geoffry Roberts <[email protected] >>> > wrote: >>> >>>> The use case is, I am walking a complex object graph and persisting >>>> what I find there. Said object graph in my case is always EMF (eclipse >>>> modeling framework) compliant. An EMF graph can have in if references >>>> to--brace yourself--a non-cross document containment reference. When using >>>> Mongo, these were persisted as a DBObject embedded into a containing >>>> DBObject. I'm trying to decide whether I want to follow suit. >>>> >>>> Any thoughts? >>>> >>>> >>>> On Thu, Apr 24, 2014 at 4:03 PM, Sean Busbey <[email protected]>wrote: >>>> >>>>> Can you describe the use case more? Do you know what the purpose for >>>>> the embedded changes are? >>>>> >>>>> >>>>> On Thu, Apr 24, 2014 at 2:59 PM, Geoffry Roberts < >>>>> [email protected]> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I am in the throws of converting some(else's) code from MongoDB to >>>>>> Accumulo. I am seeing a situation where one DBObject if being embedded >>>>>> into another DBObject. I see that Mutation supports a method called >>>>>> getRow() that returns a byte array. I gather I can use this to achieve >>>>>> a >>>>>> similar result if I were so inclined. >>>>>> >>>>>> Am I so inclined? i.e. Is this the way we do things in Accumulo? >>>>>> >>>>>> DBObject, roughly speaking, is Mongo's counterpart to Mutation. >>>>>> >>>>>> Thanks mucho >>>>>> >>>>>> -- >>>>>> There are ways and there are ways, >>>>>> >>>>>> Geoffry Roberts >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sean >>>>> >>>> >>>> >>>> >>>> -- >>>> There are ways and there are ways, >>>> >>>> Geoffry Roberts >>>> >>> >>> >> > > > -- > There are ways and there are ways, > > Geoffry Roberts >
