9 ms·

If you want to stop out of control spend, have your analysts learn SQL. Avoid database systems that charge per query (like tinybird) and make damn certain your

If you want to stop out of control spend, have your analysts learn SQL. Avoid database systems that charge per query (like tinybird) and make damn certain your people know SQL if you do. Ignore and preferably fire people who mention things like “data lakes”.

cosmolev 4y ago
Wow, I've previously had exactly same feelings about couple of people from whom I heard "data lakes".
- steveBK123 4y ago
  Only thing worse is "data lakehouse"
  - silisili 4y ago
    I couldn't help but laugh the first time I saw that. Should we go ahead and file copyright on Data Ocean and Data Beachhouse?
    - beckingz 4y ago
      Careful, if you build wrong you'll get wiped out by a data hurricane.
- teddyh 4y ago
  “We used to dream about having our data in a warehouse! We had to have our data in a lake!”
h4kor 4y ago
I always wonder, who looks at their pricing model and decides "Paying multiple dollars to query on a few GB of data sounds reasonable"?
- vorpalhex 4y ago
  The person who doesn't have to pay the bill.
- ericd 4y ago
  Seriously? A $10k dedicated server would have a payback period measured in minutes.
  - IanCal 4y ago
    Importantly it depends on how often these things are run and who has to maintain a server.
  - aynyc 4y ago
    It depends on the business unit. Some don't have the ability to run a technology group to run a $10K dedicated server.
    - nneonneo 4y ago
      But they have the budget to run $10K of queries a day?
    - paulmd 4y ago
      Query bills of $40k a day will pay for a lot of staff, or a lot of outside expertise to administer it for you.
    - Gordonjcp 4y ago
      I feel like for 1.4 million USD a year I could solve that problem for them.
  - xhrpost 4y ago
    I don't think it's always that easy. I work on some large databases (1TB+) where even queries utilizing indexed columns still take prohibitively long to run. Sure we could look into partitioning (and we likely might) but then more work is progressively falling on engineering to keep the system running for the standards of analysts but not necessarily the product. BigQuery in these cases has been very useful. Everything I throw at it returns in seconds. I can also do more text comparison queries that on a standard RDBMS would have required a full text index (which would probably be huge). But with BigQuery even those queries take seconds and I don't have to take production resources to view it.
_peregrine_ 4y ago
I think it’s worth mentioning that tinybird doesn’t necessarily charge per query, the billing model seems more geared towards API usage, though queries are the underpinning. Also it’s not unreasonable to see people spending $10K+ a day in Snowflake because bad practices just like this.
steveBK123 4y ago
1000% this Almost every solution I've seen to tooling that is supposed to "avoid data analysts having to learn SQL" is far more costly, requires engineering staffing, performs much slower and sometimes requires the analyst to instead learn some esoteric less powerful language ... If your job is to slice&dice data all day, and can't be bothered to learn SQL, I don't know what to say.
- treis 4y ago
  The data lake problem is specifically due to microservices or SOA. People love to separate customers from orders until they realize that you want to do complex filtering on customers and join it to their orders. Then everyone says "oh crap" when they realize they've created a problem without a great solution.
  - paulmd 4y ago
    Yes. Fundamentally there is almost no data that is not relational in some aspect. Any given document, you can virtually instantly start picking out "ok that could be a foreign key...", and if one does not exist, it certainly will before too many sprints go by. And most usages of NoSQL are essentially equivalent to a row within a table, especially given many NoSQL solutions have bugs or performance issues with deeply nested documents (ran into that with SOLR - deep pagination can give incorrect results with nested documents). Personally I view a true document (not a table row turned into JSON) as being the deeply-nested kind, and ideally generated from the relational data itself, to allow different "dimensionalities" to be represented without needing pivots/windows/analytical queries, and that's very seldom what I see it being used for in practice. Again, most people just have a RDBMS row but stored in JSON. example: in the "netflix" example, your movies, your actors, your users, your likes, etc are all relational, and then you build a document collection that is good for searching movies, a collection that is good for displaying user data/history/settings, a collection for displaying actors' filmography, etc, but all are generated from the same actual, consistent relational data.
    - didgetmaster 4y ago
nodejsthrowaway 4y ago
>Avoid database systems that charge per query oh my god i'm currently $13k/mo in dynamodb costs because of this whereas the same requirements sql database costs $2k/mo
rozenmd 4y ago
I heard at a certain Professional Social Network company that some of their analysts would slam their db cluster with inefficient queries until it rebooted, and first one to rerun their query would finally get a result. Learn SQL ffs.
deleted 4y ago
[deleted]

cosmolev 4y ago

Wow, I've previously had exactly same feelings about couple of people from whom I heard "data lakes".

steveBK123 4y ago
Only thing worse is "data lakehouse"
- silisili 4y ago
  I couldn't help but laugh the first time I saw that. Should we go ahead and file copyright on Data Ocean and Data Beachhouse?
  - beckingz 4y ago
    Careful, if you build wrong you'll get wiped out by a data hurricane.
teddyh 4y ago
“We used to dream about having our data in a warehouse! We had to have our data in a lake!”

h4kor 4y ago

I always wonder, who looks at their pricing model and decides "Paying multiple dollars to query on a few GB of data sounds reasonable"?

vorpalhex 4y ago
The person who doesn't have to pay the bill.
ericd 4y ago
Seriously? A $10k dedicated server would have a payback period measured in minutes.
- IanCal 4y ago
  Importantly it depends on how often these things are run and who has to maintain a server.
- aynyc 4y ago
  It depends on the business unit. Some don't have the ability to run a technology group to run a $10K dedicated server.
  - nneonneo 4y ago
    But they have the budget to run $10K of queries a day?
  - paulmd 4y ago
    Query bills of $40k a day will pay for a lot of staff, or a lot of outside expertise to administer it for you.
  - Gordonjcp 4y ago
    I feel like for 1.4 million USD a year I could solve that problem for them.
- xhrpost 4y ago
  I don't think it's always that easy. I work on some large databases (1TB+) where even queries utilizing indexed columns still take prohibitively long to run. Sure we could look into partitioning (and we likely might) but then more work is progressively falling on engineering to keep the system running for the standards of analysts but not necessarily the product. BigQuery in these cases has been very useful. Everything I throw at it returns in seconds. I can also do more text comparison queries that on a standard RDBMS would have required a full text index (which would probably be huge). But with BigQuery even those queries take seconds and I don't have to take production resources to view it.

_peregrine_ 4y ago

I think it’s worth mentioning that tinybird doesn’t necessarily charge per query, the billing model seems more geared towards API usage, though queries are the underpinning. Also it’s not unreasonable to see people spending $10K+ a day in Snowflake because bad practices just like this.

steveBK123 4y ago

1000% this Almost every solution I've seen to tooling that is supposed to "avoid data analysts having to learn SQL" is far more costly, requires engineering staffing, performs much slower and sometimes requires the analyst to instead learn some esoteric less powerful language ... If your job is to slice&dice data all day, and can't be bothered to learn SQL, I don't know what to say.

treis 4y ago
The data lake problem is specifically due to microservices or SOA. People love to separate customers from orders until they realize that you want to do complex filtering on customers and join it to their orders. Then everyone says "oh crap" when they realize they've created a problem without a great solution.
- paulmd 4y ago
  Yes. Fundamentally there is almost no data that is not relational in some aspect. Any given document, you can virtually instantly start picking out "ok that could be a foreign key...", and if one does not exist, it certainly will before too many sprints go by. And most usages of NoSQL are essentially equivalent to a row within a table, especially given many NoSQL solutions have bugs or performance issues with deeply nested documents (ran into that with SOLR - deep pagination can give incorrect results with nested documents). Personally I view a true document (not a table row turned into JSON) as being the deeply-nested kind, and ideally generated from the relational data itself, to allow different "dimensionalities" to be represented without needing pivots/windows/analytical queries, and that's very seldom what I see it being used for in practice. Again, most people just have a RDBMS row but stored in JSON. example: in the "netflix" example, your movies, your actors, your users, your likes, etc are all relational, and then you build a document collection that is good for searching movies, a collection that is good for displaying user data/history/settings, a collection for displaying actors' filmography, etc, but all are generated from the same actual, consistent relational data.
  - didgetmaster 4y ago

nodejsthrowaway 4y ago

>Avoid database systems that charge per query oh my god i'm currently $13k/mo in dynamodb costs because of this whereas the same requirements sql database costs $2k/mo

rozenmd 4y ago

I heard at a certain Professional Social Network company that some of their analysts would slam their db cluster with inefficient queries until it rebooted, and first one to rerun their query would finally get a result. Learn SQL ffs.

deleted 4y ago

[deleted]