Das deutsche Python-Forum

Solange man nicht zu viele gleichzeitige Writes in die Datenbank hat, ist das ok.

Lasse gerade testweise 20 Maschinen-Clients in einer While True Schleife ihre Daten updaten. Außer einer hohen CPU-Auslastung scheint das keine Probleme zu machen. Von der Seite her sehe ich da also keine Probleme.

Sieht vielleicht sonst noch jemand Probleme? Ansonsten würde ich diesen Ansatz weiterverfolgen.

Bisher schütze ich den DB Zugriff mit einem Lock, so dass immer nur einer parallel auf die DB zugreifen kann.
Ist jetzt so schon ein bisschen performant lastig. Gefällt mir nicht so.

Ist der Lock notwendig, oder gibt es da Alternativen?

SQLite kommt mit parallelen Reads zurecht, mit parallelen Writes eher nicht.

Leonidas hat geschrieben:SQLite kommt mit parallelen Reads zurecht, mit parallelen Writes eher nicht.

Ja, das ist klar.

sqlite3.connect(database[, timeout, isolation_level, detect_types, factory])

When a database is accessed by multiple connections, and one of the processes modifies the database, the SQLite database is locked until that transaction is committed. The timeout parameter specifies how long the connection should wait for the lock to go away until raising an exception. The default for the timeout parameter is 5.0 (five seconds).

Aber der interne Lock von Sqlite dürfte doch eigentlich reichen?

Das bedeutet, dass die komplette Datenbank für die gesamte Dauer einer Transaktion für Schreibzugriffe gesperrt ist. Ich denke, ich brauche dir nicht zu erklären, dass eine solche künstliche Serialisierung der Zugriffe einem hohen Durchsatz entgegen steht. Finden viele parallele Zugriffe statt, werden früher oder später eine Verbindungsversuche fehlschlagen, weil der Timeout abläuft.

Vollwertige DBMS dagegen können parallele Schreibzugriffe ohne künstliche Serialisierung durchführen, und sind daher weitaus leistungsfähiger im Bezug auf hohe Schreiblast.

Ein richtiges DBMS kommt ja auch mit vielen höheren Anforderungen aus wie von mir gegeben.

ice2k3 hat geschrieben: Anzahl Clients: Es könnten ca. bis zu 25 Maschinen Anfragen senden (Standard 5-10) und mehrere PC-Clients. (Alle haben vermutlich ein 5 Sekunden Intervall, wobei die Datenmenge auf der PC Seite entsprechend höher ist, weil diese alle Daten empfangen und die Maschinen nur jeweils ihre spezifischen senden.)

Ganz konkret: Jede Maschine sendet alle 5 Sekunden ca. 10 SQL Befehle, die die DB verändern. Oberstes Maximum sind 50 Maschinen.
Das Programm vom PC greift zur Zeit nur lesend auf die DB zu.

Siehst du hier irgendwelche Probleme?

Du kannst doch rechnen, oder? Im schlimmsten Fall springen alle 50 Clients gleichzeitig an und senden jeweils zehn Anweisung, dass ergibt im schlimmsten Fall 500 nahezu parallele Schreibzugriffe. Ob das für die gegebene Anwendung problematisch ist, musst du über einen Lasttest selbst herausfinden. 50 nahezu parallel laufende lassen sich auf einem modernen System noch gut simulieren, also kannst du einen Server und 50 Clients mal auf der selben Maschine starten und die Clients eine hohe Anzahl an Schreibzugriffen abfeuern lassen. Dann siehst du schon, wann und wie der Server aussteigt.

Wenn du natürlich eine Abstraktionsschicht wie SQLAlchemy verwenden würdest, bräuchtest du dir darum nur bedingt Sorgen machen, da die eigentliche Datenbank austauschbar wäre.

An Belastungstests kommt das ganze natürlich nicht dran vorbei, und sind z.T. auch schon erfolgreich abgelaufen, da hatte ich aber noch meine eigenen Locks implementiert (s. meine vorherigen Posts). Vielleicht lass ich das ja einfach mal mit meinen eigenen Locks. Oder ich implementiere eine Art "Limiter", der den Zugriff auf die DB kontrolliert und ggf. einschränkt. Als einfachste Lösung einfach Semaphore, so dass nicht nur ein Thread, sondern mehrere Threads einen Query ausführen können, oder auch einen komplexen Algorithmus, der das ganze regelt. Im Prinzip habe ich ja volle Kontrolle über den DB-Zugriff, da die Clients nur die Daten mit Pyro übertragen und auf dem Server werden diese dann in SQL Queries umgesetzt und ausgeführt.

lunar hat geschrieben: Wenn du natürlich eine Abstraktionsschicht wie SQLAlchemy verwenden würdest, bräuchtest du dir darum nur bedingt Sorgen machen, da die eigentliche Datenbank austauschbar wäre.

1. Was heißt "bedingt"?
2. Denkst du, dass das problemlos in meine bestehende Architektur eingefügt werden kann (Remotezugriffe auf die DB mit Pyro).
3. Ist es sehr aufwendig, sich in SQLAlchemy einzuarbeiten, das in das Programm zu integrieren und alle SQL Statements zu ersetzen?

Natürlich kannst du die Datenbankzugriffe auch verwalten und beispielsweise in eine Warteschleife einfügen. Allerdings ist es doch ein bisschen seltsam, die Datenbankleistung künstlich zu limitieren, nur weil man kein der Aufgabe angemessenes DBMS einsetzen möchte. Solange SQLite mit der Last zurecht kommt, besteht ja kein Grund zur Sorge, aber wenn die Last steigt, dann ist auch eine künstliche Verlangsamung nicht wirklich sinnvoll (zumal das ja andere Probleme, wie fehlende Persistenz und zusätzliche Komplexität mit sich bringt).

lunar hat geschrieben:Wenn du natürlich eine Abstraktionsschicht wie SQLAlchemy verwenden würdest, bräuchtest du dir darum nur bedingt Sorgen machen, da die eigentliche Datenbank austauschbar wäre.

1. Was heißt "bedingt"?

Naja, wenn du ein ineffizientes Datenmodell oder ineffiziente Ausdrücke nutzt, dann nutzt dir auch ein gutes DBMS nicht so viel

2. Denkst du, dass das problemlos in meine bestehende Architektur eingefügt werden kann (Remotezugriffe auf die DB mit Pyro).

SQLAlchemy an sich ist nicht komplex und bringt auch andere Vorteile, wie z.B. die Möglichkeit, SQL-Abfragen ohne Zeichenketten-Manipulation zusammensetzen zu können. Aber wie du das in dein Programm integrierst ... woher soll ich denn das wissen? Wenn deine Architektur den Dienst vom Datenbankzugriff sauber trennt, dann ist eine zusätzliche Schicht kein Problem, wenn du den Datenbankzugriff aber wild über den gesamten Code verstreut hast, wird das natürlich schwerer

3. Ist es sehr aufwendig, sich in SQLAlchemy einzuarbeiten, das in das Programm zu integrieren und alle SQL Statements zu ersetzen?

Sich in SQLAlchemy einzuarbeiten, ist nicht aufwendig, die Dokumentation bietet gute Tutorials. Es in eine Anwendung zu integrieren, kann dagegen sehr aufwendig sein, wenn die Anwendung schlecht strukturiert ist

gerold hat geschrieben:Installieren von PostgreSQL und psycopg2 unter Windows XP bzw. Windows Vista:

0.) Den alten Balast loswerden: psycopg, psycopg2 und PostgreSQL deinstallieren und den Computer neu starten.

1.) Installiere dir unter Vista auf keinen Fall "Python für 64 Bit". Nimm weiterhin "Python für 32 Bit". Installiere dir das neueste Python 2.6.x. Spiele unter Windows gar nicht erst mit Python 3. Das bringts nicht. Wenn es irgendwelche Inkompatibilitäten gibt, dann lassen die sich im Nachhinein in kürzester Zeit im Programm anpassen. http://python.org/ftp/python/2.6.1/python-2.6.1.msi

2.) Installiere PostgreSQL. Am Besten nimmst du den "pgInstaller" und nicht den "One click installer". Dessen Sinn habe ich sowiso noch nicht verstanden. Nimm die Version "8.3.4" http://wwwmaster.postgresql.org/downloa ... .3.4-1.zip, denn dafür gibt es einen passenden Windows-Treiber für Python. Es wird wahrscheinlich in den nächsten Tagen einen neuen Treiber für 8.3.5 geben, aber darauf muss man ja nicht warten. Das kann man später updaten.

3.) Installiere "psycopg2". Das Findest du für Python 2.6.x hier: http://www.stickpeople.com/projects/pyt ... elease.exe
Diese EXE-Datei musst du nur mit einem Doppelklick ausführen und schon ist die Schnittstelle installiert.

4.) Ausprobieren: http://www.python-forum.de/topic-12304.html

mfg
Gerold

Ich hab das ganze mit Windows 7 versucht (und den inzwischen aktuellen Versionen (python 2.7.2 / PostGreSQL 9.0 / psycopg2-2.4.2.win32-py2.7-pg9.0.4-release.exe von http://www.stickpeople.com/projects/python/win-psycopg/). Bei der Installation erfolgt aber immer ein Abbruch:

psycopg2-2.4.2.win32-py2.7-pg9.0.4-release.exe funktioniert nicht mehr
Das Programm wird aufgrund eines Problems nicht richtig ausgeführt. Das Programm wird geschlossen und Sie werden benachrichtigt, wenn eine Lösung verfügbar ist.

Super, das Windows keine andere Fehlermeldung kreiiert. Hat jemand ne Idee, woran es liegen kann? Auf einem XP-Rechner hatte es super geklappt, aber bei meinem Windows7 streikt der Installer.

Falls jemand das Problem ebenfalls schon hatte und löste, wäre ich über ne Hilfe dankbar.