Kapan sebaiknya Anda TIDAK menggunakan indeks spasial?


29

Saya menanyakan hal ini karena saya terutama bekerja dengan Oracle tetapi selama setahun terakhir saya telah menggandakan PostGIS dan SQLServer 2008. Sebagian besar fungsi spasial di Oracle tidak akan bekerja tanpa indeks spasial yang mengembalikan kesalahan ORA-13226:

13226, 00000, "antarmuka tidak didukung tanpa indeks spasial" // * Penyebab: Tabel geometri tidak memiliki indeks spasial. // * Tindakan: Pastikan tabel geometri yang dirujuk dalam operator spasial memiliki indeks spasial di atasnya.

Bagi saya ini masuk akal. Anda menjalankan kueri spasial = Anda harus memiliki indeks spasial. Tapi sejauh yang saya mengerti, PostGIS dan SQL Serve tidak memerlukan ini. PostGIS bahkan tampaknya memiliki fungsi (_ * mis. _STContains) yang SECARA EKSPLISIT tidak akan menggunakan indeks spasial.

Jadi pertanyaannya adalah- apakah ada kasus di mana Anda TIDAK boleh menggunakan indeks spasial ?. Tidak harus apakah pendekatan 'ambil atau tinggalkan' yaitu tidak akan membuat perbedaan, tetapi di mana TIDAK menggunakan indeks spasial akan meningkatkan kinerja? Bagi saya, kalimat terakhir adalah kontradiksi dalam hal tetapi sebaliknya mengapa PostGIS akan menyediakan fungsi-fungsi ini?


3
Jika Anda ingin melihat di mana indeks membuat segalanya lebih lambat dalam SET PostGIS enable_seqscan = off. Ini akan memaksa PostgreSQL untuk menggunakan indeks setiap saat. Bandingkan kecepatannya dengan aktif.
Sean

Terima kasih telah memulai utas ini. Saya telah menuangkan informasi di internet, mencoba mencari tahu mengapa organisasi saya (pemerintah) tidak menggunakan indeks spasial (atau bahkan atribut) pada kelas dan tabel fitur oracle / sde mereka. Sekarang saya punya beberapa argumen untuk disajikan kepada mereka sehingga saya tidak perlu mencabut rambut saya, menunggu pertanyaan untuk menyelesaikan sendiri.
Mike

Jawaban:


12

mapoholic,

Secara umum, tidak ada alasan untuk melakukan kueri spasial tanpa indeks spasial kecuali Anda berurusan dengan tabel yang sangat kecil. Meski begitu Anda akan menggunakan ST_ yang tidak menggunakan indeks tetapi memiliki && operator kotak korsleting. fungsi yang dimulai dengan _ST tidak dimaksudkan untuk digunakan oleh pengguna akhir. Alasan mereka ada adalah karena mereka harus. Indeks spasial PostGIS menggunakan inlining SQL untuk memaksa penggunaan indeks - _ST biasanya dilakukan oleh GEOS dan && adalah indeks yang mungkin disusun ulang. Jadi _ST benar-benar merupakan artefak implementasi.

jadi singkatnya - itu bukan satu fungsi sehingga operasi indeks dapat disusun kembali terjadi sekaligus sebelum pemeriksaan spasial lebih intens.


sorakan LR1234567. Saya pikir inilah yang saya cari.
mapoholic

25

Jika dataset Anda ditambahkan ke dan sering diperbarui, maka pernyataan INSERT, DELETE dan UPDATE yang menyebabkan indeks dibangun kembali dapat memperlambat database.

Untuk sisipan massal, seperti memuat seluruh dataset OSM ke dalam basis data, mungkin lebih cepat untuk menjatuhkan indeks dan membuatnya lagi setelahnya.

Jika lebih efisien untuk mengabaikan indeks (misalnya tabel cukup kecil untuk dimuat ke dalam memori), prosesor kueri basis data harus melakukan ini secara otomatis.

Saya berharap alasan utama untuk memungkinkan kueri dijalankan tanpa indeks spasial adalah untuk mengukur manfaat kinerja yang Anda dapatkan dengan menggunakan indeks, tanpa harus menjatuhkannya.

Akhirnya jika Anda ingin menunjukkan peningkatan kinerja yang sangat besar ke kueri dan tampilan peta, Anda mungkin ingin menunda membuat indeks ke momen yang tepat dalam pengembangan sistem ...


3
(+1) Apakah saya mendeteksi sedikit sinisme dalam komentar terakhir itu? :-)
whuber

Tidak sama sekali ;-) Tetapi menjatuhkan / membuat ulang indeks yang disetel dengan hati-hati adalah jawaban yang berguna untuk "Mengapa X banyak waktu dihabiskan untuk perubahan basis data"?
geografisika

Terima kasih geografi- dan saya setuju dengan komentar Whuber! ;-) Saya mengerti bahwa Anda akan menjatuhkan / menonaktifkan indeks spasial ketika memuat massal - atau semua indeks untuk masalah ini, tetapi Anda tidak dapat memikirkan alasan mengapa Anda akan pernah melakukan permintaan spasial TANPA menggunakan indeks spasial? Jika tabel cukup kecil, menggunakan indeks mungkin tidak membuat perbedaan - cukup adil - tetapi memilih untuk tidak menggunakan indeks ?. Tidak tahu, saya kira saya hanya lebih bingung dengan keberadaan fungsi non-spasial-indeks PostGIS ...
mapoholic

2
Jika sebuah tabel cukup kecil dan muat ke dalam memori, menggunakan indeks mengharuskan akses disk acak yang lebih mahal daripada melakukan pemindaian berurutan. wiki.postgresql.org/wiki/…
Sean

2
@mapoholic - _ST_Contains dapat ditinggalkan ketika Anda harus secara manual melakukan prefilter data Anda, dilihat dari old.nabble.com/…
geografi

10

Saya pikir ini tersirat, tapi saya TIDAK akan menggunakan indeks spasial untuk kueri ketika saya memiliki indeks non-spasial yang bisa saya gunakan sebagai gantinya. Sebagai contoh, saya memiliki 2.113.450 poin yang menjangkau Amerika Serikat dimuat ke dalam tabel. Jika saya ingin menarik semua titik yang ada di negara bagian Alaska, saya bisa melakukan kueri spasial yang menggunakan indeks GIST pada geometri titik untuk membandingkannya dengan geometri negara bagian Alaska, ATAU, saya hanya bisa menggunakan bidang "state_alpha" dalam data titik (yang juga diindeks) untuk mengembalikan semua poin yang memiliki "state_alpha" = 'AK'.

"Di mana bagian spasial dari ini", Anda bertanya? Nah, jika saya perlu melakukan beberapa analisis spasial lebih lanjut pada Alaska_points setelah saya kumpulkan, lebih cepat mengumpulkan geometri titik tersebut menggunakan kueri non-spasial terlebih dahulu. Ini juga berarti bahwa untuk kumpulan data yang sangat besar, Anda mendapat manfaat dari menambahkan bidang pencarian (atau tabel). Sekali lagi, saya tahu ini mungkin jelas bagi semua orang, saya hanya menyebutkannya karena saya pernah mengalaminya di masa lalu dengan kumpulan data global yang hanya diindeks secara spasial, dan di mana pertanyaan umum adalah "semua fitur di dalam suatu negara". Kami memperoleh banyak kinerja dengan menambahkan bidang country_fips yang diindeks.

Berikut adalah beberapa hasil dari EXPLAIN ANALYZE yang membuktikan maksudnya. (CATATAN: Saya mencoba membuat kueri spasial seefisien mungkin dengan menggunakan kueri BBOX. Menggunakan garis besar status hanya akan membuatnya lebih lambat.)

# explain analyze select count(*) from gnis_names where state_alpha = 'AK';
Aggregate  (cost=57359.45..57359.46 rows=1 width=0) (actual time=76.606.. 76.607 rows=1 loops=1)
<snip>
Total runtime: 76.676 ms

# explain analyze select count(*) from gnis_names where the_geom && GeomFromText('POLYGON((-179.14734 51.219862,-179.14734 71.3525606439998,179.77847 71.3525606439998,179.77847 51.219862,-179.14734 51.219862))',4326);
Aggregate  (cost=27699.86..27699.87 rows=1 width=0) (actual time=86.523..86.524 rows=1 loops=1)
<snip>
Total runtime: 86.584 ms 

Terima kasih banyak untuk itu. Ini mungkin tampak jelas ketika Anda mengatakannya, tetapi pikiran pertama saya adalah menjalankan kueri spasial bukan atribut saja. +1 untuk ini!
mapoholic

0

Perhatikan pernyataan ini

Bagi saya ini masuk akal. Anda menjalankan kueri spasial = Anda harus memiliki indeks spasial

Bagi saya ini tidak masuk akal sama sekali dan saya pikir SQL Server dan Postgis melakukan pekerjaan yang lebih baik atau setidaknya tidak mengganggu Anda dengan detail kinerja. Bahkan, baik SQL Server dan Postgis kadang-kadang bahkan tidak menggunakan indeks spasial sama sekali (kembali ke pemindaian tabel penuh).

Untuk Oracle, Anda harus membuat indeks dan karena itu Anda harus mengisi user_sdo_geom_metadata.

Hanya membandingkan ini dengan indeks alfanumerik, mereka ada untuk alasan kinerja, pernyataan SQL Anda harus bekerja dengan dan tanpa itu.

Dalam database Oracle, letakkan indeks dan Anda akan mendapatkan banyak kesalahan dan aplikasi yang tidak akan dapat menggunakan kueri spasial, karenanya gagal berfungsi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.