Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › 32-Bit-Software: Die Openstreetmap…

Warum keine UUIDs?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Warum keine UUIDs?

    Autor: burzum 14.02.13 - 14:44

    Wie ich das verstehe geht es um die ids in der Datenbank die nun zu groß werden?

    Warum setzte man nicht auf UUIDs?

    http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Warum keine UUIDs?

    Autor: cljk 14.02.13 - 15:45

    burzum schrieb:
    --------------------------------------------------------------------------------
    > Wie ich das verstehe geht es um die ids in der Datenbank die nun zu groß
    > werden?
    >
    > Warum setzte man nicht auf UUIDs?
    >
    > en.wikipedia.org#Random_UUID_probability_of_duplicates


    Ich würde vermuten aus dem gleichen Grund, warum die meisten in DBs keine UUIDs verwenden - jedenfalls nicht als Primärschlüssel: da sie unnötig groß sind und als String daher kommen. Und Stringvergleiche sind von Natur aus uneffizienter als numerische.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Warum keine UUIDs?

    Autor: cHaOs667 14.02.13 - 15:56

    cljk schrieb:
    --------------------------------------------------------------------------------
    > Und Stringvergleiche sind von Natur aus uneffizienter als numerische.
    Exakt das ist der Grund. Der Rechenaufwand beim vergleichen zweier Buchstaben ist um ein vielfaches größer als beim vergleich zweier Zahlen. Deswegen arbeiten Datenbanken auch mit nummerischen IDs.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Warum keine UUIDs?

    Autor: KeysUnlockTheWorld 14.02.13 - 16:46

    burzum schrieb:
    --------------------------------------------------------------------------------
    > Wie ich das verstehe geht es um die ids in der Datenbank die nun zu groß
    > werden?
    >
    > Warum setzte man nicht auf UUIDs?
    >
    > en.wikipedia.org#Random_UUID_probability_of_duplicates
    Wie die oben schon sagten, es ist langsam, bei millionen von Datensätzten merkst du das extrem.
    <not serious> kannst dich zu unseren Externen Vollidioten gesellen </not serious>Die haben in der Datenbank hinter deren Anwendungen die PKs als NChar(25) und Numeric(8,0) deklariert...(ihr wollt gar nich wissen wie das Datenbankmodell aussieht) Jetzt darf ich das via ETL Prozessen 'reparieren' und in unser DWH zum Auswerten laden.
    Was ich damit sagen möchte, wenn UUIDs jetzt 'in' werden, habe ich keine Lust immer wieder so eine Sche*ße zu Gold(=Auswertungsgeschwindigkeit) zu machen.



    2 mal bearbeitet, zuletzt am 14.02.13 16:48 durch KeysUnlockTheWorld.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Warum keine UUIDs?

    Autor: hungkubwa 15.02.13 - 06:53

    UUIDs lassen sich auch in Hex oder sogar Dezimalzahlen konvertieren.
    Außerdem bietet MySql ein besonderen Feldtypen für UUIDs.

    Und ich warte lieber 2 Sekunden länger für eine Abfrage als das ich in 4 Jahren einen Integer Overflow habe.
    Jeder muss seine Prioritäten selber setzen.

    PS: Ich kenne eine Datenbank die mehrere milliarden Einträge hat, in die hunderte Terabyte geht und UUIDs nutzt und trotzdem binnen < 2 Sekunden antwortet.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Warum keine UUIDs?

    Autor: lspcity 15.02.13 - 10:20

    hungkubwa schrieb:
    --------------------------------------------------------------------------------
    > PS: Ich kenne eine Datenbank die mehrere milliarden Einträge hat, in die
    > hunderte Terabyte geht und UUIDs nutzt und trotzdem binnen < 2 Sekunden
    > antwortet.

    Aha? Die da wäre?
    In-memory wird es nicht sein, denn von "hunderte[n] Terabyte" Arbeitsspeicher hab ich noch nichts gehört.

    Die Sache ist, dass es bei solch riesigen Datenmengen nicht bei einer Verzögerung von 2 Sekunden bleibt, sondern sich schnell auf 30 Sekunden oder größer ausdehnt.
    Des Weiteren spielt die Last der Server eine immense Rolle. Sind genug Kapazitäten vorhanden, dass hunderte von Zugriffen "gleichzeitig" möglich sind?
    Und zuletzt ist es ja nicht so, dass nur 1 Node zurückgegeben wird, sondern für eine Karte "viele tausende".

    [Edit]Ach und nicht zu vergessen: OpenStreetMap & "begrenzte Mittel" sind Begriffe, die ganz eng miteinander verbunden sind.[/Edit]

    Ich würd dich gerne mal sehen, wie du in die Karte reinzoomst oder die Karte verschiebst und dabei jedesmal 2 Sekunden warten musst, bis sich das Bild ruckelnd aufbaut...



    2 mal bearbeitet, zuletzt am 15.02.13 10:22 durch lspcity.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: Warum keine UUIDs?

    Autor: xbeo 05.03.13 - 23:55

    KeysUnlockTheWorld schrieb:
    --------------------------------------------------------------------------------
    > burzum schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wie ich das verstehe geht es um die ids in der Datenbank die nun zu groß
    > > werden?
    > >
    > > Warum setzte man nicht auf UUIDs?
    > >
    > > en.wikipedia.org#Random_UUID_probability_of_duplicates
    > Wie die oben schon sagten, es ist langsam, bei millionen von Datensätzten
    > merkst du das extrem.
    > kannst dich zu unseren Externen Vollidioten gesellen Die haben in der
    > Datenbank hinter deren Anwendungen die PKs als NChar(25) und Numeric(8,0)
    > deklariert...(ihr wollt gar nich wissen wie das Datenbankmodell aussieht)
    > Jetzt darf ich das via ETL Prozessen 'reparieren' und in unser DWH zum
    > Auswerten laden.
    > Was ich damit sagen möchte, wenn UUIDs jetzt 'in' werden, habe ich keine
    > Lust immer wieder so eine Sche*ße zu Gold(=Auswertungsgeschwindigkeit) zu
    > machen.

    Wie ueberall in der Welt hat alles seine Vor- und Nachteile.
    UUIDs werden gerne in verteilten Anwendungen verwendet, oder halt da wo zentrale ID-Generierung schwierig/teuer ist.

    Wenn du eine ETL-Phase hast, hast du in der auch alle Zeit der Welt, um aus den UUIDs alles moegliche zu machen. Wenn das immernoch zu lange dauert, hast du ein unschlagbares Argument fuer neue Hardware.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige
  1. IT-Operations Consultant Master Data (m/w)
    Media-Saturn IT-Services GmbH, Ingolstadt
  2. Softwareentwickler/in
    Robert Bosch GmbH, Leonberg
  3. Information Security Architect (m/w) - Car IT-Umfänge
    Daimler AG, Stuttgart
  4. Moodle-Administrator (m/w)
    Fachhochschule Südwestfalen, Hagen

Detailsuche



Blu-ray-Angebote
  1. Total Recall (Steelbook Edition) [Blu-ray]
    7,90€
  2. The Green Hornet (inkl. 2D Blu-ray) [Blu-ray 3D]
    9,90€
  3. Oscar-Filme zum Sonderpreis
    (u. a. Grand Budapest Hotel 7,90€, Birdman 9,90€, 12 Years a Slave 9,97€)

Weitere Angebote



Haben wir etwas übersehen?

E-Mail an news@golem.de


Galaxy View im Test: Samsungs Riesentablet scheitert als Fernseher-Alternative
Galaxy View im Test
Samsungs Riesentablet scheitert als Fernseher-Alternative
  1. Lehrer IT-Ausstattung an Schulen weiterhin nicht gut
  2. Huawei Mediapad M2 10.0 Gut ausgestattetes 10-Zoll-Tablet mit Stylus für 500 Euro
  3. Oberschule Weiter zu wenig Computer an den Schulen

Staatliche Überwachung: Die Regierung liest jeden Post
Staatliche Überwachung
Die Regierung liest jeden Post
  1. ÖPNV in San Francisco Die meisten Überwachungskameras sind nur Attrappen
  2. Videoüberwachung Innenministerkonferenz will Body-Cams für alle Polizisten
  3. Schnüffelgesetz Vodafone warnt vor Backdoors im Mobilfunknetz

Unravel im Test: Feinwollig schön und frustig schwer
Unravel im Test
Feinwollig schön und frustig schwer
  1. The Witness im Test Die Insel der tausend Labyrinthe
  2. Oxenfree im Test Urlaub auf der Gruselinsel
  3. Amplitude im Test Beats und Groove auf Knopfdruck

  1. Xeon D-1571: Intel veröffentlicht sparsamen Server-Chip mit 16 Kernen
    Xeon D-1571
    Intel veröffentlicht sparsamen Server-Chip mit 16 Kernen

    Doppelt so viele Kerne bei etwas geringerem Takt und weiterhin 45 Watt: Intel positioniert den neuen Xeon D frühzeitig gegen die ARM-v8-Konkurrenz im Kampf um Marktanteile im Micro-Server-Segment.

  2. Die Woche im Video: Sensationen und Skandale
    Die Woche im Video
    Sensationen und Skandale

    Golem.de-Wochenrückblick Forscher haben Einsteins Gravitationswellen nachgewiesen und wir haben Neues zur Datenspeicherung beim VBB aufgedeckt. Sieben Tage und viele Meldungen im Überblick.

  3. Micron: Von 1Y-/1Z-DRAM-, 3D-Flash- und 3D-Xpoint-Plänen
    Micron
    Von 1Y-/1Z-DRAM-, 3D-Flash- und 3D-Xpoint-Plänen

    Micron hat einen Ausblick auf kommende Speichertechnologien gegeben: DRAM soll in feineren Strukturen gefertigt werden, 3D-NAND-Flash-Speicher mit TLCs wird zum Standard und ein Drittel aller Server mit zwei oder vier Sockeln sollen künftig 3D Xpoint nutzen.


  1. 09:21

  2. 09:03

  3. 00:24

  4. 18:25

  5. 18:16

  6. 17:46

  7. 17:22

  8. 17:13