Pages: 1 2 3 [4] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 5 post(s) |
Plutoinum
German Cyberdome Corp Veritas Immortalis
|
Posted - 2006.09.02 02:09:00 -
[91]
Edited by: Plutoinum on 02/09/2006 02:14:16
Originally by: Qutsemnie
Hashing should assume the hash generated isnt unique and plan for collisions in reliable fashion.
If they just want a unique key at dev time and don't need to generate the hash-value later on the client once again, then my first idea to solve it now would be to either use a common database to check for duplicates or just use a common key generator on a single server that all devs use. Even better a combination of both that allows your machine to check out a range of unused keys for your work. Later your machine could connect again and update the server with the info, which keys are used and which are still free. Over 4 bil unique file keys should be enough for EVE's lifetime with that method. This would also allow you to check-in all used keys so far, so that the new generator knows it and doesn't assign them again and you could just go on with the 32-bit key like it is now without the need to make big changes. Well, maybe there are other reasons, why that isn't an option, but speculating is fun.
|
Jenna Malone
Caldari W-hat LLC
|
Posted - 2006.09.02 14:51:00 -
[92]
Edited by: Jenna Malone on 02/09/2006 14:52:25
Originally by: Jaden Haryl Well SQL server hardly cares whether its a string or not when it indexes, but the size of the key does matter, and 128bit GUID is 4 times the size of a 32bit int, and this definetly affects performance. Also for a table with a high volume of inserts sequential ints will vastly out perform GUIDs as pages do not have to split. There are some white papers out there going into great depth about the performance implications of GUIDs for PKs, heck check out comp.databases.theory and can see it beaten to death, but I wouldnt go there telling them you store attributes in rows, they will tear you apart, as it is such a common elementary mistake to use a relational DB this way.
BTW any reason you guys are using a GUID on a table with only 1.8 mill rows, a 32bit int should be more than enough, or go big int, either way better performance. Maybe you guys are replicating? Then again you should just be creating new tables with different rows for different object types and not storing all objects attributes in one big table, but I digress.
GUIDs only affect performance when inserting. However there's no performance difference in retrieving rows by GUID or integers (well, there might be a very negligable one, on a long run, but it's small ass tiny), unless you forgot to put an index on it.
|
Skogen Gump
|
Posted - 2006.09.02 18:42:00 -
[93]
Originally by: Jenna Malone
GUIDs only affect performance when inserting. However there's no performance difference in retrieving rows by GUID or integers (well, there might be a very negligable one, on a long run, but it's small ass tiny), unless you forgot to put an index on it.
That's my experience too; the only problem really is that it's harder to type a guid into Query Analyser
|
bovine syndrome
Amarr Intergalatic Blue Navy
|
Posted - 2006.09.03 07:17:00 -
[94]
surely it would be be,
math: 4,294,967,295 man:0
?
|
Miss Overlord
Gallente Garoun Investment Bank
|
Posted - 2006.09.03 09:17:00 -
[95]
Originally by: Skogen Gump
Originally by: Jenna Malone
GUIDs only affect performance when inserting. However there's no performance difference in retrieving rows by GUID or integers (well, there might be a very negligable one, on a long run, but it's small ass tiny), unless you forgot to put an index on it.
That's my experience too; the only problem really is that it's harder to type a guid into Query Analyser
any other alternatives available then ?
|
Jaden Haryl
|
Posted - 2006.09.03 17:19:00 -
[96]
Edited by: Jaden Haryl on 03/09/2006 17:19:08
Originally by: Jenna Malone Edited by: Jenna Malone on 02/09/2006 14:52:25 GUIDs only affect performance when inserting. However there's no performance difference in retrieving rows by GUID or integers (well, there might be a very negligable one, on a long run, but it's small ass tiny), unless you forgot to put an index on it.
You are over simplifing by a long shot, yes inserts are where you will see the most performance reduction from using random GUID's, but as a consequence of all that page splitting in either the table or the index (clustered or non-clustered) you will see MUCH more index fragmentation which if not controlled through index rebuilds will degrade performance far in excess of the base line reduction in speed that will exist simply because the key itself is 4 times the size of an int.
Sure you can rebuild indexes more often, but that process in itself leads to degraded performance or downtime to complete, and if your DB is 24/7 you may not have a good "downtime".
So again whats the point of using a GUID if you don't have to, all your buying yourself is less performance for the same result? If you need it GUID are great though, don't get me wrong, I use them all the time in specific situations where they are necessary and therefore the costs have to be accepted.
Maybe it makes little difference in the size of the database you deal with, but I can tell you a good DBA will know there are significant implications.
|
elFarto
New Order Industries
|
Posted - 2006.09.04 19:10:00 -
[97]
I've got some resource (.stuff) loading code that doesn't have hash collisions, I can sell it to you for a reasonable price
Regards elFarto
NPC database Mal: This is your captain speaking. We're having some technical difficulties, so we may experience some turbulence, and then explode. |
Admai Sket
|
Posted - 2006.09.05 09:34:00 -
[98]
Originally by: Linerra Tedora Edited by: Linerra Tedora on 31/08/2006 17:53:59 Ahh yes.. the allmighty david...
Linkage
edit : no smack intended.. just to have a quiet fun time... after all, i have many german friends...
WTF?
|
Kweel Nakashyn
Minmatar Aeden
|
Posted - 2006.09.07 19:00:00 -
[99]
Edited by: Kweel Nakashyn on 07/09/2006 19:05:42 Edited by: Kweel Nakashyn on 07/09/2006 19:04:50
Originally by: Crunch Hardiron
Originally by: Rahn Sohwant I think 32 bits ought to be enough for anybody.
Is it sad that not only did I get that, I laughed?
Yes... @work we use 80 bits and we still get some naughty things sometimes :)
Edit : mmmm... k
|
Kweel Nakashyn
Minmatar Aeden
|
Posted - 2006.09.07 19:02:00 -
[100]
Edited by: Kweel Nakashyn on 07/09/2006 19:04:35 Edited by: Kweel Nakashyn on 07/09/2006 19:02:59
Originally by: Miss Overlord
Originally by: Skogen Gump
Originally by: Jenna Malone
GUIDs only affect performance when inserting. However there's no performance difference in retrieving rows by GUID or integers (well, there might be a very negligable one, on a long run, but it's small ass tiny), unless you forgot to put an index on it.
That's my experience too; the only problem really is that it's harder to type a guid into Query Analyser
any other alternatives available then ?
Do a damn select before any insert. If it gives a row, reinsert somewhere else. Perf = perf / 2 (or in case of very bad luck 3), and Data Security = Data Security x the 32 bit key :).
|
|
|
|
|
Pages: 1 2 3 [4] :: one page |
First page | Previous page | Next page | Last page |