Kami menggunakan Google AppEngine untuk menjalankan kueri spasial / atribut dan masalah utama (dari hari pertama) adalah bagaimana mengindeks kumpulan garis / poligon berukuran besar secara sewenang-wenang. Data titik tidak terlalu sulit (lihat geohash, geomodel dll) tetapi kumpulan poligon kecil / besar yang dikelompokkan secara acak selalu menjadi masalah (dan dalam beberapa kasus, masih)
Saya sudah mencoba beberapa versi pengindeksan spasial yang berbeda pada GAE tetapi kebanyakan hanya dua varian di bawah ini. Tidak ada yang secepat database SQL dan semua memiliki pro / kontra. pengorbanan tampaknya masuk akal untuk sebagian besar aplikasi pemetaan berbasis internet sekalipun. Juga, dua di bawah ini perlu digabungkan dengan penyisihan geometri dalam memori (melalui JTS dll) untuk menghapus semua fitur yang tidak sesuai dengan parameter pencarian akhir. dan akhirnya, mereka bergantung pada fitur-fitur spesifik GAE tapi saya yakin itu bisa diterapkan ke arsitektur lain (atau menggunakan TyphoonAE untuk berjalan di cluster linux, EC2 dll)
Kisi - Kemas semua fitur untuk area tertentu ke dalam indeks kisi yang dikenal. Tempatkan indeks spasial kecil di grid sehingga Anda dengan cepat menavigasi set fitur yang dikandungnya. Untuk sebagian besar kueri, Anda hanya perlu menarik beberapa kisi yang cepat, karena Anda tahu konvensi penamaan kisi yang tepat dan bagaimana kaitannya dengan entitas K / V (mendapat, bukan kueri)
Pro - cukup cepat, mudah diimplementasikan, tanpa jejak memori.
Kontra - preproses diperlukan, pengguna perlu menentukan ukuran kisi, geom besar dibagikan pada beberapa kisi, pengelompokan dapat menyebabkan kisi menjadi kelebihan beban, biaya serialisasi / deserialisasi dapat menjadi masalah (bahkan ketika dikompresi melalui buffer protokol)
QuadKeys - Ini adalah implementasi saat ini. pada dasarnya sama dengan Grids kecuali tidak ada set level grid. ketika fitur ditambahkan, mereka diindeks oleh kisi-kisi kunci yang benar-benar berisi batas-batasnya (atau dalam beberapa kasus, dibagi menjadi dua ketika kunci tunggal tidak dapat digunakan, pikirkan dateline). Setelah qk ditemukan, maka dipecah menjadi jumlah maksimum qk yang lebih kecil yang memberikan representasi butir yang lebih baik dari fitur tersebut. pointer / bbox ke fitur tersebut kemudian dimasukkan ke dalam gridindex ringan (sekelompok fitur) yang dapat ditanyakan (desain asli menanyakan fitur secara langsung tetapi ini terbukti terlalu lambat / intensif CPU dalam kasus di mana hasilnya besar)
Quadline Polyline http://www.arc2earth.com/images/help/GAE_QKS_1.png
Polygon Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_2.png
Konvensi penamaan quadkey yang digunakan di atas sudah terkenal dan yang lebih penting, cenderung melestarikan lokalitas (dijelaskan lebih lanjut di sini )
Poligon di atas terlihat seperti ini: 0320101013123 03201010131212 03201010131213 0320101013133 0320101013133 03201010131302 03201010131303 032010101313002 032010101313003 0320101010131310
jika batas kueri cukup kecil, Anda dapat langsung mengambil melalui qk. ini optimal karena hanya satu, panggilan rpc batch ke datatore GAE. jika batasnya cukup besar sehingga mencakup terlalu banyak qks yang mungkin (> 1000) maka Anda dapat melakukan kueri menggunakan filter (mis: qk> = 0320101013 dan qk <= 0320101013 + \ ufffd). Konvensi penamaan quadkey plus cara GAE indexes strings memungkinkan kueri di atas untuk mengambil hanya grid yang ada yang jatuh di bawah nilai qk itu.
ada peringatan dan masalah perf lainnya tetapi secara umum, kemampuannya untuk query pada quadkey yang membuatnya layak
contoh - permintaan di negara bagian AS: geojson
Pro - cukup cepat, tidak ada konfigurasi ukuran grid, tidak ada jejak memori, tidak ada grid yang penuh sesak
Cons - preprocessing diperlukan, kemungkinan overfetch dalam beberapa skenario, tidak ada data polar
Space Filling Curves - Lihatlah pembahasan Alfred's NextGen Queries di Google I / O tahun ini. Dimasukkannya kurva pengisian ruang / waktu umum bersama dengan operator MultiQuery baru (berjalan secara paralel) akan memungkinkan untuk beberapa pertanyaan spasial yang sangat keren. Apakah akan mengalahkan kinerja SQL tradisional? Sulit dikatakan tetapi harus skala dengan sangat baik. Dan kami dengan cepat mendekati masa depan di mana perangkat seluler yang selalu ada dalam segala bentuk / ukuran akan secara dramatis meningkatkan lalu lintas ke situs / layanan Anda.
akhirnya, saya juga setuju bahwa Anda harus melihat dengan cermat domain masalah Anda sebelum memilih NoSQL di atas SQL. Dalam kasus kami, saya benar-benar menyukai model penetapan harga GAE sehingga benar-benar tidak ada pilihan tetapi jika Anda tidak perlu mengukur, menghemat waktu dan hanya menggunakan standar sql db