gmcquillan

This reminds me of my project a bit: https://www.scrydata.com/. I spent a bunch of time trying to automate the migration portion to take the risk out of doing these big migrations. I wonder if you thought a more automated tool might be of use for ongoing migration testing?

We built a tool that catches migration regressions before production by replaying real query traffic against shadow databases.

The blog post walks through a concrete example: a missing index that causes a 92x regression on a core query path. Staging misses it because it has 100 rows instead of 25k. Scry catches it because it replays actual production queries at real data scale.

You can replay this exact scenario locally in under 2 minutes:

scry demo Install: https://github.com/scrydata/scry-cli/releases

The demo spins up a source Postgres, applies a migration with a missing index, replays captured traffic, and shows you the regression report. No cloud account needed — everything runs locally.

Happy to answer questions about the architecture (transparent PG proxy for query capture, CDC replication for shadow databases, NATS for event streaming).

Squarespace Infrastructure | Portland, OR; New York, NY | Onsite | www.squarespace.com | Will relocate

Our platform empowers millions of people — from individuals and local artists to entrepreneurs shaping the world’s most iconic businesses — to share their stories and create an impactful, stylish, and easy-to-manage online presence.

https://www.squarespace.com/about/company

We're currently hiring the following roles in our Infrastructure Organization:

* Senior Traffic Engineer: https://www.squarespace.com/careers/jobs/2152045

* Senior Compute Engineer: https://www.squarespace.com/careers/jobs/2187986

* Senior Database Engineer: https://www.squarespace.com/careers/jobs/2187994

Tech Stack: Backend: Java, Golang, some Python. Frontend (Where applicable): ReactJS.

I think that if the uncertainty of the models were under threat, then this would be a bigger issue. We'd be reading about this in Nature, not The Economist.

This premise, I think, has flaws:

I didn't see any citation for the "past 15 years air temperatures at the Earth’s surface have been flat" number, but I do notice that the NASA number quoted is a five year running average (over only 10 years), which would naturally flatten any trends over that time frame.

It seems like this notion that "warming is over" is pretty cyclical. Check out: http://www.skepticalscience.com/global-cooling-january-2007-...

This image in particular is interesting: http://www.skepticalscience.com/graphics/Escalator_2012_500....

And the "What do we make of this" is definitely a valid question. Every model is going to be inaccurate to some degree. We should strive to improve them!

I took issue with picking a few individual researchers' models which have a lower range than the IPCC estimates (which are influenced by those lower estimates). The case could, and probably is, be made for higher ranged estimates. The point is, if you curate a subset of models to bolster your bias, you're not contributing any meaningful data to the discourse.

I don't know that I agree with the thesis of this article whatsoever; basically some cherry-picked research estimates "we may only see 1.5 to 2 degree increases, and we haven't had any real warming in the past 10 years; Therefore, we might want to reevaluate the amount of energy and attention we spend on mitigating carbon emissions"

That seems like a pretty flimsy argument.

1. I don't think there's strong evidence that 'global average temperatures stopped increasing.' Many of the world's largest average temperature readings have happened in the last ten years (2010, especially, but even recent reports show upward trends: http://www.ncdc.noaa.gov/sotc/national/2012/13).

2. Cherry-picking a few people whose models show a lower than average range, doesn't tell me anything other than the author of this article is suffering from wishful thinking.

3. The heart of the article seems to be suggesting this: "If climate change isn't that bad, maybe we don't have to do anything about it, " but ignores the opposite proposition. Oddly, I'm not even sure why such an article is necessary since the world collectively isn't making any earnest attempts to curb carbon emissions. Any reductions have been economically based, not environmental.

No, I think this is a hit piece on the climate change movement couched as due-diligence and beneficial skepticism.

This may be old, but I just stumbled upon it.

I'm not sure you read the article fully, because relationships were never described in the article. Instead, it was high read/update load which caused problems.

Mongo, on paper, should be an ideal candidate for this job; but, due to complications with the locking model and with its inability to do online compactions, it's failing.

I'm more interested in which databases people are using.

Funny. I totally forgot that Softlayer had bought ThePlanet. So, I guess the distinction is redundant.

Interesting. Thanks for the info. This is definitely the kind of information I'm looking for.

Joe,

We have a combination of random and sequential data access patterns. Our data fits really well into key/value data stores, such as Cassandra. We'd prefer to get 10k qps for random I/O, of course that's data-model dependent.

Our Data is currently in the hundreds of gigs to several terabytes, but is likely to increase quite a bit in the coming months.

If we buy hardware, we're definitely planning on testing SSD extensively.

The main question is about who to Colo or Rent from.

Urbanairship in Portland, OR is hiring for an Ops position: http://urbanairship.com/jobs/operations-engineer/

This is an interesting concept. However, I think this article needs to define its target audience better. It seems to be speaking specifically to people doing web hosting (which you may or may not argue includes all of LAMP use-cases).

The idea that we can forgo operating systems because there are APIs to call doesn't make sense if your company heavily invests in infrastructure. Sometimes you need low-level access to hardware to fine-tune performance and scalability because your use-case is not the general use-case, even in a "cloud" environment.

It definitely helped to separate the incoming queue from the actions queue on the central loghost. Unfortunately, I don't have good data comparing the two. At this time, our loghost is an EC2small, so relatively susceptible to I/O disruption, and we haven't had any problems.

If you're running a whole datacenter's worth of logs into your loghost, then you might want to consider a distributed approach. For medium sized companies, I don't see why rsyslog wouldn't do the trick.

In an ideal world this is true. But in reality we don't always have control over the codebase from birth until deprecation. Often, you find yourself a newcomer to code, and being able to reason your way though it can be time consuming, and scary.

I think this article's approach is a good one. Take precautions, use things like continuous builds, static analysis tools to boost your confidence, but DO make the necessary changes. Better sooner than later.

Fascinating. The thing I find interesting about this service is that it seems to work seamlessly with multiple queue backends. That would have been really useful at my company, where we completely swapped out our queue server infrastructure. Nice work!