[Talk-de] ?Unterstützung für die(?) Server

AK-Palme ak-palme at ak-palme.de
Di Sep 25 12:13:47 UTC 2007


Moin,
um jetzt mal mit dem träumen aufzuhören: Als fuesika die Idee mit dem 
Mirror bei mir ansprach, hatte ich einige Zeit eine Idee, die mir recht 
sinnvoll erscheint.
Abgekupfert ist die Idee von apt-proxy & co. Wenn eine Anfrage auf den 
Mirror abgesetzt wird, dann guckt der Mirror, ob er aktuelle Daten hat, 
und wenn er sie nicht hat, fischt er sich die Daten vom Primärserver.
Ob die Daten aktuell sind, kann man entweder durch ein timeout 
Festlegen, z.b. dass man a) beim generieren sagt, dass der tile und eine 
bestimmte Uhrzeit abläuft oder b) ein tile Beispielsweise 2 Tage hält, 
nachdem er auf den Mirror gekommen ist, oder c) Bei jeder Anfrage ein 
Header mitgeschickt wird, der angibt, wann das Tile gebaut wurde, und 
der Mirror diesen Zeitpunkt mit seinen Daten vergleicht und ggf. die 
neuen Daten holt.
Das ganze könnte man recht entspannt über HTTP abwickeln, da ja auch 
alle Headerfunktionen, deflate, etc verfügbar sind. Die letzte Methode 
habe ich mir mit HTTP-Code 100 - Continue nach dem Header vorgestellt. 
Dann muss der Server erst nach dem Continue mit den Daten generieren 
anfangen.
Möglich wäre auch eine Kombination.

Dieses Konzept hat natürlich nur Sinn, wenn man einen lokalen Mirror 
nutzt. Vorteil ist, dass der Master-Server nicht beeinträchtigt wird, 
und dass es einfach zu portieren ist.

Gruss,
Christian

Frederik Ramm wrote:
> Hallo,
>
>   
>> Sehe ich richtig, dass es das Ziel sein sollte, die Write-Querys zu
>> verkürzen/teiles um das Locking effektiver zu machen?
>>     
>
> Was ich geschrieben habe, war ein Beispiel, das mal auf der  
> englischen Liste geposted wurde. Wo genau der Falschenhals ist, weiss  
> ich aber nicht; vermutlich weiss das keiner so genau. Auf  
> munin.openstreetmap.org (Rechner "db") kannst Du dir einen Eindruck  
> vom Zustand des db-Servers machen.
>
>   
>> Man könnte, wenn
>> man einen MySQL-Cluster nutzt das Ziel mit LOW_PRIORITY-Updates  
>> machen.
>> Wenn man dann noch wenige und effektive B-Trees in der Indexierung  
>> nutzt
>> würde das sicher viel Wirkung zeigen. Oder wird das schon gemacht?
>>     
>
> Was die Indexierung anbetrifft, war es immer das Problem, dass man  
> effektiv halt entweder nach Laengen- oder nach Breitengrad indexieren  
> konnte, beim jeweils anderen dann aber ein huebscher Tablescan  
> drankam. Das ist jetzt durch ein "Quadtile"-Indexing verbessert  
> worden, aber optimal ist das noch sicher nicht.
>
>   
>> Statt planet-File könnte man im Grunde doch durch ein Planet-Table
>> ersetzen? Das würde das Caching und die Performace der Datenbank  
>> nutzen.
>> Oder sehe ich das falsch, dass das Planet-File eine Art "SELECT * FROM
>> alle_tabellen" ist?!
>>     
>
> Doch, ist es - aber es soll ja schliesslich nur ein einziges mal der  
> Select gemacht werden, und das Ergebnis soll dann verteilt werden.  
> Dieser Select (natuerlich sind es ein paar mehr) ist im Moment  
> hoellisch ineffektiv geloest, die Erstellung des Planet-Files dauert  
> um die 5 Stunden oder so. Da gibt es vel Optimierungspotenzial (und  
> auch schon Leute, die dran herumbasteln). Ich weiss nicht so ganz,  
> was Du mit "Planet Table" meinst. Das Planet-File ist derzeit 16 GB  
> gross (unkomprimiert als XML, aber die MySQL-interne Darstellung wird  
> sicherlich auch ihre 2 GB brauchen) und es wird, wenn der TIGER- 
> Import amgeschlossen ist, um die 200 GB haben. Mit Caching ist da  
> vermutlich nicht mehr viel zu wollen.
>
> [Meine Verteil-Idee]
>
>   
>> Die Idee finde ich gut, aber sie ist doch extrem hoch skaliert. Als
>> Unterscheidungsmerkmal könnte man den Baum sowie den DNS-Baum  
>> aufbauen.
>> Wobei dann jeder Server für einen bestimmten Koordinatenbereich
>> zuständig ist. Das würde auch das Problem lösen wie die Daten aktuell
>> bleiben.
>>     
>
> Ja, das koennte man machen, allerdings wuerde ich das nicht gut  
> finden, weil es weniger anarchisch als mein Vorschlag waere. Bei  
> meinem Vorschlag kann mehr oder weniger jeder einen Slave aufsetzen,  
> und jeder kann sich frei ueberlegen, an wessen Slave er sich  
> dranhaengen will - der, dessen Server am besten funktioniert, bekommt  
> automatisch die Nutzer (also nicht wirklich automatisch, aber es  
> spricht sich halt rum, dass der und der den schnellsten Server hat).  
> Bei Deiner DNS-Idee wuerden wir zentral festlegen muessen, wer jetzt  
> den Zuschlag fuer ein bestimmtes Gebiet bekommt, und muessten damit  
> auch gleich sicherstellen, dass derjenige auch kein Idiot ist und  
> sein Server funktioniert und so. Das wiederum wuerde uns zwingen, die  
> Leute gruendlich auszuwaehlen und allerhand Bedingungen aufzustellen,  
> wann jemand "gut genug" ist, um so einen Server zu betreiben... alles  
> unnoetiger Verwaltungsaufwand, den man ebenso dem "freien Markt"  
> ueberlassen koennte.
>
> Bye
> Frederik
>
>   





Mehr Informationen über die Mailingliste Talk-de