4 ms·

It's perfect for serverless, like lambdas? For small datasets (<100MB), perhaps, but I disagree with the author that this scales well. I wouldn't want to be de

It's perfect for serverless, like lambdas? For small datasets (<100MB), perhaps, but I disagree with the author that this scales well. I wouldn't want to be deploying a multi-gigabyte binary every time i make a change to the dataset...

fddhjjj 5y ago
It depends on your deployment setup? Or the frequency of dataset changes? I check-in a one-line change and CI/CD kicks off a docker build and push. A multi gigabyte binary is pushed to AWS ECR every time. I hardly notice. One benefit is the consistency. Small change. Pushed. Large change. Pushed. Dataset. Pushed. New OS, new code, new lib, new data all the same. Maybe it doesn’t scale to frequent updates? If you are streaming me data, I can’t update my image every second..
- tlarkworthy 5y ago
  no, it's no good for big data sets because lambda warmup time and RAM consumption is proportional to binary size. Just reference the data as a URL to static storage, problem solved.
  - HelloNurse 5y ago
    > no, it's no good for big data sets because lambda warmup time and RAM consumption is proportional to binary size What binary size? What RAM consumption? With a SQLite database or something similar you'll have a small and possibly unchanged program, one or more large replaced database files, and only the unavoidable reloading of actually used index pages contributing to memory use and "warmup" after an update. Of course if instead of relying on some efficient DBMS that manages indexing and caching you have to discard and reload a large file in its entirety after an update in order to hold all its content in memory your database is part of the problem and not part of the solution.
  - simonw 5y ago
    Weirdly Cloud Run claims that cold start time isn't coupled to the size of the binary. I find that larger database files on Cloud Run do need to be assigned a higher amount of RAM though, or they fail to start - but I'm not sure if that's a bug in how my code works. I've not yet spent much time tweaking SQLite parameters.
  - fddhjjj 5y ago
    We switched from deployment: > I wouldn't want to be deploying a multi-gigabyte binary every time i make a change to the dataset... To runtime startup: > lambda warmup time And cost: > RAM consumption is proportional to binary size
tantalor 5y ago
> multi-gigabyte I forgot how to count that low
simonw 5y ago
I have a few projects running on Cloud Run that deploy around a GB of SQLite data. Works pretty well! Not so great above 2GB though, at that point the model of deploying a copy of the data with each deploy stops working so well. This pattern is mostly useful for content-oriented sites with human editors. It's pretty rare for any human-edited publication to generate more than a few hundred MBs of structured data!
ramoz 5y ago
I deploy AI to prod. Low data gravity in high performant envs (SSD relevant here) is a common component. ~4.1TB raid0 on a bunch of ssds xN distributed nodes we depoly, leveldb shards & client in the app. Daily updates, blue/green needed

fddhjjj 5y ago

It depends on your deployment setup? Or the frequency of dataset changes? I check-in a one-line change and CI/CD kicks off a docker build and push. A multi gigabyte binary is pushed to AWS ECR every time. I hardly notice. One benefit is the consistency. Small change. Pushed. Large change. Pushed. Dataset. Pushed. New OS, new code, new lib, new data all the same. Maybe it doesn’t scale to frequent updates? If you are streaming me data, I can’t update my image every second..

tlarkworthy 5y ago
no, it's no good for big data sets because lambda warmup time and RAM consumption is proportional to binary size. Just reference the data as a URL to static storage, problem solved.
- HelloNurse 5y ago
  > no, it's no good for big data sets because lambda warmup time and RAM consumption is proportional to binary size What binary size? What RAM consumption? With a SQLite database or something similar you'll have a small and possibly unchanged program, one or more large replaced database files, and only the unavoidable reloading of actually used index pages contributing to memory use and "warmup" after an update. Of course if instead of relying on some efficient DBMS that manages indexing and caching you have to discard and reload a large file in its entirety after an update in order to hold all its content in memory your database is part of the problem and not part of the solution.
- simonw 5y ago
  Weirdly Cloud Run claims that cold start time isn't coupled to the size of the binary. I find that larger database files on Cloud Run do need to be assigned a higher amount of RAM though, or they fail to start - but I'm not sure if that's a bug in how my code works. I've not yet spent much time tweaking SQLite parameters.
- fddhjjj 5y ago
  We switched from deployment: > I wouldn't want to be deploying a multi-gigabyte binary every time i make a change to the dataset... To runtime startup: > lambda warmup time And cost: > RAM consumption is proportional to binary size

tantalor 5y ago

> multi-gigabyte I forgot how to count that low

simonw 5y ago

I have a few projects running on Cloud Run that deploy around a GB of SQLite data. Works pretty well! Not so great above 2GB though, at that point the model of deploying a copy of the data with each deploy stops working so well. This pattern is mostly useful for content-oriented sites with human editors. It's pretty rare for any human-edited publication to generate more than a few hundred MBs of structured data!

ramoz 5y ago

I deploy AI to prod. Low data gravity in high performant envs (SSD relevant here) is a common component. ~4.1TB raid0 on a bunch of ssds xN distributed nodes we depoly, leveldb shards & client in the app. Daily updates, blue/green needed