الزيادة التلقائية على تخزين طاولة أزور

Question

أقوم حاليا بتطوير تطبيق لتخزين طاولة أزور. في هذا التطبيق، لدي جدول سيكون له عدد قليل نسبيا إدراج (بضعة آلاف / يوم) وسيتم استخدام المفتاح الأساسي لهذه الكيانات في جدول آخر، والذي سيكون له مليارات من الصفوف.

لذلك أنا أبحث عن وسيلة لاستخدام عدد صحيح تدريجي، بدلا من GUID، كإجراء أساسي في الجدول الصغير (نظرا لأن ذلك سيوفر الكثير من التخزين وقابلية التوسع للإدراجات ليس مشكلة حقا).

كانت هناك بعض المناقشات حول هذا الموضوع، على سبيل المثال http://social.msdn.microsoft.com/forums/en/windowsazure/thread/6b7d1ece-301b-44f1-85ab-eeb274349797..

ومع ذلك، نظرا لأن مشكلات التزامن يمكن أن تكون من الصعب حقا تصحيح الأخطاء والكتشف، فأنا غير مريح بعض الشيء مع تنفيذ ذلك. سؤالي هو إذا كان هناك حملة جيدا من هذا؟

Answer 1

لم أنفذ هذا بعد لكنني أعمل على ذلك ...

يمكنك البذور قائمة انتظار مع معرفاتك التالية لاستخدامها، فما عليك سوى اختيارهم عند الحاجة إليهم.

تحتاج إلى الاحتفاظ بجدول لاحتواء قيمة أكبر عدد يضاف إلى قائمة الانتظار. إذا كنت تعرف أنك لن تستخدم طن من الأعداد الصحيحة، فيمكنك الحصول على عامل كل ما يستيقظ في كثير من الأحيان وتأكد من أن قائمة الانتظار لا تزال لديها أعداد صحيحة فيها. يمكنك أيضا الحصول على قائمة انتظار Int التي يمكن أن تحقق العامل لمواكبة الاستخدام.

يمكنك أيضا ربط هذا العمال حتى إذا كانت قائمة الانتظار فارغة عند حاجة الكود الخاص بك إلى معرف (عن طريق الصدفة)، فقد يتراجع عن قيلولة العامل لإنشاء المزيد من المفاتيح في اسرع وقت ممكن.

إذا فشلت هذه المكالمة، فستحتاج إلى وسيلة (إخبار العامل الذي ستقوم به بالعمل بالنسبة لهم (قفل)، ثم القيام بالعاملين في الحصول على المعرف التالي وفتح)

1. قفل
2. احصل على المفتاح الأخير الذي تم إنشاؤه من الجدول
3. زيادة وحفظ
4. الغاء القفل

ثم استخدم القيمة الجديدة.

Answer 2

لكل من سيجده في البحث، هناك حلا أفضل. الحد الأدنى من الوقت لقفل الجدول هو 15 ثانية - ذلك فظيع. لا تستخدمه إذا كنت ترغب في إنشاء حل قابل للتطوير حقا. يستخدم Etag!

إنشاء كيان واحد في جدول معرف (يمكنك حتى تسمية ذلك كمعرف أو أيا كان).

1) اقرأها.

2) الزيادة.

3) insignorupdate. مع ETag المحدد (من استعلام القراءة).

إذا كانت العملية الأخيرة (InsertOrUpdate) ينجح، ثم لديك معرف جديد، فريد من نوعه، زيادة تلقائية. إذا فشل (استثناء مع HttpStatusCode == 412)، وهذا يعني أن بعض العميل الآخر غيره. لذلك، كرر مرة أخرى 1،2 و 3. الوقت المعتاد ل Read+InsertOrUpdate اقل من 200ms.. وبعد بلدي فائدة الاختبار مع المصدر على جيثب.

Answer 3

يرى فئة Uniqueidgenerator بواسطة جوش تويست.

Answer 4

الحل الذي وجدته يمنع المعرفات المكررة وتتيح لك التلقائي هو

1. قفل (عقد الإيجار) ودع هذا بمثابة بوابة منطقية.

2. ثم اقرأ القيمة.

3. اكتب القيمة المتزايدة

4. الافراج عن عقد الإيجار

5. استخدم القيمة في التطبيق / الجدول

ثم إذا كان دور عاملك يتعطل خلال تلك العملية، فلن يكون لديك معرف مفقود فقط في متجرك. IMHO أفضل من التكرارات.

هنا هو نموذج الكود والمزيد من المعلومات في هذا النهج من ستيف ماركس

Answer 5

إذا كنت بحاجة فعلا إلى تجنب GUIDs، فقد فكرت في استخدام شيء بناء على التاريخ / الوقت ثم الاستفادة من مفاتيح التقسيم لتقليل مخاطر التزامن.

يمكن أن يكون مفتاح التقسيم الخاص بك عن طريق المستخدم والسنة والشهر واليوم والساعة، وما إلى ذلك يمكن أن يكون مفتاح الصف هو بقية DateTime بسعر صغير بما يكفي للسيطرة على التزامن.

بالطبع عليك أن تسأل نفسك، بسعر التاريخ في أزور، إذا كان تجنب GUID يستحق كل هذا الجهد الإضافي (بافتراض أن GUID ستعمل فقط).