Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › IBM will Datenbanken beschleunigen

RDBMS können günstiger getuned werden

  1. Thema

Neues Thema Ansicht wechseln


  1. RDBMS können günstiger getuned werden

    Autor: SELECTOR 28.10.08 - 11:14

    Man muss nur den Controllern und vor allem den Marketing Heinis beibringen, das SAS (Ich meine die Software, nicht die Hardware) nicht das Maß aller Dinge ist. Dann müssen sie davon überzeugt werden, dass Flatfiles auch prima in die Datenbanken gedumped werden können. Wenn sie im nächsten Schritt noch lernen, wie man Indizes auf die Tabellen einrichtet, sind sie endlich mal wieder am arbeiten und nicht am warten.
    Wenn man ihnen dann auch noch die Augen öffnet und etwas von Views erzählt, anstatt jeden SELECT in eine neue Tabelle zu schreiben und darauf die nächste Abfrage zu führen, dann könnten wir unsere Terabyte-Server locker plattmachen und die Daten auf ein paar Disketten packen.
    Erinnert mich irgendwie an Martin Luther King:
    "I had a dream ..."

    DROP

  2. Re: RDBMS können günstiger getuned werden

    Autor: TURBO 28.10.08 - 12:06


    > aller Dinge ist. Dann müssen sie davon überzeugt
    > werden, dass Flatfiles auch prima in die
    > Datenbanken gedumped werden können. Wenn sie im

    Also sollten z.B. Fotos in der DB und nicht im Filesystem gespeichert werden?

  3. Re: RDBMS können günstiger getuned werden

    Autor: blafasel 28.10.08 - 12:10

    TURBO schrieb:
    -------------------------------------------------------
    > > > aller Dinge ist. Dann müssen sie davon
    > überzeugt
    > werden, dass Flatfiles auch prima
    > in die
    > Datenbanken gedumped werden können.
    > Wenn sie im
    >
    > Also sollten z.B. Fotos in der DB und nicht im
    > Filesystem gespeichert werden?

    Warum nicht?

  4. Re: RDBMS können günstiger getuned werden

    Autor: lalaundlulu 28.10.08 - 12:49

    und wenn mann es dann nur mit einer query engine zu tun hätte, wuerde alles wie geschmiert laufen.

  5. Re: RDBMS können günstiger getuned werden

    Autor: frlan 28.10.08 - 13:42

    >> Also
    >> sollten z.B. Fotos in der DB und nicht im
    >> Filesystem gespeichert werden?
    >
    > Warum nicht?

    Habe ich mir auch schon Gedacht. Je nach Datenbank und Art der Bilder kann man da einiges heraus holen.

  6. Re: RDBMS können günstiger getuned werden

    Autor: panzi 28.10.08 - 13:58

    blafasel schrieb:
    -------------------------------------------------------
    > TURBO schrieb:
    > --------------------------------------------------
    > -----
    > > > > aller Dinge ist. Dann müssen sie
    > davon
    > überzeugt
    > werden, dass Flatfiles
    > auch prima
    > in die
    > Datenbanken gedumped
    > werden können.
    > Wenn sie im
    >
    > Also
    > sollten z.B. Fotos in der DB und nicht im
    >
    > Filesystem gespeichert werden?
    >
    > Warum nicht?
    Weil ein Webserver statische datein schön performant servieren kann! Weil es vollkommen unnötig ist binary blobs in eine DB zu packen. In der DB will ich Daten haben. Etwas mit Semantik das ich auch in ner query verwenden kann. Was bei Bildern net der Fall ist. Solche Bilder werden dann vom DB Server zum Webserver kopiert und dann zum Client geschickt. Unnötige Kopiervorgängne (event. sogar übers Intranet!). Migration wird auch schneller wenn ich nur die Daten migrieren muss und die Datein ganz einfach auf der selben Platte liegen bleiben können.

  7. Re: RDBMS können günstiger getuned werden

    Autor: DerMuedceJo 28.10.08 - 14:53

    SELECTOR schrieb:
    -------------------------------------------------------
    > Man muss nur den Controllern und vor allem den
    > Marketing Heinis beibringen, das SAS (Ich meine
    > die Software, nicht die Hardware) nicht das Maß
    > aller Dinge ist. Dann müssen sie davon überzeugt
    > werden, dass Flatfiles auch prima in die
    > Datenbanken gedumped werden können. Wenn sie im
    > nächsten Schritt noch lernen, wie man Indizes auf
    > die Tabellen einrichtet, sind sie endlich mal
    > wieder am arbeiten und nicht am warten.
    > Wenn man ihnen dann auch noch die Augen öffnet und
    > etwas von Views erzählt, anstatt jeden SELECT in
    > eine neue Tabelle zu schreiben und darauf die
    > nächste Abfrage zu führen, dann könnten wir unsere
    > Terabyte-Server locker plattmachen und die Daten
    > auf ein paar Disketten packen.
    > Erinnert mich irgendwie an Martin Luther King:
    > "I had a dream ..."
    >
    > DROP
    Nicht die Controler und Marketingleute, die Entwickler sollten mal was tun. Anstatt Performanceprobleme mit Hardware zu erschlagen ( "Ach ist das System jetzt langsam ..."), mal richtig analysieren, Datenbank aufbauen und entsprechend die Queries optimieren.
    Da sind auch die DBA's gefragt. Nicht immer alles auf die User schieben. Aber Analyse ist bei den meisten ein PfuiBa Wort.

  8. Re: RDBMS können günstiger getuned werden

    Autor: Collision 28.10.08 - 21:37

    Na, deine ersten Datenbank-Gehversuche gemacht und mächtig stolz auf dein Halbwissen?

  9. Re: RDBMS können günstiger getuned werden

    Autor: Jochen Bedersdorfer 28.10.08 - 22:06

    2nd Level Caches können unnötige Kopieraktionen vermeiden helfen.
    Auch Einsatz eines Proxies soll helfen.
    Ansonsten muss man sich noch einen zusätzlichen Mechanismus überlegen, wie man Daten über Cluster repliziert. Datenbanken können das alles prima erledigen.
    Nicht umsonst ist IBM schon vor über 15 Jahren auf die Idee gekommen mit ihren AS/400 Maschinen eine Datenbank als grundlegenden Datenspeicher zu nehmen und das Filesystem auf dieser Datenbank zu implementieren...


    panzi schrieb:
    -------------------------------------------------------
    > blafasel schrieb:
    > --------------------------------------------------
    > -----
    > > TURBO schrieb:
    >
    > --------------------------------------------------
    >
    > -----
    > > > > aller Dinge ist.
    > Dann müssen sie
    > davon
    > überzeugt
    >
    > werden, dass Flatfiles
    > auch prima
    > in
    > die
    > Datenbanken gedumped
    > werden
    > können.
    > Wenn sie im
    >
    > Also
    >
    > sollten z.B. Fotos in der DB und nicht
    > im
    >
    > Filesystem gespeichert werden?
    >
    > Warum nicht?
    > Weil ein Webserver statische datein schön
    > performant servieren kann! Weil es vollkommen
    > unnötig ist binary blobs in eine DB zu packen. In
    > der DB will ich Daten haben. Etwas mit Semantik
    > das ich auch in ner query verwenden kann. Was bei
    > Bildern net der Fall ist. Solche Bilder werden
    > dann vom DB Server zum Webserver kopiert und dann
    > zum Client geschickt. Unnötige Kopiervorgängne
    > (event. sogar übers Intranet!). Migration wird
    > auch schneller wenn ich nur die Daten migrieren
    > muss und die Datein ganz einfach auf der selben
    > Platte liegen bleiben können.
    >


  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Forschungszentrum Jülich GmbH, Jülich
  2. Hochland SE, Heimenkirch, Schongau
  3. FUNKINFORM Informations- und Datentechnik GmbH, Ettlingen
  4. THD - Technische Hochschule Deggendorf, Deggendorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,31€
  2. (u. a. Wolfenstein: Youngblood, Days Gone, Metro Exodus, World War Z)
  3. (-91%) 1,10€
  4. 4,16€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Probefahrt mit Mercedes EQC: Ein SUV mit viel Wumms und wenig Bodenfreiheit
Probefahrt mit Mercedes EQC
Ein SUV mit viel Wumms und wenig Bodenfreiheit

Mit dem EQC bietet nun auch Mercedes ein vollelektrisch angetriebenes SUV an. Golem.de hat auf einer Probefahrt getestet, ob das Elektroauto mit Audis E-Tron mithalten kann.
Ein Erfahrungsbericht von Friedhelm Greis

  1. Mercedes EQV Daimler zeigt elektrische Großraumlimousine
  2. Freightliner eCascadia Daimler bringt Elektro-Lkw mit 400 km Reichweite
  3. Mercedes-Sicherheitsstudie Mit der Lichtdusche gegen den Sekundenschlaf

Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

Nachhaltigkeit: Jute im Plastik
Nachhaltigkeit
Jute im Plastik

Baustoff- und Autohersteller nutzen sie zunehmend, doch etabliert sind Verbundwerkstoffe mit Naturfasern noch lange nicht. Dabei gibt es gute Gründe, sie einzusetzen, Umweltschutz ist nur einer von vielen.
Ein Bericht von Werner Pluta

  1. Nachhaltigkeit Bauen fürs Klima
  2. Autos Elektro, Brennstoffzelle oder Diesel?
  3. Energie Wo die Wasserstoffqualität getestet wird

  1. Electric Flight Demonstrator: DLR stellt Konzept für Elektroflugzeug vor
    Electric Flight Demonstrator
    DLR stellt Konzept für Elektroflugzeug vor

    Das DLR hat zusammen mit Siemens und weiteren Unternehmen eine Machbarkeitsstudie für ein Flugzeug mit Elektroantrieb erstellt. Es soll das erste größere Flugzeug sein, das mit einem solchen Antrieb ausgestattet wird.

  2. 10th Gen Core: Intel verwirrt mit 1000er- und 10000er-Prozessoren
    10th Gen Core
    Intel verwirrt mit 1000er- und 10000er-Prozessoren

    Ifa 2019 Wer nicht genau hinschaut, erhält statt eines vierkernigen 10-nm-Chips mit schneller Grafikeinheit einen Dualcore mit 14++-Technik und lahmer iGPU: Intels Namensschema für Ice Lake und Comet Lake alias der 10th Gen macht das CPU-Portfolio wenig transparent.

  3. Comet Lake: Intel bringt sechs Kerne für Ultrabooks
    Comet Lake
    Intel bringt sechs Kerne für Ultrabooks

    Ifa 2019 Mit den Comet Lake U gibt es erstmals sechs Kerne für Ultrabooks, obendrein kombiniert Intel die 15-Watt-Chips mit schnellem LPDDR4-Speicher. Das Namensmodell ist jedoch so krude, dass Intel es selbst erläutern muss.


  1. 15:19

  2. 15:00

  3. 15:00

  4. 14:36

  5. 14:11

  6. 13:44

  7. 13:13

  8. 12:40