5 ms·
The data rules worth $40k a day
- alterneesh 4y agoI just skimmed through the article tbh, but I saw 14 GB and what looked like a predicate pushdown optimization. I think DuckDB could handle that on my 16GB mac.
- deleted 4y ago[deleted]
- datalopers 4y agoIf 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”.
- 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
- cosmolev 4y agoWow, I've previously had exactly same feelings about couple of people from whom I heard "data lakes".
- steveBK123 4y agoOnly thing worse is "data lakehouse"
- 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 agoI always wonder, who looks at their pricing model and decides "Paying multiple dollars to query on a few GB of data sounds reasonable"?
- ericd 4y agoSeriously? A $10k dedicated server would have a payback period measured in minutes.
- h4kor 4y agoThe example in the article is 40k/day for querying on 14 GB of data, every second. You can do that on a ~100/month machine or a somewhat modern laptop.
- mrguyorama 4y agoOur entire, hundreds of millions of dollars business with hundreds of millions of orders of historical data can be "explored" by a data scientist on an average macbook. If your data scientists can't do data science, then that's pretty bad
- IanCal 4y agoImportantly it depends on how often these things are run and who has to maintain a server.
- aynyc 4y agoIt depends on the business unit. Some don't have the ability to run a technology group to run a $10K dedicated server.
- _peregrine_ 4y agoI 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 ago1000% 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 agoThe 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 agoYes. 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
- rozenmd 4y agoI 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]
- kiernanmcgowan 4y agoMaterialized Views are damn near magic for solving issues involving slow queries on for tools that don't need real time results (eg daily reporting). They essentially act as a cache of a query at a given point in time that you're able to refresh whenever you want. https://www.postgresql.org/docs/current/rules-materializedviews.html https://www.postgresql.org/docs/current/rules-materializedvi...
- leeoniya 4y ago> It’s only significant weakness now is in Materialized views, with their lack of incremental refresh. > That work towards incrementally updated views is happening and progressing. For now, it's a separate extension, though: https://github.com/sraoss/pg_ivm https://github.com/sraoss/pg_ivm. https://news.ycombinator.com/item?id=32098603 https://news.ycombinator.com/item?id=32098603
- cultofmetatron 4y agoI just sent this to our devops guy with the headline "INVESTIGATE FEASABILITY, I WANT THIS ASAP"
- johnthescott 4y agorelational databases do best with facts. a proper materialized view is just another fact. in my experience materialized views are critical for most large databases.
- WesleyJohnson 4y agoOne of the many reasons I wish we hadn't chosen MySQL. Our internal dashboard has loads of "reports" that are basically tabular displays of queried data with optional filtering and sorting on every column, plus pagination. It's near impossible to make any of them performant due to not being able to optimize for a specific use case; because of the myriad of combinations of filters and sorts different users might apply. We've tried to explain this many times over, even bringing in a DBA consultant who said the same thing, but we're still met with "why is this so slow?" on a regular basis. Materialized views wouldn't be a silver bullet, but it would certainly help by allowing us to "cache" all of the joins and pre-processing into indexable views.
- royjacobs 4y agoThe example shown has 14GB of data, which is absolutely tiny, yet it can still rack up $40k in costs per day if used incorrectly (i.e. less than optimal, but not egregiously wrong)? Why would you use this?
- Foobar8568 4y ago
- sumtechguy 4y agoNever ever become 'the SQL guy' in your group. No one wants to learn it. SQL is the intersection of set theory, computational theory, network usage, cpu usage, and laziness. "your table is 120 columns wide and nothing but strings with no rules of the data types and no indexes, sooooo your perf is a bit slow huh?" "yeah how did you know?" "wild guess"
- Foobar8568 4y agoAmong my favorites, "NULL" vs NULL, date/timezone/utc and locals, anything related to data warehouse. Transferring everyday billions of records from SaAS applications.
- beckingz 4y agoWe should start a business selling data intelligence to solve this problem. Maybe call it... business intelligence?
- oefrha 4y agoScanned 6.67GB and processed for 2.41s, cost $40340.16 / 86400 = $0.4669. More than the hourly cost of AWS on-demand a1.x4large with 16 vCPU and 32GB of RAM. Can’t think of a worse advertisement for their product.
- altdataseller 4y agoSeriously, when i read this, i was like, there is no way i will ever use this example product they mentioned in TinyBird. After reading it, i was curious what the writer’s relationship was with TinyBird. Was he/she a recent user? Then i put my palm over my face..
- schnebbau 4y agoI can think of another way to save $40k/day: don't use this product.
- bernf 4y agoIsn't this all extremely elementary and common knowledge for someone designing these workflows? Next blog post about how to not waste money by just not doing something extremely poorly optimized.
- cosmolev 4y agoDon't use floating point for monetary calculations.
- johnthescott 4y agoat $40k/day SAVINGS you could build your own dc, easily.
- doix 4y agoI'm really curious how people use these types of platforms in practice. It seems really easy to screw yourself over when you're "expirementing". The advice seems really obvious, but I'm sure I'd absent mindedly do a super naive query at some point and potentially cost my employer a lot of money. I worked on a system to capture the production test data in a semiconductor company. We had trillions of rows and terabytes of data. While we were figuring stuff out, I'm sure I ran queries that scanned the entire dataset accidentally. I imagine one of those queries would have cost at least 1k to run. Our entire setup cost less than 10k a month to run on AWS regardless of how many queries we ran. I can't imagine spending 40k on 14gb of data regardless of what you were doing.
- _peregrine_ 4y agoYeah I mean I look at this example and it’s obviously pretty “extreme” - nobody is running that query every second (at least I hope not) - but I think the principle is important. You run that query once a day and it’s still costing you 1Kx what it would if it were optimized.
- 101008 4y agoI remember when I studied databases in college, the execution plan took care of what to do first: join, filters, etc (I remember doing excercises with paper and pen where I got a query, a few tables, and I had to build the optimal execution tree). So this product is not only expensive, but I have to think of the execution plan myself? Or I am wrong and modern dbs don't do that?
- blandcoffee 4y agoI've understood it to be a bit more nuanced than that. If you were to perform two queries: Query 1 -> join Table A with Table B, both have 1M records Query 2 -> Filter Table A to 10k records, then join Table A with Table B (1M records) I would expect Query 2 to execute faster - I don't think the exec plan would've optimized Query 1 equivalently.
- a_c 4y ago> What if I told you I could save you $40,000 a day? Learn from history, specifically, SQL. Or people who think they are too important to learn SQL aren't that important after all
- yellow_lead 4y ago> If I built an application to visualize this result and refreshed it every second, I would spend $40,340.16/day on Tinybird’s Pro-plan. What? Even if I used SQLite on my laptop and queried this thing every second, I'd still use <$3 a day. Also, this platform has no concept of caching? Don't understand this post at all, total clickbait based on an inefficiency in your platform you really shouldn't be advertising.
- femto113 4y agoThis headline is egregiously misleading clickbait, since it is based on an absurd and self contradictory hypothetical: "If my product had 10,000 daily active users generating 100 events per day, I’d easily hit that size in less than a year ... If I built an application to visualize this result and refreshed it every second, I would spend $40,340.16/day on Tinybird’s Pro-plan" There is no plausible business sense in refreshing the display of a year's worth of data every second, and even scaling back to a likely still-unreasonably-frequent refresh rate of once per hour you're down to just $11/day.
- krnlpnc 4y agoI'm sorry but if your egress costs are 40k/day I think it's time to consider leasing your own pipe. $1.2 million per month will get you one hell of an internet connection.
- didgetmaster 4y agoMythical creature vs 'Real-World Sighting'? I try to never underestimate the potential for someone to do something really stupid and I'm sure there are some egregious examples out there where a DB was set up and run such that outrageous charges resulted; but has anyone seen a situation in real life anywhere close to this kind of example? Even if there was a instance where a poorly designed and implemented data set caused a $40K charge for a single day; I wonder how long it would take for the bean counters to notice and take action?
- nickdothutton 4y agoLost me at refreshing every second. Probably only needs updating a couple of times per day. This is why you drill into requirements rather than blindly accepting them without question.
- _peregrine_ 4y agoSo I read the full article and it's interesting. Maybe the title is a little misleading, but when you actually read it I think they make it pretty clear that it's an extreme example designed to prove a simple point: bad data practice has a cost. For somebody who isn't super data savvy but wants to get into the space, I actually found it helpful.
- deleted 4y ago[deleted]
- johnthescott 4y ago$40k/day. no way.