Pengumuman terbaru Radar mengenai HorizonDB , pangkalan data geospatial tersuai mereka yang dibina dengan Rust dan RocksDB , telah mencetuskan perbincangan sengit dalam kalangan pembangun tentang kebolehlaksanaan menggantikan penyelesaian yang telah mantap seperti Elasticsearch dan MongoDB . Syarikat itu mendakwa sistem baharu mereka mengendalikan 1,000 pertanyaan sesaat bagi setiap teras sambil mengekalkan masa respons sub-milisaat untuk reverse geocoding.
Dakwaan Prestasi HorizonDB:
- 1,000 QPS setiap teras
- Latensi median geokod hadapan: 50ms
- Latensi median geokod songsang: <1ms
- Penskalaan linear pada perkakasan komoditi
- Memproses lebih 1 bilion panggilan API setiap hari
 |
|---|
| HorizonDB Radar mendakwa metrik prestasi tinggi dalam pertanyaan geospatial |
Komuniti Mempersoalkan Dakwaan Kebolehpercayaan
Komuniti pembangun telah membangkitkan kebimbangan yang ketara mengenai kekurangan butiran teknikal dalam pengumuman Radar . Ramai yang mempersoalkan aspek asas seni bina sistem yang tidak ditangani dalam siaran asal. Maklumat utama yang hilang termasuk bagaimana data diagihkan merentasi berbilang pelayan, apa yang berlaku apabila perkakasan gagal, dan bagaimana sistem memastikan tiada data hilang semasa gangguan.
Kebimbangan ini menyerlahkan skeptisisme yang lebih luas tentang penyelesaian pangkalan data tersuai. Walaupun Radar mempromosikan angka prestasi yang mengagumkan, pembangun berpengalaman tahu bahawa ujian sebenar datang apabila sistem menghadapi kegagalan yang tidak dijangka atau perlu berkembang melebihi reka bentuk asal mereka.
Penyelesaian Alternatif Mendapat Perhatian
Perbincangan ini telah membawa perhatian kepada alternatif sumber terbuka sedia ada yang mungkin menawarkan faedah serupa tanpa kerumitan membina dari awal. Typesense dan DuckDB telah muncul sebagai cadangan popular, dengan pembangun memuji prestasi mereka untuk pertanyaan geospatial dan status sedia untuk pengeluaran mereka.
Kedua-duanya sumber terbuka sepenuhnya termasuk persediaan berkelompok/berserpih.
DuckDB , khususnya, telah mendapat pengiktirafan untuk keupayaan plugin spatial mereka, terutamanya untuk aplikasi di mana data tidak kerap berubah. Walau bagaimanapun, sesetengah pembangun telah mencatatkan cabaran integrasi apabila cuba menggabungkan berbilang teknologi pangkalan data dalam satu projek.
Alternatif Sumber Terbuka yang Disebut:
- Typesense: Enjin carian teks penuh dengan keupayaan geo
- DuckDB: Pangkalan data analitik dengan plugin spatial
- Photon: Enjin carian OpenStreetMap menggunakan Elasticsearch
- Quickwit: Alternatif Elasticsearch untuk pengurusan log
Pembahagian Pengalaman Elasticsearch
Mungkin aspek paling menarik dalam perbincangan komuniti ialah pembahagian yang ketara dalam pengalaman Elasticsearch . Walaupun Radar menyebut kerumitan operasi sebagai sebab utama untuk beralih daripada Elasticsearch , beberapa pembangun berkongsi pengalaman yang berbeza dalam menjalankan kluster Elasticsearch yang stabil dengan overhed penyelenggaraan yang minimum.
Seorang pembangun melaporkan menguruskan 12 nod dengan 200 juta dokumen bagi setiap nod, memerlukan hampir tiada penyelenggaraan aktif selain daripada pemantauan asas. Ini menunjukkan bahawa reputasi Elasticsearch untuk kerumitan mungkin lebih berkaitan dengan pendekatan pelaksanaan daripada had sistem yang wujud.
Perbandingan Tumpukan Teknologi:
| Tumpukan Sebelumnya | Tumpukan HorizonDB |
|---|---|
| Elasticsearch (pengekodan geo ke hadapan) | Rust + RocksDB |
| MongoDB (pengekodan geo terbalik) | Tantivy (carian) |
| Pelbagai perkhidmatan mikro | S2 (pengindeksan spatial) |
| - | FSTs (pemampatan rentetan) |
| - | LightGBM + FastText (ML) |
Pertukaran Inovasi vs Kestabilan
Perbualan yang lebih luas menyentuh ketegangan asas dalam pilihan teknologi. Walaupun penyelesaian tersuai boleh menawarkan keuntungan prestasi yang mengagumkan dan kesesuaian sempurna untuk kes penggunaan tertentu, ia juga memperkenalkan risiko sekitar penyelenggaraan jangka panjang, pengetahuan pasukan, dan kebolehpercayaan sistem.
Kebangkitan semula pembangunan pangkalan data tersuai mewakili peluang dan cabaran untuk industri. Syarikat semakin bersedia untuk melabur dalam penyelesaian khusus apabila alat sedia ada tidak memenuhi keperluan tepat mereka, tetapi pendekatan ini memerlukan sumber kejuruteraan dan kepakaran yang ketara yang tidak dimiliki oleh banyak organisasi.
Perdebatan sekitar HorizonDB akhirnya mencerminkan persoalan yang lebih besar tentang bila hendak membina berbanding membeli, dan sama ada keuntungan prestasi daripada penyelesaian tersuai membenarkan kerumitan dan risiko tambahan yang mereka perkenalkan.
Rujukan: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
 |
|---|
| Memahami indeks terbalik dan implikasinya dalam teknologi pangkalan data |