في نهاية الشهر الماضي ، بدأت 2GIS في عرض الشرفات. لقد أظهرنا المداخل للمؤسسات منذ 2013 ، ويبدو أن المداخل هي نفس المداخل. فلماذا الآن؟ جميع المنتجات والعمليات الداخلية جاهزة ، كل ما عليك فعله هو إضافة المزيد وتصحيح العرض في واجهة المستخدم.
بالإضافة إلى الإجابة القياسية "كانت هناك أولويات أخرى" ، هناك أيضًا إجابة غير قياسية تمامًا: "إنها ليست بهذه البساطة". تتناول هذه المقالة الصعوبات التي تم حلها وكيفية حلها.
أولاً ، المدخل ليس المدخل. لذلك ، في مدخل واحد يمكن أن يؤدي إلى عدة مداخل ، عادة من جوانب مختلفة من المبنى. تعريف "كتلة (متعددة المستويات) من الشقق ذات المدخل المشترك" غير صحيح أيضًا. يحدث أن يؤدي أحد المدخل إلى الطابق الأول من المدخل ، والآخر - إلى الطابق الثاني والطوابق اللاحقة.
ثانيًا ، أريد البحث عن المداخل.
هذه فرصة مرغوبة جدًا ، نظرًا لأن المداخل بعيدة عن أن تكون دائمًا موجودة بطريقة واضحة.
بالإضافة إلى أرقام الدخول ، هناك أيضًا أسماء (عادة من حرف واحد).
أو حتى
في كالينينغراد - يتم تعيين عنوان منفصل للسلم.
ثالثًا ، قررنا أنه إذا قمنا بالبحث عن المداخل ، فلماذا لا ندعم البحث برقم الشقة على الفور. قرروا - وجمعوا نطاقات الشقق ، حتى الآن ، دون ربط الكلمة. كما هو الحال مع المداخل ، لا يمكن أن تحتوي الشقق على أسماء رقمية فقط (غالبًا ما تكون هناك متغيرات بالحرف "a") ، والنطاقات بعيدة عن كونها مستمرة دائمًا. في المنازل القديمة في سانت بطرسبرغ ، يكون الترقيم غريبًا إلى حد ما: يمكن أن تكون الشقق 1 و 3 في نفس المدخل ، ويمكن أن تكون الشقة 2 في الجزء المقابل من المبنى.
الاستطراد الغنائي حول التحقق من صحة البياناتلا تحاول أن تجعل التحقق من صحة البيانات التي تم جمعها ذكيًا جدًا - في العاصمة الشمالية هناك حالات يمكنك فيها الدخول إلى شقة واحدة من عدة مداخل ، وفي بعض المستوطنات الأوروبية يحتوي العنوان بالإضافة إلى المنزل على اسم المدخل ورقم الشقة في هذا المدخل. يرضي بيتر أيضًا بمبنى له مدخلين ثامن.
رابعاً ، أريد أن أظهر المداخل على الخريطة دائماً ، وليس فقط عندما ندرس معلومات منزل أو مدخل معين.
وأخيرًا ، هناك العديد من المداخل - وفقًا للتقدير الحالي ، هناك حوالي مائة ألف منها في موسكو وحدها. التقييم الأول "على الأصابع" أعطى بعض الأرقام الفلكية - لقد ارتكبنا خطأ مرة كل ست مرات إلى الجانب الأكبر.
الاستنتاجات:- نحتاج إلى كيان إضافي ، يحمل اسمه الخاص ، يحتوي على قائمة من نطاقات الشقق التي يمكن إرفاق مداخل المبنى بها.
- سنبحث عن هذا الكيان وسنظهر له بطاقة معلومات منفصلة.
- نحن مضطرون إما لزيادة حجم البيانات التي تم تنزيلها بواسطة تطبيق الهاتف مرة أخرى ، أو لإظهار هذه البيانات فقط إذا كان هناك اتصال بالشبكة ، أو أن نخرج بشيء بالتنسيق.
الوصول إلى الحل
تتطلب النقطتان الأوليان تغييرات في كل من المنتجات الداخلية والخارجية ، ولكن هذا أمر روتيني. هذا الأخير هو مسألة مختلفة تمامًا. نظرًا لأننا لا نرغب في إزعاج المستخدمين ، فقد وضعنا قيودًا: يجب أن تكون البيانات متاحة في وضع عدم الاتصال ، ويجب ألا تؤدي إضافتها إلى زيادة حجم قواعد البيانات.
كيف؟ من ناحية ، تحتاج إلى تقليل الحجم الحالي للبيانات ، من ناحية أخرى ، يمكنك التفكير في مثل هذا التنسيق لتخزين المعلومات حول المداخل بحيث تكون كمية البيانات الإضافية ضئيلة.
تقليل حجم البيانات
هناك طريقتان لتقليله:
- انظر بعناية إلى البيانات المخزنة وحاول العثور على شيء يمكننا الاستغناء عنه.
- فكر فيما إذا كان من الممكن تخزين البيانات بطريقة أو بأخرى بطريقة أكثر كفاءة مما نقوم به الآن.
تطور تنسيق تخزين البيانات قبل عصر الشرفاتالخيار الأول والأسهل
الطريقة التقليدية لحفظ البيانات المعقدة هي
تطبيعها ووضعها في قاعدة بيانات الجدول وإنشاء
فهارس مساعدة. ذات مرة ، قام 2GIS بذلك فقط ، باستثناء تقليل الحجم ، تم فرز محتويات كل جدول بحيث تتطابق قيم الخلية كلما أمكن ذلك مع قيم الصف السابق. قمنا بتخزين الأعمدة بشكل مستقل ، وتسلسل مطوي لقيم متطابقة.
مثال مبسط للغاية لتحسين تخزين طاولة مع المباني:
يسمح لك التطبيع بتقليل التكرار ، ولكن هناك أيضًا جانب سلبي - من أجل تكوين عنصر واجهة مستخدم لبعض الكائنات ، يجب عليك إجراء العديد من الاستعلامات التي تصل إلى عدد كبير من الجداول. ومع ذلك ، في ذلك الوقت ، تم استخدام هذه الجداول ليس فقط للحصول على البيانات للعرض ، ولكن لجميع المهام تقريبًا ، بما في ذلك البحث عن النص وأنواع مختلفة من البحث عن السفر. لجميع هذه المهام ، سمحت لنا البيانات الطبيعية فقط بتقليل كمية المعلومات المعالجة.
البيانات الخاصة بعرض الخريطة لها بالفعل تنسيق ثنائي خاص بها وتم تخزينها في كتلة منفصلة. تدريجيا ، قمنا بعمل تنسيقات ثنائية منفصلة لتسريع البحث عن الاتجاهات والبحث عن النصوص. تم ترك المعلومات فقط في قاعدة البيانات ، والتي تم استخدامها لعرض بطاقات الكائنات ، وكذلك لروابط بعض الكائنات مع الآخرين.
تبسيط العمل
كيف يمكنك تبسيط العمل مع البيانات؟ تلقي جميع البيانات اللازمة لسحب البطاقة في وقت واحد عن طريق معرف الكائن. نظرًا لأن
الإصدار عبر الإنترنت يتلقى بالفعل جميع البيانات من
واجهة برمجة التطبيقات لطلب واحد
بتنسيق JSON ، يمكنك في الوقت نفسه دمج التنسيقات المستخدمة في جميع منتجاتنا.
يجب أن يتم استلام كل من json لعرض البطاقات ، والاتصالات لعدد محدود من الأشياء ، من قوة عدة عشرات في كل مرة. ولكن هناك سيناريوهات حيث يلزم الحصول على السمات الفردية في وقت واحد للعينات الكبيرة ، حتى مئات الآلاف. من المنطقي أكثر فصل هذه السمات إلى كيان منفصل بتنسيق تخزين منفصل - خصائص. يمكن أن تكون الخصائص من النوع وتخزينها بشكل أكثر كفاءة في تنسيق ثنائي.
نهج ساذج لتخزين json هو استخدام قاعدة بيانات ذات قيمة رئيسية. خذ موسكو كمثال ، كأكبر مشاريعنا. حتى في أبسط شكل ممكن - لكل كائن يتم تخزين json نفسه ، 8 بايت من المعرف وحرف محدد - سيستغرق الدليل 1.9 غيغابايت. الحجم الناتج أكبر تقريبًا بست مرات من الخيار السابق الموصوف ، ولا يزال هذا بدون روابط وخصائص.
قمنا بتضخيم الأشياء عن عمد عن طريق حشوها بمعلومات حول كل شيء قد يكون مطلوبًا لعرض بطاقاتها ، ولكنك لا تزال بحاجة إلى تخزين أسماء الحقول وعلامات الاقتباس والفواصل والأقواس.
ضغط البيانات
التطبيع ليس الطريقة الوحيدة للقضاء على التكرار. الطريقة الشعبية الثانية هي الضغط. يأخذ أرشيف lzma لملفنا السميك بشكل لا يصدق 55 MiB فقط.
بالطبع ، لا يمكننا استخدام هذا التنسيق مباشرة ، لأنه للوصول إلى كائن تعسفي ، نحتاج إلى فك جميع البيانات المخزنة في وقت سابق ، ولا يتم فك أرشيف lzma بسرعة كبيرة.
كيف يمكننا الحصول على وصول عشوائي سريع من ناحية ، ومن ناحية أخرى ، عن طريق ضغط البيانات ، تقليل حجم المساحة المطلوبة؟ الجواب هو استخدام ترقيم الصفحات.
الآن بعد أن تم ترقيم البيانات ، يمكننا ضغط كل واحد على حدة. للوصول إلى مكان عشوائي ، نحتاج إلى فك ضغط الصفحة ومسحها ضوئيًا ، ولكن هذا أسرع بكثير من تفريغ الأرشيف بأكمله ومسحه ضوئيًا.
في هذا التنسيق ، يتم تخزين جميع البيانات - json'y والعلاقات والخصائص. يبقى ربط هذه البيانات مع معرفات الكائنات. لكل معرف ، نحتاج إلى تخزين زوج واحد أو أكثر
<رقم التخزين ، رقم البيانات في التخزين> .
يتم تخزين جميع الأرقام التسلسلية والإزاحة والأحجام بتنسيق مضغوط مشابه لـ
UTF-8 ، حيث تأخذ القيم الصغيرة بايت واحد فقط. هذا يسمح لنا بتقليل حجم الروابط ببساطة عن طريق فرز محتويات المستودعات الثنائية لتقليل تكرار حدوثها.
تحتوي بعض الخصائص على العديد من قيم التردد ، وبالتالي يعطي الفرز زيادة كبيرة في الحجم. من ناحية أخرى ، بسبب ذلك ، لا يمكن أن يتطابق الرقم التسلسلي للبيانات لجميع المخازن.
أيضًا ، بعيدًا عن جميع الكائنات ، توجد بيانات في جميع المخازن ، وبالتالي فإن تخزين أرقام التخزين أكثر كفاءة من الإشارة إلى الكائنات الفارغة.
تسريع استرجاع البيانات
التنسيق الموصوف به مشكلة واحدة. للعثور على رقم الكائن الذي يخزن الفهارس للمعرف المحدد ، نحتاج إلى إجراء بحث ثنائي داخل بيانات الكائن الأول. للقيام بذلك ، تحتاج إما إلى تحميل 10.9 ميغابايت في الذاكرة ، أو القيام بـ 21 قراءات إضافية. كلا الحلين غير مناسبين لنا ، وبالتالي نقوم بتقليل عدد القراءات عن طريق تخزين البيانات في شجرة.
نقوم بتجميع البيانات على 32 كائنًا ، وفي المستويات المتوسطة نقوم بتخزين 128 من المعرفات الأولى للعقد المتداخلة. أضفنا ثلاثة مستويات من الشجرة وخفضنا عدد القراءات الإضافية إلى أربعة (ولكن في الواقع ، مع مراعاة التخزين المؤقت لعقد الشجرة التي تمت قراءتها سابقًا ، حتى 1-3). السعر - أقل بقليل من 400 كيلوبايت.
في هذه المرحلة ، نحن فعالون جدًا في تخزين العلاقات والممتلكات ، لكن json تشغل مساحة كبيرة. هذا أمر مفهوم. كلما كبر حجم الصفحة ، زاد عدد الكائنات هناك وكلما كانت خوارزمية الضغط أفضل لتحديد المعلومات الزائدة عن الحاجة. ولكن ، من ناحية أخرى ، كلما زاد العمل الذي يتعين علينا القيام به لقراءة كائن واحد. Json's هي أشياء كبيرة جدًا ، وبالتالي هناك عدد قليل جدًا منها في صفحة واحدة. لذلك ، تحتاج إلى مساعدة الخوارزمية على القيام بعملها بشكل أفضل.
كسر جبسون إلى أجزاء
أولاً ، تحتوي العديد من الكائنات على مخططات بيانات متطابقة ؛ تختلف قيم السمات فقط. ثانيًا ، العديد من قيم السمات هي نفسها حتى للكائنات ذات المخططات المختلفة. سنقوم بفصل المخططات وقيم السمات إلى مخازن منفصلة ، وسنقوم بتخزين json في الشكل: رابط إلى مخطط + روابط لقيم السمات.
في مخطط البيانات لدينا ، عدد أسماء السمات محدود. حتى نتمكن من وضعها في ملف منفصل وتخزين الرقم بدلاً من ذلك. سنقوم أيضًا بإجراء بعض التغييرات الإضافية ، مع الأخذ في الاعتبار أن json هي دائمًا كائنات.
نعم ، لقد ضغطنا بشكل أساسي على بياناتنا بأنفسنا ، مما قلل من نطاق عمل الخوارزمية. ولكن من ناحية أخرى ، قمنا بإبطاء الوصول إلى البيانات إلى حد ما ، ولا تزال الخوارزمية تساعد ، ضغط القيم المماثلة المخزنة في مكان قريب.
قمنا بتعيين حجم الصفحة على 1 كيلوبايت وتبين أنه بينما قمنا بتحسين التنسيق بحيث ، من ناحية ، لم تكن القراءة بطيئة للغاية ، ومن ناحية أخرى ، كانت البيانات ممتلئة قدر الإمكان ، ... لقد تجاوزنا بالفعل "الجداول المحسنة" سواء في الحجم أو لسهولة الاستخدام. ولكن ليس من أجل لا شيء أن كل هذا كان! يجب أن يكون الحد الأقصى للربح من ضغط قيم السمات والخصائص والمخططات. نحن نحرض على zlib ونتحقق من أن قراءة البيانات من قاعدة البيانات تستغرق وقتًا قصيرًا على خلفية بقية العمل. راضيا عن النتيجة ، ننتقل إلى مهام أخرى.
تخلص من ما هو غير ضروري
نبدأ في التقليل من خلال البحث عن البيانات التي يمكنك التخلص منها. اتضح أنه خلال وجود التنسيق ، تعلمنا الاستغناء عن أكبر اتصال. هذا هو 10٪ من الحجم!
لا يزال رمز هذه البيانات مرتبطًا ، لكن التغييرات الضرورية تافهة جدًا. ولكن لا يمكن تغيير التطبيقات التي تم إصدارها بالفعل بسهولة. نحن نسعى جاهدين للمحافظة على أطول فترة ممكنة ليس فقط للوراء ، ولكن أيضًا للتوافق المباشر. وإذا كان الأول مألوفًا للجميع ، فربما لا يفكر الكثيرون في الثانية. نحن مضطرون إلى دعمه بسبب الذيل الطويل نوعًا ما للمستخدمين الذين قاموا ، لأسباب مختلفة ، بإيقاف التحديثات التلقائية ولا يسارعون إلى التبديل إلى إصدار جديد من التطبيق.
توزيع المستخدم حسب الإصدارفي أعلى القائمة هو توزيع المستخدمين حسب أحدث إصدارات تطبيق Android. الجزء السفلي هو iOS.
من السهل ملاحظة أن مستخدمي أجهزة iOS يتم تحديثهم بسهولة أكبر ، ولكن حتى بينهم يوجد الكثير من مستخدمي الإصدارات القديمة.
ما زلنا نقوم أيضًا بإصدار بيانات جديدة للنسخة المجمدة لـ Windows Phone. وعلى الرغم من أن مستخدمي WP8 يشكلون جزءًا صغيرًا فقط من جمهورنا ، إلا أن العدد المطلق هو 200.000 شهريًا تقريبًا.
لدينا منذ فترة طويلة آلية تسمح لنا بإنتاج العديد من تنسيقات البيانات ، وتحدد تلقائيًا الإصدارات التي يجب أن تحصل على ما. الفرصة جيدة ، ولكنك ما زلت بحاجة إلى معرفة كيفية تفريغ هذه التنسيقات. كانت المهمة الكبيرة الأولى هي تنفيذ خدمة ستستقبل جميع البيانات وتصفية الجديد لتنسيق قاعدة البيانات القديمة والقديمة للجديد.
مكافأة لطيفة من العمل المنجز هي تقليل حجم التحديثات الشهرية ، نظرًا لأن الاتصال عن بُعد قد تغير بشكل كبير من شهر لآخر ، مما يؤدي إلى تضخم حجم الاختلافات.
إذا نظرت إلى البيانات المتبقية ، في المجموع ، يمكنك الضغط على نفس 10 ٪ ، ومع ذلك ، فإن السعر سيكون أعلى بشكل لا يضاهى. قررنا حتى الآن عدم لمس.
تحسين تنسيق التخزين الحالي
كما هو مكتوب أعلاه ، قمنا بإنشاء 1 صفحة KiB ولم نحزم جميع المستودعات الثنائية.
أول شيء نقوم به هو محاولة حزم الصفحات ذات الروابط أيضًا ، والتحقق من أن الاختلاف في سرعة استقبال البيانات يقع في منطقة الخطأ.
العنصر التالي هو اختيار حجم الصفحة الأمثل. كلما كبر حجم الصفحة ، زادت فعالية ضغط البيانات ، ولكن كلما تم جلب البيانات بشكل أبطأ. وإذا زاد حجم الوقت وتكاليف الذاكرة بشكل خطي مع زيادة حجم الصفحة ، يصبح الكسب أقل وأقل ملحوظة. بعد الاختبارات ، قررنا زيادة الحجم إلى 8 KiB.
تأثير حجم الصفحة على التحديدات الكبيرةإذا كان من المتوقع أن يؤدي توسيع الصفحة إلى إبطاء التحديدات الصغيرة ، فإنه يتم تسريع التحديدات الكبيرة - من بين مئات العناصر. هذا يعني أنه بطريقة جيدة تحتاج إلى اختيار أحجام مختلفة للتخزين اعتمادًا على حالات استخدام البيانات المخزنة فيها.
في المجموع ، يمكن لهذه النقطتين فقط تقليل القاعدة بنسبة 18٪!
قم بتغيير تنسيق الضغط
zlib ، بالطبع ، كلاسيكي ، لكن
zstd يوفر سرعة ضغط أعلى مع نسبة ضغط أكبر. علاوة على ذلك ، يسمح لك zstd أولاً ببناء قاموس واحد لجميع البيانات المتاحة ، ثم حفظه مرة واحدة وضغطه مع جميع الصفحات. وبالتالي ، فإننا نقوم بإبطاء عملية إنشاء ملف بقاعدة بيانات بشكل لائق ، لكننا نضغط بنسبة 8 ٪ إضافية.
أضف شرفات
طريقة سهلة
أسهل طريقة هي جعل كل مدخل كائنًا منفصلاً ، وفهرسه بشكل منفصل (وفقًا لتقديرات تقريبية + 10٪ من حجم الفهرس) ، وتخزين هندسته بشكل منفصل في البيانات لرسم الخريطة.
ستؤدي هذه الطريقة إلى تضخيم القاعدة بنسبة 3٪. في المراحل السابقة ، فزنا بأكثر من كافٍ للتهدئة والعمل مع المداخل وفقًا للمخطط المعتاد ، ولكن ... في وقت بدء العمل ، لم نكن متأكدين من ذلك ، وكان العمل على شكل بديل بالتوازي.
تقييم مفصل للمهتميندعنا نحاول تقييم الزيادة في حجم الحزمة مع قاعدة البيانات لكل كائن:
8 بايت - المعرف ،
6 بايت - عدد المخازن المستخدمة (البيانات + خمس خصائص ؛ يتم استخراج الخصائص من البيانات الرئيسية وتخزينها في شكل ثنائي ، حيث أنها مطلوبة غالبًا لعدد كبير من الكائنات في وقت واحد) ،
3 بايت - فهرس في مستودع البيانات ،
2 بايت - إزاحة بيانات الكائن ،
5 بايت - قيم البيانات - 2 بايت لكل دائرة ، 3 بايت في المتوسط لمعلومات الشقة (نعتقد أنه سيكون هناك العديد من التكرارات ويتم تخزين البيانات نفسها مرة واحدة) ،
6 بايت - إزاحة إحداثيات البيانات (الخصائص الأخرى لها العديد من القيم المكررة وستنهار) ،
8 بايت - تنسيق القيم.
إجمالي 38 بايت لكل كائن. في حالة موسكو ، يبلغ 4.5 ميغابايت لأكثر من 124 ألف مدخلات مجمعة.
بعد ذلك ، نحتاج أيضًا إلى تخزين الاتصال بين المنزل والمداخل ، وهو 2.5 بايت لكل مبنى سكني و 8 بايت لكل مدخل. 1 MiB آخر.
الآن نحن نفكر في مقدار كل هذا سيستغرق على الخريطة.
أولاً ، يجب علينا تخزين الهندسة. بالنسبة للخطوط المتعددة ، تأخذ النقطة الأولى دائمًا 8 بايت ، ويتم تخزين جميع النقاط اللاحقة على أنها تختلف عن الدقة المطلوبة. نحن هنا راضون عن دقة وحدات القياس. تتكون معظم المدخلات من نقطتين ليستا بعيدتين جدًا عن بعضهما البعض ، وبالتالي يمكن افتراض أن الهندسة نفسها ستشغل 10 بايت. المجموع 1.2 ميبا.
نحتاج أيضًا إلى ربط معرف الإدخال والكائن بهندسته. الفهرس هو نفس التخزين الثنائي مثل أي شيء آخر ، يتم تخزين وجهة الاتصال فقط (1 بايت) ورقم الطبقة (1 بايت) ورقم الكائن (3 بايت). بالإضافة إلى 8 بايت لكل معرف ، بالإضافة إلى شجرة بحث سريعة. إجمالي آخر 1.5 ميغا بايت.
كما قيل في بداية المقال ، نريد عرض المداخل على الخريطة باستمرار ، والطريقة الأسهل للقيام بذلك هي تفريغ طبقة أخرى بالنقاط ، ولكن ... يمكنك أيضًا إعادة استخدام الطبقة مع الأشكال الهندسية ، وإنشاء
رمز جديد سيعرض الصورة التي نحتاجها في النقطة الأخيرة من الخطوط المتعددة.
10 ٪ من فهرس البحث هو 5.9 ميجابايت. تلخيص كل شيء ، نحصل على 14.2 MiB ، وهو ما يزيد قليلاً عن 3 ٪.
الخيار الحالي
بدلاً من فهرسة المداخل وتضخيم فهرس البحث ، نبحث عن منازل ، ولكن بالإضافة إلى ذلك ، نقوم بترميز كلمات الاستعلام واختيار العناوين منها (ذات الصلة بالبحث عن المداخل في كالينينغراد) ، والمداخل و / أو الشقق. وبالتالي ، عند المخرج ، لدينا معرف المنزل وحقول النص المكتوبة ، والتي من خلالها يجب أن نجد الدرج الذي نحتاجه.
ملاحظةهذه نقطة مثيرة للجدل. من ناحية ، يسمح لنا بتقليل حجم قاعدة البيانات ، ومن ناحية أخرى ، يضع قيودًا على تنسيق الإدخال - لن تكون المداخل في العديد من الطلبات التي سيتم معالجتها بشكل صحيح باستخدام البحث الصادق.
علاوة على ذلك ، بدلاً من تفريغ الأشياء الفردية ، نقوم بتضمين جميع المعلومات حول المداخل مباشرة في بيانات المبنى.
وأخيرًا ، ننقل جزءًا من الأشكال الهندسية إلى الدليل.
هذا الأخير يستحق الكشف بمزيد من التفصيل.
أولاً ، نلاحظ أن معظم المدخلات هي نقطتان ولهما نفس الطول. يمكن تخزين هذه المدخلات في شكل نقطة + اتجاه ، أي حفظ 1 بايت لكل إدخال.
ثانيًا ، نفترض أن معظم المنازل في المدن الحديثة نموذجية ، وبالتالي ، فإن تهجير نقاط مداخلها بالنسبة للنقطة المركزية للمنزل سيتزامن إلى منعطف.
لدينا بالفعل النقاط المركزية للمباني.
ماذا لو أضفنا خاصية جديدة للمبنى - "الاتجاه" الصحيح الخاص به ، ولكل إدخال اثنين من الإزاحات الصحيحة - بالأرقام العشرية على طول وخط عمودي على خط الاتجاه؟ بالنظر إلى كيفية تخزين json مع المعلومات ، ستشغل هندسة الإدخال في المتوسط ما يزيد قليلاً عن وحدتي بايت.مكافأة إضافية هي أنه نظرًا لأن الهندسة موجودة في الدليل ، فإننا لم نعد بحاجة إلى تخزين المراسلات بين معرف الإدخال ورقم الكائن في طبقة الخريطة.ناقص - أصبح الرمز أكثر تعقيدًا. في وقت سابق قلنا للتو الخريطة "إظهار مثل هذه الأشياء" ، والآن عند عرض المدخلات نستخرج هذه البيانات من json ونضيف كائنات ديناميكية إلى الخريطة. كل شيء ليس مخيفا جدا هنا. بحلول وقت عرض مفاتيح الأسهم لمدخلات json ، لدينا بالفعل الكائنات المقابلة ، أي أنه لا توجد حاجة للذهاب إلى قاعدة البيانات. مع نقاط الدخول المعروضة ، كل شيء أسوأ قليلاً - الآن علينا أن نحدد في الخلفية المنازل التي يمكن رؤيتها ، وسحب بيانات هذه المنازل من قاعدة البيانات ، وتحليل json ، وإذا كان هناك مدخلات ، قم بإنشاء كائنات ديناميكية لها.نظرًا لأننا قد كتبنا بالفعل كودًا إضافيًا لعرض مداخل المداخل ، فلا شيء يمنعنا من البدء في تخزين المدخلات ذات النقطتين في المؤسسة في الدليل. المكاسب في هذه الحالة ستكون صغيرة ، ولكنها مجانية.كم قدم لنا؟ 3٪ تحول إلى 0.5٪. كان بإمكاننا أن نفعل أقل من ذلك ، لكننا تركنا معرّفات في البيانات (التي يتم ضغطها بشكل سيء إلى حد ما) لتبسيط معالجة رسائل المستخدم حول المدخلات غير الدقيقة.النتيجة
أضفنا عددًا كبيرًا من المداخل ، مع تقليل حجم الملف ببيانات الخريطة بنسبة 0.5٪ وتقليل حجم الملف ببيانات الدليل بنسبة 26.6٪. هذا الأخير لا يزال أكبر ملفاتنا ، ولكنه واحد فقط من الملفات "الثقيلة" الأربعة ، لذلك تبين أن التغيير الإجمالي كان أكثر تواضعا - 10.1٪.لم يتم جمع المداخل بعد. سيزداد حجم القواعد قليلاً بمرور الوقت (وفقًا للتقديرات الحالية ، ستزيد موسكو نفسها بنسبة 0.4٪) ، ولكن على أي حال ، فإن الهدف هو إطلاق المداخل دون زيادة الحجم ، أكثر مما تم تحقيقه.ما هي الخطوة التالية؟
إذا تحدثنا عن تحسينات البقالة ، فسوف ندعم المداخل والشقق في نصائح البحث ، وكذلك في البحث عن نقاط البداية والنهاية للبحث عن الاتجاهات. نفكر أيضًا في عرض مداخل مهمة للمباني (خاصة في مراكز التسوق) بنفس طريقة عرض الشرفات.في الخطط الفنية ، هناك فحص للعديد من الأفكار التي يمكن أن تؤدي إلى مزيد من التخفيض في حجم الملف بالبيانات المرجعية ، وتحتاج إلى النظر بعناية في الملفات الأخرى.وبالطبع سنقوم بتصحيح الأخطاء التي لدينا حتى الآن.فكرة أخرى: استخدم JSON بحكمة
مما سبق ، يشير الاستنتاج إلى أنه لا يمكنك التفكير كثيرًا في التنسيقات الثنائية واستخدام JSON فقط. هذا ليس صحيحًا تمامًا.
هذا يعمل لصالحنا ، لأنه في نفس الوقت نحتاج إلى استقبال عدة عشرات من الأشياء من القوة. بالإضافة إلى ذلك ، نستخدم Rapidjson ، وهو ذكي جدًا ويستهلك القليل من الذاكرة.يجدر أيضًا تقييد نقل بيانات JSON من C ++ إلى واجهة المستخدم المكتوبة بلغة أخرى.أولاً ، عليك تحويلها إلى سلسلة.ثانيًا ، سيعيد المحللون المتاحون من جزء واجهة المستخدم تجميع هذا الخط ، وسيفعلونه بشكل أبطأ.من الأفضل الحصول على جميع البيانات من JSON بنفسك ، ورمي واجهات بسيطة مكيفة لعرض عناصر محددة في جانب واجهة المستخدم.