HN user

WALoeIII

276 karma

https://www.andrewloe.com/

[ my public key: https://keybase.io/waloeiii; my proof: https://keybase.io/waloeiii/sigs/YA7PZUiF1uBYwXHp5NaXW6-noq_6l5IGSJxVxnCacqY ]

Posts3
Comments125
View on HN

Frequently at design time you don't know enough. This is exactly why SQL is great, it is incredibly flexible, it can also allow you to get in your own way, this is just a feature to help detect that.

This is very useful for batch or cleanup jobs.

For example, imagine a system where items are soft-deleted immediately upon user action, but not actually deleted for a few days to facilitate restoration (recycle bin).

There is going to be some nightly/hourly/scheduled job that actually really deletes these records. Initially it will have little work to do, but over time as the system grows it may become slow. Typically this would be hard to separate from other slow queries, you would have to catch it running while causing other queries to pile up. Query time isn't necessarily useful here as you may have enough I/O to cover the slow query replacing pages in the cache, but that I/O would be better serving user facing requests instead of this cleanup job.

This feature allows for the "work" it really takes to serve the query to cause it to error, instead of time which may grind down for other reasons. At this point you know its time to re-think the soft-deletion strategy, you disable the job. Maybe you sweep more frequently? Maybe you keep a look-aside of things to sweep to avoid scans? Maybe you sweep during a low-traffic time? Whatever. It buys you time to think.

I wish there were something comparable for MySQL.

The OAuth Bible 13 years ago

This is excellent, especially the diagrams.

I'd love to see a explanation of the security implications of each flow. As I understand it the "most secure" flow is OAuth 1.0a (three-legged), but its a total pain so it is mostly avoided. OAuth 2.0 is dramatically simpler, but there are bespoke additions (Google and Facebook come to mind) that you have to handle, typically in the name of security. I am ignorant of all the implications and would like a guide.

You are thinking too hard. Just pick one, you can always change later.

All of the options you have presented are "Very Good" - they do so many things right. To steal a pithy quote from my co-worker: "Its a balloon squeeze."

This decision will not determine the success or failure of your business, move along.

I pick Rails & Ruby.

Next time you are caching a bit list with memcached and running out of space, you may replace that big list with a bloom filter.

This is why nginx gzips the body before writing the headers out.

You can use 'chunked_transfer_encoding' to enable chunking, combined with 'proxy_buffering off', your backend can stream the body and nginx will gzip the chunks. Disabling buffering has other consequences, so be sure to read up and experiment before you go to production.

In my experience you get an IP returned as an A record for each AZ you have instances in. Inside each AZ traffic is balanced equally across all instances attached to the ELB. The ELB service itself is implemented as a Java server running on EC2 instances, and it is scaled both vertically and horizontally to maximize throughput.

I wish I could upvote this 50 times.

The diagrams show two separate masters in different regions with their own slaves, yet DNS is essentially randomly delivering users to each "half". There is no mention of how this is handled, or even that you would have to consider it.

You can't just put nodes in different regions, even with a database like MongoDB. It will work in theory, in practice you'll have all kinds of latency problems.

WAN replication is a hard problem and glossing over it by waving your hands is a disservice to readers.

"Real" solutions are to run a database that is tolerant of partitioning, and have application level code to resolve the inevitable conflicts. Riak, Cassandra and other Dynamo inspired projects offer this. On the other hand you can use a more consistent store and hide the latency with write-through caching (this is how Facebook does it with memcached + MySQL), but now you have application code that deals with managing this cache.

Either way you have to have very specific application code to handle these scenarios, and you may even run a combination of solutions for different types of data you need to store. There is no silver bullet, there is no framework or product that does it for you.

Amazon EC2 down? 14 years ago

A "full-spec" machine, another X-Large with 4 EBS volumes that I can fail over to. Its in circular replication with the other "active" master (only one is receiving writes at a time). These instances are only snapshotted once a day to keep them as fast as possible.

Amazon EC2 down? 14 years ago

I run a master with a "hot" master each in a different AZ and slaves of each in their respective AZs for days like today. Expensive, but makes it easy to sleep at night.

The slaves have their EBS disks snapshotted every 30 minutes, the master every 24 hours.

Agreed, start with a known entity. Take the one special table that is killing you and move it to a special database (Riak/Cassandra etc) suited for that task only once you understand exactly what you need.

Eventual Consistency is a feature, not a limitation of Riak (and friends).

It requires you to think about your application different, but it enables things that you could not do before.

For example, you can now handle databases in multiple datacenters, reducing latency to the client.