6,947 karma · joined February 24, 2011
I guess the ability to have a schemalass and no type checking format (just like JSON), while enjoying some performance benefits? It just feels like a weird niche to me.
With MessagePack the schema is embedded alongside the data, exactly like JSON. So it's just binary instead of text encoding, which saves some space, but as you pointed out, standard text compression algorithms are going to likely perform similar or superior.
Edit: Apparently my sarcasm wasn't thick enough so let me make my point crystal: COVID-19 is a real, genuine threat that's just getting started, but HN is filled with armchair fuckwits [1][2] who dismiss it because they lack simple math skills.
Of course. It's just managed by someone else and you often are paying per usage. And you'll find yourself needing to wrangle numerous serverless platforms to actually build out relevant business logic if you want to do something meaningful, one third-party microservice at a time.
> Also, because it's just a static site, there's no backend or database, so you get better security.
It's not as trendy to think of it this way, but "static sites" are just caches with manual invalidation.
That so feels like a mistake because that's the sort of tactic that would completely and utterly remove their capability of ever working as a corporate lawyer ever again for any company.
If that genuinely happened, that lawyer needs to be disbarred, but that's a pretty damn egregious accusation.
Or maybe we're in a tech bubble and if you want engineers, you have to acquiesce to their demands of working with the latest shiny tools while they create mountains of technical debt, because if you don't, they'll just go to another startup that allows that behavior, or they'll go twiddle their thumbs at a FAANG while banking $300k+ total comp for their 5-years of experience.
I'm not trying to say one could replicate this business with a few scripts, but it sure as hell doesn't need a service mesh that looks like a mutated SARS-CoV3.
My bigger point to the OP was why bother using a DBMS that is specifically tuned for running fast analytical queries if they only intended to use it as a storage layer and pushing all of the analysis into Python. Use a solution focused on storage, not analysis, if that's the use case.
> As i'm sure things like pivot tables and rolling windows are a PITA in SQL
I can't speak for clickhouse, but group-by and window functions are a very standard part of any SQL analysts toolbelt.
Pricing is about the same and it's guaranteed to you, not to a instance that may get shut down
That's significantly different from someone running their own ecommerce site where they are very clearly the merchant of record.
[1] https://wordpress.org/plugins/static-html-output-plugin/
From the article: "However, by 2015, as VisualEditor and Parsoid matured and became established, maintaining two parallel wikitext engines in perpetuity was untenable"
They didn't write it in PHP for speed, that was merely a side effect. They wrote it in PHP so they could have a single language for the system.
To anyone reading this: Don't store lots of small files on S3. It's a terrible idea.
Provisioned IOPS is one area that can get expensive very quick, but people often don't realize that you get 3 PIOPS included with every 1GB of allocated storage, so you really don't need to pay for provisioned IO if you have a decent amount of storage.
If you want auto-scaling you need to look at Aurora or Redshift, which are quite different and significantly more expensive. I've not used those.
So, no, I don't know why anyone would use bitbucket at this point.
That's by design. Amazon has found it's far more effective to deploy their excess capital toward company expenditures in the form of acquisitions, real estate, capex, employees, stock buybacks, etc rather than letting it get taxed as corporate operating income.
Those dollars do ultimately get taxed, to be clear, but in the form of employment taxes, individual capital gains, individual income taxes, and property taxes.
Make a product that seamlessly integrates with the rest of their ecosystem so they're more likely to acquire you than replace you.
When doing multiprocessing, it's advisable to fork() instead of creating fresh processes (or launching them in containers etc). As long as you preload the necessary libraries/modules in the parent process before the fork, children will reference the same memory in a copy-on-write fashion. It keeps overhead extremely low.
This [1] article is for the Unicorn (ruby) webserver but the way it explains forking, signals, and pipes for inter-process control it's absolutely illuminating. These techniques are applicable to any unix-based applications, including php daemons.
[1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...
https://www.amazon.com/dp/product/1118530802 and possibly https://www.amazon.com/dp/0764567578/
e.g. insert into rollup_clicks_hourly select hour, count(*) clicks from clicks where created_at >= ? and created_at < ? group by 1
Justin Kan sold Twitch to Amazon for nearly $1B after 7 years, Socialcam for $60M in 18 months, and Exec for "under $10M" in 2 years.
That's how he raised $75M. The company/product was completely irrelevant.
And nothing happens, 6 months later AWS launches your exact product.
Founders need to be extremely careful when talking to potential acquirers. Dollar signs cloud your vision and you need to understand why they're talking to you. It may be genuine interest or it may be deceit in order to gain a competitive edge.