0

Requirement:
we need to assign a random, long enough number/string to merchants so that they are uniquely identifiable(do not want someone to guess the identifier ). This is required because we are printing this number/string as QR code and giving it to merchants so that our users can read the QR code and get the info about the merchant.

current Implementation:
we cannot print id's as they will be sequential, so we have introduced a new field (externalId) to store a unique id generated by TimeBasedGenerator of JUG UUID generator. As I researched more I found there are performance issues with UUID. All the articles talks about UUId as primary key, I am not using UUID as primary key but as a secondary identifier. I am not worried about inserts and updates, as they will be fewer as compared to search. As user will be sending us the UUID read from the printed QR code and we will need to search the merchant using this UUID field, Hence there will be huge impact on performance.

solution as per me:
instead of UUID we will give a combination of ID:UUID, so that when we get the request we can split and fetch the merchant using ID and check if the externalId(UUID) present in our DB matches with the one provided, if it matches we return the merchant other wise not.

Will this solution increase the performance significantly or the time taken by string operations will nullify the effect.

Is there any better approach to do this?

Thanks

Parveen Yadav
  • 85
  • 9
  • Have you searched/read anything about RSA? There's a security package in Java that can create RSA Keys. It's randomnly generated and can be encoded and decoded. Here's some documentation: https://docs.oracle.com/javase/tutorial/security/apisign/gensig.html – Gabriel Câmara Apr 20 '16 at 12:14

2 Answers2

1

UUIDs are generated in various flavors. As you are perhaps already aware, RFC 4122 outlines a variant (i.e. UUID schema) that defines five different versions. I suggest that you look into version 1 of RFC 4122.

Version 1 uses a MAC address of the machine generating the UUID as the last 12 digits of the generated UUID.

Assume you go to a second-hand computer recycler and purchase an obsolete ethernet adaptor; power it up and get the MAC address of that adaptor; and then destroy the adaptor (shredder, shot-gun, acid, etc.). You can now be assured that no other computer in the universe will -ever- generate a V1 UUID using that MAC address.

Now you could write a UUID (RFC 4122, V1) generator that would use harvested MAC address.

You could harvest a separate MAC address (from additional cards) for each merchant, and then you would be able to identify UUIDs generated for each.

BONUS: You might experiment with V1 UUIDs using Mahonri Moriancumer's UUID and GUID Generator and Forensics.

Mahonri Moriancumer
  • 5,993
  • 2
  • 18
  • 28
  • [Type 1 UUIDs in MySQL context](http://mysql.rjweb.org/doc.php/uuid), including code to rearrange the bits. – Rick James Apr 22 '16 at 03:50
0

The best implementation would depend on your UUID'S character distribution but what I did when faced with similar situation is use only the UUID for the end user. In the database I added a column filled with the first 2 chars of the UUID and indexed that column.

Either this or, as you proposed, the ID would serve the same purpose. The benefits of indexing a partial UDID are that

  1. you can tweak how many characters to use to improve performance
  2. the id is not used externaly potentially causing issues.

On the other hand, an integer index is probably using less memory and in no need of tweeking

Performance wise, for my implementation we were facing search queries of 1 in a million taking 7-8 seconds. With this solution we dropped to a few milliseconds

user3802077
  • 849
  • 9
  • 22