Based this latest description, simply not specifying an affinity key here would be sufficient. But presumably you were specifying the affinity key to cause co-location. The reason a lookup on the K of the KV pair is fast is because it can hash to a node. If the affinity key was not included in the K then you would not get colocation. To do a lookup on only part of K means you cannot hash to node. Assuming that you can't know the affinity key a priori, i.e., you know the person and not the company, there are other solutions. Depending on the data, you may be able to use a replicated cache for other (company) data rather than trying to co-locate this record with that other data. That increases the storage and insert/update cost for company records. There are also a number of solutions using Java to send closures to the server nodes.
On Wed, Mar 21, 2018 at 1:55 AM, Naveen <[email protected]> wrote: > My whole and sole requirement is to make lookup work fast, this can only be > achieved with lookup based on primary key, cluster knows which node is > holding this record based on the key, no other look-up can give best > results > close to primary key lookup. > > We have done some tests on lookup based on the indexed column, which is > giving (1/5)th of the TPS of lookup based on the primary key > > Lookup with primary key was around 30K TPS > Lookup on indexed column was around 6 K TPS > > Though its indexed, request still goes to all the nodes, instead of > querying > the source table it will query index table which is small in size and > sorted, so retrieval process is faster, is this understanding correct ?? > > Results are justifiable, considering the architecture, where indexes are > distributed across the nodes. > > In my view, affinity should not influence the data model, at the most it > can > add to the memory footprint by adding extra column to the table just for > the same of using affinity (collocating the data). > > If the whole idea of having affinity key as part of the primary key is to > just identify the order of fields, then we should look for other ways not > by > enforcing the affinity key as part of composite primary key. > > Regards > Naveen > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
