10 ms·

Wow, nice explanation. I was expecting a lengthy post with refuting everything uber said and explaining why pgsql was a better choice and uber was wrong. Nice

by gnur 10y ago

Wow, nice explanation. I was expecting a lengthy post with refuting everything uber said and explaining why pgsql was a better choice and uber was wrong. Nice and clean post showing that acknowledging a weakness isn't a terrible choice. I do wonder whether a different data structure would have mitigated the issue instead of transitioning to a different storage engine.

collyw 10y ago
Yes, I have a lot more respect for this than say MongoDb which claims to be great at everything.
- spriggan3 10y ago
  > MongoDb which claims to be great at everything lol right, with MongoDb, Map Reduce is a joke, GridFS is slow and barely usable, the storage is extremely inefficient, the "query engine" slow, and don't get me started on their "full text search" engine. MongoDb is a successful marketing stunt in the "Nodejs era".
  - oneloop 10y ago
    Also, wasn't there a ridiculous issue that they had where the db can't be bigger than 4gb on a 32 bit file system because that's the largest size a file can have...?
    - thom_nic 10y ago
      Yes, apparently the limit on 32-bit is 2GB actually. MongoDB has always stated upfront that 32-bit architectures are not recommended for production use for precisely this reason: http://blog.mongodb.org/post/137788967/32-bit-limitations http://blog.mongodb.org/post/137788967/32-bit-limitations This has also has been stated on their download page for 32-bit binaries as well.
      - StavrosK 10y ago
        It hasn't always been stated there, and it was a warning on a README somewhere. The server would run happily on 32 bits, and never crash or produce any user-visible errors, it would just silently corrupt data while pretending the insertion went great.
        brazzledazzle 10y ago
        And that's the real issue I would think. If it shut itself down or went into read-only and generated errors it wouldn't be so bad. The limitations 32-bit architectures are why we have 64bit architectures. I think it's fair as a developer to require x64 instead of jumping through hoops to support both architectures. But if you're going to release 32-bit binaries for something like development or testing you should be explicit about the use cases and limitations and avoid failing silently when they're exceeded.
        MichaelGG 10y ago
        This stems from their choice of "mmap and done" as their entire IO strategy, for earlier versions. The data loss is silly though and shows their attitude.
      - Zardoz84 10y ago
        Oracle 9 on 32 bit can handle 32GiB databases without any issue, and bigger setup to use more that a single file per table space. And Oracle 9 it's old. Note: I hate Oracle DB, but I must work with Oracle 9/10/11/2 DBs because is what our clients have.
    - DCoder 10y ago
      > When running a 32-bit build of MongoDB, the total storage size for the server, including data and indexes, is 2 gigabytes. For this reason, do not deploy MongoDB to production on 32-bit machines. From https://docs.mongodb.com/manual/installation/#faq-32-bit-limitations https://docs.mongodb.com/manual/installation/#faq-32-bit-lim... There was also the issue where errors were either logged or not, based on the result of Math.random(): http://stackoverflow.com/q/16833100/1233508 http://stackoverflow.com/q/16833100/1233508
    - bluejekyll 10y ago
      While I don't care about mongoDB, who's running 32bit anymore? And for a production DB?
      - brohee 10y ago
        DB exist on more than servers, e.g. in an embedded environment... You find sqlite in the oddest places... One could imagine finding mongodb there too, with bonus data corruption...
      - Zardoz84 10y ago
        Spain public administrations.
      - radiowave 10y ago
        For example, the 32 bit mongoDB instance that's managing a grand total of 2 wifi access points here.
    - qwertyuiop924 10y ago
      Umm... Wow, mongo. Boy, am I glad I didn't decide to pick you. Let's get some statistics. MySQL and Postgres both have and undefined max DB size, and max table sizes upwards of 16 and 32 TB, respectively. SQLite has no max table size I could find, but had a max DB size of 140 TB. 140TB. And this is from a database that reccomends not using it if your data grows too large.
- DiabloD3 10y ago
  For the kind of stuff Uber stores, they may actually be doing it wrong (given what that Postgre mailing list post says) because that is one hell of an ugly use case for any DB. I would have tried solving it by loading a dual E5v4 server full of 3TB and a slew of SSDs for L2ARC+ZIL under ZFS: more SSDs > bigger SSDs because the absolute worst case SSD performance that any and all SSDs suffer from is random reads (not writes) can slow to 200MB/sec even on those insanely fast "enterprise" PCI-E SSDs that do 2-4GB/sec continuous reads. Given that, there are only four dbs worth using: Postgre, Oracle, DB2, and MS SQL. Unless you're doing something that is truly not suited for SQL (or SQL is insanely overkill), or you're Google and have a database in the hundreds or thousands of TB and literally have to write your own database (they went from almost inventing mapreduce, to going full circle back to full scale distributed RDBMS SQL with F1, which I wish they'd open source), any other database is just going to be a pain in the ass, buggy, and full of gotchas and undiscovered corner cases simply because it doesn't have over a decade of development and millions of users behind it. Also, I have not included MySQL for obvious reasons: fun for toy SQL DBs where sqlite isn't a good fit, but not for enterprise use by any means. Uber switching to MySQL over Postgre is rather scary, I wouldn't want to be a Uber investor right now.
  - nubela 10y ago
    You wouldn't wanna be an Uber investor because choice of DBMS? As a programmer, I think this is the problem with developers thinking that technical problems are a bigger deal than it is.
    - viraptor 10y ago
      Mysql eats and corrupts data by design. For a company responding to real time events in physical world, that can be a big issue. I know they're trying to improve their defaults lately, but a lot of weird behaviour remains. And you don't have to be an expert DBA to know that choosing a technology known for silent data corruption is risky.
      - deleted 10y ago
        [deleted]
- deleted 10y ago
  [deleted]
_pmf_ 10y ago
> Nice and clean post showing that acknowledging a weakness isn't a terrible choice. Reading between the lines: "let's ignore the obviously suboptimal choice of architecture and concentrate on the DB specific issues addressed". OTOH, what would be a nice way of doing CQRS completely within postgres?
- hagbarddenstore 10y ago
  CQRS doesn't imply event sourcing. CQRS works fine with the standard RDBMS workflow.
- serguzest 10y ago
  https://github.com/JasperFx/marten https://github.com/JasperFx/marten
  - _pmf_ 10y ago
    Ah, very nice!
deleted 10y ago
[deleted]
_RPM 10y ago
I think if this was a giant corporation or someone like Mark Zuckerberg, there would be some nice PR post refuting Uber's claims.

by gnur 10y ago

collyw 10y ago

Yes, I have a lot more respect for this than say MongoDb which claims to be great at everything.

spriggan3 10y ago
> MongoDb which claims to be great at everything lol right, with MongoDb, Map Reduce is a joke, GridFS is slow and barely usable, the storage is extremely inefficient, the "query engine" slow, and don't get me started on their "full text search" engine. MongoDb is a successful marketing stunt in the "Nodejs era".
- oneloop 10y ago
  Also, wasn't there a ridiculous issue that they had where the db can't be bigger than 4gb on a 32 bit file system because that's the largest size a file can have...?
  - thom_nic 10y ago
    Yes, apparently the limit on 32-bit is 2GB actually. MongoDB has always stated upfront that 32-bit architectures are not recommended for production use for precisely this reason: http://blog.mongodb.org/post/137788967/32-bit-limitations http://blog.mongodb.org/post/137788967/32-bit-limitations This has also has been stated on their download page for 32-bit binaries as well.
    - StavrosK 10y ago
      It hasn't always been stated there, and it was a warning on a README somewhere. The server would run happily on 32 bits, and never crash or produce any user-visible errors, it would just silently corrupt data while pretending the insertion went great.
      - brazzledazzle 10y ago
        And that's the real issue I would think. If it shut itself down or went into read-only and generated errors it wouldn't be so bad. The limitations 32-bit architectures are why we have 64bit architectures. I think it's fair as a developer to require x64 instead of jumping through hoops to support both architectures. But if you're going to release 32-bit binaries for something like development or testing you should be explicit about the use cases and limitations and avoid failing silently when they're exceeded.
        MichaelGG 10y ago
        This stems from their choice of "mmap and done" as their entire IO strategy, for earlier versions. The data loss is silly though and shows their attitude.
    - Zardoz84 10y ago
      Oracle 9 on 32 bit can handle 32GiB databases without any issue, and bigger setup to use more that a single file per table space. And Oracle 9 it's old. Note: I hate Oracle DB, but I must work with Oracle 9/10/11/2 DBs because is what our clients have.
  - DCoder 10y ago
    > When running a 32-bit build of MongoDB, the total storage size for the server, including data and indexes, is 2 gigabytes. For this reason, do not deploy MongoDB to production on 32-bit machines. From https://docs.mongodb.com/manual/installation/#faq-32-bit-limitations https://docs.mongodb.com/manual/installation/#faq-32-bit-lim... There was also the issue where errors were either logged or not, based on the result of Math.random(): http://stackoverflow.com/q/16833100/1233508 http://stackoverflow.com/q/16833100/1233508
  - bluejekyll 10y ago
    While I don't care about mongoDB, who's running 32bit anymore? And for a production DB?
    - brohee 10y ago
      DB exist on more than servers, e.g. in an embedded environment... You find sqlite in the oddest places... One could imagine finding mongodb there too, with bonus data corruption...
    - Zardoz84 10y ago
      Spain public administrations.
    - radiowave 10y ago
      For example, the 32 bit mongoDB instance that's managing a grand total of 2 wifi access points here.
  - qwertyuiop924 10y ago
    Umm... Wow, mongo. Boy, am I glad I didn't decide to pick you. Let's get some statistics. MySQL and Postgres both have and undefined max DB size, and max table sizes upwards of 16 and 32 TB, respectively. SQLite has no max table size I could find, but had a max DB size of 140 TB. 140TB. And this is from a database that reccomends not using it if your data grows too large.
DiabloD3 10y ago
For the kind of stuff Uber stores, they may actually be doing it wrong (given what that Postgre mailing list post says) because that is one hell of an ugly use case for any DB. I would have tried solving it by loading a dual E5v4 server full of 3TB and a slew of SSDs for L2ARC+ZIL under ZFS: more SSDs > bigger SSDs because the absolute worst case SSD performance that any and all SSDs suffer from is random reads (not writes) can slow to 200MB/sec even on those insanely fast "enterprise" PCI-E SSDs that do 2-4GB/sec continuous reads. Given that, there are only four dbs worth using: Postgre, Oracle, DB2, and MS SQL. Unless you're doing something that is truly not suited for SQL (or SQL is insanely overkill), or you're Google and have a database in the hundreds or thousands of TB and literally have to write your own database (they went from almost inventing mapreduce, to going full circle back to full scale distributed RDBMS SQL with F1, which I wish they'd open source), any other database is just going to be a pain in the ass, buggy, and full of gotchas and undiscovered corner cases simply because it doesn't have over a decade of development and millions of users behind it. Also, I have not included MySQL for obvious reasons: fun for toy SQL DBs where sqlite isn't a good fit, but not for enterprise use by any means. Uber switching to MySQL over Postgre is rather scary, I wouldn't want to be a Uber investor right now.
- nubela 10y ago
  You wouldn't wanna be an Uber investor because choice of DBMS? As a programmer, I think this is the problem with developers thinking that technical problems are a bigger deal than it is.
  - viraptor 10y ago
    Mysql eats and corrupts data by design. For a company responding to real time events in physical world, that can be a big issue. I know they're trying to improve their defaults lately, but a lot of weird behaviour remains. And you don't have to be an expert DBA to know that choosing a technology known for silent data corruption is risky.
    - deleted 10y ago
      [deleted]
deleted 10y ago
[deleted]

_pmf_ 10y ago

> Nice and clean post showing that acknowledging a weakness isn't a terrible choice. Reading between the lines: "let's ignore the obviously suboptimal choice of architecture and concentrate on the DB specific issues addressed". OTOH, what would be a nice way of doing CQRS completely within postgres?

hagbarddenstore 10y ago
CQRS doesn't imply event sourcing. CQRS works fine with the standard RDBMS workflow.
serguzest 10y ago
https://github.com/JasperFx/marten https://github.com/JasperFx/marten
- _pmf_ 10y ago
  Ah, very nice!

deleted 10y ago

[deleted]

_RPM 10y ago

I think if this was a giant corporation or someone like Mark Zuckerberg, there would be some nice PR post refuting Uber's claims.