هي GUID التصادم ممكن ؟
https://stackoverflow.com/questions/184869
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا أعمل على قاعدة بيانات في SQL Server 2000 التي تستخدم GUID لكل مستخدم يستخدم التطبيق انها مرتبطة.بطريقة أو بأخرى, اثنين من المستخدمين انتهى مع نفس المعرف الفريد العمومي.أنا أعرف أن مايكروسوفت يستخدم خوارزمية توليد عشوائي GUID التي لديها منخفضة للغاية فرصة التسبب في collisons بل اصطدام لا يزال ممكنا ؟
المحلول
وأساسا، لا. أعتقد أن شخصا ذهب التلويث مع قاعدة البيانات الخاصة بك. اعتمادا على GUID الإصدار الذي تستخدمه قيمة إما فريد (لأشياء مثل النسخة 1 المعرفات الفريدة العمومية)، أو كليهما فريدة من نوعها وغير متوقعة (لأشياء مثل الإصدار 4 المعرفات الفريدة العمومية). تنفيذ SQL خادم لNEWID الخاصة بهم () تظهر وظيفة لاستخدام رقم عشوائي 128 بت، لذلك كنت لن تحصل على حدوث تصادم.
لفرصة 1٪ من الاصطدام، وكنت بحاجة لتوليد حوالي 2.600.000.000.000.000.000 المعرفات الفريدة العمومية.
نصائح أخرى
أساسا أنها ليست ممكنة !, ، وهناك احتمالات فلكية منخفضة.
ولكن...أنا الشخص الوحيد في العالم الذي أعرفه ، كان GUID colision مرة واحدة (نعم!).
و أنا متأكد من ذلك, و أنه لم يكن خطأ.
كيف حدث ذلك في تطبيق صغير الذي كان يعمل على كمبيوتر الجيب ، في نهاية العملية الأوامر التي لديه إنشاء GUID يجب أن تصدر.الأمر بعد أن أعدم على الملقم الذي تم تخزينه في الجدول الأمر على الخادم جنبا إلى جنب مع تاريخ تنفيذ الإعدام.يوم واحد عندما كنت التصحيح أصدرت وحدة القيادة (مع ولدت حديثا GUID المرفقة) و لم يحدث شيء.أنا فعلت هذا مرة أخرى (مع نفس المعرف الفريد العمومي ، لأن guid ولدت مرة واحدة فقط في بداية التشغيل), ومرة أخرى, ولا شيء, وأخيرا محاولة لمعرفة لماذا الأمر ليس المنفذة ، راجعت الجدول الأمر ، نفس المعرف الفريد العمومي كما هو الوضع الحالي تم إدراج 3 أسابيع.لا أصدق هذا أنا استعادة قاعدة بيانات من 2 أسابيع النسخ الاحتياطي ، guid كان هناك.التحقق من التعليمات البرمجية الجديدة guid كان الذي تم إنشاؤه حديثا لا شك في ذلك.الأسرى guid الاصطدام حدث مرة واحدة فقط, ولكن أنا حقا أتمنى أن فاز في اليانصيب بدلا من ذلك ، فرصة أكبر :).
تحرير:هناك بعض العوامل التي يمكن أن زادت بشكل كبير من فرصة حدوث هذا, كان التطبيق قيد التشغيل على كمبيوتر جيب المحاكي ، المحاكي لديه لإنقاذ الدولة الميزة ، مما يعني أنه في كل مرة على استعادة حالة بالتوقيت المحلي استعادة أيضا و guid يستند على الداخلية الموقت....كما guid توليد خوارزمية ضغط الإطار قد يكون أقل مما هو على سبيل المثال COM واحد...
وهم نظريا ممكن، ولكن مع 3.4E38 عدد ممكن، إذا قمت بإنشاء عشرات التريليونات من المعرفات الفريدة العمومية في السنة فرصة وجود نسختين واحدة هو 0.00000000006 (<لأ href = "http://en.wikipedia.org/ ويكي / UUID # Random_UUID_probability_of_duplicates "يختلط =" noreferrer "> المصدر ).
إذا انتهى اثنين من المستخدمين مع نفس GUID، وأود أن الرهان أن هناك خطأ في البرنامج الذي يسبب البيانات المراد نسخها أو مشتركة.
أولا دعنا ننظر إلى فرصة تصادم اثنين Guid.وهو كما إجابات أخرى ذكر ، 1 في 2^128 (10^38) بسبب عيد ميلاد مفارقة, مما يعني أن فرصة 50 ٪ من اثنين Guid الاصطدام احتمال فعلا 1 في 2^64 (10^19) الذي هو أصغر كثيرا.ولكن هذا لا يزال عدد كبير جدا مثل احتمال تصادم على افتراض أنك تستخدم عدد معقول من المعرفات الفريدة العمومية منخفضة.
نلاحظ أيضا أن Guid لا تحتوي على طابع زمني أو عنوان MAC أكبر عدد من الناس كما يبدو أن نعتقد.كان هذا صحيحا بالنسبة v1 Guid ولكن الآن v4 Guid تستخدم ، التي هي مجرد عدد شبه عشوائي وهو ما يعني أن إمكانية الاصطدام يمكن القول العالي لأنها لم تعد فريدة من نوعها وقت و آلة.
لذلك أساسا الجواب هو نعم ، الاصطدامات المحتملة.لكن من المستبعد جدا.
تحرير:ثابت يقول 2^64
وفرص اثنين المعرفات الفريدة العمومية عشوائية الاصطدام (~ 1 في 10 ^ 38) هو أقل من فرصة عدم الكشف عن / حزمة TCP الفاسدين IP (~ 1 في 10 ^ 10). HTTP: //wwwse.inf.tu-dresden .de / البيانات / دورات / SE1 / SE1-2004-lec12.pdf ، الصفحة 11. هذا ينطبق أيضا على محركات الأقراص ومحركات الأقراص المدمجة، وغيرها ...
والمعرفات الفريدة العمومية هي فريدة من نوعها إحصائية وبيانات تقرأ من ديسيبل هو فقط الصحيح إحصائيا.
وأود أن تنظر الحلاقة أوكام كدليل جيد في هذه الحالة. ومن غير المرجح للغاية أن يكون لديك تصادم GUID. ومن أكثر عرضة لديك خلل، أو أي شخص العبث مع البيانات الخاصة بك.
المعرف الفريد في. هناك عدة طرق لتوليد المعرفات الفريدة العمومية. ويبدو أن القديم (؟) وسيلة تستخدم عنوان ماك، طابع زمني وصولا الى وحدة قصيرة جدا وعداد فريدة (لإدارة أجيال سريعة على نفس الكمبيوتر)، ولذلك جعلها تكرار يكاد يكون من المستحيل. ولكن أسقطت هذه المعرفات الفريدة العمومية لأنها يمكن أن تستخدم لتعقب المستخدمين ...
وأنا لست متأكدا من الخوارزمية الجديدة المستخدمة من قبل Microsoft (يقول المقال سلسلة من المعرفات الفريدة العمومية يمكن التنبؤ، يبدو أنها لم تعد استخدام الطابع الزمني؟ المقال مايكروسوفت مرتبطة فوق تقول شيئا آخر ...).
والآن، وقد صممت بعناية لتكون المعرفات الفريدة العمومية، بالاسم، فريدة من نوعها على مستوى العالم، ولذا فإنني سوف خطر عليه من المستحيل، أو من احتمال جدا منخفض جدا جدا. وأود أن ننظر في أي مكان آخر.
واثنين WIN95 الآلات التي لديهم بطاقات إيثرنت مع عناوين MAC مكررة سوف تصدر GUID مكرر في ظل ظروف رقابة مشددة، وخاصة إذا، على سبيل المثال، قوة تنفجر في بناء وكلاهما التمهيد في نفس الوقت بالضبط.
وأنا أعلم الناس مثل الجواب شعورا جيدا أن المعرفات الفريدة العمومية هي سحرية ومضمونة لتكون فريدة من نوعها، ولكن في الواقع، فإن معظم المعرفات الفريدة العمومية هم مجرد أرقام عشوائية 121 بت (سبعة من البتات تضيع على تنسيق). إذا كنت لا تشعر بالراحة عند استخدام رقم عشوائي كبير، ثم يجب أن لا تشعر بالراحة باستخدام GUID.
هل من الممكن أن الرموز المستخدمة لتوليد GUID يكون خطأ في ذلك؟ نعم، بالطبع ما في وسعها. ولكن الجواب هو نفسه كما أنه سيكون لعلة مترجم - التعليمات البرمجية الخاصة بك هو أوامر من حجم أكثر عرضة للعربات التي تجرها الدواب، وذلك للبحث هناك أولا
وبالطبع من الممكن .... محتمل؟ لا يحتمل، ولكن كان ذلك ممكنا.
وتذكر، ونفس الجهاز يولد كل GUID (الخادم)، لذلك الكثير من "العشوائية" التي تقوم على فقدان الجهاز معلومات محددة.
ولمجرد التكشير، حاول النصي التالي ... (يعمل على SQL 2005، غير متأكدة 2000)
declare @table table
(
column1 uniqueidentifier default (newid()),
column2 int,
column3 datetime default (getdate())
)
declare @counter int
set @counter = 1
while @counter <= 10000
begin
insert into @table (column2) values (@counter)
set @counter = @counter + 1
end
select * from @table
select * from @table t1 join @table t2 on t1.column1 = t2.column1 and t1.column2 != t2.column2
وتشغيل هذا مرارا وتكرارا (يستغرق أقل من ثانية) تنتج مجموعة واسعة إلى حد ما من أول اختيار، حتى مع وجود فجوة زمنية قصيرة للغاية. وحتى الآن حدد الثانية لم تسفر عن أي شيء.
ومستحيل إذا كان لدى المستخدمين أجهزة مختلفة مع بطاقات الشبكة، وحتى لو لم يكن فإنه لا يزال خطر النظري تقريبا هامشي للغاية.
وأنا شخصيا أود أن ننظر في أي مكان آخر كما هو على الأرجح الخلل بدلا من الصدام GUID ...
وتوفير بالطبع أن لا يقطع بت قبالة GUID لجعله أقصر.
من المؤكد انه من الممكن، وربما حتى احتمالا. انها ليست مثل كل GUID في جزء عشوائية من مساحة عدد ممكن. في حالة أن اثنين من المواضيع حاولت لتوليد واحدة في وقت واحد، ما عدا نوع وظيفة GUID مركزية مع الإشارة حولها، فإنها يمكن أن ينتهي بك الأمر مع نفس القيمة.
وسوف أستهل هذا مع "أنا لست الشخص الشبكات، ولذا فإنني قد جعل الجمل غير متماسكة تماما بعد".
وعندما كنت أعمل في جامعة ولاية إلينوي، كان لدينا اثنين من أجهزة الكمبيوتر المكتبية ديل، أمر في أوقات مختلفة. وضعنا أول واحد على الشبكة، ولكن عندما حاولنا وضع ثانية واحدة على شبكة بدأنا تلقي أخطاء مجنون. بعد الكثير من المشاكل، تقرر أن الجهازين تم إنتاج نفس GUID (لست متأكدا بالضبط لماذا، لكنه جعلها غير صالحة للاستعمال على حد سواء على الشبكة). ديل استبدال الواقع على حد سواء آلات أنها معيبة.
وانه من غير المحتمل جدا أن عليك تشغيل في اصطدام GUID إذا كنت توليد لهم من خلال شيء من هذا القبيل وظيفة NEWID() في SQL Server (على الرغم من الممكن بالطبع، كما أكد إجابات أخرى). شيء واحد لم تكن قد أشار هو أنه في الواقع المحتمل جدا أن عليك أن تصل إلى التصادم إذا كنت توليد المعرفات الفريدة العمومية في جافا سكريبت على المتصفحات في البرية. لا فقط هناك أحيانا مشاكل في RNG في متصفحات مختلفة، ولكني أيضا تشغيل في مشاكل حيث يبدو أن العناكب جوجل لتخزين نتائج وظائف من هذا القبيل، وانتهى يمر مرارا وتكرارا نفس GUID حتى أنظمتنا.
واطلع على إجابات مختلفة هنا لمزيد من التفاصيل:
