è possibile con Kibana (preferibilmente la nuova brillante versione 4 beta) per eseguire join sul lato dell'applicazione?Elasticsearch/Kibana: join Application-side
So che ES/Kibana non è costruito per sostituire i database relazionali e di solito è un'idea migliore per denormalizzare i miei dati. In questo caso d'uso, tuttavia, questo non è l'approccio migliore poiché la dimensione dell'indice sta esplodendo e le prestazioni scendono:
Sto indicizzando miliardi di documenti contenenti informazioni di sessione dei flussi di rete come questo: ip sorgente, porta sorgente, IP di destinazione, porta di destinazione, marca temporale.
Ora voglio anche raccogliere informazioni aggiuntive per ogni indirizzo IP, come la geolocalizzazione, asn, reverse dns ecc. Aggiungere queste informazioni ad ogni singolo documento di sessione rende l'intero database ingestibile: ci sono milioni di documenti con lo stesso IP gli indirizzi e la ridondanza di aggiungere le stesse informazioni aggiuntive a tutti questi documenti portano a un enorme ingordigia e un'esperienza utente insensibile anche su un cluster con centinaia di gigabyte di RAM.
Invece vorrei creare un indice separato contenente solo indirizzi IP univoci e i metadati che ho raccolto per ognuno di essi.
La domanda è: Come posso analizzare ancora i miei dati utilizzando kibana? Per ogni documento restituito dalla query, kibana dovrebbe eseguire una ricerca nell'indice ip e "arricchire virtualmente" ogni indirizzo ip con queste informazioni. Qualcosa come l'aggiunta di campi virtuali in modo che la struttura sarebbe simile a questa (al volo):
IP sorgente, porta sorgente, paese fonte, ASN di origine, fonte fqdn
Sono consapevole che questo sarebbe venuto al costo di più query.
Per curiosità, stai usando doc_values per la cache di campo non analizzata? Personalmente, prima ancora di tentare di normalizzare i miei dati, proverei a passare a doc_values per vedere se ciò è stato d'aiuto. Potresti anche voler vedere gli ordinali globali int (ad esempio https://www.elastic.co/guide/en/elasticsearch/reference/1.6/fielddata-formats.html) ma con dati di cardinalità elevati in realtà non penso che sarebbe essere un'ottima idea .... – evanv