Datenquelle OSM ==> Zukunft?

Hallo zusammen.

Wenn ich mir die Datenbankstatistik so anschaue:
http://munin.openstreetmap.org/openstreetmap/smaug.openstreetmap-df.html
hab ich kmein guten Bauchgefühl.

Wie soll das denn in Zukunft werden?
BRauchen wir ne eigene Serverfarm?
Wer kann und will denn das noch verwalten und warten?

Gibts irgendwo Optimierungsbedarf und Möglichkeiten?
Wenn ich da an die Historie denke, könnte man dann doch z.B. Änderungen länger als 3 Jahre zurück verwerfen…

Wie denkt ihr zu dem Thema?

Gruß

Wenn es knapp wird dann kann man erstmal anfangen die gelöschten Elemente die schon x Jahre gelöscht aus der Datenbank zu entfernen.

Jop… paar Platten haben in dem System auch noch Platz.

Ansonsten Platten gegen grösserer Tauschen… Oder anderes Raid level wählen (wenn die cpu / controller) da mitspielen

Hmm naja das zu verteilen wäre ja auch eine interessante wenn auch schwer zu realisierende Möglichkeit. Ich denke wenn die Wichtigkeit von OSM zunimmt kommen auch Sponsoren…auf Google wie bei Wikipedia würde ich dabei allerdings nicht setzten hihi :wink:

mit der History habe ich kein Problem (bin ja erst sei 3 Monaten dabei :wink:

aber jetzt im Ernst:

Man könnte ja z.B. über “Meilensteine” nachdenken, von denen es etwa 1 pro Jahr geben könnte. Alles was vorher war, braucht ja nun wirklich nicht mehr online zu sein.
Aber ob das langfristig was bringt, wage ich sehr zu bezweifeln.

Da sich OSM ja immer mehr zu einem Globalen Projekt entwickelt, sollte man darüber nachdenken, zumindest die Datenbank auch global zu verteilen. So etwas in der Richtung “Cloud Computing” für verteilte Datenbanken.
Und das Rendern könnte ebenfalls verteilt werden, ähnlich wie es tiles@home schon macht.

Ich weiss nicht, ob die von osm verwendete Datenbankssoftware das kann, mysql soll es können und oracle kann es definitiv - aber das würde Kohle kosten und nicht zuwenig.

gruss

wambacher

Warum wegwerfen?
Die Historie ggfs. bis auf die 10 letzten Einträge auf einen eigenen Server /
in eine eigene Datenbank.
Dann noch den History-View häppchenweise mit 10/20/30/50 Einträgen pro Seite,
dann kommen wir auch wieder mit Relationen mit hunderten Elementen und
Versionsnummer größer 100 klar.

Übrigens sollte die Möglichkeit eine Datenbank auf mehrere Platten/Server
zu verteilen bei jeder Datenbank-SW, die auf große Datenbanken abzielt,
dabei sein. Resp. sollte es entsprechende Version für solche Einsatzfälle geben.

Edbert (EvanE)

http://donate.openstreetmap.org/comments/, Datum 2009-02-08

Gruß, cilista

Hui, google hat für OSM gespendet :slight_smile:

Du hast bedenken, weil die Festplatte eines einzelnen Servers voller wird? Der hat gerade mal 10 Stück 450-GB-Festplatten verbaut. Da ist noch verdammt viel nach oben öffen vom technischen.
Vom Geld her dürfte es auch kein Problem sein, wenn Geld fehlt wird ein Sponsorenaufruf gestartet, da finden sich ganz sicher Leute die unterstützen.
Das einzige, was irgendwann kritisch wird, ist die Zeit. Wenn die Grafik stimmt, wird die Datenbank in 9 Monaten das Disklimit erreicht haben. 2-4 Monte dürfte man planen müssen um einen neuen Server aufzusetzen. Außer der Server ist so ausgelegt, daß man die Platten nacheinander tauschen kann gegen größere. 2 TB Platten rein und fertig. Aber das weiß ich nicht, ob das überhaupt so funktioniert.

Wir haben doch von Strato 3 Server für den FOSSGIS bekommen, was ist mit denen?

Naja ich denke mal so schnell wirds keine Bezahlbaren SAS platten mit entsprechender Seektime geben.

Zu den Strato servern kann ich nix sagen… wäre aber mal nett wenn man die Spezifikationen zu den Dingern hat.

Man kann sich als “normaler Enduser” mitunter nicht vorstellen, was bei professionellen Servern so alles geht:

  • Hardware Raid mit redundanten und eventuell gespiegelten Platten
  • Hot Swap erlaubt Austauschen der Geräte im laufenden Betrieb
  • Spiegeln von ganzen Servern
  • Cluster von Rechnern, die “nach Draußen” wie ein einziges System aussehen - Load Sharing
  • Grid-Computing: Globale Lastverteilung
  • Cloud-Computing: + Globale Datenhaltung

und noch einiges mehr.

Die Hardware macht dabei nur einen geringen (Kosten-)Anteil aus. Das richtige OS und die passende Datenbank bringt dann den Rest.

Als doch ziemlich “alter Hase” mach ich mir wesentlich mehr Gedanken/Sorgen um die Sicherheit der Systeme. Sicherheit im Sinne von “Schutz” UND in Form von “Stabilität/Robustheit”.

Wobei meine “Sorgen” relativ gering sind, da die OSM-Admins die Sache sehr gut im Griff haben. Lob! Lob!

mfg

wambacher

Eine server “farm” ist es zwar noch nicht ganz, aber immerhin sind inzwischen 17 server, betrieben von der OSMF, verteilt auf drei Standorte im Einsatz. Abgesehen von diesen Core servern, kommten dann noch die t@h server, die Fossgis server, einige Server aus Frankreich und noch diverse weitere Server die externe OSM basierte Dienste anbieten. OSM ist also schon jetzt auf eine beachtliche Groesse angewachsen. Insofern sehe ich eigentlich positiv in die Zukunft, das OSM auch weiterhin die Infrastruktur entsprechend den Beduerfnissen skaliert bekommt. Immoment laeuft jedenfalls eigentlich alles recht glatt und die naechsten paar Monate sollte es nicht zu groesseren Engpaessen kommen.

Die History wird sicherlich wenn es irgendwie zu vermeiden geht nicht komplett geloescht. Es gab aber in der Vergangenheit schon gelegentlcih mal eine Zaesur wodurch aeltere Vergangenheit nicht mehr auf dem normalen Wege zugaeglich ist. So z.B. geschehen bei der Umstellung von API 0.4 auf 0.5, wobei das mehr mit der “inkompatibilitaet” des Daten modeles zu tun hatte als auf Grund des Platten-platzes.

Eine geographische Verteilung der Datenbank wird warscheinlich erst mal nicht kommen, da der “Wartungsaufand” einer solchen Loesung unnoetig hoch ist und es weniger komplexe Loesungen gibt.

Derzeit wird geplant den jetztigen DB server um weitere zwei Festplatten aufzuruesten um den Plattenplatz zu erweitern und den Hauptspeicher auf 64Gb ram zu erhoehen. Das gibt dann wahrscheinlich wieder ein paar Monate mehr Verschnaufpause und dann wird man wieder sehen muessen wo die Resourcen am knappesten sind und wie man das am besten angeht. Aber so ist es halt in einem schnell wachsenden Projekt, das man immer dort anbaut wo es gerade klemmt oder brennt. :slight_smile:

Stabilitaet und Robustheit? Klar, koennte besser sein. Es gibt schon ein paar kritische Single points of Failure, wie z.B. den DB server, den Tile server, oder die Netzwerk infrastruktur des Hosters. Wenn eines dieser ploetzlich komplett den Geist aufgeben wuerde, gaebe es vermutlich schon ein paar Tage downtime bis ersatz beschaffen werden kann, was natuerlich extrem unschoen waere. Aber da muss man halt zwischen Wachstum und Sicherheit ein wenig abwaegen und schauen wie man das Vorhandene am effizientesten einsetzt. Mit weiterem Wachstum kommt aber mit Sicherheit auch erhoehte Redundanz und Sicherheit.

Die Admins tun jedenfalls ihr Moeglichstes um alles stabil am laufen zu halten und sind sehr Kompetent in der Sache und waren bislang sehr erfolgreich dabei.

Ein paar links zu den Server Specs:
http://wiki.openstreetmap.org/wiki/Server
http://wiki.openstreetmap.org/wiki/FOSSGIS/Server

Vielleicht tut sich ja mal irgendwann ein sehr großer Spender auf damit man alles neu machen kann?
Mal ne Mail an http://de.wikipedia.org/wiki/Mark_Shuttleworth schreiben :smiley:

Ich denk auf jeden Fall auch das die Admins, wer auch immer die bezahlt, einen wirklich guten Job machen!