3 ms·
I love the nerdery around 1BRC. My axe to grind is that unless you do dangerous stuff DBs are just as fast, less complicated, and more resilient to data updates
by camgunz 3y ago
I love the nerdery around 1BRC. My axe to grind is that unless you do dangerous stuff DBs are just as fast, less complicated, and more resilient to data updates than application code [0]. Do more in the database!
0: https://geraldonit.com/2024/01/31/1-billion-row-challenge-in-sql-and-oracle-database/ https://geraldonit.com/2024/01/31/1-billion-row-challenge-in...
- riku_iki 3y agoactually that guy can now be sued, per TOS it is illegal to publish benchmarks for Oracle DB.
- Rexxar 3y agoI'm not sure this part of the TOS is valid in many jurisdictions. But there is a better reason to not publish benchmarks: they do not deserve free advertisement. We should just collectively forget they exist and use other tools.
- riku_iki 3y agowhich corp is considered to be good now days?..
- christophilus 3y agoUmbrella Corp.
- giantrobot 3y agoI agree with doing more in the database, you're closer to the data (disk/disk cache/L2 cache) than the application code is. At the same time I get really nervous around doing work in the database because you have to be really disciplined that the in-database code (functions, views, etc) match the code in source control. Also that your testing/QA database contains all the same code and enough test data to actually exercise the performance bounds of that code. With application code I can easily step through it in a debugger and verify the deployed code matches what's in the repo. It's more difficult to do in the database because it requires more organizational discipline.
- camgunz 3y agoYeah you need some different tools when working in data. I've been recommending dbt [0] as kind of the on-ramp for SREs to data work. Among other things it allows you to keep your work in a VCS and has a testing framework. [0]: getdbt.com