Webspace MySQL DB VS. Heroku PostgreSQL DB | Leistung vergleichen

[Zoja]

Hallo!

Ich habe einen Webspace mit 250 GB Speicherplatz und ich kann bis zu 50 MySQL-Datenbanken haben.

Ich benutze Heroku, Flask für meine Anwendung und ich benutze das Heroku PostgreSQL DB Add-On.



Jetzt habe ich mir überlegt, warum ich die Datenbanken nicht von meinem Webspace nutzen soll. Heroku hat ein Rowlimit von 10.000 für die kostenlose Datenbank und die nächste Stufe kostet 9 $. Mein gesamter Webspace ist günstiger und ich habe 50 Datenbanken.



Ich habe bereits mit dem Testen begonnen und die MySQL-Datenbank von meinem Webspace erfolgreich mit einer Flaskanwendung verbunden, die zurzeit auf localhost läuft.



Jetzt möchte ich die Unterschiede zwischen diesen beiden Datenbanken herausfinden. Haben meine Webspace-Datenbanken Leistungseinschränkungen im Vergleich zur PostgreSQL-Datenbank von Heroku? Oder ist die heroku DB einfach teuer, weil sie sehr einfach zu bedienen und einzurichten ist?



Wo finde ich alle relevanten Informationen?



Für PostgreSQL kann ich eine Verbindung über PGAdmin4 herstellen und für die MySQL-Datenbank verwende ich PHPMyadmin4, aber wie würde ich Leistungsunterschiede feststellen?



Hier sind einige Beispiele, worüber ich gerade denke:

https://elements.heroku.com/addons/heroku-postgresql



Herokus postgreSQL DB hat sogar auf dem 9$ tier 0 RAM.

Es hat ein connection limit von 20.



Wie viel RAM hat die MySQL-Datenbank auf meinem Webspace? Gibt es auch ein connection limit oder

wird der connection limit von Heroku künstlich erstellt, damit die Benutzer ihren Plan upgraden.

Vielen Dank!

[__deets__]

Ein connection limit von 20 ist IMHO satt. Das bedeutet ZEITGLEICH 20 Verbindungen. Ich weiss jetzt nicht, was du so treibst mit deiner Flask Anwendung, aber wenn die 20 konkurrierende User verknusen kann, dann ist das eine Menge.

Ich persoenlich bevorzuge Postgres, weil es eine Vielzahl von Features hat, die MySQL nicht hat. Reichere Queries, transaktionales DDL, bessere Administration.

Vor allem aber ist die Heroku-DB auf dem gleichen System wie deine Flask Anwendung. Wenn du jetzt einfach eine andere DB nimmst, dann

- musst du sicherstellen, dass die nicht scheunentor-offen ist, und dir jemand deine Datenbank/Server-Space angreift.
- du massive Latenzen fuer DB-Queries bekommst. Wenn das kein Problem ist, dann sind erst Recht 20 Verbindungen kein Problem.

Ansonsten kann man mit beiden DBs arbeiten. Ist viel Geschmacksache.

[Zoja]

Ein connection limit von 20 ist IMHO satt. Das bedeutet ZEITGLEICH 20 Verbindungen. Ich weiss jetzt nicht, was du so treibst mit deiner Flask Anwendung, aber wenn die 20 konkurrierende User verknusen kann, dann ist das eine Menge.

Ich persoenlich bevorzuge Postgres, weil es eine Vielzahl von Features hat, die MySQL nicht hat. Reichere Queries, transaktionales DDL, bessere Administration.

Vor allem aber ist die Heroku-DB auf dem gleichen System wie deine Flask Anwendung. Wenn du jetzt einfach eine andere DB nimmst, dann

- musst du sicherstellen, dass die nicht scheunentor-offen ist, und dir jemand deine Datenbank/Server-Space angreift.
- du massive Latenzen fuer DB-Queries bekommst. Wenn das kein Problem ist, dann sind erst Recht 20 Verbindungen kein Problem.

Ansonsten kann man mit beiden DBs arbeiten. Ist viel Geschmacksache.

Alles klar, vielen dank. Das Hilft schonmal.

Mir geht es grundsätzlich um das Verständnis. Ich habe keine Probleme mit der performance und hatte auch nie welche.
Heroku's server haben auch einen Standort in Frankfurt, Latenz sollte also kein Problem sein für die MySQL DB, die auf dem Webspace liegt.

Der einzige Nachteil wäre dann security, weil die MySQL DB an einem anderen Ort liegt, aber ich denke dieses Problem hat man immer, also dass man gehackt oder sonst wie angegriffen werden kann.

[__deets__]

Hmmjaaaneeee. Es ist allgemein ein guter Rat, eine "rohe" Datenbankverbindung NICHT einfach der Weltoeffentlichkeit zur Verfuegung zu stellen. Die sollte immer geschuetzt werden. Denn die Datenbanken versuchen da nicht, besonders gehaertet zu sein. Da kann also von DOS bis brute force Passwort-Raten alles dabei sein. Verschluesselung ist AFAIK auch nicht dabei. Darum mindestens VPN oder SSH-Tunnel.

Und Latenzen addieren sich auf. Ein ping von 10ms bedeutet das *JEDES* Query diese Latenz addiert. Und dann noch mal pro Ergebnisseite. Da koennen dann locker ein paar dutzend Roundtrips bei rumkommen, und schon hast du 1-2 Sekunden Latenz.

[Zoja]

Da kann also von DOS bis brute force Passwort-Raten alles dabei sein. Verschluesselung ist AFAIK auch nicht dabei

Aber all diese Dinge kann man doch auch mit der PostgreSQL DB von Heroku auch machen?

Wenn ich das add-on nutze, erstelle ich auch ganz simple eine connection:

Code: Alles auswählen

engine = create_engine("PostgreSQL DB URL", convert_unicode=True)
db_session = scoped_session(sessionmaker(autocommit=False, autoflush=False, bind=engine))
Base = declarative_base()
Base.query = db_session.query_property()

Und wenn ich die MySQL DB vom Webspace nutze, dann nutze ich einfach einen anderen connection Link:

Code: Alles auswählen

create_engine("MySQL DB URL", convert_unicode=True)

Alles andere ist identisch.

[__deets__]

Kannst du die Heroku-URL auch lokal (also bei dir zuhause) eingeben, und darauf zugreifen? Ohne SSH oder VPN? Wenn ja, dann ist das Mist. Aber dann natuerlich auch keine Verschlechterung. Doch nur weil da "postgres://ein-rechner-im-gleichen-rechenzentrum-den-man-von-aussen-nicht-erreicht-steh" ist das eben keine Luecke. Doch wenn dein Flask bei Heroku lebt (und so verstehe ich dich) und du willst deine MySQL bei billighoster.de benutzen, dann musst du die DB nach aussen auf machen.

[Zoja]

Kannst du die Heroku-URL auch lokal (also bei dir zuhause) eingeben, und darauf zugreifen? Ohne SSH oder VPN? Wenn ja, dann ist das Mist. Aber dann natuerlich auch keine Verschlechterung. Doch nur weil da "postgres://ein-rechner-im-gleichen-rechenzentrum-den-man-von-aussen-nicht-erreicht-steh" ist das eben keine Luecke. Doch wenn dein Flask bei Heroku lebt (und so verstehe ich dich) und du willst deine MySQL bei billighoster.de benutzen, dann musst du die DB nach aussen auf machen.

Ich kann über die PostgreSQL URL von Heroku überall auf die DB zugreifen.

Ich denke es macht dann eben keinen Unterschied.

[__deets__]

Ich sehe gerade, man kann das bei Heroku: https://devcenter.heroku.com/articles/h ... ns-ingress

Finde ich ungewoehnlich. Wuerde ich gerne eine Begruendung lesen, warum die das fuer OK halten. Kann sein, dass es durch die quasi-anonymisierung der AWS-Instanzen funktioniert, weil man sowas wie ec2-117-21-174-214.compute-1.amazonaws.com nicht raten kann.

Und das die SSL benutzen wusste ich nicht. Das solltest du auch in jedem Fall tun, wenn MySQL das auch kann. Denn sonst kann jeder Hop mitlesen.

[__deets__]

Und es kann schon einen Unterschied machen, weil Angriffe auf meinedomain.de eben per Port-Scan automatisiert erfolgen. Wie gesagt, warum die das bei Heroku so machen, finde ich erstmal ueberraschend.

[Zoja]

Ich sehe gerade, man kann das bei Heroku: https://devcenter.heroku.com/articles/h ... ns-ingress

Finde ich ungewoehnlich. Wuerde ich gerne eine Begruendung lesen, warum die das fuer OK halten. Kann sein, dass es durch die quasi-anonymisierung der AWS-Instanzen funktioniert, weil man sowas wie ec2-117-21-174-214.compute-1.amazonaws.com nicht raten kann.

Und das die SSL benutzen wusste ich nicht. Das solltest du auch in jedem Fall tun, wenn MySQL das auch kann. Denn sonst kann jeder Hop mitlesen.

SSL kommt doch von der Anwendung? Aber danke für den Tipp! Ich gucke es mir nochmal genauer an.

Die ganzen Konfiguration zu finden und die Unterschiede ist überigens mein initiales Problem.

In PHPmyAdmin habe ich noch nichts dazu gefunden.

Zum Beispiel steht bei der Heroku PostgreSQL DB 4GB RAM und ein connection limit. Jetzt denke ich aber, dass das künstlich erzeigte Limits von Heroku sind,
damit Nutzer ihren Plan updaten und Heroku verdient. Ich finde zumindest keine Limitierungen für die MySQL DB auf meinem Webspace.

[__deets__]

SSL ist eine Protokoll-Unabhaengige Technologie. Die gibt's bei HTTP (dann eben HTTPS) genauso wie bei SMTP und eben augenscheinlich auch bei einer Datenbank-Verbindung mit Postgres. Du kannst eine HTTPS-faehige (oder sogar erzwingende) Seite haben, aber dann voellig ungeschuetzt mit der DB kommunizieren. Das ist auch egal wenn es per lokalem Socket oder im Rechenzentrum passiert. Sobald die Pakete ueber das oeffentliche Internet geroutet werden, sollte man das halt anschalten.

[__blackjack__]

@Zoja: Deine Anwendung kommuniziert mit PostgreSQL SSL-verschlüsselt. Das ist nicht ”normal”, weil man Datenbanken normalerweise nicht einfach so über das Internet verfügbar macht, sondern nur Netzintern, und da ist Verschlüsselung unüblich. Ich kenne keinen normalen Webhoster der Datenbanken einfach so aus dem Internet zugreifbar macht, also ist die Frage wie Du von Heruko aus auf die DB beim Webhoster zugreifen kannst, bzw. ob das überhaupt geht.

Also nächstes würde ich bei Heruko mal schauen was die bei eingehenden Traffic der von ”innen” initiiert wird für Beschränkungen haben.

[DasIch]

Zum Beispiel steht bei der Heroku PostgreSQL DB 4GB RAM und ein connection limit. Jetzt denke ich aber, dass das künstlich erzeigte Limits von Heroku sind,
damit Nutzer ihren Plan updaten und Heroku verdient. Ich finde zumindest keine Limitierungen für die MySQL DB auf meinem Webspace.

Der Anbieter deines Webspaces möchte auch Geld verdienen, daraus folgt dass es auch Limitierungen geben muss. In der Regel wird er dir die näher bringen wenn du "auffällig" wirst. Ich persönlich würde einen Anbieter bevorzugen der die Grenzen den Angebots klar aufzeigt aber bei einem Hobby Projekt spielt dass vielleicht keine so große Rolle.

Was die Anzahl der Datenbank Verbindungen angeht, würde ich dir diesen Artikel empfehlen. tl;dr: weniger ist oft mehr wenn es um Datenbank Verbindungen geht

[Zoja]

@DasIch, @__blackjack__, @__deets__

Vielen Dank für die Informationen. Ich beschäftige mich jetzt mehr mit dem Thema und verstehe das immer besser.

Ich habe jetzt auf meinem Webhoster ein paar Testcases erstellt und zwar habe ich eine DB (A), die von außer zu erreichen ist. Diese kann ich z.B. mit phpmyadmin öffnen und mit mysql workbench ich kann auch ganz normal Daten hinzufügen (über eine Webseite)

Datenbank B ist nur über localhost zu erreichen, d.h. nur im internen Netzwerk. Ich kann diese Datenbank mit phpmyadmin öffnen und ganz normal Daten hinzufügen (über eine Webseite). ABER ich kann nicht mehr darauf über MySQL Workbench zugreifen, weil es nicht im selben Netzwerk liegt.

Jetzt möchte ich verstehen wie das funktionieren würde, wenn man die Daten "klaut", also ich möchte es selbst bei mir mal machen. Datenbank (A) wäre dann ja angreifbar, weil sie kein SSL nutzt (also beide Datenbanken haben kein SSL). Jetzt möchte ich Datenbank A angreifen:

Kann ich das jederzeit tun?
Kann das nur geschehen wenn ein User gerade Daten hinzufügt und "Protokolle?" gesendet werden?

Gibts dazu Tutorials irgendwo? Wo kann ich mich informieren?

Ich versichere, ich möchte nicht irgendwo jemanden hacken oder Schaden anrichten, ich will es einfach nur selbst verstehen.

Gruß,
Roman

[__deets__]

Der Angriff geschieht unabhaengig von SSL. Das verhindert nur, dass auf einer bestehenden Verbindung nicht einfach passiv gelauscht werden kann. Und zum angreifen oeffnest du einfache eine TCP/IP Verbindung zur DB. Eine simple (und wenig erfolgversprechende) Vorgehensweise waere, einfach die Credentials zu raten. Also klassisches brute forcing. Das ist aber ueblicherweise nicht das vorgehen. Eher probiert man, Luecken auszunutzen. Also zB unicode in den Credentials zu schicken, die dann einen Speicherueberlauf ausloesen den man ausnutzen kann, etc. Das ist kein einfaches und allgemeines Thema, sondern setzt intimes Wissen ueber die konkret verwandte DB, deren Version, und deren Code vorraus.

Mit bestehenden Verbindungen kann man meines Wissens nach nichts anfangen. Die werden ja zum legitimen Benutzer geroutet.

[Zoja]

Der Angriff geschieht unabhaengig von SSL. Das verhindert nur, dass auf einer bestehenden Verbindung nicht einfach passiv gelauscht werden kann. Und zum angreifen oeffnest du einfache eine TCP/IP Verbindung zur DB. Eine simple (und wenig erfolgversprechende) Vorgehensweise waere, einfach die Credentials zu raten. Also klassisches brute forcing. Das ist aber ueblicherweise nicht das vorgehen. Eher probiert man, Luecken auszunutzen. Also zB unicode in den Credentials zu schicken, die dann einen Speicherueberlauf ausloesen den man ausnutzen kann, etc. Das ist kein einfaches und allgemeines Thema, sondern setzt intimes Wissen ueber die konkret verwandte DB, deren Version, und deren Code vorraus.

Mit bestehenden Verbindungen kann man meines Wissens nach nichts anfangen. Die werden ja zum legitimen Benutzer geroutet.

Danke nochmal!

Wie würde ich denn auf einer bestehenden Verbindung lauschen? Wo soll ich starten mich zu informieren?

[Zoja]

Und zum angreifen oeffnest du einfache eine TCP/IP Verbindung zur DB.

Um das zu machen muss man ja auch erstmal die Addresse der Datenbank kennen, oder?

[__deets__]

Hier ein Artikel: https://www.hackingarticles.in/penetrat ... port-3306/

Und auf einer bestehenden Verbindung kannst du nur passiv lauschen, wenn du Teil der Verbindung bist. Also entweder ein HOP innerhalb der TCP/IP Verbindung, oder durch eine man-in-the-middle-Attack, oder wenn du Teil eines Netzwerkes bist, in dem du alle Pakete abgreifen kannst. Also zB einem oeffentlichen und nicht veschluesselten WLAN. Oder einem Ethernet.

Und bitte nicht einfach den Post direkt ueber deinem full-quoten. Den kann man ja auch so lesen.

[__deets__]

Klar muss man eine Adresse kennen. Hast du mal in deine Webserver-Logs geschaut, und darin die tausenden komischen Requests gesehen, die zB auf wordpress-URLs gehen, auch wenn du gar keine WP Installation hast? Das ist alles durch scanning und raten zustande gekommen. Wenn du eine Domain hast, dann ist das veroeffentlicht, das es die gibt. Also lasse ich einfach nmap auf gegen deine Domain laufen (und 100000 andere, die ich mir von WHOIS abegriffen habe), und schon kenne ich alle offenen Services. Oder ich scanne IP-Ranges von Providern. Oder ich schaue durch Foren-Beitraege hier, und sehe veroeffentlichte Daten. Etc.

[Sirius3]

Ein üblicher Weg ist, Standardpasswörter auszuprobieren. Die Erfahrung zeigt, dass Leute, die ihre Datenbank nicht sichern auch keine sicheren Passwörter benutzen. Dann erlaubt ein weiterer offener Port natürlich, dass mehr potentielle Sicherheitslücken angreifbar sind, da geht es aber darum, eine konkrete Lücke auszunützen. Vorteilhaft ist, dass bei LowCost-Providern auch die MySQL-Versionen oft uralt und selten gepacht sind, so dass bekannte Lücken Monate und Jahrelang nicht geschlossen werden.

Unterschied zwischen Heroku und einem 08/15-Anbieter ist, dass ersterer gewisse Performance- und Verfügbarkeitsgarantien abgibt.
Bei einem all-in-one-Anbieter bedeutet es meist, dass Du den selben Rechner mit hunderten Leuten teilst, und wenn alle die zur Verfügung gestellten Resourcen nutzen würden, das System hoffnungslos überlastet wäre.
Solange Du nur hin und wieder und moderat die Resourcen nutzt, wird das dem Anbieter egal sein, merkt er aber, dass Du das System über Gebühr nutzt, wird er Dich dazu überreden wollen, ein ein höherpreisiges Produkt zu wechseln oder schmeißt Dich einfach so raus.
Es ist wie beim all-you-can-eat-Buffet, das Essen ist reichlich aber von minderer Qualität und wenn Du zum fünften Mal den Teller volllädst, fragt Dich der Besitzer, ob Du nicht mal das Angebot der Konkurrenz testen willst.