Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

by Martin Kleppmann

The things that can go wrong are called faults,

Essa definição ficou muito abrangente, faltou uma diferença específica, de outra forma não tem diferença acidental com a subs.

Counterintuitively, in such fault-tolerant systems, it can make sense to increase the rate of faults by triggering them deliberately—for example, by randomly killing individual processes without warning.

Distingo: isto não é contraintuitivo; pois, se está se planejando para falhas, é necessário encontrar um modo de tensionar o sistema, para que o cenário de falha possa emergir.

Even when they have the best intentions, humans are known to be unreliable.

Seguindo esse linha de pensamento, eu me pergunto se de algo "unreliable" pode sair algo "reliable". Parece que não, porque toda criação imita o seu criador, como está escrito na glosa "Omne agens agit sibi simile". Assim como uma pegada deixada na lama imita a forma daquele que a deixou. Logo... É evidente que a confiabilidade de um efeito deve refletir a confiabilidade de sua causa. -- Concedo a maior; humanos são conhecidos por serem "unreliable", nego. Já que a medida da predicação aqui é dada pelo termo médio, segue-se que: os seres humanos são unreliable para medir reliability. Quod erat demonstrandum!

How do we make our systems reliable, in spite of unreliable humans?

Aqui há um erro clássico de predicamento de causalidade errônea, porque uma vez cesada a causa, cesa também o efeito. etc… A confusão entre causa eficiente e causa imediata é um erro comum que pode levar a decisões equivocadas. Se a causa de erro é a ação humana, não há como criar sistemas reliables [derivadas de ação humanas]. Respondo, concedo a antecedente; distingo a consequência: o objeto da ação aqui é na verdade criar sistemas confiáveis. Então, é necessário concebê-los de forma a mitigar os efeitos do erro humano. Logo, etc... Quod erat demonstrandum!

The median is also known as the 50th percentile, and sometimes abbreviated as p50.

O problema em usar p50 é que os números não serão uniformes. Prova da primeira; supondo que temos 10 pessoas; 9 dessas pessoas não tem casas; e uma única pessoa tem 10 cases: em média temos 1 casa por pessoa. Isso só funcionária em uma progressão.

The advantage of using an ID is that because it has no meaning to humans, it never needs to change: the ID can remain the same, even if the information it identifies changes.

Distingo a maior; IDs does not have meaning for humans; uma vez que um ID é como o tipo de sinal que leva consigo aquilo que é simbolizado, eles podem ser significativos para humanos. O argumento só leva em conta o que o símbolo representa, pois, uma vez que o simbolizado está presente, o símbolo deixa de fazer sentido. Logo, etc... Concedo a menor; e distingo a conclusão: se a informação simbolizada pelo ID mudar, o simbolizado mudou; e o ID sofreu mudança formal, apesar da matéria continuar a mesma. Quod erat demonstrandum!

The moral of the story is that a NoSQL system may find itself accidentally reinventing SQL, albeit in disguise.

Distingo; dado que NoSQL significa Not Only SQL, não se trata de reinventá-lo, mas simplesmente de implementá-lo.

If the same query can be written in 4 lines in one query language but requires 29 lines in another, that just shows that different data models are designed to satisfy different use cases.

Esse exemplo foi bem tendencioso. Ele montou uma estrutura de grafo em um banco relacional — o que fez a consulta de dados ridiculamente difícil — e depois concluiu-se que para esse caso específico, melhor seria usar outro tipo de banco. Obviamente, o problema aqui seria a modelagem dos dados, e não o que foi apresentado. A premissa menor também está viciada, porque o número de linhas em uma query não deve ser o fator principal para escolher entre data models; Logo, etc...

One thing that document and graph databases have in common is that they typically don’t enforce a schema for the data they store, which can make it easier to adapt applications to changing requirements.

“É próprio do sábio ordenar!” — Aristóteles.

At the time of writing, joins are supported in RethinkDB,

Isso é verdade, mas usando JOIN no RethinkDB vai retornar uma arvore binária com left e right node. Para realmente agrupar os dados temos que implementar um `zip`

say you’re looking for the key handiwork, but you don’t know the exact offset of that key in the segment file. However, you do know the offsets for the keys handbag and handsome, and because of the sorting you know that handiwork must appear between those two.

This is how a binary tree works!