Tool für EF-Suche erstellen | Hilfe
- Starter*in Panther
- Datum Start
ANZEIGE
S
smalessu
Guest
Der Provinzausflugstarif. Naja, als oneway ggf brauchbar, auch wenn es die alte C ist.
Das ist wenig für atpco. Wer ist der Provider, und wie viele Leute teilen sich lizenzgemäß den Zugang?
Der Thread wurde gerade an mich heran getragen - ich hätte mich durchaus früher geäußert 
, aber besser spät als nie .
Mich interessiert: wie weit sind Eure Bemühungen voran geschritten?
Zum hiesigen Stand: ich selbst mache so etwas natürlich nicht, weiß aber das andere Leute so etwas erfolgreich praktizieren. Natürlich ist nicht jede popelige OTA auf dieser Welt an das System angeschlossen, aber es sind durchaus einige OTAs dabei. Ich würde behaupten, dass die Top 15 (in Bezug auf die Größe des Unternehmens) angeschlossen sind, sowie auch einige Flugsuchmaschinen.
Zum "Problem" der Änderungen auf unterschiedlichen Buchungsseiten: das passiert äußerst selten. Die OTAs verändern vielleicht Layouts ihrer Seiten, wovon aber (XHR-)Requests und JSON Antworten fast nie betroffen sind. Wer also "intelligent" crawled, hat hier kaum Ärger. Wer natürlich irgendwelche Browser emuliert und sich nicht an die dahinterliegenden Requests hält, hat selbst Schuld.
Zum Blocken von IPs: hier lässt sich kaum Konsistenz erkennen. Manche sind total empfindlich, manche blocken fast nie etwas. So oder so sollte man natürlich ausreichend IPs in der Hinterhand haben.
Wer Kosten scheut, ist sowieso falsch. Um schnell und ordentlich zu arbeiten, sollte man schon mindestens zwei Server wie den PX121-SSD von Hetzner unterhalten. Dazu kommen diverse Nebenkosten.
Ist das Ganze trotzdem profitabel? Da ich selbst sowas ja nicht mache, kann ich nur berichten, dass es das wohl ist.
Gegenüber meinem alten Post hat sich an dem System, soweit ich weiß, durchaus auch einiges geändert. Damals konnte wohl noch nicht mit großen Datenmengen umgegangen werden, was sich heute geändert hat. Heute werden also sämtliche Daten in DBs erfasst, die danach nur über Webinterfaces ausgewertet werden. Früher haben die Server das wohl noch nicht mitgemacht. So hat man viel mehr Daten, die für andere Dinge wieder nützlich sein können (was scheren einen schon ein paar mehr Zeilen in DBs...). Eine simple 3X-Suche für eine potentiell interessante Strecke führt dann in kurzen Momenten zu über 300k Ergebnissen (Screens wurden mir weitergeleitet):
Klar ist das heftig, aber moderne Systeme können noch viel mehr leisten.
Dadurch, dass die Tabelle, die potentiell interessante Flughäfen enthält, geschrumpft ist, ist auch die Suche nochmals beschleunigt:
Wie man sieht, enthält diese gerade mal knapp 6.000 Einträge. 60002 Abfragen sind nicht wirklich sonderlich viele. Je nachdem, wie weit man das Ganze ausdehnt, wird es natürlich noch einmal mit einer mehr oder weniger großen Zahl multipliziert.
CPM etc. lässt sich nun per Join in Kombi mit kleineren Rechenformeln bestimmen.
---------------
Ich reiße hier nur die Thematik an, aber will nur zeigen, dass es doch möglich ist (mir natürlich nicht, aber anderen Leuten wohl schon).
, aber besser spät als nie .Mich interessiert: wie weit sind Eure Bemühungen voran geschritten?
Zum hiesigen Stand: ich selbst mache so etwas natürlich nicht, weiß aber das andere Leute so etwas erfolgreich praktizieren. Natürlich ist nicht jede popelige OTA auf dieser Welt an das System angeschlossen, aber es sind durchaus einige OTAs dabei. Ich würde behaupten, dass die Top 15 (in Bezug auf die Größe des Unternehmens) angeschlossen sind, sowie auch einige Flugsuchmaschinen.
Zum "Problem" der Änderungen auf unterschiedlichen Buchungsseiten: das passiert äußerst selten. Die OTAs verändern vielleicht Layouts ihrer Seiten, wovon aber (XHR-)Requests und JSON Antworten fast nie betroffen sind. Wer also "intelligent" crawled, hat hier kaum Ärger. Wer natürlich irgendwelche Browser emuliert und sich nicht an die dahinterliegenden Requests hält, hat selbst Schuld.
Zum Blocken von IPs: hier lässt sich kaum Konsistenz erkennen. Manche sind total empfindlich, manche blocken fast nie etwas. So oder so sollte man natürlich ausreichend IPs in der Hinterhand haben.
Wer Kosten scheut, ist sowieso falsch. Um schnell und ordentlich zu arbeiten, sollte man schon mindestens zwei Server wie den PX121-SSD von Hetzner unterhalten. Dazu kommen diverse Nebenkosten.
Ist das Ganze trotzdem profitabel? Da ich selbst sowas ja nicht mache, kann ich nur berichten, dass es das wohl ist.
Gegenüber meinem alten Post hat sich an dem System, soweit ich weiß, durchaus auch einiges geändert. Damals konnte wohl noch nicht mit großen Datenmengen umgegangen werden, was sich heute geändert hat. Heute werden also sämtliche Daten in DBs erfasst, die danach nur über Webinterfaces ausgewertet werden. Früher haben die Server das wohl noch nicht mitgemacht. So hat man viel mehr Daten, die für andere Dinge wieder nützlich sein können (was scheren einen schon ein paar mehr Zeilen in DBs...). Eine simple 3X-Suche für eine potentiell interessante Strecke führt dann in kurzen Momenten zu über 300k Ergebnissen (Screens wurden mir weitergeleitet):
Klar ist das heftig, aber moderne Systeme können noch viel mehr leisten.
Dadurch, dass die Tabelle, die potentiell interessante Flughäfen enthält, geschrumpft ist, ist auch die Suche nochmals beschleunigt:
Wie man sieht, enthält diese gerade mal knapp 6.000 Einträge. 6000
2 Abfragen sind nicht wirklich sonderlich viele. Je nachdem, wie weit man das Ganze ausdehnt, wird es natürlich noch einmal mit einer mehr oder weniger großen Zahl multipliziert.CPM etc. lässt sich nun per Join in Kombi mit kleineren Rechenformeln bestimmen.
---------------
Ich reiße hier nur die Thematik an, aber will nur zeigen, dass es doch möglich ist (mir natürlich nicht, aber anderen Leuten wohl schon).
Zuletzt bearbeitet:
| Anzahl Startflughäfen | Anzahl Zielflughäfen | Kombinationen | Anzahl Datenpaare pro Abfrage | Kosten des Anbieters pro Abfrage | Verursachte Kosten pro Durchlauf pro Anbieter | Anzahl Anbieter | Verursachte Kosten pro Durchlauf gesamt | Verursachte Kosten pro Monat bei tägl. Abfrage |
| 6.000 | 6.000 | 36.000.000 | 4 | 0,0005 € | 72.000 € | 12 | 864.000 € | 25.920.000 € |
| 1.000 | 1.000 | 1.000.000 | 4 | 0,0005 € | 2.000 € | 12 | 24.000 € | 720.000 € |
| 300 | 300 | 90.000 | 4 | 0,0005 € | 180 € | 12 | 2.160 € | 64.800 € |
| 20 | 300 | 6.000 | 4 | 0,0005 € | 12 € | 12 | 144 € | 4.320 € |
Damit sollte sich die Frage ob das profitabel ist beantworten... Ich bin stolz auf euch!
Anzahl Startflughäfen Anzahl Zielflughäfen Kombinationen Anzahl Datenpaare
pro AbfrageKosten des Anbieters pro Abfrage Verursachte Kosten pro Durchlauf pro Anbieter Anzahl Anbieter Verursachte Kosten pro Durchlauf gesamt Verursachte Kosten pro Monat bei tägl. Abfrage 6.000 6.000 36.000.000 4 0,0005 € 72.000 € 12 864.000 € 25.920.000 € 1.000 1.000 1.000.000 4 0,0005 € 2.000 € 12 24.000 € 720.000 € 300 300 90.000 4 0,0005 € 180 € 12 2.160 € 64.800 € 20 300 6.000 4 0,0005 € 12 € 12 144 € 4.320 €
Damit sollte sich die Frage ob das profitabel ist beantworten... Ich bin stolz auf euch!
Wie gesagt: ich habe damit nichts zu tun. Ich profitiere hier und da vielleicht mit, bin technisch aber unfähig so etwas zu realisieren. Bei Kontakten aus dem Netz wird vielleicht hier und da mal was ausgetauscht, das war's dann aber auch.
Woher kommen die 0,00005€/Abfrage? Fallen tatsächlich so hohe Kosten an?
Die 0,0005 € sind eine einfache Schätzung meinerseits.
ITA/Google möchte für QPX Express z.B. 0,035 USD pro Abfrage haben. https://developers.google.com/qpx-express/v1/pricing
Hier mal die API-Kosten von Flightstats: https://developer.flightstats.com/getting-started/pricing
Klar haben die großen Anbieter andere Systeme and ganz andere Verträge... aber kosten tut es. Punkt. Kayak to pay ITA Software at least $21M over three years - Tnooz Und ob sich da das Komma jetzt noch um ein oder zwei Stellen verschiebt, ist angesichts der schieren Masse an Anfragen am Ende auch egal. Es wäre für die Anbieter sicher billiger den Betreibern - also leider nicht dir - pro Person einfach 2-3 Fööööörst-Tix im Monat zu spendieren. Vielleicht sollten sie das einfach mal Anfragen?! Und rein aus der Logik heraus ist dieses Brute-Force für die Suche nach EFs auch nur bedingt sinnvoll - was schon die Masse an nötigen Anfragen zeigt.
ITA/Google möchte für QPX Express z.B. 0,035 USD pro Abfrage haben. https://developers.google.com/qpx-express/v1/pricing
Hier mal die API-Kosten von Flightstats: https://developer.flightstats.com/getting-started/pricing
Klar haben die großen Anbieter andere Systeme and ganz andere Verträge... aber kosten tut es. Punkt. Kayak to pay ITA Software at least $21M over three years - Tnooz Und ob sich da das Komma jetzt noch um ein oder zwei Stellen verschiebt, ist angesichts der schieren Masse an Anfragen am Ende auch egal. Es wäre für die Anbieter sicher billiger den Betreibern - also leider nicht dir - pro Person einfach 2-3 Fööööörst-Tix im Monat zu spendieren. Vielleicht sollten sie das einfach mal Anfragen?! Und rein aus der Logik heraus ist dieses Brute-Force für die Suche nach EFs auch nur bedingt sinnvoll - was schon die Masse an nötigen Anfragen zeigt.
Vergesst bei der hypothetischen Berechnung nicht, dass damit nur an einer Datumskombination gesucht wurde! Die meisten OTAs unterhalten selbst noch eigene gecachte Datenbanken, so dass nicht jede Abfrage auch Kosten verursacht.
Die angesprochene Rechenpower sieht für mich etwas übertrieben aus. Da könnte man sicher was "in die Cloud" optimieren und das System verteilter gestalten. (Abfragen auf billige Instanzen, die Masterdatenbank lese optimiert gestalten. Löst auch noch nebenbei mögliche Probleme bei IP Sperren)
Die meisten OTAs unterhalten selbst noch eigene gecachte Datenbanken, so dass nicht jede Abfrage auch Kosten verursacht.Die angesprochene Rechenpower sieht für mich etwas übertrieben aus. Da könnte man sicher was "in die Cloud" optimieren und das System verteilter gestalten. (Abfragen auf billige Instanzen, die Masterdatenbank lese optimiert gestalten. Löst auch noch nebenbei mögliche Probleme bei IP Sperren)
Interessant.
Ich habe von Leuten gehört, die bei Kayak seit Jahren täglich deutlich mehr als diese 36M Abfragen machen (ob das wahr ist, oder nur Angeberei kann ich nicht beurteilen). Das wären bei 0,0005€/Abfrage ja bereits 180k€/Tag, was ja dann im Monat bereits höhere Kosten verursachen würde, als die Kosten die bei Kayak im Jahr anfallen.
Ich vermute daher, dass die Kosten weit geringer ausfallen, als die angenommenen 0,0005€.
Das wäre mal was
.Naja, ich habe ja nur ein paar kurze Informationen dargestellt. Tatsächlich werden die Routen nach unterschiedlichsten Kriterien zusammengestellt. Dadurch, dass mittlerweile eine riesige Datenbasis da ist (Routemaps der Allianzen sowie sehr vieler Airlines, Ergebnisse aus BruteForce...), kann man daraus durchaus Routen generieren.
Vergesst bei der hypothetischen Berechnung nicht, dass damit nur an einer Datumskombination gesucht wurde!
Klar. Wäre für mich persönlich nicht so relevant, da meine Urlaubszeiten ziemlich eingeschränkt sind. Da bleiben wenige Daten übrig.
Das trifft m.W. auf manche tatsächlich zu.
Das ist das, was wohl ein Server durchschnittlich so leisten muss. Wenn man das nun auf mehreren Servern so betreibt, dann kann man problemlos bis 20k Queries/s hochskalieren. Damit ist ein vernünftiger Betrieb dann auch möglich
Eine Alternative wäre wohl das beispielsweise auf Digitalocean Droplets zu betreiben, die man in der Anzahl automatisch an die Anforderungen anpasst. Kostenmäßig gewinnt man dadurch wohl kaum etwas, tendenziell hat man aber mehr zu tun.
Spannendes Thema.
Ich habe letzte Jahr mit einem Freund mal auf Low Level Basis und einer Source (ITA) so was getestet. Hat technisch sauber funktioniert. Auch die Datenmengen zu verarbeiten war eigentlich kein Thema.
Wir sind über die schiere Menge an Kombinationen bzw. der Kombinationslogik gestolpert. Aber wenn die Menge der Kombinationen ausgedünnt wird bzw. die die Häufigkeit der Suche, so ist das technisch kein Problem.
Gruss
TimoC
Ich habe letzte Jahr mit einem Freund mal auf Low Level Basis und einer Source (ITA) so was getestet. Hat technisch sauber funktioniert. Auch die Datenmengen zu verarbeiten war eigentlich kein Thema.
Wir sind über die schiere Menge an Kombinationen bzw. der Kombinationslogik gestolpert. Aber wenn die Menge der Kombinationen ausgedünnt wird bzw. die die Häufigkeit der Suche, so ist das technisch kein Problem.
Gruss
TimoC
Das sind doch ganz nette Zahlen, da lohnt es sich sicher auf andere Systeme zu schauen als nur (My?)SQL DBs. Transaktionen werden wohl z.B. keinen jucken und einiges einsparen.
Oder direkt auf EC2 Contatinern, oder... Aufwandsmäßig hält sich das auch in Grenzen, wenn das gesamte System darauf ausgerichtet ist.
Was die Anfrage "Wir hören auf eure Server zu knechten, dafür spendiert ihr uns F-Tix" zur Folge hätte, dürfte klar sein... und damit wird eigentlich auch deutlich, was da im Endeffekt abläuft. Anders ausgedrückt: Ich möchte ungern der sein, dessen Rechnungsadresse bei YXZ-Host angegeben ist - mit ein bissl "Scriptkiddie spielen" hat das absolut nichts mehr zu tun.
Es ist ja schön, dass das für die Gruppe so skalierbar ist - aber die Kisten auf der Gegenseite müssen auch unterhalten werden oder bezahlen sie diese auch? Ich stelle mir gerade vor, die Anbieter rüsten für x-Euronen auf um die Anfragen zu packen und plötzlich sagt die Gruppe: "Och nöö... kein Bock mehr.. wir schalten unsere Crawler ab." Wohin mit den ganzen Kapazitäten? Wenn ich mir die Werte da so ansehe, werden sich selbst Kosten von 0,0000001 € pro Abfrage noch zu einem schönes Sümmchen addieren und irgendwann ist das Fass voll. Sprich: Dagegen vorgehen lohnt sich plötzlich, man kann sich dann ja vielleicht die Kosten vom Verursacher erstatten lassen. Sollte das Vorgehen vorab von den Anbietern genehmigt worden sein: Hut ab - sieht gut aus - auch wenn ich der Meinung bin, dass es mit Kanonen auf Spatzen schießen ist! Falls nicht:
Es ist ja schön, dass das für die Gruppe so skalierbar ist - aber die Kisten auf der Gegenseite müssen auch unterhalten werden oder bezahlen sie diese auch? Ich stelle mir gerade vor, die Anbieter rüsten für x-Euronen auf um die Anfragen zu packen und plötzlich sagt die Gruppe: "Och nöö... kein Bock mehr.. wir schalten unsere Crawler ab." Wohin mit den ganzen Kapazitäten? Wenn ich mir die Werte da so ansehe, werden sich selbst Kosten von 0,0000001 € pro Abfrage noch zu einem schönes Sümmchen addieren und irgendwann ist das Fass voll. Sprich: Dagegen vorgehen lohnt sich plötzlich, man kann sich dann ja vielleicht die Kosten vom Verursacher erstatten lassen. Sollte das Vorgehen vorab von den Anbietern genehmigt worden sein: Hut ab - sieht gut aus - auch wenn ich der Meinung bin, dass es mit Kanonen auf Spatzen schießen ist! Falls nicht:
Angefangen um eine neue Programmiersprache zu lernen, habe ich mir in den letzten Jahren ein Tool programmiert, das ziemlich genau das kann, was in diesem Thread gesucht wird.Mehrere Abflug- bzw. Zielflughäfen, flexible Reisedaten, Filtermöglichkeiten nach Stopps, Reisedauer, Benachrichtigung wenn unter einem bestimmten Preis, usw.
Meine Erfahrungen dazu:
Suchvorgänge dauern sehr lange
Je komplexer die Suche wird, desto länger dauert der Vorgang. Der Server kann nur eine bestimmte Anzahl an Abfragen auf einmal bearbeiten. Der Aufwand steigt exponentiell!
Es ist teuer
Ein performanter Server kostet Geld. Nicht nur die Datenbank muss viel arbeiten, auch die CPU muss die ganzen Daten erstmal verarbeiten, um sie dann in der DB speichern zu können. Ist man bei einem on-demand-Anbieter kann ein Programmierfehler oder eine zu komplexe Anfrage sehr schnell sehr teuer werden.
Die 2-3 günstigen Urlaubsflüge, die ich dadurch pro Jahre fliege, können das lange nicht kompensieren.
Früher konnte ich bei Flightfox vieles wieder reinholen. Aber leider haben sie die meisten Experten gefeuert und Chimpando hat bisher nicht viel Traffic.
Fazit
Ohne speziellen Anwendungsfall würde ich es nicht noch einmal programmieren. Vor allem die aufgewendete Arbeitszeit steht in keinem Verhältnis mit den Ersparnissen
Meine Erfahrungen dazu:
Suchvorgänge dauern sehr lange
Je komplexer die Suche wird, desto länger dauert der Vorgang. Der Server kann nur eine bestimmte Anzahl an Abfragen auf einmal bearbeiten. Der Aufwand steigt exponentiell!
Es ist teuer
Ein performanter Server kostet Geld. Nicht nur die Datenbank muss viel arbeiten, auch die CPU muss die ganzen Daten erstmal verarbeiten, um sie dann in der DB speichern zu können. Ist man bei einem on-demand-Anbieter kann ein Programmierfehler oder eine zu komplexe Anfrage sehr schnell sehr teuer werden.
Die 2-3 günstigen Urlaubsflüge, die ich dadurch pro Jahre fliege, können das lange nicht kompensieren.
Früher konnte ich bei Flightfox vieles wieder reinholen. Aber leider haben sie die meisten Experten gefeuert und Chimpando hat bisher nicht viel Traffic.
Fazit
Ohne speziellen Anwendungsfall würde ich es nicht noch einmal programmieren. Vor allem die aufgewendete Arbeitszeit steht in keinem Verhältnis mit den Ersparnissen