Bagaimana kami menambahkan pintu masuk ke peta dan mengurangi ukuran pangkalan sebesar 10%

Pada akhir bulan lalu, 2GIS mulai menampilkan beranda. Kami telah menunjukkan pintu masuk ke organisasi sejak 2013, dan pintu masuk tampaknya merupakan pintu masuk yang sama. Jadi mengapa sekarang? Semua produk dan proses internal siap, yang perlu Anda lakukan adalah menambahkan sedikit lebih banyak dan memperbaiki tampilan di UI.

Selain jawaban standar "Ada prioritas lain," ada juga yang tidak cukup standar: "Tidak begitu sederhana." Artikel ini adalah tentang kesulitan apa dan bagaimana kami menyelesaikannya.

Pertama, pintu masuk bukan pintu masuk. Jadi, dalam satu pintu masuk bisa mengarah beberapa pintu masuk, biasanya dari sisi bangunan yang berbeda. Definisi "blok apartemen (multi-level) dengan pintu masuk bersama" juga salah. Kebetulan bahwa satu pintu masuk mengarah ke lantai pertama dari pintu masuk, dan yang lainnya - ke lantai kedua dan selanjutnya.


Kedua, saya ingin mencari pintu masuk.


Ini adalah kesempatan yang cukup dicari, karena pintu masuknya jauh dari selalu terletak di jalan yang jelas.


Selain nomor masuk, ada juga nama (biasanya dari satu huruf).


Atau bahkan seperti di Kaliningrad - alamat terpisah diberikan tepat ke tangga.


Ketiga, kami memutuskan bahwa jika kami ingin melakukan pencarian pintu masuk, maka mengapa tidak segera mendukung pencarian dengan nomor apartemen. Mereka memutuskan - dan mengumpulkan rentang apartemen, sejauh ini tanpa lantai mengikat. Seperti halnya pintu masuk, apartemen tidak hanya memiliki nama numerik (paling sering ada varian dengan huruf "a"), dan rentangnya jauh dari selalu kontinu. Di rumah-rumah tua St. Petersburg, penomorannya agak aneh: apartemen 1 dan 3 bisa berada di pintu masuk yang sama, dan apartemen 2 bisa berada di seberang gedung.



Keempat, saya ingin selalu menunjukkan pintu masuk di peta, dan tidak hanya ketika kita mempelajari informasi rumah atau pintu masuk tertentu.

Dan, akhirnya, ada banyak pintu masuk - menurut perkiraan saat ini, ada sekitar seratus ribu di antaranya di Moskow saja. Penilaian pertama "di jari" memang memberikan beberapa angka astronomi - kami melakukan kesalahan setiap enam kali ke sisi yang lebih besar.

Kesimpulan:

• Kami membutuhkan entitas tambahan, yang memiliki namanya sendiri, berisi daftar rentang apartemen dan yang dapat dilampirkan di pintu masuk gedung.
• Kami akan mencari entitas ini dan akan menunjukkannya kartu informasi terpisah.
• Kami dipaksa untuk sekali lagi meningkatkan ukuran data yang diunduh oleh aplikasi seluler, atau menunjukkan data ini hanya jika ada koneksi jaringan, atau untuk membuat sesuatu dengan format.

Mendapatkan solusi

Dua poin pertama memerlukan perubahan pada produk internal dan eksternal, tetapi ini adalah rutin. Yang terakhir adalah masalah yang sama sekali berbeda. Karena kami tidak suka mengganggu pengguna, kami menetapkan batasan: data harus tersedia secara offline, dan menambahkannya tidak boleh menambah ukuran database.

Bagaimana? Di satu sisi, Anda perlu mengurangi ukuran data saat ini, di sisi lain, Anda dapat membuat format untuk menyimpan informasi tentang pintu masuk, sehingga jumlah data tambahan minimal.

Kurangi volume data

Ada dua cara untuk menguranginya:

• Perhatikan dengan cermat data yang disimpan dan cobalah untuk menemukan sesuatu yang bisa kita lakukan tanpa.
• Pikirkan apakah mungkin menyimpan data dengan lebih efisien daripada yang kita lakukan sekarang.

Singkirkan yang tidak perlu

Kami mulai mengurangi dengan mencari data yang dapat Anda singkirkan. Ternyata selama keberadaan format, kita telah belajar untuk melakukannya tanpa koneksi terbesar. Ini 10% dari ukuran!

Kode untuk data ini masih terikat, tetapi perubahan yang diperlukan cukup sepele. Namun aplikasi yang sudah dirilis tidak dapat dengan mudah diubah. Kami berusaha untuk mempertahankan selama mungkin tidak hanya mundur, tetapi juga kompatibilitas langsung. Dan jika yang pertama akrab bagi semua orang, maka banyak orang mungkin dengan senang hati tidak memikirkan yang kedua. Kami terpaksa mendukungnya karena ekor pengguna yang agak panjang, karena berbagai alasan, telah mematikan pembaruan otomatis dan tidak terburu-buru untuk beralih ke versi aplikasi yang baru.


Kami juga masih merilis data baru untuk versi beku untuk Windows Phone. Dan meskipun pengguna WP8 hanya membuat sebagian kecil dari pemirsa kami, dalam jumlah absolut ini hampir 200.000 per bulan.

Kami telah lama memiliki mekanisme yang memungkinkan kami menghasilkan beberapa format data, dan secara otomatis menentukan versi mana yang harus mendapatkan apa. Peluang itu bagus, tetapi Anda masih perlu belajar cara membongkar format ini. Tugas besar pertama adalah mengimplementasikan layanan yang akan menerima semua data dan menyaring yang baru untuk format database lama dan yang lama untuk yang baru.

Bonus bagus dari pekerjaan yang dilakukan adalah mengurangi ukuran pembaruan bulanan, karena koneksi jarak jauh telah sangat berubah dari bulan ke bulan, menggembungkan ukuran perbedaan.

Jika Anda melihat data yang tersisa, maka secara total Anda dapat menekan 10% yang sama, namun, harga akan jauh lebih tinggi. Sejauh ini kami memutuskan untuk tidak menyentuh.

Optimalkan format penyimpanan saat ini

Seperti yang tertulis di atas, kami membuat 1 halaman KiB dan mengemas tidak semua repositori biner.

Hal pertama yang kami lakukan adalah mencoba mengemas juga halaman-halaman dengan tautan, dan memeriksa apakah perbedaan dalam kecepatan menerima data ada di wilayah kesalahan.

Item berikutnya adalah memilih ukuran halaman optimal. Semakin besar ukuran halaman, semakin efisien data dikompresi, tetapi semakin lambat data diambil. Dan jika dengan meningkatnya ukuran halaman, waktu dan biaya memori tumbuh secara linear, maka keuntungannya menjadi semakin tidak terlihat. Setelah tes, kami memutuskan untuk menambah ukuran menjadi 8 KiB.


Secara total, hanya dua poin ini yang dapat mengurangi basis sebesar 18%!

Ubah format kompresi

zlib, tentu saja, adalah klasik, tetapi zstd memberikan kecepatan dekompresi yang lebih tinggi dengan rasio kompresi yang lebih besar. Selain itu, zstd memungkinkan Anda untuk membuat kamus tunggal untuk semua data yang tersedia, dan kemudian menyimpannya sekali dan mengompresnya dengan semua halaman. Jadi, kami memperlambat proses pembuatan file dengan database, tetapi kami memeras tambahan 8%.

Tambahkan beranda

Cara mudah

Cara termudah adalah dengan membuat setiap pintu masuk objek yang terpisah, indeks secara terpisah (sesuai dengan perkiraan kasar + 10% dari ukuran indeks), dan secara terpisah menyimpan geometri mereka dalam data untuk menggambar peta.

Metode ini akan mengembang basis dengan total 3%. Pada tahap sebelumnya, kami menang lebih dari cukup untuk menenangkan diri dan bekerja dengan pintu masuk sesuai dengan skema yang biasa, tetapi ... pada saat mulai bekerja, kami tidak yakin tentang hal ini, dan mengerjakan format alternatif secara paralel.

Opsi saat ini

Alih-alih mengindeks pintu masuk dan menggelembungkan indeks pencarian, kami mencari rumah, tetapi juga menandai kata-kata permintaan dan mengekstrak alamat dari itu (relevan untuk mencari pintu masuk di Kaliningrad), pintu masuk dan / atau apartemen. Jadi, di pintu keluar kita memiliki pengidentifikasi rumah dan bidang teks yang diketik, dimana kita harus menemukan tangga yang kita butuhkan.


Selanjutnya, alih-alih membongkar objek individual, kami menyertakan semua informasi tentang pintu masuk langsung ke data bangunan.
Dan akhirnya, kami mentransfer sebagian geometri ke direktori.

Yang terakhir layak diungkapkan secara lebih rinci.

Pertama, kami memperhatikan bahwa sebagian besar input adalah dua titik dan memiliki panjang yang sama. Input tersebut dapat disimpan dalam bentuk titik + arah, mis. simpan 1 byte per input.

Kedua, kami berasumsi bahwa sebagian besar rumah di kota-kota modern adalah tipikal, oleh karena itu, perpindahan titik-titik pintu masuk mereka relatif ke titik pusat rumah akan bertepatan hingga belokan.

Kami sudah memiliki titik pusat bangunan. , — «», — ? , json' , .

— , .

— . « - », json' . . json' , . — , , , json', , , .


, . , .

? 3% 0,5%. , ( ), .

Hasil

, 0,5% 26,6% . - , — «» , — 10,1%.


. ( 0,4%), , , .

?

, , . , ( ).

, , .

, , , .

One more thought: JSON

, JSON. Ini tidak sepenuhnya benar. , . rapidjson, .

JSON C++ UI, .

-, .

-, , UI-, , .

JSON' , UI , .