هل تحتاج إلى تخزين 128 * بت * المفتاح الأساسي: هل يجب أن أستخدم SQL Azure أو Azure Table؟ أو مجرد استخدام قائمة مرتبطة في Azure Blob

Question

أحتاج إلى تخزين PK (128 بت). سيكون لكل int بعض الأعمدة المقابلة ... لا يتم تعريف أي مخطط الآن ... وأريد أن يكون المخطط مرنًا في المستقبل. (أنا فقط بحاجة إلى مرونة محافظة على سبيل المثال إضافة أعمدة جديدة من وقت لآخر)

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

ما هي أفضل تقنية للتعامل مع هذا الطلب؟ أنا مهتم بشيء يوفر لي المال (لكل معاملة) ، ومساحة تخزين. أنا مهتم أيضًا بالأداء.

بماذا توصي؟

تحديث

حسنًا ، ما هذا؟ أرغب في إنشاء تاريخ من البيانات لعناوين IPv6. بالطبع سيكون هذا جدولًا متفرقًا للغاية ... لكنني بحاجة إلى تتبع أشياء معينة فيما يتعلق بـ IP.

Answer 1

ستكون جداول Windows Azure هي توصيتي ، ولكن لا يوجد سوى ترتيب من النوع واحد محدد ، لذلك سيكون من الصعب البحث إلى الأمام والخلف. قد ينتهي بك الأمر إلى تخزين كل مفتاح مرتين ، مرة واحدة في الترتيب العادي ، وبمجرد عكس (0xFFF ... مفتاح) لدعم كل من اتجاهات المسح الضوئي بكفاءة.

Answer 2

للتوضيح ، أعتقد أنك بحاجة إلى مفتاح 128 بت (وليس 2^128 بت).

أنا أتناول هذا كمسألة حول اختيار نوع مفتاح DB ، لست متأكدًا من العواقب التي تثيرها زاوية Azure. AFAIK هو بناء على رأس MS-SQL.

128 بت أو 16 بايت هو نفس حجم GUID (فريد من نوعه) لكنني لا أعتقد أنك تريد استخدام ذلك. على الرغم من وجود دعم لاستخدامه كمفتاح.

سيكون الخيار المباشر مثل Binary (16) ، لكنني لا أعرف مدى ملاءمة ذلك كـ PK.

يمكنك ترميزها كسلسلة char (32) Hex ، وهذا ليس مفرطًا.

بالنسبة لتقديرات التطبيق العملي ، فإن العامل الرئيسي هو مدى تفوق بياناتك ، أو أفضل: كم عدد العناوين التي تتوقع تخزينها؟

Answer 3

بادئ ذي بدء ، فرضيتك في 2^128 INTEGER KEYS خاطئة ، لأنك ذكرت أنك تريد تخزين عناوين IP V6. يبلغ طول عنوان IP V6 128 بت. لتخزينها كصبع عدد صحيح ، تحتاج إلى 128/32 أو 4 أعداد صحيحة 32 بت لكل عنوان. وبالتالي فإن التقدير الصحيح هو 2^128 عناوين محتملة * 4 أعداد صحيحة ليصبح المجموع 2^128 * 4 مفاتيح الأعداد الصحيحة 32 بت ....

على أي حال ، أريد ذلك بالبايت ، لذلك سنذهب فقط 2^128 عناوين محتملة * 4 أعداد صحيحة * 4 بايت لكل عدد صحيح = 5.44 * 10^39 بايت. بعد ذلك ، اتبع حساب أندرياس وسوف ينتهي بك الأمر إلى المزيد ....

ومع ذلك ، فإن فكرة IP V6 هي أن لدينا عناوين أكثر مما نحتاج إلى استخدامه. لذلك أشك بشدة في أي مكان بالقرب من 2^128 سيتم تعيينه لسنوات عديدة. على الأكثر إذا ذهبنا إلى IP V6 في الوقت الحالي ، سيكون لدينا مساحة عنوان IP V4 تم تعيينها ولا شيء آخر ، وعلى الرغم من أن عدد عناوين IP يزيد كل عام ، وليس بهذا القدر.

على أي حال ، يبدو أنك لا تعرف ما الذي تقوم بتخزينه لأن المخطط غير محدد ، لذا قد يكون جدول Azure هو ما تريده. في الغالب هو المفتاح/القيمة. لكل عنوان IP يمكنك تخزين خصائص مختلفة تمامًا. ومن السهل حقًا إضافة خاصية أخرى/إزالة خاصية أخرى باستخدام عمليات التحديث/الإدراج/الدمج. ولكن إذا كنت تريد تطبيق بعض التوحيد على بياناتك بدلاً من استخدام SQL. صحيح أنه سيتعين عليك تعديل المخطط مع حدوث تغييرات ، لكن هذا سيؤلف أن كل صف (وبالتالي عنوان IP) لديه نفس البيانات. وإلا ، فمن السهل الخروج من أعمدة/خصائص "المطلوبة" أو أخطقها إذا كان لديك تطبيقات متعددة. لكنه يعتمد حقًا على ما تريد القيام به. هل تقدر أكثر سلامة البيانات أم أنك تقدر مرونة الخصائص؟ على الرغم من أن المخطط يجب تغييره ، إلا أن هناك أوامر لإضافة/إزالة الأعمدة من المخطط. أكثر هل تريد أن يقوم كل عنوان IP بتخزين نفس الخصائص أو يمكن أن يكون لكل منها خصائص مختلفة. أعتقد أن طريقة جدول Azure ربما تأخذ تخزينًا أقل لكل عنوان من طريقة SQL إذا كنت لا تستخدم معظم الخصائص لعنوان IP معين. لذلك كل هذا يتوقف على ما تبحث عنه.