Communitysoftware mit Extras. Jemand Interesse mitzuwirken?

[omaliesschen]

Es ist eine Volltextsuche über 1,7 Millionen n. Und alle mit dem selben Namen.INT++ was es nochmal verlangsamt. Wenn ich unter den 1.7m einen Nutzer mit anderem Namen versteck dauerst ein kurzes zucken. Also sollte das Thema Performance vom Tisch sein.

Ohne RAID mit schwacher HDD auf einem alten Pentium4 Dual Core.

Höheres Offset spielt auch keine Rolle.

SELECT *
FROM `authors`
WHERE `name` LIKE '%min%'
LIMIT 800000 , 50

Showing rows 800000 - 800049 ( 50 total, Query took 0.4496 sec)

Es wird schon nen Grund haben warum die Nutzersuche bei ComputerBase limitiert wurde.

 

[ice-breaker]

Diese falsche Aussage kann ich nicht stehen lassen. Selbst 1.7 Millionen sind nur wenige MB Ram - mit Prefix-Compression sogar lächerlich wenig.
Und langsam ist da gar nix, das ganze ist nen Index-Scan auf nem B-Tree, dass der mit dem selben Namen beginnt stört die DB reichlich wenig, der findet in Nanosekunden die richtige Position. Ein B-Tree wurde für sowas geschaffen.

Gut, da sind wir jetzt in ein Expertenthema reingerutscht, mein Lieblingsthema, die Datenbank-Optimierung und -Implementierung Da kann man schonmal falsch liegen, aber das es auf ner alten Maschine flutscht ist kein Wunder, das wird auch auf meinem Raspi flutschen, da du direkt ein Beispiel gebracht hast, was die Datenbank sehr gut optimieren kann - bis auf den langsamen Offset. Da wäre dann eine Art Trie am sinnvollsten, da ist mir aber keine Datenbank bekannt, die das einsetzt.

 

[omaliesschen]

dass der mit dem selben Namen beginnt stört die DB reichlich wenig

Aber die HDD.

 

[ice-breaker]

Nein, das liegt im Ram. Wenn die DB so dämlich wäre, alles von der DB zu laden, würden Queries Jahre dauern. Die Seektime einer HDD liegt bei ungefähr 3ms, da deine Daten nicht durchgängig an der gleichen Stelle liegen sondern verteilt hast du mehrere Seeks, du siehst also dass es zeitlich gar nicht möglich ist, dass alles von der DB geladen wird.
(Ausnahme: dein Username ist in InnoDB der Primary Key wodurch deine Daten auf der HDD nach dem Username sortiert liegen würden, eben geclustered nach dem PK Aber auch dann könnte durch versch. Seiten immernoch ein Lookup nach einer anderen Datenbankpage stattfinden).

Und genau deswegen sagte Daaron, dass die DB-Performance erst bei 7stelligen Datenmengen (und ich wiederhole es erneut: ich erhöhe auf 8) wirklich interessant wird. Denn dann kann nicht mehr alles im Ram hängen, und auch die 80/20 wird immer weniger greifen, so dass wirklich oft auf die HDD zugegriffen werden muss. DANN wird jede kleine DB-Optimierung und jeder kleiner Fehler wird mit minutenlangen Queries bezahlt. Und auch dann sieht man, dass General Purpose Datenbanken wie MySQL nicht für jedes Problem geschaffen sind und ggf. ein Column Store wie HANA sinnvoller ist, da der bessere Kompressionen der Daten anbieten kann und somit mehr in den Ram passt.

 

[omaliesschen]

Aber Du siehst, denke ich, dass zumindest ein Teil unserer Streitdiskussion grundlos war.

 

[ice-breaker]

Nein, das sehe ich nicht, da müsstest du mir erst sagen auf welchen Teil du dich beziehst.
Denn die DB-Performance kann es nicht sein, da ist genau das eingetreten, was Daaron und ich prophezeit haben: Aussagen über die Performance bei lächerlich geringen Datenmengen. Aussagen über die DB-Performance kann man erst treffen, wenn reale Daten (auf Grund der Verteilung der Daten verhalten sich Demo-Daten meist anders) wenn die DB wirklich so gut gefüllt ist. Mit genug Erfahrung kann man einigen Problemen aus dem Weg gehen, aber man wird trotzdem später viel Hand anlegen müssen, weil man etwas nicht bedacht hat oder einfach irgendetwas nicht absehbar (z.B. die z.T. sehr miesen Query-Optimierungen von MySQL bei großen Datenmengen).


Aber ich denke wird mittlerweile klar, dass ich nicht generell gegen irgendein OpenSource Projekt bin, wie könnte ich. Sondern ein so wirklich großes Projekt ohne die nötige Erfahrung anzugehen. Jeder Entwickler hat klein angefangen, und man ist mit der Zeit gewachsen, aber sich mit Projekten zu sehr zu übernehmen, hat nie geholfen.

 

[omaliesschen]

Ich kann den Zirkus gerne mal mit rand() und md5 füllen. Sollte realen Daten am nähesten kommen. Allerdings muss ich jetzt weg. Außer die Struktur der DB würde sich hier übrigens nicht mehr viel "optimieren" lassen.

Aussagen über die Performance bei lächerlich geringen Datenmengen.

Naja. 1.7millionen sind im von Daroon genannten 7 stelligen Bereich.

Sondern ein so wirklich großes Projekt ohne die nötige Erfahrung anzugehen.

Quark. Erklär die Aussage mal ein bisschen.

Es geht hier nicht um ein PS starkes Auto oder Gefahrtiere. Wenn ich was vermurks -> Restart.

Wenn Du im GitHubCode ein Securityproblem findest geb ich Dir einen aus.

 

[ice-breaker]

Ich kann den Zirkus gerne mal mit rand() und md5 füllen. Sollte realen Daten am nähesten kommen. Allerdings muss ich jetzt weg.

Aus Erfahrung: nein kommen sie nicht. Sowohl Zufallswerte als auch md5 werden eine Gleichverteilung der Daten verursachen, in der Realität bilden sich aber gewisse HotSpots (der Name Max

Außer die Struktur der DB würde sich hier übrigens nicht mehr viel "optimieren" lassen.

Die DB-Struktur ist 90% der Optimierung und für fast die gesamte Performance zuständig bzw. schuldig, die restlichen 10% nur die definierten Queries. Und die Queries hängen meist von der definierten Struktur ab...

Naja. 1.7millionen sind im von Daroon genannten 7 stelligen Bereich.

wie ich schon sagte, sind imho 7 stellige Daten zu wenig. Und Daaron wird sicherlich auch nicht das untere Ende damit gemeint haben sondern mehr Richtung 60-80 Millionen.

Aber ganz ehrlich, das ganze geht nun für das Thema hier viel zu viel ins Detail.
Quark. Erklär die Aussage mal ein bisschen.

Es geht hier nicht um ein PS starkes Auto oder Gefahrtiere. Wenn ich was vermurks -> Restart.

Und wenn du das Projekt vermurkst hast du ne riesige grauenhafte Codebasis und kaum etwas dazugelernt. Am meisten lernt man doch wenn man fremden guten Code liest, denn der Stil den man am Anfang hat ist mies und verletzt wirklich viele Grundprinzipien.
Deswegen ist es auch sinnvoll sowas gleich mit nem richtigen Framework anzufangen, da kann man nicht mehr ganz so viel Mist anstellen.

Wenn Du im GitHubCode ein Securityproblem findest geb ich Dir einen aus.

Und was sollen diese Ausflüchte wieder? Was hat der Code von Github und Securityprobleme in diesem mit deinem Projekt zu tun? Vor allem weil Security in diesem Thema noch kein Thema war, aber stimmt, hätte man mal ansprechen müssen, da wird ein Anfänger immernoch in viel zu viele dieser Fälle reintappen - aber immerhin hat dein Code schonmal keine SQL-Injection Probleme beim Verwenden von Prepared Statements *clap*.

 

[Daaron]

Simulieren wir doch mal eine CB-Query: Zeige die ersten 5 Beiträge aller Personen mit dem Rang Captain... davon ausgehend, dass uns nur das Wort "Captain" bekannt ist und intern beim Rang ein Integer steht, der als Fremdschlüssel für eine Tabelle mit 9 => "Captain" dient.

Wenn du solche Queries hast, dann kommst du langsam in Huddeleien. Oder wenn du überprüfen willst, welche von 2000 Artikeln, die jeweils ~200 Variationen haben, grundsätzlich verkaufbar sind (in einer Variante ist ein Lagerbestand > MIN_LAGER)

 

[Fonce]

Es ist eine Volltextsuche über 1,7 Millionen

Nur mal so aus neugier, hab ich was verpasst(bin nun wirklich kein DB^^) oder seit wann ist ein LIKE in SQL eine Volltextsuche?
LIKE nutzt doch als Parameter einen Regulären Ausdruck und macht dann Patter matching...

 

[omaliesschen]

Mein Fehler.

 

[Daaron]

Nur mal so aus neugier, hab ich was verpasst(bin nun wirklich kein DB^^) oder seit wann ist ein LIKE in SQL eine Volltextsuche?

Korrekt. LIKE, mit Ausnahme von %LIKE%, ist ziemlich performantes Pattern Matching. Eine Volltext-Suche würde gänzlich anders aussehen.
1.) sie geht nur bei MyISAM, InnoDB kann es (noch) nicht
2.) MATCH column AGAINST text [IN BOOLEAN MODE]
3.) FULLTEXT, insbesondere im Boolean-Modus, hat ein paar verdammt interessante Nebeneffekte, die man mit LIKE einfach nicht erreicht.

 

[ice-breaker]

InnoDB hat Volltextsuche

 

[Daaron]

OK, anders: Mir fällt grad keine Stable-Distribution ein, bei der MySQL Fulltext über InnoDB kann, da selbst Debian 7 und Ubuntu 12.04 nur MySQL 5.5 verwenden.
Klar könnte man 5.6 nachrüsten, aber dann hast du wieder die Sorgen mit der manuellen Paketkontrolle hinsichtlich Sicherheitsupdates... Nene, da sag ich lieber weiterhin: Kein FULLTEXT unter InnoDB. Vielleicht mit Debian 8...

 

[ice-breaker]

hihi, na es hieß ja vorher, dass es nicht existiert, nicht dass es in stable distros enthalten ist

 

[asdfman]

Hab ich mich nie mit auseinandergesetzt. Ich denke da an alles außer kommerziell.

Das ist problematisch. Zumindest die definition freier Software erfüllst du nicht mehr, wenn du kommerzielle Nutzung ausschließt.
Die Open Source definition ist weitgehend deckungsgleich, kenne sie aber nicht im Detail.

€: Bitte schlagt mich. Hätte ich lieber mal statt auf absenden zu klicken erstmal Google angemacht.
Die Voraussetzung, dass kommerzielle Nutzung möglich sein muss ist sogar der allererste Punkt der Open Source Definition:

1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

http://opensource.org/osd-annotated

 

[Daaron]

Mein Tip: http://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Ich halte das Ding für einen netten Mittelweg. Bei BSD oder MIT schappt sich am Ende ein Entwickler den ganzen Code und vermarktet ihn Closed Source. Bei GPL wird nie ein Entwickler mitarbeiten, der monetäres Interesse hat.

Auf jeden Fall muss eben eine Lizenz her, bevor auch nur ein Fitzelchen Code veröffentlicht wird.

 

[omaliesschen]

Die DB-Struktur ist 90% der Optimierung und für fast die gesamte Performance zuständig bzw. schuldig, die restlichen 10% nur die definierten Queries.

Ich meinte damit die Anordnung und Zusammensetzung. Es ist übrigens in dem Beispiel kein BTREE sondern ein FULLTEXT.

 

[ice-breaker]

Ach und was unterscheidet einen FULLTEXT Index von einem B-Tree? Ein B-Tree ist eine fundamentrale Datenstruktur der Informatik. Ein Fulltext-Index ist ein nicht näher definiertes Gebilde einer Datenbank auf der man Volltextsuchen ausführen kann.

Und jetzt kommt der Spaß für dich: Ein Fulltext-Index in MyISAM ist ein B-Tree, genauer gesagt nach der Implementierung sind es sogar 2 B-Trees. Einer für die vorkommenden Worte und einer für die Worthäufigkeit, näheres lässt sich im Netz finden.

Und sollte es ein Fulltext-Index sein, wurde er sowieso falsch genutzt. MySQL dürfte diesen für deine Operation nicht nutzen*, oder war so klug deinen Fehler zu erkennen, und hat ihn trotzdem genutzt, was MySQL leider viel zu oft macht, also irgendwie Queries zu reparieren, dass sie ausführbar sind statt mit einem Fehler zu returnen. (Eine EXPLAIN Ausgabe mit keinem und hohem Offset würde mich interessieren )


* ich kann da nur empfehlen sich mal anzusehen wie Lucene oder Sphinx ihre Volltextsuchen implementieren um den Unterschied zu verstehen. Denn ein LIKE und eine Volltextsuche sind da in der Ausführung und in den Datenstrukturen fundamental verschieden.

 

[Daaron]

Ich meinte damit die Anordnung und Zusammensetzung. Es ist übrigens in dem Beispiel kein BTREE sondern ein FULLTEXT.

Wieso? Weil phpMyAdmin da eine Unterscheidung macht?
Kleiner Tip: Ein FULLTEXT in MySQL ist ein Spezialfall eines BTREE.... und LIKE sollte über FULLTEXT nicht korrekt funktionieren. Tut es das doch, dann hast du lediglich Schwein. FULLTEXT-Indizes verwendet man mit MATCH ... AGAINST ....

Also mal wieder der gute alte Tip: Statt immer auf das ach so nutzlose Uni-Wissen zu schimpfen udn dich mit deiner nichtvorhandenen Ausbildung überlegen zu fühlen solltest du doch mal ein paar Semester studieren. Dann verstehst du auch solch elementaren Geschichten wie binäre Suchbäume und die Indizes in MySQL.