Hallo Lug!
Ich habe folgende Tabelle:
CREATE TABLE pages ( sequences longtext COLLATE utf8_unicode_ci NOT NULL, revid int(11) NOT NULL, pageid int(11) NOT NULL, title varchar(250) COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (revid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Sie ist 3GB groß und enthält 550k Einträge. Die sequences sind Text.
Es gibt drei Befehle, die ich auf der Tabelle ausführe: INSERT INTO pages (sequences,revid,pageid,title) VALUES(:sequences,:revid,:pageid,:title) SELECT sequences FROM pages WHERE revid=:revid (30x pro Sekunde) SELECT count(*) AS pages FROM pages
Jetzt gibt es zwei Probleme. Erstens wächst der Speicherbedarf von MySQL fast auf die Größe der Tabelle. Gebe ich ihm nicht den RAM, also momentan innodb_buffer_pool_size=3G, wird die Ausführungszeit der Queries extrem lang, und die CPU-Last steigt ins Unermessliche.
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert. Diesen SELECT habe ich testweise in einen VIEW gepackt, aber das ändert nichts. Fordere ich zweimal pro Sekunde SELECT count(*) an, verdoppelt sich die Last auf 50%.
Thomas
Zitat von Thomas Schmidt schmidt@netaction.de:
Hallo Lug!
Ich habe folgende Tabelle:
CREATE TABLE pages ( sequences longtext COLLATE utf8_unicode_ci NOT NULL, revid int(11) NOT NULL, pageid int(11) NOT NULL, title varchar(250) COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (revid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Sie ist 3GB groß und enthält 550k Einträge. Die sequences sind Text.
also eine eher kleine Tabelle ...
Es gibt drei Befehle, die ich auf der Tabelle ausführe: INSERT INTO pages (sequences,revid,pageid,title) VALUES(:sequences,:revid,:pageid,:title) SELECT sequences FROM pages WHERE revid=:revid (30x pro Sekunde)
Die sollte rasend schnell gehen, da Suche nach einem PK.
SELECT count(*) AS pages FROM pages
Jetzt gibt es zwei Probleme. Erstens wächst der Speicherbedarf von MySQL fast auf die Größe der Tabelle. Gebe ich ihm nicht den RAM, also momentan innodb_buffer_pool_size=3G, wird die Ausführungszeit der Queries extrem lang, und die CPU-Last steigt ins Unermessliche.
welcher Anfragen, da sind 2. Die Suche nach dem PK sollte IMHO nicht leiden.
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert. Diesen
Ich nix MySQL, aber unter PG würde dies auch dauern, da es einen Seq-Scan erfordert. Normalerweise braucht man dies nicht, also die exakte Anzahl. Oft reicht eine grobe Schätzung der Gesamtanzahl, sie gilt ja streng genommen auch nur für die konkrete TX, in der Du das abfragst. Also, entweder guggst Du in den Statistiken nach einer Schätzung (in PG wäre dies pg_class.reltuples), oder aber führst über einen TRIGGER einen exakten Counter.
SELECT habe ich testweise in einen VIEW gepackt, aber das ändert
Ein VIEW ist eh nix weiter als ein Alias für einen SELECT.
Andreas
Vielen Dank Andreas!
Gerade habe ich "OPTIMIZE pages" ausgeführt. Anscheinend war der Primary Key wirkungslos, da alle Daten in der selben Datei lagen. Das Optimize müsste die Keys nochmal in einer zweiten Datei extra gespeichert haben.
Effekt ist, dass deutlich weniger RAM verbraucht wird. Ab wann die Datenbank wieder mangels Speicher langsam wird, wird sich zeigen.
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert.
Also, entweder guggst Du in den Statistiken nach einer Schätzung (in PG wäre dies pg_class.reltuples), oder aber führst über einen TRIGGER einen exakten Counter.
Die Schätzung liegt um Faktor zwei daneben. Epic fail. Auf 10% sollte die Zahl schon stimmen.
Ich möchte auch wissen, wie viele Einträge in der letzten Sekunde dazugekommen sind. Der TRIGGER ist natürlich etwas unhandlich, aber wohl die beste Lösung.
Thomas
Zitat von Thomas Schmidt schmidt@netaction.de:
Vielen Dank Andreas!
Gerade habe ich "OPTIMIZE pages" ausgeführt. Anscheinend war der Primary Key wirkungslos, da alle Daten in der selben Datei lagen. Das Optimize müsste die Keys nochmal in einer zweiten Datei extra gespeichert haben.
Effekt ist, dass deutlich weniger RAM verbraucht wird. Ab wann die Datenbank wieder mangels Speicher langsam wird, wird sich zeigen.
In einem $anderen_db_system gibt es den Befehl EXPLAIN ANALYSE <query>, wo man sehr schön u.a. Dinge wie geschätzte und reale Anzahl Ergebnisssätze, genutze Indexe, Cache Hit/Miss, Größe temp. Files und einiges mehr sehen kann ... bei MySQL ist das alles ja eher Blindflug.
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert.
Also, entweder guggst Du in den Statistiken nach einer Schätzung (in PG wäre dies pg_class.reltuples), oder aber führst über einen TRIGGER einen exakten Counter.
Die Schätzung liegt um Faktor zwei daneben. Epic fail. Auf 10% sollte die Zahl schon stimmen.
Ich möchte auch wissen, wie viele Einträge in der letzten Sekunde dazugekommen sind. Der TRIGGER ist natürlich etwas unhandlich, aber wohl die beste Lösung.
Ja, wenn es genau sein soll, ...
Andreas
bei MySQL ist das alles ja eher Blindflug.
Ich dachte, es würde nur mir so gehen. Momentan habe ich damit zu kämpfen, dass aufwändige Queries den Server zustopfen und dann allen Prozessen die Verbindung gekappt wird. Anschließend kann für mehrere Minuten kein Client mehr auf die Datenbank zugreifen, egal ob phpmyadmin, PDO, "$ mysql" auf der Bash oder sonstwas.
Thomas
Hallöchen
Zitat von Thomas Schmidt schmidt@netaction.de:
bei MySQL ist das alles ja eher Blindflug.
Blindflug? Wo? EXPLAIN SELECT ... funktioniert wunderbar und ist auch gut auf einer schwarzen Konsole und weißer Schrift lesbar.
Ich dachte, es würde nur mir so gehen. Momentan habe ich damit zu kämpfen, dass aufwändige Queries den Server zustopfen und dann allen Prozessen die Verbindung gekappt wird. Anschließend kann für mehrere Minuten kein Client mehr auf die Datenbank zugreifen, egal ob phpmyadmin, PDO, "$ mysql" auf der Bash oder sonstwas.
Das sieht sehr nach persistenten Verbindungen aus ... Mach mal "normale" daraus. An sonsten mal die max_connections hochsetzen.
Schönes Wochenende,
Falk
falk.doering@fadoe.de falk.doering@fadoe.de wrote:
Hallöchen
Zitat von Thomas Schmidt schmidt@netaction.de:
bei MySQL ist das alles ja eher Blindflug.
Blindflug? Wo? EXPLAIN SELECT ... funktioniert wunderbar und ist auch gut auf einer schwarzen Konsole und weißer Schrift lesbar.
Vergleiche einfach mal das EXPLAIN von MySQL mit dem von PostgreSQL.
Ich dachte, es würde nur mir so gehen. Momentan habe ich damit zu kämpfen, dass aufwändige Queries den Server zustopfen und dann allen Prozessen die Verbindung gekappt wird. Anschließend kann für mehrere Minuten kein Client mehr auf die Datenbank zugreifen, egal ob phpmyadmin, PDO, "$ mysql" auf der Bash oder sonstwas.
Das sieht sehr nach persistenten Verbindungen aus ... Mach mal "normale" daraus. An sonsten mal die max_connections hochsetzen.
Das hat wohl eher was mit der Engine zu tun. Im Hosting-Bereich ist das fast immer noch MyISAM. Aber ich will mich jetzt da nicht weiter drüber auslassen ... aber davon abgesehen, weil das oben das Thema war: erklär mir doch mal, was man so aus einem MySQL-Explain lesen kann. Vielleicht sehe ich ja auch den Wald vor lauter Bäumen oder so nicht...
Andreas
Thomas Schmidt schmidt@netaction.de wrote:
bei MySQL ist das alles ja eher Blindflug.
Ich dachte, es würde nur mir so gehen. Momentan habe ich damit zu kämpfen, dass aufwändige Queries den Server zustopfen und dann allen Prozessen die Verbindung gekappt wird. Anschließend kann für mehrere
MyISAM?
Wir können bei uns die Uhren danach stellen, wann das Nagios kommt, weil bei Kunden das Backup läuft.
Minuten kein Client mehr auf die Datenbank zugreifen, egal ob phpmyadmin, PDO, "$ mysql" auf der Bash oder sonstwas.
tell news.
Andreas
Hallo,
andreas@a-kretschmer.de schrieb:
Zitat von Thomas Schmidt schmidt@netaction.de:
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert. Diesen
Ich nix MySQL, aber unter PG würde dies auch dauern, da es einen Seq-Scan erfordert.
Eigentlich sollte es auch ein Full-Scan ueber einen Index tun, in dem nachweislich alle interessierenden Datensaetze enthalten sind (z.B. PK-Index). Ist natuerlich eine Frage der Spitzfindigkeit des Optimizers.
Normalerweise braucht man dies nicht, also die exakte Anzahl. Oft reicht eine grobe Schätzung der Gesamtanzahl, sie gilt ja streng genommen auch nur für die konkrete TX, in der Du das abfragst. Also, entweder guggst Du in den Statistiken nach einer Schätzung (in PG wäre dies pg_class.reltuples),
die Statistik halbwegs aktuell zu halten, kostet ein ANALYZE und damit fast einen Full Scan (je nach Genauigkeit).
oder aber führst über einen TRIGGER einen exakten Counter.
TRIGGER: Bei sowas also Trigger auf INSERT und DELETE. Man muss sich dann dessen bewusst sein, dass man Redundanzen schafft, die einem in manchen Faellen wieder auf die Fuesse fallen.
Die einfache Implementierung zaehlt in einem Datensatz in einer getrennten Tabelle mit, es gibt dann bei jedem INSERT/DELETE eine Sperre auf diesen Datensatz. Solange keine parallellaufenden Aktionen auf der urspruenglichen Tabelle ausgeloest werden, hat man als Performanceeinbusse nur die Ausfuehrung vom Trigger und das Update (Satz finden, Datensatz aendern, Transaktionslog schreiben).
Bei mehreren konkurrierenden Transaktionen hat man da eine u.U. ekelhafte Serialisierung erzeugt.
@Thomas: Wann und wo brauchst Du die Anzahl der Datensaetze in der Tabelle? Fuer den Fall, dass Du das im selben Prozess wie das INSERT brauchst, kannst Du am Anfang das SELECT count(*) machen und dann die datensatzerzeugende Anwendung eigenstaendig die INSERTs zaehlen lassen - das stimmt solange wie keine anderen Transaktionen INSERT oder DELETE ausfuehren.
Holger
Holger Dietze hdietze42@web.de wrote:
Hallo,
andreas@a-kretschmer.de schrieb:
Zitat von Thomas Schmidt schmidt@netaction.de:
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert. Diesen
Ich nix MySQL, aber unter PG würde dies auch dauern, da es einen Seq-Scan erfordert.
Eigentlich sollte es auch ein Full-Scan ueber einen Index tun, in dem nachweislich alle interessierenden Datensaetze enthalten sind (z.B. PK-Index). Ist natuerlich eine Frage der Spitzfindigkeit des Optimizers.
Dummerweise hat der Index aber keine Informationen darüber, welche Datensätze in welcher Transaction sichtbar sind ...
Normalerweise braucht man dies nicht, also die exakte Anzahl. Oft reicht eine grobe Schätzung der Gesamtanzahl, sie gilt ja streng genommen auch nur für die konkrete TX, in der Du das abfragst. Also, entweder guggst Du in den Statistiken nach einer Schätzung (in PG wäre dies pg_class.reltuples),
die Statistik halbwegs aktuell zu halten, kostet ein ANALYZE und damit fast einen Full Scan (je nach Genauigkeit).
ACK.
oder aber führst über einen TRIGGER einen exakten Counter.
TRIGGER: Bei sowas also Trigger auf INSERT und DELETE. Man muss sich dann dessen bewusst sein, dass man Redundanzen schafft, die einem in manchen Faellen wieder auf die Fuesse fallen.
Da geb ich Dir Recht.
Btw.: lange nix mehr von Dir gehört ...
Andreas
Am 23.07.2011 00:16, schrieb Holger Dietze:
Hallo,
andreas@a-kretschmer.de schrieb:
Zitat von Thomas Schmidt schmidt@netaction.de:
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert. Diesen
Ich nix MySQL, aber unter PG würde dies auch dauern, da es einen Seq-Scan erfordert.
Eigentlich sollte es auch ein Full-Scan ueber einen Index tun, in dem nachweislich alle interessierenden Datensaetze enthalten sind (z.B. PK-Index). Ist natuerlich eine Frage der Spitzfindigkeit des Optimizers.
SELECT count(*) ist ein Scan über den PK. Solange keine anderen Kriterien angegeben werden, die den Index aushebeln, wird bei count(*) der PK verwendet.
Rico
Ich habe jetzt die Tabelle von InnoDB nach MyISAM konvertiert. Wahrscheinlich war das dämlich, aber es löst meine Probleme.
Das COUNT(*) geht extrem schnell: SELECT table_rows FROM information_schema.tables WHERE TABLE_SCHEMA = 'datenbank' AND table_name='pages'
Die 6,5GB große Tabelle wurde 4,5GB groß. Vorher brauchte MySQL 4,5GB RAM, jetzt nur noch 500MB.
Die CPU-Last sank auf 2%.
Und ja, die Daten sind noch da.
Thomas
Thomas Schmidt schmidt@netaction.de wrote:
Ich habe jetzt die Tabelle von InnoDB nach MyISAM konvertiert. Wahrscheinlich war das dämlich, aber es löst meine Probleme.
Und ja, die Daten sind noch da.
noch ...
Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 23.07.2011 13:14, schrieb Andreas Kretschmer:
Thomas Schmidt schmidt@netaction.de wrote:
Ich habe jetzt die Tabelle von InnoDB nach MyISAM konvertiert. Wahrscheinlich war das dämlich, aber es löst meine Probleme.
Und ja, die Daten sind noch da.
noch ...
Woran machst du die möglichen Datenverluste fest, an einer DB- bzw. Tabellengröße oder an der Menge Datensätze? Ich hatte bisher noch keine Probleme, weder bei 10 Mio. DS noch bei 3,5 GB pro Tabelle. (mehr hatte ich noch nicht). InnoDB ist nicht pauschal besser, PG auch nicht. So wie das hier aussieht, sind Transaktionen gar nicht nötig und da bringt InnoDB gegenüber MyISAM keinen Vorteil.
PG soll zwar bei großen Datenmengen (wo fängt das an?) besser skalieren, aber da hab ich mangels Erfahrung noch keine Vergleiche angestellt. Bisher hat mich die Benutzerverwaltung von PG von der Verwendung abgehalten. :-(
Gruß Rico
Rico Koerner rico@netbreaker.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 23.07.2011 13:14, schrieb Andreas Kretschmer:
Thomas Schmidt schmidt@netaction.de wrote:
Ich habe jetzt die Tabelle von InnoDB nach MyISAM konvertiert. Wahrscheinlich war das dämlich, aber es löst meine Probleme.
Und ja, die Daten sind noch da.
noch ...
Woran machst du die möglichen Datenverluste fest, an einer DB- bzw. Tabellengröße oder an der Menge Datensätze? Ich hatte bisher noch keine
Erfahrung @work ;-)
Probleme, weder bei 10 Mio. DS noch bei 3,5 GB pro Tabelle. (mehr hatte ich noch nicht). InnoDB ist nicht pauschal besser, PG auch nicht. So wie das hier aussieht, sind Transaktionen gar nicht nötig und da bringt InnoDB gegenüber MyISAM keinen Vorteil.
Ja, ich kenne die Argumentationen, z.B. aus früheren MySQL-Dokus, gegen Transaktionen und referentielle Integrität und so. Nur bin ich der Meinung, wenn die die Wahl zwischen zwei Systemen hat, wovon eines nix kann und das andere viele Dinge, die man von ref. Datenbanken ganz einfach erwartet, einfach gut kann, dann ist die Entscheidung eigentlich logisch.
Und Transaktionen sind ein wirklich feines Ding, insbesondere wenn man diese auch bei DDL hat.
Und Transaktionen sind nicht der einzigste Vorteil von z.B. PG, da kommen noch Dinge wie RI dazu oder Features wie TRIGGER, VIEWS, procedurale Languages, rekursive Abfragen, CTE-Abfragen etc., was PG alles kann.
Dazu ein Optimizer, der fast immer sehr smart ist.
Und, ganz wichtig: eine super Community. Egal was Du für ein Problem hast: über die Mailinglisten bzw. IRC bekommst Du innerhalb von Minuten einen Support, der einmalig ist.
PG soll zwar bei großen Datenmengen (wo fängt das an?) besser skalieren, aber da hab ich mangels Erfahrung noch keine Vergleiche angestellt.
MySQL mit MyISAM skaliert schon bei kleinen Datenmengen nicht, wenn da z.B. Schreibprozesse Tabellen komplett sperren oder das Backup dies tut.
Deine Meinung, es reicht ja MyISAM, vertreten viele, die MySQL verwenden. Die Resultate sind dann z.B. große Shops oder andere Seiten, die bei uns laufen. Plötzlich wächst das System. Plötzlich will man z.B. Replikation haben. Leider knallt die z.B. bei MyISAM schon dann, wenn auf dem Master eine Abfrage mal schief geht. Peng. Und wenn das Backup plötzlich eine Stunde läuft (weil der Shop gut läuft ...) und dann aber immer beim Backup die DB mit 500 Prozessen LOCKED voll läuft und der Shop knallt (und damit eine Stunde Umsatz weg ist), dann sitzt man in der MyISAM-Falle...
Bisher hat mich die Benutzerverwaltung von PG von der Verwendung abgehalten. :-(
Was genau meinst Du damit, die pg_hba.conf?
Mich halten z.B. die Gründe hier vor der Verwendung von MySQL ab: http://sql-info.de/mysql/gotchas.html
Mag sein, daß nicht mehr alle gelten.
Andreas
Am 23.07.2011 15:57, schrieb Andreas Kretschmer:
Rico Koerner rico@netbreaker.de wrote:
Ja, ich kenne die Argumentationen, z.B. aus früheren MySQL-Dokus, gegen Transaktionen und referentielle Integrität und so. Nur bin ich der Meinung, wenn die die Wahl zwischen zwei Systemen hat, wovon eines nix kann und das andere viele Dinge, die man von ref. Datenbanken ganz einfach erwartet, einfach gut kann, dann ist die Entscheidung eigentlich logisch.
Ich will hier keinen Glaubenskrieg vom Zaun brechen, aber warum soll ich mit dem LKW zum einkaufen fahren, wenns auch in den Rucksack paßt. Wenn ich die vielen Dinge nicht brauch, sind sie meist nur Ballast.
Und Transaktionen sind ein wirklich feines Ding, insbesondere wenn man diese auch bei DDL hat.
Wie gesagt, wenn man sie braucht. Bei mysql muß das in die Application wandern. Da find ich die in der DB schon passender.
Und Transaktionen sind nicht der einzigste Vorteil von z.B. PG, da kommen noch Dinge wie RI dazu oder Features wie TRIGGER, VIEWS, procedurale Languages, rekursive Abfragen, CTE-Abfragen etc., was PG alles kann.
Trigger und Views hab ich bisher noch am meisten vermisst, für den Rest fehlte bisher die Notwendigkeit bzw. müßte ich mal überdenken, wo ich es sinnvoll einsetzen könnte.
Und, ganz wichtig: eine super Community. Egal was Du für ein Problem hast: über die Mailinglisten bzw. IRC bekommst Du innerhalb von Minuten einen Support, der einmalig ist.
Kann auch bei mysql nicht klagen, inzwischen ist nur das Rauschen dort etwas groß geworden, aber ich vermute, das passiert jeder Software, die einsteigertauglich ist.
Deine Meinung, es reicht ja MyISAM, vertreten viele, die MySQL verwenden. Die Resultate sind dann z.B. große Shops oder andere Seiten,
Ich bin da nicht festgefahren, ich hab PG schon als Alternative zu mysql in Betracht gezogen. Wenn es aber keine selbst entwickelte Anwendung ist, fehlt oftmals sogar die Möglichkeit zum Umstieg.
die bei uns laufen. Plötzlich wächst das System. Plötzlich will man z.B.
Ja, das Wachstum ist meistens das Problem. Oder besser gesagt, die Weitsicht bei der Entwicklung. Irgendwann muß man den Rucksack dann doch eintauschen. ;-)
Replikation haben. Leider knallt die z.B. bei MyISAM schon dann, wenn auf dem Master eine Abfrage mal schief geht. Peng. Und wenn das Backup
Gut zu wissen, daß die Replikation problematisch ist.
plötzlich eine Stunde läuft (weil der Shop gut läuft ...) und dann aber immer beim Backup die DB mit 500 Prozessen LOCKED voll läuft und der Shop knallt (und damit eine Stunde Umsatz weg ist), dann sitzt man in der MyISAM-Falle...
1h Backup? Ist die DB 100 GB groß? (Ich hab bei 10 GB (alle DB) mal 6 min geschafft.) Ich kann mir nicht vorstellen, welcher Shop eine solche Datenmenge benötigt oder die Anwendung ist schlecht entworfen.
Bei der Größe ist an der Backupstrategie etwas falsch. LOCK -> Snapshot -> Backup Damit sollte die Downtime nur wenige Sekunden.
Klar, wenn die Datenbank solche Mechanismen eingebaut hat, ist das auf jeden Fall besser.
Bisher hat mich die Benutzerverwaltung von PG von der Verwendung abgehalten. :-(
Was genau meinst Du damit, die pg_hba.conf?
Ja, genau die. Hab grad nochmal testweise auf einer Maschine (squeeze) frisch installiert, nachdem ich mich kurz im Tutorial (Kap. 17) eingelesen hab und gesehen hab daß man anscheinend nicht zwingend für die Benutzerverwaltung in der pg_hba rumfummeln muß.
~# psql psql: FATAL: Ident authentication failed for user "root" ~# psql -U postgres psql: FATAL: Ident authentication failed for user "postgres"
Das Tutorial hilft an der Stelle auch nicht mehr weiter. :-(
Mich halten z.B. die Gründe hier vor der Verwendung von MySQL ab: http://sql-info.de/mysql/gotchas.html
Da gibts aber auch eine für PG. Da steht u.a. auch drin daß count(*) sehr langsam ist. Nur um mal wieder den Bezug zum ursprünglichen Thema zu finden. ;-) Womit wir wieder an dem Punkt ankommen, daß es vom Anwendungszweck abhängt, welche DB mehr/weniger Vor- und Nachteile hat.
Rico
Rico Koerner rico@netbreaker.de wrote:
Und Transaktionen sind nicht der einzigste Vorteil von z.B. PG, da kommen noch Dinge wie RI dazu oder Features wie TRIGGER, VIEWS, procedurale Languages, rekursive Abfragen, CTE-Abfragen etc., was PG alles kann.
Trigger und Views hab ich bisher noch am meisten vermisst, für den Rest fehlte bisher die Notwendigkeit bzw. müßte ich mal überdenken, wo ich es sinnvoll einsetzen könnte.
Nun, mittels der diversen Sprachen (plpgsql, plperl, ...) kannst Du direkt in der DB weite Teile der Anwendungslogig unterbringen. Das kann u.U. schon wirklich enorme Vorteile haben. Natürlich zu Lasten der Portierbarkeit...
Und, ganz wichtig: eine super Community. Egal was Du für ein Problem hast: über die Mailinglisten bzw. IRC bekommst Du innerhalb von Minuten einen Support, der einmalig ist.
Kann auch bei mysql nicht klagen, inzwischen ist nur das Rauschen dort etwas groß geworden, aber ich vermute, das passiert jeder Software, die einsteigertauglich ist.
MySQL hat nicht einmal eine 'freie' Doku, aber okay jetzt...
Deine Meinung, es reicht ja MyISAM, vertreten viele, die MySQL verwenden. Die Resultate sind dann z.B. große Shops oder andere Seiten,
Ich bin da nicht festgefahren, ich hab PG schon als Alternative zu mysql in Betracht gezogen. Wenn es aber keine selbst entwickelte Anwendung ist, fehlt oftmals sogar die Möglichkeit zum Umstieg.
Ja, leider ist vieles auf MySQL festgelegt.
plötzlich eine Stunde läuft (weil der Shop gut läuft ...) und dann aber immer beim Backup die DB mit 500 Prozessen LOCKED voll läuft und der Shop knallt (und damit eine Stunde Umsatz weg ist), dann sitzt man in der MyISAM-Falle...
1h Backup? Ist die DB 100 GB groß? (Ich hab bei 10 GB (alle DB) mal 6 min geschafft.) Ich kann mir nicht vorstellen, welcher Shop eine solche Datenmenge benötigt oder die Anwendung ist schlecht entworfen.
Wir haben bei uns durchaus recht große Shops laufen, bei einigen kommen Jahresumsätze im mehrstelligen Millionenbereich pro Jahr zusammen. Das läuft dann auch mal gern auf HA-Clustern und so, nette Sachen.
Und fast alle Shops basieren auf einer Software, die mit M anfängt und mit agento endet. Und diese hat eine etwas krude DB-Philosophie: da wird massiv de-normalisiert... und ja: es wird die DB als Cache 'mißbraucht'. Jedenfalls - da kommen z.T. wirklich große Datenmengen zusammen. Okay, es wird da dann aber auch InnoDB verwendet. Aber manche Kunden haben auch so ihre Eigenentwicklungen, und das zu sehen ist manchmal, ähm, ernüchternd.
Bisher hat mich die Benutzerverwaltung von PG von der Verwendung abgehalten. :-(
Was genau meinst Du damit, die pg_hba.conf?
Ja, genau die. Hab grad nochmal testweise auf einer Maschine (squeeze) frisch installiert, nachdem ich mich kurz im Tutorial (Kap. 17) eingelesen hab und gesehen hab daß man anscheinend nicht zwingend für die Benutzerverwaltung in der pg_hba rumfummeln muß.
~# psql psql: FATAL: Ident authentication failed for user "root" ~# psql -U postgres psql: FATAL: Ident authentication failed for user "postgres"
Das Tutorial hilft an der Stelle auch nicht mehr weiter. :-(
Nun ja, da gibt es neben der offiziellen Doku auch noch einige andere, man muß es halt mal sich durchlesen. Ist aber nicht wirklich soo dolle komplex, finde ich.
Mich halten z.B. die Gründe hier vor der Verwendung von MySQL ab: http://sql-info.de/mysql/gotchas.html
Da gibts aber auch eine für PG. Da steht u.a. auch drin daß count(*) sehr langsam ist. Nur um mal wieder den Bezug zum ursprünglichen Thema zu finden. ;-)
Ja, das erfordert halt einen kompletten seq. scan.
Okay, ich denke, wir beenden mal den Thread nun...
Andreas
Am 23.07.2011 18:58, schrieb Andreas Kretschmer:
Rico Koerner rico@netbreaker.de wrote:
Und fast alle Shops basieren auf einer Software, die mit M anfängt und mit agento endet. Und diese hat eine etwas krude DB-Philosophie: da wird massiv de-normalisiert... und ja: es wird die DB als Cache 'mißbraucht'.
Das hatte ich befürchtet, wenns geht liegen dort auch noch massenweise Binärdaten (Bilder) in der DB. Gut zu wissen mit dem 'M'. Aus Anwendersicht ist das aber das beste Shopsystem. Schade daß hinter der Fassade so geschlampt wird.
Jedenfalls - da kommen z.T. wirklich große Datenmengen zusammen. Okay, es wird da dann aber auch InnoDB verwendet. Aber manche Kunden haben auch so ihre Eigenentwicklungen, und das zu sehen ist manchmal, ähm, ernüchternd.
InnoDB macht das Backup aber auch nicht leichter, damit kann mysqlhotcopy wieder nicht umgehen.
~# psql psql: FATAL: Ident authentication failed for user "root" ~# psql -U postgres psql: FATAL: Ident authentication failed for user "postgres"
Das Tutorial hilft an der Stelle auch nicht mehr weiter. :-(
Nun ja, da gibt es neben der offiziellen Doku auch noch einige andere, man muß es halt mal sich durchlesen. Ist aber nicht wirklich soo dolle komplex, finde ich.
Wenn nicht mal die 1. Schritte zur Benutzung im offiziellen Handbuch stehen, nutzt es wenig. Frei aber unbrauchbar, zumindest an der Stelle. Ich fühl mich in dem Handbuch wie Asterix im "Haus das Irre macht".
Kap. 1 Einstieg: Möglicherweise ist PostgreSQL bei Ihnen schon installiert, ...
Nein, ist es nicht, aber ich bin der Sysadmin und apt-get kann ich bedienen. Aber das allein reicht nicht.
Wenn Sie PostgreSQL selbst installieren, dann ... Kapitel 14. nachgeschaut ... Nein, ich will das nicht selbst kompilieren, aber vielleicht find ich trotzdem den entscheidenden Hinweis. Also les ichs. -> Fehlanzeige.
Inzwischen bei Kap. 17 angekommen - ein Lichtblick. Datenbankbenutzer sind vollständig getrennt von Betriebssystembenutzern. Und nicht root, sondern postgres ist der richtige Benutzer, den ich mit -U bei psql angeben kann. Funktioniert aber nicht.
Zurück zu Kap. 1 >> 1.3 Möglicherweise hat der Systemadministrator schon eine Datenbank für Sie erstellt.
Nein, hat er nicht, er versucht gerade herauszufinden wie das geht.
Nochmal zu Kap. 17, vielleicht hab ich was übersehen. Weiter bei Kap. 18, auch nichts, Kap. 19 - Clientauthentifizierung. pg_hba - klingt gut. local all all trust - nein das will ich auch nicht local all root trust - das sollte reichen
~# psql psql: FATAL: database "root" does not exist ~# psql -U postgres psql: FATAL: Ident authentication failed for user "postgres"
Sonst mehr Verwirrung als Klarheit: Wenn zum Beispiel Ident sagt, dass der Benutzer "bryanh" ist und er als PostgreSQL-Benutzer "guest1" verbinden will, dann wird die Verbindung erlaubt, wenn in pg_ident.conf ein Eintrag für ein Map "omicron" ist, der sagt, dass "bryanh" als "guest1" verbinden darf.
Häää ???
Das hilft auch nicht. Nagut, die Doku bringts nicht, frag ich mal Tante Google nach der Fehlermeldung. Irgendwann (gefühlt der 20. Foren-Thread) ist mal ein "su postgres" zwischen den Zeilen herauszulesen. Treffer, das hätte aber auch im Handbuch stehen können. Ein halber Tag für diese Erkenntnis motiviert nicht grad zum weitermachen.
Über den Rest kann ich mir erst später ein Urteil bilden, für heute reichts mir erst mal. Wenn man es einmal geschafft hat, ist auch das Schwierigste ganz einfach. Die Nadel im Heuhaufen zu suchen (die richtige inoffizelle Doku), spricht nicht grad für PG.
Rico
Rico Koerner rico@netbreaker.de wrote:
psql: FATAL: Ident authentication failed for user "postgres"
Das Tutorial hilft an der Stelle auch nicht mehr weiter. :-(
Nun ja, da gibt es neben der offiziellen Doku auch noch einige andere, man muß es halt mal sich durchlesen. Ist aber nicht wirklich soo dolle komplex, finde ich.
Wenn nicht mal die 1. Schritte zur Benutzung im offiziellen Handbuch stehen, nutzt es wenig. Frei aber unbrauchbar, zumindest an der Stelle.
Ich mag da jetzt nicht weiter drüber diskutieren wollen, will auch keinen Flamewar bzgl. DB-System. Nur soviel: das Kapitel User-Auth mag in der Tat nicht sonderlich gut dokumentiert zu sein, das sieht man auch recht oft in diversen Mailinglisten etc. Mag auch daher kommen, daß es so viele verschiedene Möglichkeiten gibt, User zu authorisieren, und nicht alle (in einer Client-Server-Umgebung heutzutage) noch sinnvoll sind (Stichwort IDENT)
Andererseits bin ich der Meinung, daß PG eine wirklich gute Doku hat (zu der ich auch schon Kritik an die Macher geschickt habe, um diese zu verbessern ...). Sie ist halt von den 'Machern' geschrieben, weniger von den 'Benutzern', aber dieses Problem hat irgendwie jede OSS, finde ich.
Was MySQL betrifft: es hat eine gewaltige User-Basis. Das kann und darf man nicht ignorieren. Da steckt definitiv auch sehr viel Wissen dahinter, von Leuten, die damit arbeiten. Und es hat auch gute Ansätze, und es gibt definitiv gute Entwicklungen da. Storage-Engines für spezielle Zwecke z.B. Und PG lernt manche Dinge auch von MySQL, 9.1 wird z.B. 'unlogged tables' mitbringen, weil es eben wirklich Anwendungen gibt, wo man auf Dinge wie wirklich sichere Transaktionen verzichten kann UND WILL, nur um Performance zu bekommen.
Also, slow down, kein Flamewar, okay?
Andreas
Hej!
2011-07-23 11:19, Thomas Schmidt skrev:
Ich habe jetzt die Tabelle von InnoDB nach MyISAM konvertiert. Wahrscheinlich war das dämlich, aber es löst meine Probleme.
Das COUNT(*) geht extrem schnell:
MyISAM speichert die Anzahl der Datensätze separat. Die Daten selbst schaut es sich bei der Query gar nicht erst an.
Und ja, die Daten sind noch da.
Jetzt hast du halt keine Transaktionsfähigkeiten mehr.
Und gerüchteweise steigt wohl die Wahrscheinlichkeit von völlig korrumpierten Datenbanken bei Stromausfall etc. (aber das *erscheint* mir ein heiliger Krieg (MyISAM vs. InnoDB/Postgres) zu sein, der nicht immer/ausschließlich auf Fakten basiert).
Viele Grüße Fabian
Fabian Hänsel fabtagon@gmx.de wrote:
Jetzt hast du halt keine Transaktionsfähigkeiten mehr.
Und gerüchteweise steigt wohl die Wahrscheinlichkeit von völlig korrumpierten Datenbanken bei Stromausfall etc. (aber das *erscheint* mir ein heiliger Krieg (MyISAM vs. InnoDB/Postgres) zu sein, der nicht immer/ausschließlich auf Fakten basiert).
Nun, das ist schon so, und basiert auf Fakten. Bei MyISAM hast Du Null Schutz gegen solche Probleme, bei z.B. PG steckt da ein doch relativ aufwendiges Konzept dahinter, z.B. hier nett erklärt:
http://www.depesz.com/index.php/2011/07/14/write-ahead-log-understanding-pos...
Natürlich hat das seine Nachteile: alle Schreiboperationen werden natürlich aufwendiger. PG hatte lange Zeit den Ruf, lahmer als z.B. MySL zu sein, und wenn man MySQL mit MyISAM fährt, dann stimmt das auch noch heute.
Andreas
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
andreas＠a-kretschmer.de -
Fabian Hänsel -
falk.doering＠fadoe.de -
Holger Dietze -
Rico Koerner -
Thomas Schmidt