Postgresql Tabellen

[__blackjack__]

@__deets__: Aber das soll doch gerade genommen werden weil es mehr als 10.000 Datensätze werden sollen.

[__deets__]

Einen Tod muss man Sterben. Meine Vorhersage: Gaming the System. Unter Ausnutzung der Spaltenanzahlbegrenzung ALLES rausholen aus den 10000 Zeilen. So wie gute deutsche am all you can eat buffet.

[__blackjack__]

Jo am besten auch nicht nur alle Spalten nutzen, sondern da auch in jedem Datensatz in jeder Spalte JSON mit ordentlich vielen Werten speichern.

[__deets__]

Ich könnte Geschichten erzählen. Aber dann kriege ich Knatsch....

[sparrow]

@Hypec: Dann lade doch die Datei mit der Datenbank doch einfach nicht mit hoch - dann wird sie auch nicht überschrieben.
Der Aufwand sollte sich, im Gegensatz zu der willkürlichen Postgres-Begrenzung, in Grenzen halten und man kann die Datenbank benutzen, wie man Datenbanken benutzen soll.

[Sirius3]

Zur Erklärung, Rechnen in der Cloud mit Containern: man hat eine klare Trennung zwischen Programmcode und der Ausführung mit etwa temporärem Speicher und dauerhafter Datenspeicherung. Den Speicher für den Programmcode bekommt man geschenkt, da kann man aber auch keine Daten speichern, die Umgebung, in der etwas ausgeführt wird, kann jederzeit automatisch platt gemacht werden und an einer anderen Stelle wieder mit dem Programmcode neu erzeugt werden, oder wegen Parallelisierung kann es 100 identische Instanzen geben.

Alles was man dauerhaft speichern will, kann deshalb nicht einfach so geschrieben werden, sondern man muß den Speicherplatz zusätzlich dazubuchen, entweder als Objektstore, oder als Datenbank oder ...

[noisefloor]

Hallo,

@Hypec: Eine DB mit 10.000 Zeilen Limit ist ja, wie schon festgestellt wurde, relativ perspektivlos für das, was du vorhast.

Du kannst bei Heroku für 9.- USD/Monat die DB größer machen, dann sind 10 Millionen Zeilen erlaubt.
Wenn dir das zu viel ist, musst du halt über einen Providerwechsel nachdenken. Sehr flexibel ist das Hosting Uberspace, da hast du ziemlich viele Möglichkeiten. Oder du rechnest dir mal durch, ob es z.B. bei AWS nicht preiswerter als 9.- USD/Monat ist.

Plan C: alles auf dem Raspi selber hosten. Dann hast du aber zusätzlich die volle Administration deines eigenen Servers an der Backe.

Gruß, noisefloor

[Hypec]

Also ich habe jetzt nochmal nachgelesen und SQLite funktioniert leider nicht zusammen mit Heroku.
https://devcenter.heroku.com/articles/sqlite3

[DasIch]

Oder du rechnest dir mal durch, ob es z.B. bei AWS nicht preiswerter als 9.- USD/Monat ist.

Der ALB alleine kostet schon ~20 USD / Monat. Traffic, Compute (EC2, ECS, Lambda, ...) und RDS kämen noch drauf. Außerdem ist es wesentlich mehr Aufwand als Heroku.

[nezzcarth]

Also ich habe jetzt nochmal nachgelesen und SQLite funktioniert leider nicht zusammen mit Heroku.
https://devcenter.heroku.com/articles/sqlite3

Ich möchte noisefloors Vorschlag bzgl. Uberspace noch mal unterstreichen. Das ist zwar keine "PaaS" in der Cloud wie Heroku, aber du hast halt einen SSH Zugang auf einen regulären Server und ziemlich viele Möglichkeiten. Bei Uberspace musst du dich dann mit mysql/mariadb begnügen, was zwar normalerweise nicht meine erste Wahl wäre, aber so tragisch ist das auch nicht. Jedenfalls hast du da eine ganze Datenbank für dich alleine und sqlite wäre ansonsten auch kein Problem.

[Hypec]

Oke ich probiere das mit Uberspace mal aus. Ich hab gelesen da kann ich auch Postgresql installieren stimmt das?

[__blackjack__]

Es gibt eine Anleitung wie man sich PostgreSQL aus den Quellen selbst kompiliert.

[nezzcarth]

Es gibt eine Anleitung wie man sich PostgreSQL aus den Quellen selbst kompiliert.

Es spricht zwar für Uberspace, dass das überhaupt möglich ist, aber ich sehe dabei den Nachteil, dass man für jedes Update neu kompilieren muss (es sei denn, Uberspace 7 hat irgendeine Art Management-Tool für sowas; gentoo oder archlinux verwenden sie jedenfalls nicht . 'toast' verwenden sie soweit ich weiß nicht mehr). Zumindest mir wäre das regelmäßige Checken nach Updates und ggf. Neu-Kompilieren etwas zu unbequem. Gerade weil die Datenbank aber für eine Webanwendung verwendet werden soll, ist das vielleicht keine gute Voraussetzung, denn die Chance, dass man das schleifen lässt ist sicher nicht so gering. Da ist es doch einfacher, die "mitgelieferte" DB zu verwenden, die von den Uberspace-Admins gewartet wird.

[noisefloor]

Hallo,

also basierend auf dem, was hier im Thread des TE steht, würde ich auch dazu tendieren, MariaDB / MySQL von Uberspace zu nutzen. Nicht, dass ich die favorisieren würde, aber wenn es wirklich "nur" um das Speichern von ein paar Messwerten geht, sollte das RDBMS relativ Latte sein. Zumal SQLite ja scheinbar auch als Alternative in Frage käme.

Gruß, noisefloor

[Hypec]

Oke ich probiere es aus. Dazu müsste ich aber erstmal Flask auf Uberspace zum laufen bekommen.

[nezzcarth]

Ich denke, du kannst dich an der Anleitung für django orientieren: https://lab.uberspace.de/guide_django.html

Grundsätzlich läuft es eben so, dass deine App in uwsgi oder gunicorn läuft und du deinen Webserver so konfigurierst, dass er intern mit diesen kommuniziert und den Traffic "durchschleust" (das ist übliche Praxis und nicht Uberspace spezifisch). Siehe z.B. auch: https://manual.uberspace.de/web-backends.html

[Hypec]

Oke ich habe mich an die Anleitung gehalten. Das einzige was ich jetzt noch wissen will ist entweder was ich hier falsch gemacht habe oder wie ich eine Richtige Debug Meldung bekomme?

Gewaechshauscontroll.ini:

Code: Alles auswählen

[uwsgi]
base = /home/hypec/Gewaechshauscontroll
chdir = /home/hypec/Gewaechshauscontroll

http = :5000
master = true
wsgi-file = %(base)/app.py
touch-reload = %(wsgi-file)

app = wsgi

#virtualenv = %(chdir)/venv

plugin = python

uid = hypec
gid = hypec

app.py:

Code: Alles auswählen

from flask import Flask

app = Flask(__name__)
app.config.update(
    DEBUG=True,
)

@app.route('/')
def hello_world():
    return 'Hello World'

if __name__ == '__main__': 
    app.run(host='0.0.0.0', port=5000, debug=True)

[nezzcarth]

Ich hatte das Tutorial vorher nur kurz überflogen. Es ist leider nicht ganz vollständig. Ich schlage folgendes vor (zuvor alle Schritte aus dem Tutorial rückgängig machen):

Code: Alles auswählen

$ cd ~
$ mkdir -p my_app/my_app
$ virtualenv -p $(which python3) my_app/venv
$ source my_app/venv/bin/activate
$ pip install gunicorn flask
# unter der Annahme, dass dein Testbeispiel in home liegt und "test.py" heißt
$ cp test.py my_app/my_app

Dann die Datei ~/etc/services/gunicorn.my_app.ini wie folgt befüllen:

Code: Alles auswählen

[program:gunicorn]
command=/home/<BENUTZER>/my_app/venv/bin/gunicorn test:app
directory=/home/<BENUTZER>/my_app/my_app
user=<BENUTZER>
autostart=true
autorestart=true
redirect_stderr=true

Anschließend weiter wie im Tutorial (supervisorctl reread; supervisorctl update; dann das webbackend). Nach den supervisorctl Befehlen sollten mit curl auf Port 8000 schon was kommen. Fehlermeldungen stehen ggf. in logs/supervisord.log. Den Teil mit der gunicorn.conf.py habe ich mal weggelassen. Wenn alles läuft, kannst du die entsprechend der Doku anlegen und anschließend wie hier beschrieben in der oben erstellen ini festlegen:
http://docs.gunicorn.org/en/latest/depl ... supervisor

[Hypec]

Oke ich habe jetzt alles so gemacht bis zu den supervisorctl Befehlen. Curl hat danach geklappt allerdings hat es dann mit dem webbackend wieder aufgehört. Das hier ist mein webbackend das sollte soweit eigentlich passen und diese Fehlermeldung bekomme ich dann, ich vermute ich muss in die gunicorn.ini noch denn richtigen host schreiben, allerdings habe ich im Internet nicht gefunden wo und wie.

Code: Alles auswählen

uberspace web backend set /my_app --http --port 8000

Code: Alles auswählen

/my_app http:8000 => NOT OK, wrong interface (127.0.0.1): PID 25819, /home/hypec/my_app/venv/bin/python3 /home/hypec/my_app/venv/bin/gunicorn test:app -b localhost:8000

[__blackjack__]

@Hypec: Webbackends müssen einfach auf 0.0.0.0 lauschen. Das ist eine virtuelle Netzwerkkarte von der jeder Uberspacer seine eigene hat und die nur innerhalb von Uberspace erreichbar ist. Das ist also nicht vom Internet aus direkt erreichbar, aber deren nginx der von aussen erreichbar ist, kann da drauf zugreifen und es nach aussen transparent weiterleiten.