Android chat mit Mysql Datenbank realisieren

  • 10 Antworten
  • Letztes Antwortdatum
hunter123

hunter123

Neues Mitglied
0
Hallo Forum,

und zwar möchte ich ein Android Chat Programmieren wo Clients sich ein eigenen Chat in der App erstellen können und mit einander Chaten.

Ich hab grob in Google gekuckt wie man ein Chat schreiben könnte aber nicht das entsprechende gefunden. Meine Frage ist ob es möglich ist mit einer Mysql datenbank dies zu realisieren wie da die Performance bei einem VServer ist.

Mein Server Tech.Daten:
  • 1 vCore
  • 2,4 GHz
  • 2 GB RAM
  • 10 GB SSD

Es müssen ungefähr 6000 Chats auf der Mysql Datenbank drauf laufen können wenn ich je chat ein Eintrag in der Mysql Datenbank vergebe.
 
Ja, das geht, wie auch mit fast jeder anderen Datenbank.

Was brauchst Du genau? Eine Schnittstelle zwischen Server und Android - Device?
 
Die Schnittstelle werde ich mit JSON-OBJECTS realisieren habe auch eine Strucktur erstellt wie ich das mache, was nur mein bedenken ist die Performance meines Servers ob er das auch packt mit dem Lesen & Schreiben ständig:smile:

Ich wollt nur Erfahrungen von anderen hören die sowas schon mal gemacht haben und mir vll lösungen was Performanter läuft empfehlen würden.
 
Du willst die 6000 Chat-Channels in der Datenbank verwalten und die Nachrichten dieser 6000 Channels über den vServer schleifen ?
Dein Server entspricht etwa einem PC von vor 15 Jahren. Also 6000 Datensätze und viel mehr kannst Du darin verwalten.
Das Lesen & Schreiben erfolgt hoffentlich nicht in die Datenbank. Wenn doch, dann wird es in jedem Fall Engstellen geben.

6000 gleichzeitig genutze Channels, mit je 2 Usern in einem Channel sind 12000 aktive Ports am Server. Default sind 150 gleichzeitige Verbindungen
zum MySQL konfiguriert. Der Wert kann aber auch erhöht werden. Pro Verbindung ( Thread ) liefert mir mysqltuner 3 MB. Thread-Stack kann aber
auch kleiner konfiguriert werden. Angenommen 1 MB - dann sind es 12G !? Allein für die Thread-Stacks bei 12000 theoretischen Verbindungen.
256kB gehen aber auch, dann sind es "nur" noch 3GB :)

Ob der Server nun 1 oder 16 Kerne hat ist in dem Fall egal - denn er wird mehr Speicher aus und umlagern als Nachrichten zu versenden !
Aber vermutlich schmiert Dir irgendwas mit OutOfMemory ab, denn dein OS braucht auch 350 MB - ... und der Apache will auch was haben pro Fork,...
und dann ein Webinterface mit am Ende PhP-Interpreter ,... braucht auch Speicher bei jeder Anfrage,...

Als Testumgebung zur Entwicklung deines Vorhabens reicht der Server aus. Aber nicht für die von Dir angedachte finale Ausbaustufe.
 
Und warum eigentlich das Rad (schon wieder) neu erfinden? Setz doch auf XMPP bzw. Jabber oder IRC oder ... oder ...

Gerade bei 6000 gleichzeitig wäre doch was Bewertes sinnvoll... Oder gibt es derart hohe Anforderungen (z.B. an Sicherheit), die das nicht zulassen?
 
@RED-BARON, ich verstehe nicht, wieso du 6000 Threads brauchst. Das macht kein Sinn. Unwahrscheinlich, dass alle Geräte gleichzeitig Daten austauschen. (Die 12000 Ports ignoriere ich mal, eigentlich gibt der Port nur das Protokoll an, welches benutzt wird. In dem Fall brauchst man eigentlich nur ein Port. ;))

Daneben hast du eine gute Chance mit der Lösung den Akku des Android-Device leer zu saugen. Insbesondere wenn die Device in einem Fahrzeug befinden, und bei jeden Wechsel der Zelle eine neue Verbindung aufgebaut wird.

Zum Beispiel könnte man Push Notification von Google benutzen um den Datenaustausch zu organisieren (man kann Notification an einzelne Device senden).

Oder eben die Lösungen die Thyrion aufgezählt hat.

Nachtrag: Wenn jeder User mit jeden anderen User ein Chatchannel aufbaut, braucht man nicht 6000 sondern fast 18.000.000 Channel. Macht bei 1MB ca. 18 TB. Das im Speicher zu verwalten ist bestimmt sehr interessant. :)
 
Zuletzt bearbeitet:
Danke für eure Antworten :)
Ich hab hier ein kleines Diagramm gemalt was grob mein Denkteil ist wie ich das machen würde.
Bei Verbesserungsvorschläge würd ich mich freuen:)
Chat_Diagramm_2015.png
 
markus.tullius schrieb:
@RED-BARONUnwahrscheinlich, dass alle Geräte gleichzeitig Daten austauschen. (Die 12000 Ports ignoriere ich mal, eigentlich gibt der Port nur das Protokoll an, welches benutzt wird. In dem Fall brauchst man eigentlich nur ein Port.
mag sein, es ist unwahrscheinlich ! Evtl. war meine Betrachtungsweise auch falsch.
Jedenfalls braucht es pro Verbindung zur Datenbank am Server einen Thread.
Was die Ports anbelangt: Du beziehst Dich auf den Port über den die Verbindung hergestellt wird - da braucht es nur einen. Ist die Verbindung aber
hergestellt - fließen die Daten über einen ganz anderen Port, über den der bei der Verbindungsherstellung ausgehandelt wurde. Okay 12k braucht es
dann aber immer noch nicht, sondern nur so viele wie Verbindungen bestehen : also unsere magischen 6000 :)

Wie sich nun rausstellt, möchte Hunter123 aber viele Einfüge und Löschvorgänge in der Datenbank realisieren.
MySQL ist besonders optimiert auf Lesevorgänge - eignet sich daher wunderbar für Foren u.a. Anwendungen
die mehr statische als dynamische Daten halten.
Den Query-Cache, falls InnoDB konfiguriert ist, währe in seinem Fall abzuschalten.
Zum Thema ansich gibt's viele Funde im Inet. Der hier z.B.
mysql - Innodb table with many deletes and inserts - is there any disk space wasted? - Stack Overflow

Falls die 10G plötzlich nicht mehr reichen sollten :)

In der Tat lohnt sich eine gut skalierbare fertige Lösung zu suchen und mit dieser zu Testen was der Server
schafft.

Aus eigener Erfahrung, die Gesamtauslastung des Servers wird nicht linear ansteigen.
Zum Beispiel steigt der load beim Rotieren der mysql-log Files durchaus stark an. Diese Auslastungsspitzen
häufen sich aber mit Zunahme der Anwender. Es gibt sicher viele Fallstricke die ein Neuling auf dem Gebiet
nicht auf dem Radar haben kann. Das kommt aber später mit der gesammelten Erfahrung :)
 
Zuletzt bearbeitet:
@RED-BARON klammere Dich nicht so an die "magische 6000". Ein Server hat z.B nur ein Standard - Port für das Protokoll HTTP (mit TCP), nämlich 80. Und der reicht eigentlich für alle Verbindungen. ;) Wenn der Port 80 auf einem Server geschlossen wird, sind alle Verbindungen, welche das Protokoll HTTP (Standard Port 80) benutzen, verboten.
Der Verbindungsaufbau zwischen Server wird auf einer anderen Schicht organisiert (TCP oder UDP). Und funktioniert anders als du geschildert hast.
Der Bereich Thread und Netzwerkverbindung ist nicht ohne. Und Erfahrung und ein paar gute Bücher helfen schon ungemein.


@hunter123 eine einfache praktikable Lösung wäre wirklich Google Cloud Messaging. Try Cloud Messaging for Android  |  Cloud Messaging  |  Google Developers
Dort muss du dich nicht mit long living Connection (TCP / UDP) beschäftigen. Die Client senden einfach per HTTP die Texte zum Server. Der Server hingegen informiert hingegen mit einer genau adressierten Push-Nachricht das Device.
Um die Geschwindigkeit muss Du Dir keine Gedanken machen, zeitversetzte Chat - Nachrichten fallen meistens nicht auf.

Die anderen Lösungen (XMPP, IRC usw.) sind schon anspruchsvoller.
 
markus.tullius schrieb:
...
@hunter123 eine einfache praktikable Lösung wäre wirklich Google Cloud Messaging. Try Cloud Messaging for Android | Cloud Messaging | Google Developers
Dort muss du dich nicht mit long living Connection (TCP / UDP) beschäftigen. Die Client senden einfach per HTTP die Texte zum Server. Der Server hingegen informiert hingegen mit einer genau adressierten Push-Nachricht das Device.
Um die Geschwindigkeit muss Du Dir keine Gedanken machen, zeitversetzte Chat - Nachrichten fallen meistens nicht auf.

Die anderen Lösungen (XMPP, IRC usw.) sind schon anspruchsvoller.
Ist Google Cloud Messaging eigentlich nur nutzbar um von einem Server aus Android und IOS Geräte zu Benachrichtigen oder kann man auch Desktop Programme damit (außerhalb des Chrome Browsers) benachrichtigen?
 
Nicht, dass ich wüsste.
 

Ähnliche Themen

M
Antworten
21
Aufrufe
1.358
swa00
swa00
Mr-Fisch
Antworten
5
Aufrufe
963
migi01
migi01
Mr-Fisch
Antworten
8
Aufrufe
1.005
Mr-Fisch
Mr-Fisch
M
Antworten
9
Aufrufe
788
mkuz24
M
A
Antworten
5
Aufrufe
691
swa00
swa00
Zurück
Oben Unten