Suche SQL-Datenbank für große Datenmengen

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

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 !

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.

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.

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:
> 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.

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

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.

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.

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?

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.

Hardwareeinsatz auf 10 Jahre zu planen ist durchaus möglich, 
entsprechende Wartungsverträge sind bei den major brands kein Problem.

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.

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.

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

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!

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?