Abfrage über mehrere Server ( IPs)

Halllo,

ist es möglich mit Mysql Abfragen an mehere Server (IPs) gleichzeitig zu
stellen?

Rechner1: 192.168.2.10
Rechner2: 192.168.2.12

Auf beiden liegt eine TabelleX gleicher Struktur (ID,Name) aber mit je 50%
der Daten, die abgefragt werden sollen.
Also z.B. auf Rechner1 die ID 1-1000000, auf Rechner2 die ID
1000001-2000000.

Ich möchte jetzt alle IDs deren Name mit A anfangen.

Gibt es dann eine solche Art von Abfrage:

(select ID from Rechner1.TabelleX where Name like "A%")
UNION
(select ID from Rechner2.TabelleX where Name like "A%")

Sinn der Übung ist mit einer Abfrage die Rechenleistung von zwei Rechnern
gleichzeitig! zu nutzen, da die Abfrage auf einem Rechner zu langsam ist.

Besten Dank im Voraus

Re: Abfrage über mehrere Server ( IPs)

Hi PG

PG wrote:
^-- Bitte konfiguriere deinen Newsagent so, dass hier der Realname
erscheint.
> ist es möglich mit Mysql Abfragen an mehere Server (IPs) gleichzeitig zu
> stellen?

Ja, indem du clusters verwendest. MySQL ist dafür weder ausgelegt noch
ist dies sinnvoll, so zu machen.

> Gibt es dann eine solche Art von Abfrage:
> (select ID from Rechner1.TabelleX where Name like "A%")
> UNION
> (select ID from Rechner2.TabelleX where Name like "A%")
> Sinn der Übung ist mit einer Abfrage die Rechenleistung von zwei Rechnern
> gleichzeitig! zu nutzen, da die Abfrage auf einem Rechner zu langsam ist.

Du solltest dich mit dem Kapitel
Chapter 7. Optimization
http://dev.mysql.com/doc/refman/5.1/en/optimization.html

auseinander setzen. Was du beschreibst ist für MySQL ein Klacks.
Anfangen solltest du mit Indices setzen:
7.4.3. Column Indexes
http://dev.mysql.com/doc/refman/5.1/en/indexes.html

NB, hat aber für dich kaum eine Bedeutung. Es gibt seit MySQL 5.1 Index
Merge Optimization, welches IMHO in etwa das macht, was du möchtest.
7.2.6. Index Merge Optimization
http://dev.mysql.com/doc/refman/5.1/en/index-merge-optimizat ion.html

HTH, Johannes

Re: Abfrage übermehrere Server ( IPs)

PG wrote:

> Halllo,
>
> ist es möglich mit Mysql Abfragen an mehere Server (IPs) gleichzeitig zu
> stellen?
>
> Rechner1: 192.168.2.10
> Rechner2: 192.168.2.12

Möglich zwar schon, aber nicht auf die Art und Weise, die Du beschreibst.

> Gibt es dann eine solche Art von Abfrage:
>
> (select ID from Rechner1.TabelleX where Name like "A%")
> UNION
> (select ID from Rechner2.TabelleX where Name like "A%")

Du kannst Diene Applikation natürlich Verbindungen zu zwei Rechnern
herstellen lassen und auf beiden denselben Query absetzen, evtl noch
unterteilt auf bspw. gerade und ungerade IDs. Aber das wird Dir nicht viel
helfen.


> Sinn der Übung ist mit einer Abfrage die Rechenleistung von zwei Rechnern
> gleichzeitig! zu nutzen, da die Abfrage auf einem Rechner zu langsam ist.

Da kommen wir der Sache schon näher. Jetzt mal Butter bei die Fische:

- Wieviele Zeilen hat die Tabelle?
- Wieviele davon fangen mit A an?

Und vor allem:

- Existiert ein Index auf die Spalte Name?


Thomas
--
Napoleon trug immer Rot, damit seine Soldaten nicht sehen konnten, wenn er
verwundet wurde. Die Nazis trugen braune Hosen... (unbekannte Quelle)

Re: Abfrage über mehrere Server ( IPs)

Danke für die Antwort.

> Du solltest dich mit dem Kapitel
> Chapter 7. Optimization
> http://dev.mysql.com/doc/refman/5.1/en/optimization.html
>
> auseinander setzen. Was du beschreibst ist für MySQL ein Klacks.

Das ist auch nur ein Beispiel. Es geht nur darum, ob und wenn wie es
prinzipiell möglich ist.
Die tatsächliche Abfrage (Fulltext-Index über mehrere Mio. Datensätze ) ist
so umfangreich, daß es ein Server keine brauchbare Performance mehr liefern
kann.

Re: Abfrage ber mehrere Server ( IPs)

"Thomas Rachel" schrieb

> Du kannst Diene Applikation natürlich Verbindungen zu zwei Rechnern
> herstellen lassen und auf beiden denselben Query absetzen

Vielen Dank.
Gibt es dazu irgenwo im Netz ein Beispiel?
Eine Mysql-Abfrage an zwei Rechner gleichzeitig?

Re: Abfrage ber mehrere Server ( IPs)

PG schrieb:

> Gibt es dazu irgenwo im Netz ein Beispiel?
> Eine Mysql-Abfrage an zwei Rechner gleichzeitig?

Es ist nicht *eine* Abfrage. Du musst mit $programmiersprache zwei
Connections herstellen, über jede Connection eine Abfrage abschicken und
die Ergebnismengen mergen.

gruss, heli

Re: Abfrage über mehrere Server ( IPs)

"PG" wrote:

>> Was du beschreibst ist für MySQL ein Klacks.
>
> Das ist auch nur ein Beispiel. Es geht nur darum, ob und wenn wie es
> prinzipiell möglich ist.

Möglich ist vieles. Die Frage ist, ob es sinnvoll ist. IMNSHO ist das,
was dir da vorschwebt, nicht sinnvoll. Horizontale Partitionierung der
Daten macht man i.d.R. nur dann, wenn man typischerweise nur auf die
Daten einer einzelnen (oder weniger) Partition(en) zugreifen muß.

> Die tatsächliche Abfrage (Fulltext-Index über mehrere Mio. Datensätze ) ist
> so umfangreich, daß es ein Server keine brauchbare Performance mehr liefern
> kann.

Das kommt wohl auf die Definition von "brauchbare Performance" und
vor allem "Server" an. FULLTEXT Indexe sind (nicht nur) bei MySQL
eher groß. Für vernünftige Performance sollten die ins RAM passen.
Server mit 4 Operon-Cores und zweistellig GB RAM kann man problemlos
kaufen. Nichtmal übermäßig teuer.

Die weitaus wichtigere Frage dürfte sein, ob das Feature-Set der
MySQL-Volltextsuche überhaupt reicht. Das tut es nämlich nur für
eher anspruchslose Aufgaben.


XL

Re: Abfrage über mehrere Server ( IPs)

PG wrote:
> ist es möglich mit Mysql Abfragen an mehere Server (IPs) gleichzeitig zu
> stellen?
>
> Rechner1: 192.168.2.10
> Rechner2: 192.168.2.12
>
> Auf beiden liegt eine TabelleX gleicher Struktur (ID,Name) aber mit je 50%
> der Daten, die abgefragt werden sollen.
> Also z.B. auf Rechner1 die ID 1-1000000, auf Rechner2 die ID
> 1000001-2000000.
>
> Ich möchte jetzt alle IDs deren Name mit A anfangen.
>
> Gibt es dann eine solche Art von Abfrage:
>
> (select ID from Rechner1.TabelleX where Name like "A%")
> UNION
> (select ID from Rechner2.TabelleX where Name like "A%")
>
> Sinn der Übung ist mit einer Abfrage die Rechenleistung von zwei Rechnern
> gleichzeitig! zu nutzen, da die Abfrage auf einem Rechner zu langsam ist.

Das ist, solange man das Problem auf die Komplexität der Abfragen
reduziert, eine Dumme Idee[tm].

Ich nehme an, dass `Name` indiziert ist. Anderenfalls wäre dein Problem
sehr schnell gelöst.
Ein solcher Index ist vereinfacht als binärer Baum implementiert. In
diesem vereinfachten binären Baum findest du deine Daten mit log(N)
Schritten, wobei N die Anzahl der Datensätze ist.

Bei N=2.000.000 Datensätzen ist log(N)=21 (über den Daumen)

Wenn du die Daten jetzt über zwei Rechner verteilst, hat auf jedem
Rechner der Binärbaum des Indexes die Tiefe log(N/2)=log(N)-1=20. Das
heißt, der Geschwindigkeitszuwachs liegt unter 5%, obwohl du zwei
Rechner beschäftigst.

Diese Rechnung ist natürlich vereinfacht und lässt
Hardwarebeschränkungen wie RAM-Größe außer Acht. Es könnte sich durchaus
lohnen die Daten zu verteilen, wenn dadurch der Index auf beiden
Rechnern komplett ins RAM passt. Aber das glaube ich bei 2.000.000
Datensätzen eher noch nicht.

Grüße
Kai

Re: Abfrage übermehrere Server ( IPs)

Kai Ruhnau wrote:
> Bei N=2.000.000 Datensätzen ist log(N)=21 (über den Daumen)

Für die Basis 2. Die Basis ist nicht 2.

In einem Index hast Du Index Records. Ein Index-Record besteht aus den zu
indizierenden Daten und dann einer Menge von Row-Pointers zu den Rows, die
zu diesem Datum gehören.

Bei einem MyISAM Primary Key auf ein Integer ist das Integer 4 Byte groß und
der Row Pointer by Default 6 Byte. Weil ein Primary Key definiert ist als
"ein Unique Key auf eine Spalte die NOT NULL ist mit dem Namen PRIMARY",
kann es also nur einen Row Pointer pro Indexwert geben. Ein Indexrecord hat
also genau 10 Byte.

MyISAM hat Indexblöcke von 1024 Byte. In einen Indexblock passen also ca.
100 Indexrecords.

Ein Indexblock ist im Mittel zu 2/3 gefüllt. Es sind also ca. 66
Indexrecords in einem Block enthalten.

Du hast also keinen Zweibaum, sondern einen Baum mit einem Fanout von ca. 66
in Deinem B-Baum.

l(2000000)/l(2)
20.93156856932417408743
l(2000000)/l(66)
3.46297216164088121590

Oder anders gesagt, der kürzeste Pfad durch den Indexbaum hat in
Wirklichkeit nicht 20, sondern 3 Schritte und der längste Pfad nicht 21,
sondern 4 Schritte.

Für größere Indexrecords oder für Nonunique Indices ist der Fanout
schlechter. Dennoch: Bei einer Größe von 100 Byte pro Indexrecord passen
immerhin noch ca. 6 Records in einen Block und wir bekommen für 2 Mio
Datensätze etwas über 8 Schritte bis zum Ziel.

> Wenn du die Daten jetzt über zwei Rechner verteilst, hat auf jedem
> Rechner der Binärbaum des Indexes die Tiefe log(N/2)=log(N)-1=20. Das
> heißt, der Geschwindigkeitszuwachs liegt unter 5%, obwohl du zwei
> Rechner beschäftigst.

Mit den geänderten Fanout-Werten ist der Gewinn prozentual gesehen etwas
besser - wir sind "weiter vorne" auf einer logarithmischen Kurve und dort
ist sie noch etwas steiler. Dennoch ist das nicht der Punkt - wenn es bei
nur 2 Mio Records zu Problemen kommt, ist das idR ein Hinweis auf fehlende
Indices.


Kris

Re: Abfrage über mehrere Server ( IPs)

Kristian Köhntopp wrote:
> Kai Ruhnau wrote:
>> Bei N=2.000.000 Datensätzen ist log(N)=21 (über den Daumen)
>
> Für die Basis 2. Die Basis ist nicht 2.

War auch zunächst nur als einfaches Beispiel gedacht, zum besseren
Verständnis. Dank dir für das tiefgreifende Verständnis und die genauen
Abläufe.

> In einem Index hast Du Index Records. Ein Index-Record besteht aus den zu
> indizierenden Daten und dann einer Menge von Row-Pointers zu den Rows, die
> zu diesem Datum gehören.
>
> Bei einem MyISAM Primary Key auf ein Integer ist das Integer 4 Byte groß und
> der Row Pointer by Default 6 Byte. Weil ein Primary Key definiert ist als
> "ein Unique Key auf eine Spalte die NOT NULL ist mit dem Namen PRIMARY",
> kann es also nur einen Row Pointer pro Indexwert geben. Ein Indexrecord hat
> also genau 10 Byte.
>
> MyISAM hat Indexblöcke von 1024 Byte. In einen Indexblock passen also ca.
> 100 Indexrecords.
>
> Ein Indexblock ist im Mittel zu 2/3 gefüllt. Es sind also ca. 66
> Indexrecords in einem Block enthalten.
>
> Du hast also keinen Zweibaum, sondern einen Baum mit einem Fanout von ca. 66
> in Deinem B-Baum.
>
> l(2000000)/l(2)
> 20.93156856932417408743
> l(2000000)/l(66)
> 3.46297216164088121590
>
> Oder anders gesagt, der kürzeste Pfad durch den Indexbaum hat in
> Wirklichkeit nicht 20, sondern 3 Schritte und der längste Pfad nicht 21,
> sondern 4 Schritte.

Der längste Pfad ja, aber wie findest du innerhalb des Fanouts den
Datensatz für den Pfad nach unten? Geht da nicht die gewonne Zeit durch
die geringere Pfadlänge wieder drauf? Oder findet MySQL der Eintrag in
einem Indexblock aufgrund von Sortierung oder Zusatzinformationen schneller?

> Für größere Indexrecords oder für Nonunique Indices ist der Fanout
> schlechter. Dennoch: Bei einer Größe von 100 Byte pro Indexrecord passen
> immerhin noch ca. 6 Records in einen Block und wir bekommen für 2 Mio
> Datensätze etwas über 8 Schritte bis zum Ziel.

Wie gefragt: welche Laufzeit haben die 8 Schritte im Vergleich zu den 20
Schritten im Binärbaum, wo jeweils eine Entscheidung pro Ebene reicht?

Dass es sinnvoll ist den Index in Blöcke aufzuspalten, diese "am Stück"
zu laden und nicht gebrauchte "Indexseiten" auch nicht im Speicher
halten zu müssen steht außer Frage. Diese Art der Verwaltung wäre bei
einem einfachen Binärbaum sicherlich zu aufwändig (igitt! Ich will
aufwendig schreiben!).

Grüße
Kai

Re: Abfrage übermehrere Server ( IPs)

Kai Ruhnau wrote:
> Der längste Pfad ja, aber wie findest du innerhalb des Fanouts den
> Datensatz für den Pfad nach unten?

Durch binäre oder lineare Suche. Das ist jedoch auf einem In-Memory-Buffer.

Ein Byte Speicher kann individuell adressiert werden und hat eine Access
Time von n * 10E-9 (Nanosekunden).

Ein Stück Platte kann in Blöcken adressiert werden, die zudem oft als
Filesystem- oder Datenbank-Blöcke in noch größeren Einheiten zusammengefaßt
werden (Platte: 512 Byte, Filesystem: idR 4 KB. MyISAM: 1 KB, InnoDB: 16
KB). Die Zugriffszeit der Platte ist im Bereich von n * 10E-3
(Millisekunden): Average Seek Time (2-4ms) + Average Rotational Delay (1/2
Rotation = 1/250 bis 1/500 Sek, also 2-4ms) + Transfer Time
(vernachlässigbar), also ca. 5-8ms. Du hast also 120-200 Diskoperationen
mit Seeks pro Sekunde und doppelt so viele nicht konsekutive Operationen
ohne Seeks.

Oder anders: Je nach Größe der Datenstrukturen ist Speicher zwischen 1000
(1E3) und 1E5 mal schneller als ein Plattenzugriff.

Eine Millisekunde sind bei 3 GHz Zykluszeit und einer Instruktion pro Zyklus
übrigens 3 Millionen Instruktionen.


Oder noch einprägsamer: Performancetuning bei Datenbanken basiert in erster
Näherung darauf, die Platten nicht zu benutzen.

> Dass es sinnvoll ist den Index in Blöcke aufzuspalten, diese "am Stück"
> zu laden und nicht gebrauchte "Indexseiten" auch nicht im Speicher
> halten zu müssen steht außer Frage.

> Diese Art der Verwaltung wäre bei
> einem einfachen Binärbaum sicherlich zu aufwändig (igitt! Ich will
> aufwendig schreiben!).

Mach doch. Tu ich ja auch. :)




Deine Überlegungen hinsichtlicher der Speicheroperationen von B-Trees gehen
im Zeitaufwand für Plattenzugriffe unter.

Im Speicher und für In-Memory-Strukturen spielen sie eine Rolle. Darum haben
MEMORY-Tabellen by default einen HASH-Index und Cluster verwendet darum
Redblack- statt B-Trees als Indexstrukturen und InnoDB verwendet Adaptive
Hash Indexes (AHI), wenn Speicher übrig ist, um Indexzugriffe im Speicher
zu beschleunigen.

Für Speicherstrukturen und eq_ref ist ein Hash die schnellste Struktur, drum
sind MEMORY-Tabellen noch mal 3-5 mal schneller als ein MyISAM, das
komplett im Speicher liegt. Wenn der Server natürlich ins Swappen gerät und
MEMORY-Strukturen auf die Platte geraden, dann hast Du Hash-Zugriffe auf
einer Platte. Hmm, hast Du mal ein Amiga-Dateisystem gehört? Das ist das,
was dann passiert.

Kris