Unsere Firma arbeitet an einem Projekt, das eine Datenbank mit 30-50 Millionen Zeilen Produktdaten benötigt. Diese Zeilen enthalten Text, der mehrere tausend Mal pro Sekunde gleichzeitig durchsucht werden muss. Außerdem muss jede Suche weniger als eine Sekunde dauern.
Alles in allem haben wir eine 50 Millionen Reihen-Datenbank, die tausende Male pro Sekunde durchsucht werden muss. Beachten Sie, dass dies Volltextsuchen sind. Ich weiß, dass MySQL oder irgendeine relationale Datenbank alleine diese Art von Job nicht bewältigen kann. Wir suchen also jemanden, der das richtige Setup für uns entwickeln und uns bei der Implementierung zu einem von Ihnen festgelegten Preis unterstützen kann.
Zuerst möchten wir wissen, was unsere besten Optionen sind. Ich selbst habe Dinge wie Sphinx, Lucene, Cassandra, MongoDB, CouchDB, Solr usw. erforscht, weiß aber nicht, welche in Verbindung mit anderen verwendet werden sollten, um uns die bestmögliche Einrichtung zu ermöglichen.
Wenn also jemand nur einen Rat geben oder unser Stellenangebot annehmen könnte, wäre das sehr zu begrüßen.
Sie können mich hier per PM kontaktieren, und ich gebe Ihnen meine E-Mail / IM / Telefonnummer, um weiter zu diskutieren.
Danke!
Das Speichern von Daten und das Suchen sind zwei verschiedene Dinge. Wenn Sie sich Architekturen wie eBay anschauen, haben sie separate Dienste & amp; Server für Suchvorgänge. 50m Zeilen ist nichts, Sie können es mit einem der Datenspeicher speichern, keiner von ihnen ist perfekt, so dass der Unterschied Use Cases ist. ZB: Cassandra hat die schnellste Insert-Leistung mit jeder Datengröße, kann Petabyte mit Hunderten von Maschinen leicht skalieren (keine Notwendigkeit zu shard), hat lucandra < (cassndra-lucene integration, skaliert gut mit massiven Daten, aber ein Spielzeug im Vergleich zu elasticsearch), hohe Haltbarkeit, ... MongoDB hat mehr Abfrageoptionen (verwendet btree als dbms), hat kürzlich autosharding, kann alle Felder indizieren , aber schlechte Haltbarkeit, ... Postgresql ist das am weitesten fortgeschrittene Open Source dbms da draußen, hat eingebaute Master / Slave-Replikation vor kurzem, kann durch sharding, Säure & amp; sql compliant ... couchdb hat keinen Vorteil gegenüber anderen in einem Anwendungsfall Ich denke, es ist verdammt langsam, Wenn ich Säure brauche, benutze ich wahrscheinlich postgresql. Die integrierte FullText-Suchfunktionalität mit diesen Datenspeichern weist einige Probleme auf und ist nicht skalierbar.
Die am weitesten verbreitete Open-Source-Suchmaschine (massive Daten, hohe Leistung, einfache, verteilte, fehlertolerante, Rest-API) ist elasticsearch Sie können es sich als verteilte Lucene vorstellen. Solr ist im Vergleich zu Elasticsearch läge. Verwendung von rohem Lucene / Sphinx ist nicht skalierbar.
Wenn ich Sie wäre, wähle ich wahrscheinlich einen der Datenspeicher aus und verwende elasticsearh, um sie auf meiner Datenzugriffsebene zu indexieren und zu synchronisieren (Indizes für db insert / update / delete müssen geändert werden).
Grüße
Paul, willkommen in SO. Dies ist nicht wirklich der richtige Ort, um jemanden für sich arbeiten zu lassen, aber hier ist mein Rat:
Wahrhaftig abhängig von den Arten von Suchen, die Sie tun, MySql aus zu schreiben, kann ein bisschen voreilig sein.
Da es sich um Produktdaten handelt, stelle ich mir vor, dass es sich bei Ihren Suchen um Volltextsuchen handelt. Daher ist es nicht verfrüht, MySql abzuschreiben. Sphinx ist großartig, aber ein bisschen mühsam zu konfigurieren. Der Vorteil ist, dass es direkt von mysql aus indexieren kann, und Sie können auch mit jedem mysql connector / bindings, den Sie in Ihrer Anwendung verwenden, eine Schnittstelle herstellen, da es weiß, wie das mysql-Protokoll zu sprechen ist.
Ich würde sagen, Cassandra, Couch und Mongo sind nicht wirklich das, wonach du suchst, keiner von ihnen indiziert Text wie Sphinx. Du könntest deine eigenen drauflegen, aber das wäre ziemlich kontraproduktiv.
Ich habe noch nie mit Lucene gearbeitet, aber ich habe gute Dinge gehört, es ist eine ähnliche Lösung wie Sphinx afaik.
viel Glück
Tags und Links mysql full-text-search mongodb cassandra couchdb