concurrentskiplistmap فرز: هل يمكن أن يتم ذلك بمقارنة القيمة؟

Question

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

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

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

هل سيتمكن أي شخص من اقتراح كيفية تحقيق هذا؟

Answer 1

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

Answer 2

get(key) يعتمد على المقارنة (لتكون قادرة على تحديد موقع المفتاح). تقترح مقارنة يعتمد عليها get(key) (للوصول إلى القيمة المعينة للمفتاح A مقارنة على ذلك). هذا يؤدي بالضرورة إلى عودة لا حصر لها و مكدس فائض (على الجانب المشرق ، أنت تنشر في الموقع الصحيح !!)

Answer 3

مايكل على حق ، لا يمكنك الحصول على كعكتك وتناولها أيضًا ؛)

أعتقد أن لديك 3 خيارات:

1. استخدم خريطة بحيث تكون التحديثات إلى درجة المستخدم سريعة ، ودفع السعر عند الفرز للعثور على أعلى الدرجات.
2. استخدم sortedset الذي يتم فرزه حسب النتيجة بحيث يكون العثور على أعلى الدرجات سريعًا ، ولكن يجب عليك دفع السعر عند تحديث درجات المستخدم
3. حافظ على هيكلين للبيانات ، بحيث يمكنك الحصول على أفضل ما في 1 و 2. على سبيل المثال ، لديك بياناتك الحقيقية في مجموعة مرتبة حسب النتيجة ، ولكن بعد ذلك ، تحافظ أيضًا على رسم خرائط للمستخدم للفهرس في المجموعة أو ما شابه. وبهذه الطريقة ، لديك دائمًا الدرجات المرتبة ، وتحديث درجة المستخدم مجرد بحث ، وليس بحثًا. السعر الذي تدفعه مقابل هذا هو الآن تحتفظ ببعض المعلومات المكررة في مكانين ، وخاصة بالنظر إلى الوصول المتزامن ، قد يكون من الصعب ضمان تحديث كلا المكانين دائمًا في التزامن.

لن أقدم افتراضات حول ما هو أسرع بين 1 و 2. سأحاول كل منهما مع الاستخدام المتوقع والقياس لمعرفة ما هو أسوأ.

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