Gibt es momentan eine Möglichkeit auf MySQL zu connecten mit einem schnellen C Modul unter Windows und für Python3.1?
Ich habe die Python mysql-connector, aber denke es könnte auch schneller gehen. Ich habe schon in Listen geschaut, aber auf den ersten Blick sieht es nicht so aus, dass es diese Kombo gäbe?!
MySQL in C + Windows + Python3
@Xynon:
Hmm, meinste? Mag sein. Ich dachte halt weil mysql-connector Python ist, ist er langsamer. Aber die Datenmenge ist schon groß und kann sein, dass es eher am MySQL liegt. Oder kann man an der Interaction noch was optimieren? Ich habe eigentlich nur sehr lange SELECTs und "for x in cursor".
oursql hatte ich gefunden und jetzt warte ich bis der Admin mir mysql-c-connector draufmacht
Ist das dann C?
Hmm, meinste? Mag sein. Ich dachte halt weil mysql-connector Python ist, ist er langsamer. Aber die Datenmenge ist schon groß und kann sein, dass es eher am MySQL liegt. Oder kann man an der Interaction noch was optimieren? Ich habe eigentlich nur sehr lange SELECTs und "for x in cursor".
oursql hatte ich gefunden und jetzt warte ich bis der Admin mir mysql-c-connector draufmacht
Ist das dann C?-
noisefloor
- User
- Beiträge: 4149
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
> Hmm, meinste? Mag sein.
Ist i.d.R. so. Das Programm muss eine Verbindung zu DB aufbauen, die muss den Query ausführen, was ggf. mit I/O verbunden ist und dann das Ergebnis zurück liefern.
In der gleichen Zeit hat selbst die langsamste Skript-Sprache etliche Befehle ausgeführt.
Oder andersherum gesagt: Das ist eine Stelle, wo man die Optimierung auch auf unbestimmte Zeit in die Zukunft verschieben kann.
Anders sähe es ggf. aus, wenn du ein KV-Store nutzt, was alle Daten im RAM hält.
Gruß, noisefloor
> Hmm, meinste? Mag sein.
Ist i.d.R. so. Das Programm muss eine Verbindung zu DB aufbauen, die muss den Query ausführen, was ggf. mit I/O verbunden ist und dann das Ergebnis zurück liefern.
In der gleichen Zeit hat selbst die langsamste Skript-Sprache etliche Befehle ausgeführt.
Oder andersherum gesagt: Das ist eine Stelle, wo man die Optimierung auch auf unbestimmte Zeit in die Zukunft verschieben kann.
Anders sähe es ggf. aus, wenn du ein KV-Store nutzt, was alle Daten im RAM hält.
Gruß, noisefloor
Ah OK. Gut zu wissen.
Und ist
for x in c.execute("select ...")
eigentlich schon optimiert? Also er muss da nicht irgendwie immer neu verbinden?
Naja, dann dauerts halt einfach 500000 Zeilen in eine Objekt-Hierarchie einzulesen
Und ist
for x in c.execute("select ...")
eigentlich schon optimiert? Also er muss da nicht irgendwie immer neu verbinden?
Naja, dann dauerts halt einfach 500000 Zeilen in eine Objekt-Hierarchie einzulesen
-
noisefloor
- User
- Beiträge: 4149
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
AFAIK ist das Iterieren über cursor.execute(...) nicht Teil der offiziellen Python DB API 2.0, die meisten kompatiblen Modulen unterstützten es aber. Sofern für cursor.execute(...) sich die Werte erst im Verlauf der Iteration holt sollte das ok sein.Gerenuk hat geschrieben:Und ist
for x in c.execute("select ...")
eigentlich schon optimiert?
Nee, so wie so nicht. Die Connection baust du ja vorher auf - und auch erst hinterher hoffentlich wieder ab.Gerenuk hat geschrieben: Also er muss da nicht irgendwie immer neu verbinden?
Gruß, noisefloor