Servus, ich arbeite im Bereich Internet-Archive und habe da öfter einmal rechr große Datenmengen. Im Moment verwende ich eine selbstgebaute Datenbank, teilweise auch SQLIte (die Software ist in C). Früher habe ich mit dBASE und Btrieve gearbeitet. Das selbstgebaute ist sehr schnell, SQLite natürlich erheblich flexibler. Ich komme nun bei SQLite anscheinend so langsam an den Anschlag, ab 30 Mio Records wird es doch recht zäh. Mich interessieren mal Alternative zu SQLite, also "richtige" SQL-Server mit ordentlich "Schmackes". OS ist egal. Anforderungen wären: * bis zu 200 Mio Records bei akzeptablen Antwortzeiten * betriebssicher * halbwegs bezahlbar Wenn ich mir die Websites von mySQL, Oracle etc. so anschaue können die natürlich alles ;-) Hat da vielleicht jemand praktische Erfahrungen ?
Nicht die Anzahl Records zählt, sondern was man damit macht.
Ich habe mehrere große Projekte unter MySQL laufen. Die arbeiten alle mit der 'Standard Version'. Wenn die irgendwann nicht mehr ausreicht kannst du ja auch die 'Profi Version' upgraden. in der Suchmaschine deines Vertrauens -> "mysql free vs paid" und dann gucken. Gruß aus Berlin
A. K. schrieb: > Nicht die Anzahl Records zählt, sondern was man damit macht. Richtig, und darauf aufbauend hängt auch viel von der Konfiguration der DB ab. Darüberhinaus, wieviel solls denn kosten? Sogesehen, auch Facebook hat nen MySQL-Unterbau...
Auch wenn ich hier ein Hating anstoße... Guck dir mal MS SQL Express an, der sollte mit der Datenmenge umgehen können bei brauchbarer Performance. Nächste Frage: Hast du Ahnung von SQL, sodass du die Abfragen optimiert stellen kannst?
Du könntest Dir Firebird, den OpenSource-Ableger von Borland Interbase ansehen. http://www.firebirdsql.org/ Dann gibt es neben MySQL (das als Datenbankengine seit einiger Zeit auch mit SAP DB betrieben werden kann) noch postgreSQL http://www.postgresql.org Schließlich gibt es natürlich noch den MS SQL Server, aber je nach Anwendungsprofil wird das mit "halbwegs bezahlbar" in Konflikt geraten; MS dreht derzeit an allen Fronten sehr heftig an den Lizenz-Daumenschrauben. Ich werde in den nächsten 12 Monaten vermutlich ein Datenbankprojekt aus genau diesen Gründen auf Firebird migrieren, genauer Zeitpunkt steht allerdings noch nicht fest.
Troll schrieb: > Nächste Frage: > Hast du Ahnung von SQL, sodass du die Abfragen optimiert stellen kannst? Sehr indiskret :-))) Es reicht für die Sachen die ich brauche. Zum Glück ist hier im Dorf noch einer der das richtig kann. A. K. schrieb: > Nicht die Anzahl Records zählt, sondern was man damit macht. Eigentlich ist es eine recht einfache Sache ohne komplexe Abfragen: "Suche mir einen Beleg mit Kundennummer xy im Mai 2012" oder so. Vernüpfte tables habe ich nur recht wenige. Also wären ernstzunehmende Kandiaten: * mySQL * M$ SQL * firebird * postgres Da werde ich mal stöbern ... Danke !
Joachim Drechsel schrieb: > Also wären ernstzunehmende Kandiaten: > > * mySQL > * M$ SQL > * firebird > * postgres > > Da werde ich mal stöbern ... warum sieht du den MS-SQL Server nicht als alternative? Die Express version ist kostenlost. Und wenn es wirklich mal sehr viele mehr daten werden sollte, kann man dann immer noch die die große Version wechseln. Wir haben im SQL-Server in einigen Tabellen >200mil datensätze und DB-Größer mit über 200GB. Wenn es gerade nicht unter "nicht Windows" laufen soll, dann würde ich nur noch den SQL-Server vewenden.
Peter II schrieb: > warum sieht du den MS-SQL Server nicht als alternative? Ist doch in der Liste ...
Das können alle Datenbanken. Und zwar schnell, wenn man der Datenbank entsprechend passende Indexe definiert. Microsoft SQL Server Express gibts kostenlos wenn die Datenbank nicht größer als 10GByte wird. Die Express Version ist weiter dahin beschränkt, daß sie nur 1 Prozessorkern nutzt und nicht mehr als 1GByte Ram. Damit kann man aber mit kleineren Anwendungen gut leben.
Schorsch schrieb: > Oracle DB ist auch kostenlos Jepp, aber die ist noch etwas "gewöhnungsbedürftiger" als SQL Server. Und schon der SQL Server kann jemanden etwas verwirren, der noch nix mit 'richtigen' Datenbanken zu tun hatte.
Beachte, dass MySQL inzwischen Oracle gehört. Wie Oracle mit seinen zugekauften Projekten umgeht, sieht man ja bei Java. Auch Oracles eigene Datenbank zeigt: Aus sicherheitstechnischer Sicht ist Oracle-Software nicht tragbar. Mit MariaDB gibt es aber einen Ableger von MySQL, dem man seine Daten besser anvertrauen kann, falls man überhaupt MySQL will. PostgreSQL wird da ja von vielen bevorzugt.
Udo Schmitt schrieb: > Jepp, aber die ist noch etwas "gewöhnungsbedürftiger" als SQL Server. > > Und schon der SQL Server kann jemanden etwas verwirren, der noch nix mit > > 'richtigen' Datenbanken zu tun hatte. ;-) Jo, Oracle ist vielleicht Overkill für 'nen Anfänger, Profis schwören drauf. Ich wollte Oracle DB nur erwähnt haben, weil ich's nicht schlecht find.
Muss es eine relationale sein? Ansonsten würde ich mir noch bspw. CouchDB, Hibari oder Apache Cassandra ansehen oder mal testen.
Relational sollte sie schon sein. Die Geschichte mit Java und Oracle schreckt mich auch ein wenig ab. Das System sollte für min 10 Jahre (ges. Aufbewahrungszeitraum) laufen. dh es müßte langfristig auch Support verfügbar sein. Nachdem ich da bei dBASE IV mal so richtig auf die Schnauze geflogen bin, bin ich da leicht mißtrauisch bei solchen Sachen wie mariaDB etc.
Schorsch schrieb: > Oracle DB ist auch kostenlos Aber nur single-seat development license, nicht wenn man sie in production einsetzt, oder ? Hab da vor Jahren mal gestöbert und da war die Lizenz noch so. Und die normalen Lizenzen sind nicht wirklich preiswert. Grüße Andreas
Oracle ist etwas für Leute, die erst einmal einige Zeit ins System reinstecken wollen, bevor ihnen das System diese Zeit vielleicht wieder zurück gibt. MS-SQL ist einfacher im Umgang, aber hier wird die Express-Version an ihre Grenzen stossen, 10GB sind zu knapp.
A. K. schrieb: > MS-SQL ist einfacher im Umgang, aber hier wird die > Express-Version an ihre Grenzen stossen, 10GB sind zu knapp. je DB. Dann lege halt einfach je tabelle eine DB an. für das verjoinen spielt es keine rolle. Constraints gehen dann nur nicht.
Joachim Drechsel schrieb: > Das System sollte für min 10 Jahre (ges. Aufbewahrungszeitraum) laufen. > dh es müßte langfristig auch Support verfügbar sein. Dann musst du was kaufen und auch upgraden, sonst kannst du offiziellen Support knicken!
Peter II schrieb: > A. K. schrieb: >> MS-SQL ist einfacher im Umgang, aber hier wird die >> Express-Version an ihre Grenzen stossen, 10GB sind zu knapp. > > je DB. Dann lege halt einfach je tabelle eine DB an. für das verjoinen > spielt es keine rolle. Constraints gehen dann nur nicht. Das ist ja wohl mal crap++ Ich denke mit Postgresql oder mysql macht man an der stelle nichts verkehrt.
Peter II schrieb: > warum sieht du den MS-SQL Server nicht als alternative? Die Express > version ist kostenlost. Die maximale Datenbankgröße ist bei der Express-Version begrenzt. Zwar wurden im Eingangsposting gewünschte "Record"-Anzahlen genannt, aber nicht deren Größe. Bei 2012 liegt das Limit bei (immerhin( 10 GByte, bei älteren Versionen war es teilweise deutlich weniger. Was gegen den MS SQL-Server spricht, ist das Lizenzmodell, das direkt von der Anzahl der darauf zugreifenden Benutzer abhängt. Einen MS SQL-Server "ins Internet" zu hängen kann so sehr, sehr viel Geld kosten.
Rufus Τ. Firefly schrieb: > Was gegen den MS SQL-Server spricht, ist das Lizenzmodell, das direkt > von der Anzahl der darauf zugreifenden Benutzer abhängt. Einen MS > SQL-Server "ins Internet" zu hängen kann so sehr, sehr viel Geld kosten. Der Server kennt doch bei einem CGI-Programm nur einen Benutzer, nämlich das Programm was ihn abfragt ?
Rufus Τ. Firefly schrieb: > Was gegen den MS SQL-Server spricht, ist das Lizenzmodell, das direkt > von der Anzahl der darauf zugreifenden Benutzer abhängt. Den gibts auch in einem Lizenzmodell, in dem der Prozessor lizenziert wird, nicht der darauf zugreifende User.
D. I. schrieb: > Ich denke mit Postgresql oder mysql macht man an der stelle nichts > verkehrt. gehen denn in mysql mittlerweile check-constraints oder werden sie nur von Syntax unterstützt? Oder ein sinnvollen backup ohne Dumpen der datenbank? Wenn dann überhaupt Postgresql.
Joachim Drechsel schrieb: > Der Server kennt doch bei einem CGI-Programm nur einen Benutzer, > nämlich das Programm was ihn abfragt ? dann brauchst du die Web Lizens.
Peter II schrieb: > Joachim Drechsel schrieb: >> Der Server kennt doch bei einem CGI-Programm nur einen Benutzer, >> nämlich das Programm was ihn abfragt ? > > dann brauchst du die Web Lizens. Das weiß doch die DB gar nicht (wo der Kram hingeht) ;)
Joachim Drechsel schrieb: > Der Server kennt doch bei einem CGI-Programm nur einen Benutzer, > nämlich das Programm was ihn abfragt ? Solche Feinheiten interessieren Microsoft nicht. Wenn man sich auf eine benutzerabhängige Lizenz einlässt, dann ist nicht der drauf direkt zugreifende Benutzer relevant, sondern es zählen auch jene User, die indirekt über ein Zwischensystem darauf zugreifen. Das bedeutet beispielsweise, dass ein DB-Server, auf den ein öffentlicher Webserver zugreift, mit einer benutzerabhängigen Lizenz nicht machbar ist. Auch wenn der Webserver nur einen festgelegten Benutzer verwendet.
Rufus Τ. Firefly schrieb: > Was gegen den MS SQL-Server spricht, ist das Lizenzmodell, das direkt > von der Anzahl der darauf zugreifenden Benutzer abhängt. Nein bzw. je nach Version: Die Enterprise wird afaik nur noch per Core lizenziert, BI per CAL und bei der Standard geht beides. http://www.microsoft.com/en-us/sqlserver/get-sql-server/how-to-buy.aspx > Einen MS > SQL-Server "ins Internet" zu hängen kann so sehr, sehr viel Geld kosten. Wer eine Datenbank direkt ans Internet hängt, hat andere Probleme...
Arc Net schrieb: > Wer eine Datenbank direkt ans Internet hängt, hat andere Probleme... Daß ich natürlich den Betrieb im Rahmen eines Webservers meine, egal wie im einzelnen angebunden, sollte eigentlich schon irgendwie klar sein.
Wo ist das Problem MySQL zu benutzen. Vorteile: Opensource, gut dokumentiert ... etc. 200 Mio Records sind auch nicht die Welt, die Konfiguartion macht es. 1. Schau dir die verschiedenen DB-Engines an die MySQL anbietet, diese muss auch sorgfältig gewählt werden. 2. Datenbankstruktur! 3. Dann sind sparsame Abfragen natürlich das A&O -> JOINS vermeiden, Cachen etc. Als letztes wenn das alles nichts hilft -> DB-Cluster Mit MySQL auf einer Ramdisk holt man ebenfalls nochmal bis zu 30% raus, in manchen Fällen aber gar nicht geeignet ;), aber immer eine Überlegung Wert. Gruß Knecke
Postgresql oder Mysql ist schon die richtige Wahl. Wenn du wirklich Geld in die Hand nehmen kannst, schau auch mal auf Oracle oder DB2 (für letztere ist dann ein Hardwarebeschleuniger in Form einer AS/400 bzw. p-Series empfehlenswert). MariaDB ist ein Abkömmling von Mysql, der auf Durchsatz und Leistung getrimmt ist. Leider zeigt sich seit 12 Monaten immer mehr, daß der Support mit Patches gegenüber einem Mysql sehr zu wünschen übrig lässt. MS-Sql ist weder von den Kosten, noch vom Durchsatz für deine Zwecke (Meisst SELECT, UPDATE, INSERT, ggf JOINs) sinnvoll bzw konkurrenzfähig. Klar werden auf so eine Aussage einem Studien um die Ohren gehauen, die alle besagen, MSSQl sei "billiger + leistungsfähiger*) wobei das Kleingeduckte beim Sternchen dann völlig abwegige spezielle Fälle meint wie 'Schneller, wenn CPU mit 400 % übertaktet+ alle Daten der 5Kbyte "großen" DB im 1st-Level-cache eines CPU-Kerns' etc. :) Und zum Schluß schau mal, von welchen Werbeargenturen diese "Studien" gemacht wurden... Vergiß nicht: als Inet-Anwendung wirst du sehr wahrscheinlich die meißten SQL-Anfragen aus PHP, oder Javascript o.ä. machen. da ist die Verbindung Scriptsprache->SQL-DB am ehesten für Mysql & Co. ausgelegt bzw. getestet.
Adabas. Weiß gar nicht so recht, ob es die noch gibt. War vor 20 Jahren mal neben den gebräuchlichen Namen sehr interessant und damals in vielen Bereichen viel leistungsfähiger als die anderen. Frag mich nicht genau, ist lange her und ich würde vermutlich nicht mal mehr meine eigenen Sachen lesen können.
Alexander V. schrieb: > 3. Dann sind sparsame Abfragen natürlich das A&O -> JOINS vermeiden, > Cachen etc. alles wo es mehr als eine Spielzeug DB werden soll wird mit joins gemacht. durch das Normalisieren veringert sich die Datenmege. Damit wird weniger IO und RAM gebraucht. Und das Joinen der Zeilen kosten nur etwas CPU.
Falls Du bisher auch ohne die Abfrageflexibiliät und Multiuserfähigkeit einer SQL-DB ausgekommen bist, könnte unter Windows das hier noch eine Alternative sein: http://msdn.microsoft.com/en-us/library/windows/desktop/gg269259(v=exchg.10).aspx
Ich muss sagen von all den Lösungen habe ich nur mit MS-SQL Erfahrung, und ich muss sagen, lass die Finger davon. Zumindest damals war es noch ganz normal das der Server einfach mal mit der Fehlermeldung "Logdatei voll" seinen Dienst quittiert. Die Lösung ist dann, ein Backup zu machen, eine Datei zu löschen, und das Backup wieder zurück zu spielen. Betriebssicher ist das nicht. Wenn schon SQL, dann nimm halt MySQL, das wurde immerhin schon mal in großen Installationen benutzt. Natürlich darfst Du nicht vergessen die Datenbank zu optimieren. Indizes sind bei so vielen Datenfeldern Pflicht. SQL ist aber inzwischen nicht mehr Pflicht, es gibt auch Alternativen für weniger strukturierte Daten. Das läuft dann unter den Label "NoSQL". Da hast Du dann zum Beispiel Datenbankobjekte die keine festen Eigenschaften haben.
Joachim Drechsel schrieb: > Relational sollte sie schon sein. > > Die Geschichte mit Java und Oracle schreckt mich auch ein wenig ab. > Das System sollte für min 10 Jahre (ges. Aufbewahrungszeitraum) laufen. > dh es müßte langfristig auch Support verfügbar sein. Unter diesem Kriterium würde ich mir Windows-basierte Lösungen bzw. Microsoft-Produkte ganz schnell aus dem Kopf schlagen. http://www.heise.de/newsticker/meldung/MS-Office-2013-Lizenz-auf-Gedeih-und-Verderb-an-einen-PC-gebunden-1805255.html Wer weiß, was da noch kommt.
Sven P. schrieb: > Unter diesem Kriterium würde ich mir Windows-basierte Lösungen bzw. > Microsoft-Produkte ganz schnell aus dem Kopf schlagen. Dann wird auch bestimmt MS-SQL per Kacheln konfiguriert ... Im Moment ist die "komplizierteste" db in der 1. Normalform, also nichts dramatisches. Kunden können von uns revisionsfeste CD/DVD bekommen, da ist SQLIte natürlich ideal weil ich überall die gleiche db verwenden kann. Das müßte mit mySQL aber auch gehen (ich habe die Website mal überflogen). Eigentlich bleiben nur PostgreSQL und mySQL übrig ?
Joachim Drechsel schrieb: > Eigentlich bleiben nur PostgreSQL und mySQL übrig ? Wenn du bei etwas ähnlichem wie SQLite bleiben willst könntest du auch H2 oder Derby verwenden. H2 kann man auch im "Server-mode" außerhalb von Java Anwendungen nutzen und laut der mailing list nutzen das auch viele für "große Datenmengen". Vorteil wäre, dass du wieder alles in einer Datei hast. Alles hängt aber von deinem Einsatzzweck ab. Wenn du nur schreiben willst (also kein Löschen oder Update) bietet MySQL z.B. eine komprimierende Archivdatenbank Engine an, das wäre ggf. auch ein Vorteil. Wenn du bisher mit SQLite ausgekommen bist, ist vermutlich alles eine alternative und "groß" relativ.
Ich würde ja gerne bei SQLite bleiben, es ist genial einfach einzubinden, Null Aufwand für die Administration und mir pfuscht keiner rein. Am Besten hat mir die damalige Novell-"Zugabe" Btrieve gefallen. Sehr klein, schnell und zuverlässig (Test: zB dem Novell Server beim Import den Stecker gezogen. 3mal hintereinander - kein Datenverlust). Keine festen Datentypen, was reinging ging auch wieder heraus ;) Leider heißt das heute Pervasive SQL und ist unverschämt teuer. Die Standalone-Anwendungen sind eigentlich unkritisch. Ich habe eine Tabelle. Ob ich die als Textfile in den Speicher lade oder als SQL-DB ist eigentlich egal ...
Joachim Drechsel schrieb: > Eigentlich bleiben nur PostgreSQL und mySQL übrig ? Warum ist Dir Firebird aus der Aufzählung verschwunden?
Sven P. schrieb: > Unter diesem Kriterium würde ich mir Windows-basierte Lösungen bzw. > Microsoft-Produkte ganz schnell aus dem Kopf schlagen. > http://www.heise.de/newsticker/meldung/MS-Office-2... > Wer weiß, was da noch kommt. man kann ihn JETZT kostenlos laden und auch noch in 10Jahren verwenden. Er muss ja nicht auf die nächste Version mit andere Bedingungen updaten. Christian Berger schrieb: > Ich muss sagen von all den Lösungen habe ich nur mit MS-SQL Erfahrung, > und ich muss sagen, lass die Finger davon. Zumindest damals war es noch > ganz normal das der Server einfach mal mit der Fehlermeldung "Logdatei > voll" seinen Dienst quittiert. Klar wenn man eine maximal größer der DB anlegt dann kommt man immner an die grenze. Und wer eine DB betreibt sollte sich ein wenig damit beschäftigen. Eine MS-DB geht dabei aber nicht kaputt. Man verkleiner dann einfach die Log-Datei wieder und gut ist. Wenn man sich ein nicht ein loggen kann, dann gibt es immer noch die DAC (Dedizierte Admin Connection) die geht immer. > Betriebssicher ist das nicht. Wenn leute von dem Server keien Ahnung haben, dann bekommen sie auch mit anderen Produketen probleme > Wenn schon SQL, dann nimm halt MySQL, das wurde immerhin schon mal in > großen Installationen benutzt. Natürlich darfst Du nicht vergessen die > Datenbank zu optimieren. Indizes sind bei so vielen Datenfeldern > Pflicht. SQL-Server spielt in einer ganz ander Liga als MySQL. Wenn man wirklich mehr also nur abfragen machen will, dann lernt man die unterschiede kennen. (Transkationsverhalten, BulkOperationen, Diagnosemöglichekeiten, Event-Tracing, Serverübergreifen Joins.) Es gibt schon gründe warum meist DB2, Oracle und MS-SQL zusammen genannt werden. Und dann als nächste gruppe MySQL und Posgress. Ich finde mysql auch ganz nett unter linux, aber wenn ich weiss das es unter Windows laufen soll und mit die begrenzungen von der Express-Version ausreichen dann nehme ich unter Windows den SQL-Server. Und das Orcale in MySql mit drin hängt finde ich auch nicht gut, dann doch lieber Postgrql.
Rufus Τ. Firefly schrieb: > Joachim Drechsel schrieb: >> Eigentlich bleiben nur PostgreSQL und mySQL übrig ? > Warum ist Dir Firebird aus der Aufzählung verschwunden? ich habe ein paar kunden die in einer Anwendung Firebird verwenden, irgendwie kann ich nicht glauben das er wirklich mit 200Mil datensätzen klarkommt. Dort sind Datenbanken mit 900Mbyte im Einsatz und abfragen gehen nicht wirklich schnell. Auch ein wirklichens Cache von Abfragen und daten kann ich nicht beobachten. Der Ramverbaucht ist immer nur ein paar MB. Mann kann zwar in der config die Puffergrößen anpassen aber das ist irgend auch nicht der bringer. Bei vielen Verbindungen geht einem schnell der speicher aus. Und es scheinen noch Bugs aus der Borland Zeit vorhanden zu sein. Man schafft es regelmäig eine doppelete Zeile in einem Uniqe Key anzulegen. Was dann zu merkwürdigen abfragen führt. Oder auch eine NULL in einer not NULL spalte.
Christian Berger schrieb: > Ich muss sagen von all den Lösungen habe ich nur mit MS-SQL Erfahrung, > und ich muss sagen, lass die Finger davon. Zumindest damals war es noch > ganz normal das der Server einfach mal mit der Fehlermeldung "Logdatei > voll" seinen Dienst quittiert. Die Lösung ist dann, ein Backup zu > machen, eine Datei zu löschen, und das Backup wieder zurück zu spielen. > Betriebssicher ist das nicht. Die "Logdatei" ist das Transaktionsprotokoll. Damit kann man einzelne Transaktionen rückgängig machen, beschädigte Datenbanken reparieren oder eine Teilwiederherstellung vornehmen, ohne daß jedesmal die komplette Datenbank restored werden muß. Es kann durchaus größer werden als die eigentliche Datenbank und muß regelmäßig geleert bzw. abgeschnitten werden. Es ist jedoch Aufgabe des Anwendungsprogrammierers, dafür zu sorgen. Man kann auch das Wiederherstellungsmodell auf "Einfach" setzen, dann bleibt das Log automatisch klein, aber die vorgenannten Vorteile sind nur noch sehr eingeschränkt gegeben. Lizenzierung macht nur als "per CPU" bzw. "per Core" Sinn, wenn eine unbestimmte Zahl User zugreifen sollen. Kostet dann aber einige 1000€.
Peter II schrieb: > man kann ihn JETZT kostenlos laden und auch noch in 10Jahren verwenden. Wenn man auch darauf verzichtet, das darunterliegende Betriebssystem zu aktualisieren, und wenn die Hardware, auf der das ganze läuft, auch überlebt. Ob nämlich ein heute verkauftes Windows sich noch auf in zehn Jahren verkaufter Hardware sinnvoll installieren lässt, wage ich zu bezweifeln.
Rufus Τ. Firefly schrieb: > Peter II schrieb: >> man kann ihn JETZT kostenlos laden und auch noch in 10Jahren verwenden. > > Wenn man auch darauf verzichtet, das darunterliegende Betriebssystem zu > aktualisieren, und wenn die Hardware, auf der das ganze läuft, auch > überlebt. Ob nämlich ein heute verkauftes Windows sich noch auf in zehn > Jahren verkaufter Hardware sinnvoll installieren lässt, wage ich zu > bezweifeln. Und wenn die Lizenzpolitik weiter verfolgt wird, dann musst du sogar den Rechner konservieren... Da hat sich in letzter Zeit so eine Handvoll Hersteller angesammelt, um die ich allesamt einen weiten Bogen machen würde. Dazu gehört nicht nur Microsoft, sondern auch Adobe und Oracle. Deren neuerliche Politik wäre mir persönlich viel zu unzuverlässig.
Hardwareeinsatz auf 10 Jahre zu planen ist durchaus möglich, entsprechende Wartungsverträge sind bei den major brands kein Problem.
Rufus Τ. Firefly schrieb: > Wenn man auch darauf verzichtet, das darunterliegende Betriebssystem zu > aktualisieren, und wenn die Hardware, auf der das ganze läuft, auch > überlebt. Ob nämlich ein heute verkauftes Windows sich noch auf in zehn > Jahren verkaufter Hardware sinnvoll installieren lässt, wage ich zu > bezweifeln. das sich auf aktuellen PC auch ein Office2000 noch installieren lässt, kann man wohl davon ausgehen das auch ein 10Jahen auf einem Aktuellen PC der SQL-Server 2012 Express sich auch noch installieren lässt. Ob es in 10 Jahren MySQL nocht gibt, kann auch niemand mit gewissheit sagen. Und nur weil der Quelltext frei ist, heist das nicht das es sich in der nächsten compiler version ohne anpassung übersetzen läst.
Peter II schrieb: > das sich auf aktuellen PC auch ein Office2000 noch installieren lässt, Auf einen aktuellen Server, also einen mit Sandy Bridge EP, kriegst du ohne Klimmzüge kein Windows 2003 mehr drauf.
A. K. schrieb: > Auf einen aktuellen Server, also einen mit Sandy Bridge EP, kriegst du > ohne Klimmzüge kein Windows 2003 mehr drauf. es ging um Office.
Peter II schrieb: > es ging um Office. Rufus hatte das Betriebssystem als Problem erwähnt, du hattest darauf mit Office geantwortet und ich hatte den Ball wieder zum Betriebssystem zurück gespielt.
Peter II schrieb: > das sich auf aktuellen PC auch ein Office2000 noch installieren lässt, > kann man wohl davon ausgehen das auch ein 10Jahen auf einem Aktuellen PC > der SQL-Server 2012 Express sich auch noch installieren lässt. Ähm, nein. Schon auf heutigen PCs ist es schwierig Office 2000 zum Laufen zu bekommen, da es Windows verlangt. Und falls jetzt ARM populär wird ist es aus mit der Kompatibilität, dann reicht ein virtualisiertes Windows nicht mehr aus, dann musst Du wirklich einen Emulator laufen lassen. Bei MySQL kann man immer einen Programmierer anheuern der einfach die kleinen Änderungen für den Compiler macht, falls jetzt plötzlich die MySQL Community sich irgendwie auflöst.
Was langfristigen Einsatz von Systemen auf möglicherweise ändernder Hardware angeht, würde ich heute auf VMware setzen. Kostenloses ESXi drauf und darin einen Server der Wahl installieren. Das Gastsystem kann darin sehr langfristig und stabil bleiben, ggf. ewig auf dem gleichen Stand eingefroren, auch wenn man irgendwann das ESXi zusammen mit der Hardware aktualisiert.
A. K. schrieb: > Datum: 23.02.2013 11:31 > Peter II schrieb: >> es ging um Office. > Rufus hatte das Betriebssystem als Problem erwähnt, du hattest darauf > mit Office geantwortet und ich hatte den Ball wieder zum Betriebssystem > zurück gespielt. es doch darum das jeman bedenken hatte das die aktuelle Expressversion vom SQL-SQL in ein paar jahren auf einem neuen PC nicht läuft. Das es sich hierbei um eine anwendung handelt habe ich nur als Beispiel das Office erwähnt was auch nach 10 Jahren noch auf einem aktuellen PC lauffähig ist.
Christian Berger schrieb: > Bei MySQL kann man immer einen Programmierer anheuern der einfach die > kleinen Änderungen für den Compiler macht, falls jetzt plötzlich die > MySQL Community sich irgendwie auflöst. aber ob das biliger ist als ein fertige Produkt zu kaufen, würde ich doch stark bezweifeln. Ist ja nicht so das der SQL-Server ein unbedeutendes Produkt einer kleinen Firma ist. Dieser läuft auf x86, ia65, x64 und der ARM platform.
Peter II schrieb: > Ist ja nicht so das der SQL-Server ein unbedeutendes Produkt einer > kleinen Firma ist. Ist ja nicht so als ob diese nicht-kleine Firma ihre nicht-unbedeutenden Produkte nicht auch nach einer Weile einstellt. Siehe Silverlight, Windows for Pen Computing, DCOM (damit läuft ziemlich viel in der Automatisierungstechnik) oder Word Basic über OLE Automatisation. (Damit konnte man früher Office für Windows fernsteuern. Und selbst wenn, der MS-SQL-Server ist nicht nur langsamer als die ganze Konkurrenz, sondern er skaliert auch nicht. Du kannst den nicht einfach auf einer großen Kiste laufen lassen, weil auf der großen Kiste kein Windows läuft.
Christian Berger schrieb: > Du kannst den nicht einfach > auf einer großen Kiste laufen lassen, weil auf der großen Kiste kein > Windows läuft. Ich hatte bisher nicht den Eindruck, dass das beschriebene Problem in einer Leistungsregion läge, die sich mit Windows-Systemen nicht abdecken liesse. Aber darin hast du natürlich Recht. In solchen Regionen ist man beispielsweise mit Oracle Enterprise gut bedient, da sich damit auch einzelne Anfragen lastmässig auf Prozessoren und Systeme verteilen lassen. Die paar Banken, die man für solche Hard- und Software vorher ausrauben muss, sollten dann auch kein Problem mehr darstellen.
Zu Firebird: Ich kenne eine Installation, die hat inzwischen knapp 70 Gigabyte, in einer Tabelle sind mehrere Hundert Millionen Datensätze drin, und das Teil läuft trotzdem recht flott. Ist noch ein Firebird 2.1
Christian Berger schrieb: > Und selbst wenn, der MS-SQL-Server ist nicht nur langsamer als die ganze > Konkurrenz, sondern er skaliert auch nicht. Du kannst den nicht einfach > auf einer großen Kiste laufen lassen, weil auf der großen Kiste kein > Windows läuft. im vergleich zu was? ein paar 100GB ram ist auch mit Windows kein Problem. Wenn es noch größer dann ist aber auch von MySQL keine rede mehr. Ich habe schon OralceAdmins aus MSSQL-Server umschenken sehen, sie haben ein einfach nicht hinbekommen in oracle sinnvolle laufzeit bei gewissen abfragen zu erreichen. Nach Umstellng auf MS-SQL lieft es ohne Probleme auf der gleiche Hardware. Und er war begeistern wie einfach einige Dinge dort zu machen sind. Wenn es um mittelgroße Datenbanken geht, nehmen sich DB2, Oracle und MS-SQL nicht viel - das das denn mehr politische Entscheidungen. Ich denke bei der Skalbarkeit und funktionaltiät wird die Reihenfolge wohl folgende sein Firebird Mysql Postgresql MS-SQL DB2 Oracle
Peter II schrieb: > Wenn es noch größer dann ist aber auch von MySQL keine rede > mehr. Ich behaupte mal bei FB sinds noch ein paar mehr Daten...
Außerdem geht es hier um die Ablösung einer simplen Filebasierten SQLite Datenbank und nicht um einen mehrere TB fassenden Datastore. Die Kosten als auch die Einsteigshürden sind doch völlig überzogen hierfür, und gerade Oracle ist echt ein Krampf den ich keinem Empfehlen kann der "nur mal eine etwas größere Datenbank" betreiben möchte... MSSQL ist auch nicht gerade eine Administrative Freude, DB2 kenn ich nun nicht "persönlich". Und was in 10 Jahren ist kann man eh nicht so genau sagen, wenn es bisher SQLite getan hat sind irgendwelche subtilen Befürchtungen MySQL (welches weltweit auf Millionen Webservern läuft) würde von heute auf morgen "verschwinden" bloß weil man Oracle nicht mag doch total daneben...
Läubi .. schrieb: > Außerdem geht es hier um die Ablösung einer simplen Filebasierten SQLite > Datenbank und nicht um einen mehrere TB fassenden Datastore. Im Moment pro Kunde und Jahr > 700 GB bei steigender Tendez,
Ich kann dir nur empfehlen, installiere dir die Produkte, pack die Daten rein und entscheide dann selbst. Falls etwas dann unklar ist oder nicht funktioniert einfach nochmal eine Frage eröffnen. Probieren geht über studieren!
Noch als Hinweis: MySQL hat keinerlei Probleme mit riesigen Datenbanken. Siehe Wikipedia, deren Datenbanken viele, viele Terabytes beinhalten. Bei jeder Bearbeitung wird der komplette Artikeltext neu gespeichert.
T.roll schrieb: > Noch als Hinweis: > MySQL hat keinerlei Probleme mit riesigen Datenbanken. Siehe Wikipedia, > deren Datenbanken viele, viele Terabytes beinhalten. dort geht es aber "nur" um menge. Sicher Transaktionsverhatlen, mehre 100 Tabellen die verjoint werden müssen und eine großartiges Rechtesystem sind dort nicht notwendig.
Peter II schrieb: > 100 Tabellen die verjoint werden müssen und eine großartiges > Rechtesystem sind dort nicht notwendig. Hier erklärtermassen auch nicht.
Christian Berger schrieb: > Peter II schrieb: >> Ist ja nicht so das der SQL-Server ein unbedeutendes Produkt einer >> kleinen Firma ist. > > Ist ja nicht so als ob diese nicht-kleine Firma ihre nicht-unbedeutenden > Produkte nicht auch nach einer Weile einstellt. Siehe Silverlight, Silverlight an sich, ja. Die Technik, Tools etc. sind immer noch da bzw. Bestandteil von W8, WP7/8 > Windows for Pen Computing, Heißt zwar nicht mehr so bzw. sind die Funktionen in jedem Windows seit Vista integriert (wenn man so will, ist das jetzt 22 Jahre lang verfügbar...) > DCOM (damit läuft ziemlich viel in der > Automatisierungstechnik) OPC? Broken by design, da hätte auch die damals angesagte DCOM-Alternative CORBA nichts geändert. > oder Word Basic über OLE Automatisation. (Damit > konnte man früher Office für Windows fernsteuern. Was soll da nicht mehr funktionieren? > Und selbst wenn, der MS-SQL-Server ist nicht nur langsamer als die ganze > Konkurrenz, sondern er skaliert auch nicht. Du kannst den nicht einfach > auf einer großen Kiste laufen lassen, weil auf der großen Kiste kein > Windows läuft. Sprach der IBM-Verkäufer und verkaufte DB2 für Itanium-Server... Warum nutzen wohl Google, Facebook, MS und andere keine "großen Kisten"... MS-SQL ist die Basis für extrem unterschiedliche Systeme, ob das einige 100 Petabyte sind (Hotmail), Echtzeit-BI oder hochverfügbare Anwendungen sind.
Peter II schrieb: > Sicher Transaktionsverhatlen, mehre > 100 Tabellen die verjoint werden müssen und eine großartiges > Rechtesystem sind dort nicht notwendig MySQL unterstützt sowohl Transaktion (mit der passenden Engine) als auch mehrere "verjointe" Tabellen, und man kann relativ fein die Rechte pro Schema steuern ... kriegst du eigentlich Geld dafür andere DB Systeme schlecht zu reden?
Läubi .. schrieb: > MySQL unterstützt sowohl Transaktion (mit der passenden Engine) als auch > mehrere "verjointe" Tabellen, und man kann relativ fein die Rechte pro > Schema steuern ... kriegst du eigentlich Geld dafür andere DB Systeme > schlecht zu reden? wo habe ich geschrieben das das mit MySql nicht geht? Ich habe nur geschrieben das es noch mehr punkte als die Datenmenge gibt die man beachten sollte.
IBM DB2 Express-C läuft auf allen möglichen Plattformen. In der Communityversion für bis zu 2 Kerne und 2GB RAM kostenfrei, Größe der Datenbanken unbegrenzt. http://db2express.com/de/ Hat auch gute Unterstützung für die Anbindung an .NET, Java, C++, PHP... Ist auf z. B. Linux oder Windows in 5-10 Minuten installiert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.