[HN Gopher] PlanetScale Insights: Advanced query monitoring
___________________________________________________________________
PlanetScale Insights: Advanced query monitoring
Author : arjunnarayan
Score : 75 points
Date : 2022-05-26 15:02 UTC (7 hours ago)
(HTM) web link (planetscale.com)
(TXT) w3m dump (planetscale.com)
| gtCameron wrote:
| We moved from Aurora Serverless v1 to PlanetScale a couple months
| ago and love it so far. Tools like this are super helpful for
| someone like me who is a full stack developer with limited DB
| expertise to keep our platform running smoothly.
|
| Their team is awesome, I requested a couple features in the CLI
| and they were there within a few hours. Support is responsive and
| the sales team was super helpful getting everything running and
| migrated.
| joshstrange wrote:
| This is a great addition to the PlanetScale offerings. One of the
| scariest things with PS was "I have no clue how many rows are
| read/written" and usage-based plans are hard if you don't think
| in the terms they they charge in. It was just a metric I had
| never tracked or done much work on. That might be telling of
| myself and my DB management skillset (or lack there of).
|
| So far my usage has been minuscule in comparison to the PS
| limits. That said, I had been hoping for better tools to identify
| "problem queries" early instead of just when the billing cycle
| comes up and so I'm happy to see work in that direction.
|
| Just a random anecdote about PlanetScale:
|
| A few weeks ago I realized their databases did not have the
| timezone database loaded into them and it wasn't something I
| could do myself. I needed this so I could do `CONVERT_TZ` to
| convert from UTC to the user's TZ (for report aggregation). I
| reached out to support and in about a week they had added it to
| their roadmap, shipped it, and turned on the new feature for my
| DBs. They have been a joy to work with so far and I encourage you
| give them a shot, especially if you are on Aurora Serverless (V1
| or V2).
| gopalv wrote:
| > That said, I had been hoping for better tools to identify
| "problem queries" early instead of just when the billing cycle
| comes up and so I'm happy to see work in that direction
|
| I see the documentation and graphs, but can't find if
| PlanetScale provides a query interface into this data.
|
| Single user systems do okay with reports like the ones I see in
| the link, where you can actually go in and drill-down into
| specific details in there.
|
| It would much more awesome for the DBA style user if the
| reporting data was actually just loaded into another
| database/table with join schemas to query the data exactly as
| the report did. That of course, assumes the DBA is consultant
| type who is dropped in to fix cost overruns rather than the app
| developer going over their queries again.
|
| In my last job, I built something of this sort (Hive has a
| protobuf SerDe + a special table named sys.query_data), so that
| I could connect up a CDSW Jupyter notebook and narrow down
| queries with a python program + a loop.
|
| Of course, the queries themselves were also customer-paid
| queries, but it was much more flexible + a bunch of canned
| reports did most of the work when moving it across customers.
|
| But before it was baked-in into Hive/CDW, it was actually a
| syslog parser which fed into a sqlite db which is almost
| exactly the same (but mostly intended at solving txn
| locking/conflict checking across hundreds of queries touching
| the same informatica audit log table).
| throwusawayus wrote:
| tz setup is done with executing a single script. not surprising
| they could fix quickly. bigger surprise is they forgot to do
| this before youre support request. generally this is table
| stakes for managed DB
|
| this is fourth day in a row of planetscale ads^H^H^H blog posts
| being on hn front page. as i mentioned on yesterdays thread,
| innodb_rows_read is known to be buggy. regardless, by design it
| includes cached rows. terrible thing to base billing on. real
| cloud providers base it on i/o instead since this is more
| reasonable metric of "use"
|
| planetscale's fork of mysql-server adds only a single commit,
| which exposes rows_read in an extra place. this from company
| that keeps talking about "building a database"
| https://github.com/planetscale/mysql-server
| mattlord wrote:
| Installing the time zone tables on a single instance is
| certainly not hard:
| https://dev.mysql.com/doc/refman/8.0/en/time-zone-
| support.ht...
|
| The trickier part is orchestrating the ongoing management of
| that across a large dynamic fleet. And in this case, it was
| much more than simply loading the tables but about using them
| to support importing databases into PlanetScale:
| https://github.com/vitessio/vitess/pull/10102
|
| I'll link to my other comment on the billing issue:
| https://news.ycombinator.com/item?id=31509240
|
| We've had to do some other changes to our MySQL fork as well
| that will show up there, but we'd love to not have any
| patches! We'd love to keep the patch set minimal (just as
| Amazon certainly does with RDS and Aurora). And I would
| certainly argue that Vitess, which is what we build
| PlanetScale around, is a meaningful piece of technology that
| pairs with MySQL to make a great database: https://vitess.io.
| You're of course free to disagree -- and I wish you all the
| best as you work to build something great in the future.
| throwusawayus wrote:
| what other managed sql DBs charge based on rows read,
| regardless of whether they are on-disk or in-memory? honest
| question. i am familiar with a number of managed mysql and
| postgres products, and none of them bill this way that i
| have ever seen
|
| and for the record, despite planetscale staffers repeatedly
| denigrating rds (your competitor) on hn, aurora's patch set
| is not "minimal"
|
| i do think vitess is cool for what its worth. i just think
| your managed db product has bananas billing and also is
| horrendously over hyped, and your ceo's responses to
| criticism are very reminiscant of theranos or wework's
| responses to same
| mattlord wrote:
| I doubt that anyone would claim their billing metrics are
| perfect. If you find some specific workload that's
| _actually cheaper_ on another serverless database
| offering then we 'd love to hear about it (we strive for
| transparent, generous pricing). If you don't think that
| CPU usage based pricing -- which is typical for
| serverless offerings and e.g. is what Aurora serverless
| uses in Aurora Capacity Units (ACUs) -- is charging you
| for reads of cached data then I've got some bad news for
| you. :-) You're almost certainly being charged for
| reading the "row" from the network, write-ahead-logging
| for it and other ACID/MVCC related overhead, writing it
| to block device, reading it from the block device,
| reading it from memory, writing it to memory, sorting and
| comparing [pieces of] it, and writing it back to the
| network -- all of these things take CPU cycles. I find
| this argument to be entirely missing the point.
|
| Pointing out that surely Amazon would like to keep their
| patch set to a minimum (there's a high cost in
| maintaining custom patches as you upgrade MySQL) is in no
| way implying that their patch set is small. Minimal means
| the minimum required for what you need, rather than being
| some point of pride.
|
| I'm certainly not on here bashing any other offerings.
| Between the two of us, I only see one person trolling /
| bashing. :-) With that, I will leave you to your opinions
| which you are of course free to have. Best of luck.
| throwusawayus wrote:
| aurora serverless pricing is not based on _cpu cycles_.
| this is just not how ACUs actually work or scale or are
| priced, at all man
|
| anyway i gather the answer to my question is that no,
| there are no other examples of managed sql dbs that bill
| the way you do. my complaint is this is inherently not
| transparent because it violates user expectations. users
| try comparing to io based provders and fail to understand
| the pricing math comparison (on io pricing 1 read = many
| rows) or caching implications (on io pricing, cached rows
| dont count as io)
|
| as for denigrating rds, look to your ceos past hn
| comments. i would link to it, but last time i did that i
| got flagged, despite it being a recent thread that i was
| directly participating in
| mattlord wrote:
| It's fairly difficult to find actual details on ACUs and
| how it all works, the best I found after spending
| significant time looking was things like:
| https://www.jeremydaly.com/aurora-serverless-the-good-
| the-ba...
|
| According to AWS you're paying for chunks of CPU and
| memory on a per second basis:
| https://aws.amazon.com/rds/aurora/faqs/
|
| It's hard to imagine that the CPU capacity is measured in
| anything other than CPU cycles (time slices of physical
| capacity) -- in the same way it's hard to imagine that
| the memory capacity is measured in anything but bytes.
| But whatever, I don't care. It's cool, good for them. The
| point was... you don't think you're paying for reads of
| records that are cached? I give up, I fail to see how
| this can really be a good faith discussion.
|
| I don't know how all other serverless database offerings
| do pricing. What difference does it make? They're all
| different. As a user, you want it to be based on your
| usage and to be fairly and reasonably priced while also
| being easily audited and predictable. Those are the key
| properties I would care about.
|
| I honestly cannot see how you could be missing the point
| by this much and still be operating in good faith so I'll
| for real, for real stop. :-)
| throwusawayus wrote:
| you just are not understanding my point, that does not
| mean i am acting in bad faith! jeez
|
| i originally said pricing for other managed sql dbs, not
| specifically "serverless" ones. we both know that is just
| a marketing term anyway
|
| with ACUs the point is you configure min and max, and
| your cluster scales up/down based on a cpu utilization
| threshold. so, sure reading from memory uses cpu cycles
| -- but a large cached read is _incredibly unlikely_ to
| bump you over a scaling threshold which affects your
| bill, unless you're doing some huge heavy sort operations
|
| another key point is aurora serverless v2 does not scale
| down to 0 acu. you are always paying a predictable small
| amount for your base cpu and ram. minor increases in cpu
| usage literally do not impact your bill at all, which is
| why i do not believe your argument makes sense regarding
| cached reads.
| samlambert wrote:
| You think about us way more than is healthy.
| throwusawayus wrote:
| this is your response to valid criticism of your pricing
| model and functionality? as ceo? really?
| samlambert wrote:
| We love feedback and criticism. You show up on all of our
| threads and take it way too far. I promise you, nothing
| you say to us will throw us off our vision and mission.
| You will only make yourself angrier and less happy by
| yelling at us on this website.
| throwusawayus wrote:
| if you think purpose of my comments is to "throw us off
| our vision and mission" you are mistaken
| Scarbutt wrote:
| The lack of FKs is a turn off for most apps.
| joshstrange wrote:
| I can understand that, for myself I don't miss them. An index
| on the column is just fine for me and personally I prefer to
| manage that in the application layer (I know I'm probably not
| in the majority). Lack of FKs is what allows for their
| scaling technique (using Vitess) from what I understand. I'll
| say for my use it's not been an issue but I do understand
| that migrating an app that does need/use them might be
| hard/impossible without other big changes in the code.
| ithrow wrote:
| Looks like a must-have thing that is also missing from
| planetscale is point-in-time recovery.
| KwisaksHaderach wrote:
| PiTR is like the primary reason for us using a managed
| DB, it's indeed a weird and fatal omission from a managed
| DB offering.
| [deleted]
| datalopers wrote:
| Database-enforced FKs are an overrated crutch anyway. Apply
| the third normal form, utilize transactions correctly, and
| you won't ever need them.
___________________________________________________________________
(page generated 2022-05-26 23:02 UTC)