Amazon komt met hosted-zoekdienst

Amazon komt met een clouddienst voor het aanbieden van een zoekmachine. De gebruiker uploadt datasets en vervolgens levert Amazon de search-engine. Zoekresultaten kunnen vervolgens via een api worden opgevraagd.

De nieuwe Amazon-dienst kan worden gebruikt in combinatie met Amazons eigen storage-dienst S3, maar datasets kunnen ook op een andere wijze worden geüpload. Zoekresultaten kunnen worden opgevraagd als json- of xml-feed. Gebruikers betalen op basis van het aantal documenten dat moet worden doorzocht en de hoeveelheid data die heen en weer wordt geschoven.

De 'search instances' zijn beschikbaar in de smaken klein, groot en extra groot. Amazon schat dat, afhankelijk van de documentgrootte, in die instances respectievelijk 1, 4 en 8 miljoen documenten passen. Een kleine instance kost 12 dollarcent per uur; een grote 48 dollarcent en een extra grote 68 dollarcent. Daarbij moet worden aangetekend dat wanneer veel zoekresultaten worden opgevraagd, het nodig kan zijn om een extra instance te starten en gebruikers dus hogere prijzen betalen.

Voor inkomende gegevens, zoals datasets, hoeft niet te worden betaald; voor uitgaande data moet minimaal 7 en maximaal 12 dollarcent per gigabyte worden betaald, afhankelijk van het totale verbruik. Wel moet worden betaald voor batch-uploads, namelijk 10 dollarcent per 1000 batches, waarbij elke batch maximaal 5MB aan gegevens mag bevatten. Ook voor het opnieuw indexeren van gegevens moet worden betaald: 98 dollarcent per gigabyte aan data.

Reacties (22)

[ronn0]

$ 1051,20 per jaar, dat is m.i. redelijk wat geld. Met Sphinx (Search) kun je zelf gratis m.i. iets vergelijkbaars opzetten.

Waar ik wel benieuwd naar ben is de resultaten die het terug geeft en op basis van wat allemaal (mbt relevantie en vergelijkbare zoekresultaten etc.)

[arnobroekhof]

het kan voor test doeleinden goed ingezet worden denk ik, maar ik ben het met je eens dat het nogal aan de prijzige kant is.

[robinverl]

Dat is van toepassing op de meeste clouddiensten, totdat je alle voordelen en mogelijkheden gaat omzetten in de echte kosten. Je mist de schaalvoordelen als je echt distributed, redundant in meerdere datacenters wilt gaan zitten. Om nog maar niet te spreken over hardware/software onderhoud.

Natuurlijk is 1 server in-house met daarop je eigen software veel goedkoper. Maar het is zeker niet hetzelfde.

[ronn0]

Dat is uiteraard het geval, maar ik kan me weinig situaties inbeelden waarin het een kostenvoordeel op zou leveren. Natuurlijk zal het voor enkele partijen interessant zijn ergens een oplossing te hebben voor hosting e.d.

Maar het opzetten van een query naar "buiten het datacenter" gaat sowieso al veel tijd verloren waardoor het idee van een zoekdienst alweer gelijk deels verloren gaat, juist bij zoeken gaat het om milisecondes .

offtopic:
Hey Robin ;-)

[Gomez12]

Laat jij een server draaien voor 1051 per jaar dan?

[smeaggie]

Het is maar wat je "extra groot" noemt, we hebben hier een sphinx cluster draaien met ruim 1 miljard documenten, welke 2x per dag geindexeerd wordt en 24 uur per dag gebruikt. Als ik zo eens de kosten inschat kom ik met onze blade setup toch goedkoper uit... En waarschijnlijk is alleen de connect time naar de amazon API al langer dan de search time van onze cluster, en daar komt de vraag: waar is deze service dan voor bedoeld? Max 8 miljoen documenten is niet veel, dat kan je net zo makkelijk zelf op een enkele server indexen? Mis ik wat het voordeel is?

[Wizz15]

Het is max 8 miljoen 'per instance'. Kleinste instance is max 1 miljoen documenten, voor kleine datasets interessant. Ga je daar overheen, dan wordt er automatisch een nieuwe instance gestart, zodat je limiet weer hoger wordt.

Je betaalt voor wat je daadwerkelijk gebruikt, ipv vaste kosten voor een cluster wat (voor sommigen) niet continue aan zijn tax zit.

Connect time is te verwaarlozen, communicatie tussen andere AWS services/instances naar deze nieuwe API is retesnel. Dit gaat namelijk gewoon via het interne AWS netwerk en communicatie hoeft dus niet via het internet te lopen.

Als je dus eigen servers host (buiten AWS) die met deze service moeten communiceren dan gaat de connect time wel omhoog.

Het voordeel is dat het allemaal 'in de cloud' gebeurd, en voor mensen die AWS al voor andere dingen gebruiken is het nu handig dat ze niet eigen search servers hoeven op te zetten met third-party software. Ze kiezen nu gewoon voor CloudSearch, zeggen welke data doorzoekbaar gemaakt moet worden en je bent klaar in principe.

[smeaggie]

Dat kost ons dus minstens 125 instances, wat neerkomt op 85 USD per uur. Maar het zal dan ook niet voor ons bedoeld zijn...

Je hebt inderdaad een goed punt met waar je host. Als je AWS al gebruikt en je hebt niet een te grote dataset is dit wel de oplossing die zonder kennis snel in te zetten is.

[robinverl]

Je kunt je berekening nooit zo snel en eenduidig maken bij AWS. Immers is het aantal documenten een schatting gebaseerd op de grootte. Tevens is het afhankelijk van het zoekvolume.

Los daarvan denk ik wel dat je met 8 miljard documenten wellicht voorbij de schaalvoordelen grens bent van AWS waardoor het goedkoper kan zijn om het zelf te regelen.

[robinverl]

De standaard voor- en nadelen van cloud oplossingen zijn van toepassing (denk aan snel schaalbaar, failover).

Ook is minder/geen kennis van de achterliggende techniek noodzakelijk om te kunnen zoeken voor zover ik begrjip uit het nieuwsbericht. De gebruiker dumpt de betreffende bestanden en kan zoeken via de API. Klaar.

[Ramon]

Moet je wel de kennis en expertise in huis hebben om een search engine op te zetten en te onderhouden. Een beetje tegen een API aanpraten is voor de gemiddelde programmeur makkelijker.

[Zoijar]

Ze accepteren vast geen 90MB aan magnet links?

Maar even iets serieuzer; 8 miljoen documenten is toch niks? Dan kan je toch gewoon een full text search draaien op postgresql ofzo? (nou krijg je hier natuurlijk wel veel service en automatische backup, onderhoud etc. Wat dat betreft wel nuttig, en waarschijnlijk goedkoper uiteindelijk)

[Reactie gewijzigd door Zoijar op 4 augustus 2024 01:55]

[_Thanatos_]

Als je "gewoon" een fulltext search draait op 8 miljoen documenten, zul je hoe dan ook knappe hardware moeten hebben staan. Maar als je 8 miljoen documenten hebt, ben je ook geen MKB meer, lijkt me.

[TvdW]

Valt wel mee hoor. Met een inverted index kan een "simpele" zoekterm (enkele woorden icm AND of OR) in O(1) (constante tijd) uitgevoerd worden. Of je dan 8 miljoen documenten hebt of "slechts" 100.000, maakt dan niet echt uit.

[Reactie gewijzigd door TvdW op 4 augustus 2024 01:55]

[truegrit]

Ik hoop dat dit de flexibiliteit van SOLR heeft, dan kan het misschien dienen als alternatief voor onze huidige setup. Nu draait er constant een server met solr en die word niet optimaal gebruikt

[robinverl]

Ik vermoed dat het draait op een soort van Solandra (SOLR vs Cassandra) aangezien dit zeer goed distributed is uit te rollen: iets wat een vereiste is bij een cloud dienst.

[Perkouw]

Is het inderdaad niet sneller/makkelijker en vooral goedkoper door dit in eigen beheer te hebben ? Ik zie persoonlijk het nut niet echt in van deze dienst, het draait ook nog eens extern dus ben je ook weer afhankelijk van the internetz.

[i-chat]

ik denk dat je dit alleen gaat gebruiken in combi met s3 ik kan me geen weldenkend mens voorsellen die een data set gaat uploaden om die vervolgens tegen deze kosten te laten doorzoeken, maar als je nu eens enkel een hosted server hebt dan zou je al snel zoiets moeten kiezen, je eigen google-in-a-box via het web laten zoeken in je s3 omgeving gaat het namelijk niet worden.

[Dreamvoid]

Zoals met alle "make or buy" beslissingen, hoe goed zijn je interne mensen en hoeveel tijd/aandacht wil je eraan kwijt zijn? Als je een lading goedkope, competente en duimendraaiende systeembeheerders ter beschikking hebt, dan is het waarschijnlijk handiger om het zelf te doen, ja.

[cork87]

Nou snap ik dat het een nieuwe dienst betreft, maar wat is het praktisch nut hiervan?
Het is toch niet zoiets als de google search engine ofwel? Ik mis eigenlijk een stuk in het bericht wat het in grote lijnen doet.

Edit: http://pandodaily.com/201...ew-cloud-search-tomorrow/

[Reactie gewijzigd door cork87 op 4 augustus 2024 01:55]

[Tutti-frutti]

Ik heb de introductiefilmpjes bekeken, maar ik zie geen autocompletion, spellchecking (did you mean?) en geen hit highlighting. Iets wat toch redelijk standaard functionaliteit is vandaag de dag.

Ook zie ik geen mogelijkheid om het preprocessen van data te customizen (zoals je zelf je analyzers kan bouwen met Lucene/SOLR). Je hebt enkel mogelijkheid om te kiezen uit predefined field types (zoals text, unit ,...). Voor simpele zoekfunctionaliteit kan dit voldoende zijn, maar het ligt er maar net aan in welke context het gebruikt gaat worden.

Maar pluspunt is dat je je niet meer bezig hoeft te houden met de servers/schaalbaarheid, maar daarvoor lever je toch belangrijke functionaliteit in. Voor een leek is het te begrijpen. Maar ik denk dat de functionaliteit al snel onvoldoende wordt als je net dat beetje meer wilt.

edit: Dit bericht had als directe reactie gepost moeten worden (wat ik volgens mij ook gedaan heb nadat ik eerst op cork87 wilde reageren. Misschien een bugje, misschien m'n eigen fout)

[Reactie gewijzigd door Tutti-frutti op 4 augustus 2024 01:55]