• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

SQLite vs MySQL + OpenSim.ini

C

Cynnie Decosta

Guest
Mich interessiert mal was einfacher oder schneller ist von den beiden, welche Datenbank mehr Vorteile bringt. Ich habe zur Zeit MySQL.

Dann habe ich noch eine Frage, kann man zwischen den Datenbanken wechseln......also wenn SQLite doch in Frage kommt dann von MySQL zu SQLite einfach umziehen?

Das war das und jetzt noch eine Frage zur der opensim.ini

Ich hab noch eine alt gestrickte, wo ich das Gefühl habe die läuft nicht mehr. Jetzt dachte ich mir ich nehme die von Ralf, aber da gibt es wieder andere Probleme, zum Beispiel sind da alle Prims Phantom und Scripts funktionieren nicht wirklich. Auf was muß ich bei dieser ini achten?
 
Zum Vergleich der Datenbanken.

Grundsätzlich fällt so ein Vergleich recht komplex aus. In Summe aller Einzelvergleiche musst
Du wissen welchen Operationen auf die Daten häufiger ausgeführt werden um für den
*speziellen* Anwendungsfall für *Dich* entscheiden zu können bei welchem System die
Vorteile überwiegen.

http://sqlite.org/speed.html

Wenn Du jetzt MySQL hast würde ich Pi*Daumen auch dabei bleiben. SQLite ist ne feine
Sache wenn man z.B. die SQL Engine komplett in die eigene Anwendung einkompilieren
möchte und so den Installationsaufwand auf NULL bringt. Was auch ein Vorteil sein *kann*.

Vll. hilft Dir diese Einschätzung auch weiter:

http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations

>SQLite is the speed demon of choice for systems that don't
>make heavy use of concurrent connections and complicated
>database features. If you need a lot of concurrent
>connections, SQLite probably isn't the best choice. But if
>you need a lot of speed and a simple setup for a single
>connection, SQLite is the best thing I've seen.

Auf Deutsch: je mehr gleichzeitige Zugriffe auf die DB, desto langsamer wird das ganze.
 
Danke Red, das hilft mir tatsächlich weiter.....ich bleib somit bei MySQL, auf längerer Sicht gesehen das optimalste für mich, wenn ich das richtige verstehe
 
sqlite ist in der Tat eine der vebreitesten Datenbanken der Welt, z.B. auf Mobiltelefonen.

Sie ist klein, kompakt.


Für opensim kann man sagen:

sqlite:
- simpler
- weniger Resourcen (MySQl/SMSQL.. brauchen ja für den Dienst auch Speicher - und werden nur richtig schnell mit mehr Speicher)
- selfcotained, man kann also ein Verzeichniss von A nach B kopieren und hat alles dabei

MySQl:
- schneller
- deutliche Performancevorteile insbesondere bei vielen Operationen hinternander


Insofern macht eine Migration von MySQL nach SQLIte i.d.R. garkeinen Sinn. Nur sollte man an genug RAM bei MySQL denken und Anfänger wird zum starten halt erstmal zur sqlite geraten.


In Sachen .ini:

welche (von welchem Datum) von mir benutzt du, und mit welcher Version von opensim ?

Da klingt was ganz stark daneben - 1000 scripte sollten pro SIM damit kein thema sein und phantom darf auch nix sein.


cu
Ralf
 
Kann wie so oben beipflichten, die SQlite bildet klar eine einfache und auch sehr flexibele Variante im Sprach-Kontex der MYSQL zu folgen, auch sehr gut via statischer Compilierung gänzlich es z.B. auf eine Datei zu beschränken, welche die Anwendung beschreibt und der Aufwand ist natürlich gemäß der Installation auf anderen Systemen äusserst praktisch, (betrifft jetzt mal allgemein der Applikations-Entwicklung);-)
Auch ist mit der Copy 'einer' Datei, alles 'gesichert' ;-)

Es scheitert aber schlichtweg an Performance, mehre Aufgaben in mehrere Prozesse zu verteilen, d.h....full multihreading bei dieser Variante nicht erfolgen kann.

Man muss entscheiden ,was man an Leistung und Stabilität bieten möchte.
Betreibt man mehrere Regionen in der Simulation und man hat auf jeder Sim z.B. einen User, der da rumwerkelt, 'Klötzchen' baut oder den Boden verbiegt, wird dies auf jedenfall die sqlite dankend 'absagen', Fehler erzeugen und hängen und den Region-Server crashen lassen...
'Huckt' man allein auf den Simulatoren,wirds vll auch die probs nicht geben...aber der sinn ist ja auch, mal Besuche zu erlangen, was dann....

Der Idealfall wäre...einen Datenbank-Server, nur für die Prozesse der 'Ablege' und 'Abrufe'...nix weiter dazu, sämtliche Server-Komponenten greifen dann darauf zu.
Die Datenbank bildet nunmal den sensiblen Bereich,der absolut und zuverlässig in der Leistung und Zuverlässigkeit funktionieren MUSS....

Man sieht an der Architektur nun, allgemein, was die Simalation nun betrifft, doch ein gewisser Aufwand steckt...gesehen an Hardware oder Leitungskapazität.

Man kann sich in dieser Simulation alles fein gestalten und bauen, nur für wen den eigentlich, allein wirds mit der Zeit langweilig....

@Ralf: ich sehe eigentlich bei Dir immer meist das selbe Statement mit RAM oder der Opensim.ini Deiner Site,
1. RAM ist wichtig, schon klar, aber auch nicht die Allweltsantwort
2. die opensim.ini bildet nix besonders bei Dir, sie entspricht mit 'geringfügigen' Anpassungen der Default ...ich geh da paar Schritte weiter;-)


..nunja..meine Sache mal dazu;-)

lg
 
Pixel:

ich beanspruche nicht, dass ich für irgendwas eine universal-Lösung habe.

Die Opensim.ini hat bezogen auf ihre Parameter n! Möglicheiten zu Konfiguration. Ich habe mich entschieden eine jeweils gut funktionierende bbereitzustellen und zu pflegen. Genau wie das manche Grids tuen.

Interessanterweise habe ich wirklich viele Probleme erlebt, wo Leute eben diese kleinen Änderungen nicht hatten (z.B. scriptthreads) - oder simpel seit Wochen ihre ini nicht geupdatet hatten. Sie haben z.t. auch nicht den Überblick was sich geändert hatte.

Ich würde es ausdrücklich begrüßen, wenn es andere pages gäbe die mehrere Varianten für bestimmte Anwendungsfälle bereitstellen.

Zum RAM kann ich nur sagen: es wird oft gesagt "hier tuts was nicht" oder "braucht viel RAM". Wenn man es aber berechnet lichtet sich der Dunst. Ich denke hier sind schlicht viele SL-Anwender dabei ihre ersten Erfahrungen als Serverbetreiber zu machen. Das man keine Lust hat sich damit auseinanderzusetzen halte ich für menchlisch - interessiert aber die Technik nicht.

Ich kann aus meinen Monaten osgrid, dem Jahr opensim und eigenen Tests, wie denen von adam und Intel sagen: RAM matters. RAM und Netzwerk sind die Häufigsten Probleme bei Stabilität/Performance.

Es gibt ja schlicht auch viele Meßdaten dazu. Mein Lieblingshammer ist eine Client-Viewer Warteschlange von über 130MB. Wenn sich die Leute ihre brave neu gestartete (nicht gecachte) SIM so ansehen, ist das häufig nicht auf der Peilung. Und wer betriebt RAM-Monitoring ?


Kurz gesagt:

Wenn du alternative opensim.ini´s hast, so stell diese doch zur Verfügung.

Wenn du konkrete reproduzierbare Messungen zu RAM hast (oder machen willst), mach diese publik.

Beides aber am besten nicht im Forum, sondern auf Webseiten , Blogs, Wikis.

Daran haperts doch - mehr aktive Mitgestalter. Ich würde mich sehr freuen !


Jeder, der gute Infos für die Gemeinschaft bereitstellt ist doch ein schöner Fortschritt.


cu
Ralf
 
;-)....so war es auch nicht gemeint, ja das prob ist auch , das sich ini's Ändern und auch Optionen dazu kommen und der Bedarf auch besteht, sofort was in den Finger halt funktionierendes zu bekommen, logisch;-)

Nunja, schauen wir mal, vll, wenn die Zeit mal ist, werde ich mich evt. an den svn's beteiligen...dazu bedarfs es natürlich erstmal alles 'zu verstehen'.
Jeden Thunk kompiliere ich durch, wäre mal interessant was mir da so einfällt..die Server-Version zu faken, damit sie vollständigt läuft im OSGRID,welche ja eine Reihe von Buildstufen bewusst und das auch gut so, auslassen und nicht anpassen...denn z.b. funktioniert die Suche nicht im OSGRID, wenn die Version nicht der Version des Grids entspricht, um die Thunks mal ausgiebig zu testen;-)

Ja Speicher ist das Prob..nur auch eins dazu...man sollte auch ermahnen...es ist so leicht ...einen riesen fleck vollzubomben mit Regionen, nur ...funktionell werden sie nicht sein, da sie den Region-Server zu sehr belasten->ebend auch RAM und allgemeines Hardware-Vermögen....es nützt keinem, sich zig Regionen auf den Server zu knallen;-)
Das Optimum ist eigentlich eins zu eins.....ein Rechner/Server..ein Simulator....


lg;-)

Nun denne..schauen wir mal, was die Zeit bringt;-)
 
@Pixel,
ohne ein riesen Fass aufmachen zu wollen, aber könnte es sein Deine
Beobachtung bzgl. der sqlite db hängt stark vom Modus ab wie diese
betrieben wird ?
http://www.sqlite.org/threadsafe.html
Demnach sollte mehrerer gleichzeitige Zugriffe auf die db von dieser selbst
synchronisiert werden - im richtigen Modus.

>Serialized. In serialized mode, SQLite can be safely used by multiple threads with no restriction.
>...
>The default mode is serialized.
 
Auch dann stößt SQlite an Grenzen.

SQlite ist für einen bestimmten Einsatzbereich erstellt - und viele Anwendungen sind damit gut bedient, besonders wenn es um eine einfache Installation geht. Das Ganze geht allerdings auf Kosten der Skalierbarkeit.

Greifen mehrere Anwendungen/Teilprogramme gleichzeitig zu und/oder steigt die Anzahl der Zugriffe stark an, ist man mit MySQL besser bedient.

Die Datensicherung ist bei SQlite sehr einfach, eine Datei sichern, das war's. Für MySQL gibt es allerdings ein Script, das eine komplette Sicherung aller Datenbanken incl. Zugriffsrechten usw ablegt. Die Sicherung erstellt ein lauffähiges Script, mit dem die Datenbank direkt in einen neuen / anderen MySQL-Server wieder eingespielt werden kann. Bei Interesse suche ich den Downloadlink für das Script gern mal raus.

Fazit:
Wer ohne "Expansionspläne" zuhause experimentieren will, ist mit SQlite allerbestens beraten, es geht einfach, schnell und ohne großen Aufwand. Wer einen dauerhaften SIM-Server aufbauen und vielleicht später auch eine zweite SIM darauf implementieren will, dürfte mit MySQL besser beraten sein.

Yis
 
In Sachen .ini:

welche (von welchem Datum) von mir benutzt du, und mit welcher Version von opensim ?

Da klingt was ganz stark daneben - 1000 scripte sollten pro SIM damit kein thema sein und phantom darf auch nix sein.


cu
Ralf

meine ini ist eine selbst zusammen geschusterte, deswegen wollte ich deine mal nehmen. theoretisch muss ich doch nur die Datenbank auswechseln, da meine MySQL ist, richtig? was noch, OS Grid auch? OS grid interessiert mich nicht und habe auch nicht vor mich da anzuschließen, also auch raus damit.....soweit so gut, trotzdem stürzt der Server ab. 0.6.3 ist die Version die ich hab....was hab ich übersehen?
 
also... die Ini berücksichtigt halbwegs aktuelle Entwicklungen.

Sprich: 6.4 , nicht 6.3.

Wenn du also grid auf standalone geänderst hast , eine 6.4 version und deine mysql-paramter korrekt einträgst - dafür sqlite auskommentierst, sollte alles klappen.

cu
Ralf
 

Users who are viewing this thread

Zurück
Oben Unten