Pencarian berbutir halus pada dataset besar

Saya memiliki sekitar 4 juta catatan per hari dan harus disimpan selama 7 tahun secara online, jadi kami melihat 10,2 miliar catatan yang harus saya cari. Para pengguna berharap bahwa pencarian akan cukup cepat untuk UI, menghasilkan 3-5 detik

Karena politik di luar kendali saya, saya tidak dapat menggunakan solusi database rak karena itu berarti saya harus memberikan database kepada tim lain untuk dikelola (jangan tanya) yang berarti saya kehilangan kemampuan untuk mengoptimalkan perangkat keras dan perangkat lunak karena mereka memiliki layanan satu ukuran untuk semua data dan diisi (secara internal) oleh GB. Saya yakin saya akan mendapatkan komentar yang menyarankan saya menyampaikan maksud, saya sudah memiliki dan manajemen mengerti apa yang mereka minta saya lakukan adalah konyol.

Saya telah melihat menggunakan Lucene sebagai inti dari solusi saya. Menyimpan data aktual yang dipartisi berdasarkan jenis dan hari dalam file datar. Kemudian menggunakan dokumen Lucene untuk mengindeks beberapa bidang yang dicari oleh, dengan satu-satunya bidang "Disimpan" menjadi id dari catatan (sehingga saya bisa membacanya dari file datar)

Saya tidak tahu persis pada Lucene atau hard drive, tetapi sesuai pemahaman saya, akan ada IO awal / mencari waktu untuk mencari indeks, maka ketika saya memiliki semua ID dokumen Lucene, saya membaca dokumen yang akan dikenakan IO lebih lanjut Saya mencari waktu, lalu saya membaca catatan sebenarnya dari flat ... Saya tidak bisa membayangkan, mengingat ukuran dataset, bahwa ini akan sangat cepat, yang saya agak khawatirkan?

Lucene memiliki ukuran dokumen maksimum 2,1 miliar per indeks, jadi saya akan memerlukan beberapa indeks di sini.

Apakah pendekatan ini, di muka itu, tampak seperti itu bisa berhasil?

Data yang saya simpan adalah data event-action. Sebagian besar kueri akan dikelompokkan berdasarkan id acara dan mendapatkan detail acara-aksi terakhir untuk acara tertentu. Beberapa kueri akan menganalisis acara himpunan besar dan tindakan-peristiwa individualnya.

Anda belum mengatakan seberapa besar data, seberapa besar bidang masing-masing, atau berapa anggaran yang Anda miliki.

Terlepas dari sistem pengindeksan apa yang Anda pilih, pertimbangkan untuk melemparkan perangkat keras pada masalahnya. Anda tidak perlu mencari disk apa pun. Buat indeks semua data, menggunakan skema yang sangat cepat untuk dilintasi (mungkin daftar atau pohon yang diurutkan). Simpan indeks pada disk, tetapi kemudian cache seluruh indeks dalam RAM. Anda mungkin perlu puluhan, atau bahkan ratusan gigabyte RAM untuk melakukan itu.

Jika masing-masing bidang berukuran besar, atau ukuran variabel, pertimbangkan untuk mengindeks hash.

Harga yang harus dibayar oleh server untuk itu bisa menakutkan.

Mengabaikan semua rincian teknis ini adalah masalah organisasi / manajemen dan perlu diselesaikan oleh manajemen organisasi Anda.

Manajer Anda harus bersedia menendang masalah di lantai atas dan / atau meminta penggunanya untuk mengangkat masalah di tingkat tinggi.

Pada level Anda, kumpulkan atau minta estimasi untuk melakukan ini dengan Oracle dan perangkat keras Oracle. Kemudian kumpulkan estimasi realistis untuk cluster Hadoop.

Terlepas dari hype cluster ini tidak datang murah (Anda mungkin perlu sesuatu seperti 18 8 node prosesor dengan memori 64GB dan 4 x 2 TB disk tersebar di tiga rak kemudian 4 node lain untuk katalog dll). JANGAN meremehkan; jika Anda menang, Anda harus menerapkannya.

Jadi, pertama-tama mari kita dengan jelas menyatakan kembali masalah dalam hal persyaratannya:

1. Sistem harus menyimpan catatan minimum 4M per hari.
2. Sistem harus menyediakan antarmuka pencarian kepada pengguna
   2.1. Kemampuan pencarian akan mengembalikan hasil maksimal 3s
3. Sistem harus mampu mencari minimal 10,2 miliar rekaman
4. Sistem harus menggunakan database yang dirancang khusus
   4.1. Sistem harus memiliki perangkat keras dan perangkat lunak yang dioptimalkan untuk database yang akan dikembangkan

Mungkin ada persyaratan tambahan non-fungsional, serta rincian tentang seberapa besar catatan individu, yang mungkin relevan dengan situasi Anda.

Jawaban singkatnya adalah Anda memiliki masalah persyaratan. Jika Anda melihat persyaratan ini, tiga di antaranya (tiga yang pertama) berlaku dengan benar pada sistem untuk mendefinisikan fungsi dan perilakunya. Persyaratan terakhir bukanlah persyaratan yang valid dari sudut pandang murni, tetapi saya telah melihat persyaratan jenis ini dimasukkan ke dalam laporan kerja.

Jadi, cara masalah ini diselesaikan adalah dengan memperkirakan biaya persyaratan ke-4, mengingat tiga lainnya. Setelah Anda melakukannya, hadirkan itu sebagai biaya solusi Anda. Manajemen akan panik dan segera bertanya kepada Anda mengapa masalah tidak dapat diselesaikan dengan harga yang wajar. Itulah titik masuk untuk diskusi Anda tentang apa yang perlu terjadi. Siapkan alternatif yang terjangkau dan siap untuk disajikan.

Ini berbeda dengan apa yang Anda lakukan saat ini, yang mengasumsikan tiga lainnya tidak dapat dipenuhi mengingat yang terakhir. Manajemen tidak mengerti, karena yang mereka lihat hanyalah tanda dolar.

Jika saya berada di posisi Anda, saya akan mulai dengan implementasi buku yang sangat masuk akal, tidak menggunakan apa pun kecuali RDBMS biasa, tertanam dalam aplikasi, sehingga mereka tidak merasa seolah-olah mereka harus mendukung sesuatu. SQLite, H2, atau database tertanam alternatif harus dilakukan: Tidak ada file flat khusus, tidak ada indeks eksotis, tidak ada apa-apa: hanya aplikasi langsung dari praktik standar untuk menyelesaikan masalah yang dihadapi, untuk sebagian besar mengabaikan besarnya data. (Saya tentu saja akan memilih integer yang cukup besar sebagai kunci, dan itu saja, cukup banyak.)

Saat bekerja di sana, beberapa ide mungkin akan terjadi pada saya, tentang bagaimana membuatnya bekerja lebih cepat tanpa menggunakan sesuatu yang eksotis.

Kemudian, saya akan menguji ini untuk melihat bagaimana kinerjanya, dan saya akan menunjukkan hasilnya, bersama dengan solusi kerja, untuk "kekuatan yang ada" di organisasi Anda.

1. Ada kemungkinan bahwa implementasi langsung Anda akan melakukan dalam batasan yang diperlukan, sehingga Anda akan baik-baik saja di sana, tidak perlu melakukan hal lain, nol sumber daya terbuang.

2. Jika kinerja implementasi langsung di luar, tetapi tidak terlalu jauh dari, kendala yang diperlukan, "kekuatan be" bisa mengatakan "baik, ini cukup dekat, kami tidak ingin melakukan hal lain tentang hal itu, jadi itulah yang akan terjadi. " Sekali lagi, nol sumber daya terbuang.

3. Jika kinerja implementasi langsung di luar, tetapi dalam urutan yang sama besarnya, dari kendala yang diperlukan, saya akan memberitahu mereka untuk hanya membeli perangkat keras yang lebih baik, lebih besar, lebih cepat. Kemungkinan besar mereka akan melakukan itu dan kasus ditutup.

4. Jika mereka tidak ingin membeli perangkat keras yang lebih baik, lebih besar, lebih cepat, maka saya akan merekomendasikan mereka memikirkan kembali persyaratan mereka untuk tidak menggunakan RDBMS yang besar dan dapat diukur. Jika mereka masuk akal, dan Anda telah menunjukkan bahwa Anda juga masuk akal, kemungkinan mereka akan memikirkannya kembali.

5. Jika kekuatan menjadi tidak ingin mengikuti jalan yang masuk akal, dan sebaliknya mereka ingin Anda memainkan peran sebagai penyihir, maka dan hanya kemudian saya akan mulai khawatir tentang solusi eksotis. Banyak kemungkinan, hal-hal tidak akan mencapai titik itu. Tetapi bahkan jika mereka melakukannya, jumlah pekerjaan yang akan Anda lakukan dengan sia-sia sampai saat itu akan relatif kecil, dan layak bertaruh bahwa itu mungkin sudah cukup.

Berpikir dari ujung depan ...

Jika Anda memisahkan jenis pencarian Anda di UI, Anda mungkin dapat memiliki kendala yang lebih masuk akal.

Kedengarannya seperti satu jenis pencarian adalah data tindakan-peristiwa terbaru pada suatu acara, yang memungkinkan Anda untuk mengisolasi berdasarkan waktu dalam pencarian data Anda. Ini mungkin memberikan set data yang jauh lebih kecil, dengan kemungkinan harapan pengguna yang akan diambil agak segera.

Jenis pencarian lainnya, di mana kumpulan data besar atau pencarian kerangka waktu lama yang harus diselesaikan dapat diberikan UI yang berbeda (atau beberapa UI), dengan pemintal yang bagus untuk menunjukkan ... berpikir sekarang. Karena hal ini dapat dipahami oleh pengguna sebagai seperangkat persyaratan yang lebih melelahkan, kesabaran mungkin cukup diharapkan. Dan tentu saja, secara realistis diperlukan.

Saya tidak tahu apakah Anda memiliki kemampuan untuk mempengaruhi desain kecenderungan depan, tetapi jika Anda dapat menyampaikan kendala yang Anda hadapi, mudah-mudahan mereka yang menangani interaksi pengguna akan merespons dengan pemahaman (setidaknya beberapa).