3rd Party Storage Engines (infobright, nitroedb)

Hallo,
hat jemand bereits Erfahrungen mit einer der Engines (Infobright oder
Nitroedb) sammeln können?

Christian

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas Kretschmer wrote:

> Sprüche wie:
>
> "Durch ... Verzicht auf Indizes ... auf handelsüblicher Hardware ...
> beispielslos niedrige Datenbankbetriebskosten" ^¹
>
> klingen ja schon mal interessant.

Hey, das kommt mir bekannt vor, ich hab diese Woche ein Whitepaper von
Netezza gelesen, da hiess es auch sinngemäß:
"bei anderen Data Warehouse Systemen braucht man teure Schulungen allein
für die Implementierung der verschiedenen Indizes. Bei uns braucht man
das nicht, da gibt's keinen Index."
Man muss eben alles nur positiv darstellen :-)

Dieter

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas Kretschmer wrote:
> begin Christian Schmelzer wrote:
>> Hallo,
>> hat jemand bereits Erfahrungen mit einer der Engines (Infobright oder
>> Nitroedb) sammeln können?
>
> Hast Du denn welche? Berichte doch mal!
>
>
> Sprüche wie:
>
> "Durch ... Verzicht auf Indizes ... auf handelsüblicher Hardware ...
> beispielslos niedrige Datenbankbetriebskosten" ^¹
>
> klingen ja schon mal interessant.
>
>
> ^¹
> http://www.mysql.de/why-mysql/application-scenarios/data-war ehouse.html
>
>
> end
> Andreas

Hallo,
nein, ich habe eben noch keine Erfahrungen. Scheinbar kann man es auch nicht
so runterladen und testen. Daher ja auch meine Frage ob jemand die mal
getestet hat. Wenn dann rauskommt dass es nicht funktioniert oder Quatsch
ist, könnte man sich die Arbeit sparen.

Christian

Re: 3rd Party Storage Engines (infobright, nitroedb)

"Christian Schmelzer" wrote:
>> Christian Schmelzer wrote:

>>> hat jemand bereits Erfahrungen mit einer der Engines (Infobright oder
>>> Nitroedb) sammeln können?

> nein, ich habe eben noch keine Erfahrungen. Scheinbar kann man es auch nicht
> so runterladen und testen. Daher ja auch meine Frage ob jemand die mal
> getestet hat. Wenn dann rauskommt dass es nicht funktioniert oder Quatsch
> ist, könnte man sich die Arbeit sparen.

Muß ich das verstehen? Wenn man es sowieso nicht runterladen kann,
was nützen dann Erfahrungen aus dritter Hand?

Anderseits *gibt* es freie 3rd Party Engines, z.B. PBXT. Hat ein
Freund mal getestet und war recht angetan.


XL

Re: 3rd Party Storage Engines (infobright, nitroedb)

Christian Schmelzer schrieb:

> Andreas Kretschmer wrote:
>
>> Sprüche wie:
>>
>> "Durch ... Verzicht auf Indizes ... auf handelsüblicher Hardware ...
>> beispielslos niedrige Datenbankbetriebskosten" ^¹
>>
>> klingen ja schon mal interessant.

.... und lassen Schlimmstes befürchten.

> nein, ich habe eben noch keine Erfahrungen. Scheinbar kann man es auch nicht
> so runterladen und testen.

Nach der obigen Aussage kann man sich das ja wohl auch schenken.

Gruß. Claus

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas, heute mal MySQL verteitigend...
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas Kretschmer wrote:
> begin Claus Reibenstein schrieb:
>>>> Sprüche wie:
>>>>
>>>> "Durch ... Verzicht auf Indizes ... auf handelsüblicher Hardware ...
>>>> beispielslos niedrige Datenbankbetriebskosten" ^¹
>>>>
>>>> klingen ja schon mal interessant.
>>
>> ... und lassen Schlimmstes befürchten.
>
> Nun ja, ich kann Dir auch Sprüche in früheren MySQL-Dokumentationen
> zeigen, die einfach nur inhaltliche Katastrophen darstellen. Das geht
> bis dahin, daß RI als kontraproduktiv dargestellt wurde.

Je nach Umgebung *kann* das durchaus auch sein. Deadlocks (bzw. ganz
allgemein mehr Lock-Contention) bringt RI ja durchaus mit sich.
MyISAM im Gegenzug ist z.B. garantiert deadlock-frei.

Man sollte RI also nicht "aus Prinzip" und "weils ja geht" einsetzen,
sondern nur genau dann, wenn es nötig ist.

> Möglicherweise hat man ja tatsächlich da bahnbrechende Features,
> möglicherweise *braucht* man dann keine Dinge wie Indexe mehr.

Naja, "Data Warehousing" bedeutet ja u.A.

- es sind *richtig* viel Daten; Indizes passen sowieso nicht ins RAM
und auch die Pflege von Indizes ist saumäßig teuer.

- die Daten kommen aus gesicherten Quellen; Constraints sind also
nicht mehr notwendig. Hingegen ist es absolut notwending, daß die
Inserts (praktisch immer Bulk-Loads) schnell laufen.

- Queries sind adhoc; m.a.W. man weiß vorher *nicht* was für Queries
später mal kommen und kann daher auch nicht vorausschauend Indizes
anlegen um dann später schnell zu sein.

- Ausnahme zur vorherigen Regel: es wird ein Star-Schema benutzt, es
gibt *fette* Joins über den PK -> ein schneller PK lookup ist nett.


m.a.W. gibt es durchaus Gründe, bei reinen Data-Warehousing Engines
komplett auf Indizes zu verzichten. Zumindest auf Indizes im
herkömmlichen Sinn.


XL

Re: 3rd Party Storage Engines (infobright, nitroedb)

Axel Schwenke wrote:
> "Christian Schmelzer" wrote:
>>> Christian Schmelzer wrote:
>
>>>> hat jemand bereits Erfahrungen mit einer der Engines (Infobright oder
>>>> Nitroedb) sammeln können?
>
>> nein, ich habe eben noch keine Erfahrungen. Scheinbar kann man es auch nicht
>> so runterladen und testen. Daher ja auch meine Frage ob jemand die mal
>> getestet hat. Wenn dann rauskommt dass es nicht funktioniert oder Quatsch
>> ist, könnte man sich die Arbeit sparen.
>
> Muß ich das verstehen? Wenn man es sowieso nicht runterladen kann,
> was nützen dann Erfahrungen aus dritter Hand?

Es soll auch Leute geben, die bereit sind, ein Produkt zu kaufen ;-)

Resten oder Erfahrungsberichte einsammeln wäre in jedem Fall angebracht
und das soll hier offensichtlich geschehen.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas Scherbaum wrote:
> Axel Schwenke wrote:
>> "Christian Schmelzer" wrote:
>>>> Christian Schmelzer wrote:
>>
>>>>> hat jemand bereits Erfahrungen mit einer der Engines (Infobright
>>>>> oder Nitroedb) sammeln können?
>>
>>> nein, ich habe eben noch keine Erfahrungen. Scheinbar kann man es
>>> auch nicht so runterladen und testen. Daher ja auch meine Frage ob
>>> jemand die mal getestet hat. Wenn dann rauskommt dass es nicht
>>> funktioniert oder Quatsch ist, könnte man sich die Arbeit sparen.
>>
>> Muß ich das verstehen? Wenn man es sowieso nicht runterladen kann,
>> was nützen dann Erfahrungen aus dritter Hand?
>
> Es soll auch Leute geben, die bereit sind, ein Produkt zu kaufen ;-)
>
> Resten oder Erfahrungsberichte einsammeln wäre in jedem Fall
> angebracht
> und das soll hier offensichtlich geschehen.
>

Ja, genau darum geht es. Wenn es wirklich brauchbar ist, würden wir es auch
kaufen. Ich würde aber ungern vorher viel Arbeit reinstecken wenn andere
User vielleicht schon auf bekannte Probleme gestossen sind oder das Produkt
gar nicht funktioniert.

Christian

Re: 3rd Party Storage Engines (infobright, nitroedb)

Axel Schwenke schrieb:

> Andreas Kretschmer wrote:
>
>> begin Claus Reibenstein schrieb:
^^^^^^^

Er kann's immer noch nicht lassen ...

>> Nun ja, ich kann Dir auch Sprüche in früheren MySQL-Dokumentationen
>> zeigen, die einfach nur inhaltliche Katastrophen darstellen. Das geht
>> bis dahin, daß RI als kontraproduktiv dargestellt wurde.
>
> Je nach Umgebung *kann* das durchaus auch sein. Deadlocks (bzw. ganz
> allgemein mehr Lock-Contention) bringt RI ja durchaus mit sich.

s/Umgebung/Anwendung/

Die Umgebung hat sich nach der Anwendung zu richten, nicht umgekehrt.

> MyISAM im Gegenzug ist z.B. garantiert deadlock-frei.

Ein Grund, weshalb ich das nicht verwende.

> Man sollte RI also nicht "aus Prinzip" und "weils ja geht" einsetzen,
> sondern nur genau dann, wenn es nötig ist.

Und wenn es sinnvoll ist. Genau wie Indizes. Ein _genereller_ Verzicht
ist jedoch mit Sicherheit Unfug.

Ach ja: RI setzt Indizes voraus ...

Gruß. Claus

Re: 3rd Party Storage Engines (infobright, nitroedb)

Axel Schwenke wrote:

> Je nach Umgebung *kann* das durchaus auch sein. Deadlocks (bzw. ganz
> allgemein mehr Lock-Contention) bringt RI ja durchaus mit sich.
> MyISAM im Gegenzug ist z.B. garantiert deadlock-frei.

Und auch garantiert Transactions-frei :-)

> Naja, "Data Warehousing" bedeutet ja u.A.
>
> - es sind *richtig* viel Daten; Indizes passen sowieso nicht ins RAM
> und auch die Pflege von Indizes ist saumäßig teuer.

Solange man nicht einen großen Teil der gesamten Datenmenge braucht, ist
der Index-Zugriff immer noch viel effizienter, auch wenn der Index nicht
in's RAM passt. Und im Batch-Load ist die Indexpflege biliger.

> - die Daten kommen aus gesicherten Quellen; Constraints sind also
> nicht mehr notwendig. Hingegen ist es absolut notwending, daß die
> Inserts (praktisch immer Bulk-Loads) schnell laufen.

"Gesicherte Quellen", guter Witz. Das ist *das* Problem im DWH, Daten
kommen aus x verschiedenen Quellen und sind *nie* sauber.
Die Säuberung der Daten macht die Hauptarbeit beim Laden aus, egal ob
ich's jetzt im Ladeserver mache (der dazu auch Zugriff auf die DWH-Daten
braucht) oder lieber die Rohdaten lade und dann alles mit SQL im DWH.
Trotzdem hat man da kaum Checks oder Foreign Keys, da die im OLTP-System
einen sauberen Zustand zum jetzigen Zeitpunkt sicherstellen, im DWH hat
man aber eine Historie von Monaten oder Jahren und deshalb meistens eine
Versionierung der Daten.
Z.B. eine Row, die im Online-System schon längst gelöscht ist, kann/muss
im DWH immer noch referenziert werden. Referentielle Integrität geht
dann über eine Spalte plus ein Date/Timestamp, da ein bestimmter PK-Wert
nur eine bestimmte Zeitlang existiert hat:
child.spalte = parent.spalte
and child.datum between parent.von and parent.bis

> - Queries sind adhoc; m.a.W. man weiß vorher *nicht* was für Queries
> später mal kommen und kann daher auch nicht vorausschauend Indizes
> anlegen um dann später schnell zu sein.

Die meisten Queries sind auch im DWH immer noch Reports und die kann man
optimieren (selbst wenn irgendwelche BI-Tools doofes SQL erzeugen).
Die wenigsten End-User dürfen ad-hoc irgendwelche komplizierten Abfragen
schreiben, da ihr SQL dafür nicht gut genug ist :-)

Dieter

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: 3rd Party Storage Engines (infobright, nitroedb)

Andreas Kretschmer wrote:

> Im #IRC nannte mir ads heute Nacht noch diesen Link:
> http://www.dbms2.com/2007/10/22/infobright-brighthouse-mysql /

Dann ist es kein Wunder, dass es keine Indices gibt, da die Daten in
Spalten statt Rows gespeichert werden. Da gibt's noch andere DBMSe, die
das so machen, z.B. Sybase IQ.
Wenn's passt, ist das wirklich schnell, nur zuviele Spalten und Joins
darf man nicht in der Query haben :-)

> Ich dachte mir, es wäre kein Fehler, dies hier auch zu nennen.

Dbms2 lässt sich meistens ganz gut lesen, v.a. wenn wieder die "DWH
Appliances" Hersteller in den Comments aufeinander treffen:
"xxx können wir schon lange, ihr aber gar nicht, ätsch!"
"Weil wir's gar nicht brauchen, wir sind auch ohne schneller!"

Dieter