ElasticSearch-setup für eine große Gruppe mit starken Aggregationen

Kontext und den aktuellen Stand

Sind wir die Migration unserer cluster von Cassandra zu einem vollen ElasticSearch-cluster. Wir sind der Indizierung von Dokumenten auf durchschnittlich ~250-300 docs pro Sekunden. In ElasticSearch 1.2.0 stellt es ~8Go pro Tag.

{
 "generic":
    {
      "id": "twi471943355505459200",
      "type": "twitter",
      "title": "RT @YukBerhijabb: The Life is Choice - https://m.facebook.com/story.php?story_fbid=637864496306297&id=100002482564531&refid=17",
      "content": "RT @YukBerhijabb: The Life is Choice - https://m.facebook.com/story.php?story_fbid=637864496306297&id=100002482564531&refid=17",
      "source": "<a href=\"https://twitter.com/download/android\" rel=\"nofollow\">Twitter for  Android</a>",
      "geo": null,
      "link": "http://twitter.com/rosi_sifah/status/471943355505459200",
      "lang": "en",
      "created_at": 1401355038000,
      "author": {
        "username": "rosi_sifah",
        "name": "Rosifah",
        "id": 537798506,
        "avatar": "http://pbs.twimg.com/profile_images/458917673456238592/Im22zoIV_normal.jpeg",
        "link": "http://twitter.com/rosi_sifah"
      }
    },
 "twitter": {
   //a tweet JSON
 }
}

Unseren Benutzern das speichern von Anfragen in unsere SQL-Datenbank und, wenn Sie bitten, für Ihre dashboard würden wir gerne auf Wunsch unsere ES-Clusters mit Ihrer Abfrage (abgerufen aus der Datenbank) und einige aggregation oben drauf mit dem neuen ES-aggregation framework.

Jedes dashboard angezeigt wird, mit einer expliziten, vom Benutzer gewählten, Datum, Angebot, also wir verwenden immer

"range": {
 "generic.created_at": {
   "from": 1401000000000,
   "to": 1401029019706
  }
}

zusammen mit der ES-query.

Wir angegeben _routing so:

"_routing":{
 "required":true,
 "path":"generic.id"
},

und die _id mit:

"_id": {
  "index": "not_analyzed",
  "store": "false",
  "path": "generic.id"
}

Etwa 5 Tage, die wir gespeichert haben 67 Millionen Dokumente (über 40Go) in einem index. Wir haben erfahren über die gute Praxis der spliting der index von Tag zu Tag. So, jetzt unsere Indizes sind aufgeteilt in den Tag ([index-name]-[JJJJ-MM-TT]).

Derzeit jeder index hat 5 shards und 1 replica, wir haben einen cluster bestehend aus 3 Maschinen mit je 8 Kernen, 16Go RAM und 8To von HDD. Wir planen, verwenden Sie eine andere Maschine als gateway (8 Kerne, 16Go RAM, 1 HDD).

Wir haben die Winterlinde ES-Konfiguration standardmäßig neben der cluster-Konfiguration.

Fragen

  1. Für jedes Dokument, das wir indizieren wollen, sagen wir ausdrücklich, was index
    verwenden. Derzeit verwenden wir das Datum des Tages. Sollten wir das Datum des
    das Dokument, um zu verhindern, dass hot-spot? Denn derzeit es
    bedeutet, dass die Dokumente von verschiedenen Tagen (angegeben in Ihren
    created_at) Leben können, in den gleichen index des aktuellen Tages.
  2. Sind 5 Scherben genug (oder zu viel) für 21 600 000 Dokumente durch den Tag?
  3. Wenn wir wollen, dass alle unsere aggregierte Abfragen verarbeitet werden, in weniger als 1 Sekunde, wie viele Replik sollten wir setup up?
  4. Sollten wir ändern unser routing? Da wir nicht wissen, vor der Zeit, die Dokumente verarbeitet werden, bevor die aggregation für jede Anfrage, die wir dem cluster (da die Abfrage wird vom Benutzer definiert)
  5. Welche Art von hardware (wie viele Maschinen, welche Konfiguration), sollten wir in diesem cluster zu unterstützen, 6 Monate von Dokumenten?

[Update]

Ist hier einige Beispiel-Abfragen:

Einer word-cloud

GET idx-2014-05-01/stream/_search?search_type=count
{
 "query":{
   "bool": {
     "must": [{
       "query_string" : {
         "query" : "(generic.lang:fr OR generic.lang:en) AND (generic.content:javascript)"
        }},{
        "range": {
          "generic.created_at": {
            "from": 1401000000000,
            "to": 1401029019706
          }
        }}
     ]
   }
 },
  "aggs":{
    "words":{
      "terms":{
        "field": "generic.content",
        "size": 40
      }
    }
  }
}

Einem Histogramm

GET idx-2014-05-01/stream/_search?search_type=count
{
 "query":{
   "bool": {
     "must": [{
       "query_string" : {
         "query" : "generic.content:apple"
        }},{
        "range": {
          "generic.created_at": {
            "from": 1401000000000,
            "to": 1401029019706
          }
        }}
     ]
   }
 },
  "aggs":{
    "volume":{
      "date_histogram":{
        "field": "generic.created_at",
        "interval":"minute"
      }
    }
  }
}

Muss die verwendete Sprache

GET idx-2014-05-01/stream/_search?search_type=count
{
 "query":{
   "bool": {
     "must": [{
       "query_string" : {
         "query" : "(generic.lang:fr OR generic.lang:en) AND (generic.content:javascript)"
        }},{
        "range": {
          "generic.created_at": {
            "from": 1401000000000,
            "to": 1401029019706
          }
        }}
     ]
   }
 },
  "aggs":{
    "top_source":{
      "terms":{
        "field": "generic.lang"
      }
    }
  }
}

ElasticSearch-setup für eine große Gruppe mit starken Aggregationen

  • Wie habt Ihr das gelöst? Ich bin auch konfrontiert mit aggregation-heavy-Abfragen, die schlecht durchführen. Was sind die Parameter, die wir optimieren können um die situation zu verbessern? Ich denke irgendwie die Verringerung der Anzahl der buckets erstellt für jede aggregation (z.B., shard_min_doc_count - parameter) oder vielleicht die Erhöhung der Zahl der Scherben, so dass jeder shard hat zu aggregieren weniger Daten? Alle Zeiger?
InformationsquelleAutor John Smith | 2014-05-29
Schreibe einen Kommentar