
Portuguese: 
Para aumentar a velocidade do site
adicionamos outro banco de dados,
utilizando um software chamado Slony,
eu acho, para replicar nossos bancos.
Tínhamos um servidor de aplicativos
e fazíamos muitas requisições no banco.
Nosso caching
não era nem um pouco avançado.
Nós tínhamos um caching básico,
apenas no nível do aplicativo.
Esta máquina fazia requisições
às duas Postgres.
Foi a primeira vez que demos de frente
com o conceito de lag de replicação,
porque tínhamos duas máquinas separadas
que o Slony mantinha sincronizadas,
mas algumas vezes, a máquina escrava
atrasava em 5 segundos ou mais.
Se tivesse acabado de submeter um link,
fosse redirecionado ao permanente
e a requisição fosse para uma escrava sem
o link permanente, retornaríamos um 404.
Algo muito frustrante
após um envio de conteúdo.
Daí, começamos a pensar
em escrever no nosso cache
ao mesmo tempo
em que escrevíamos no banco.
Também tínhamos problema com os dois
processos de sincronizar os caches.
Não estávamos usando memcached ainda--
o modo como sincronizávamos o cache
era usando uma biblioteca chamada Spread,
a qual basicamente diz que
se enviar uma mensagem para um host,
ela será mandada para todos os outros.

Japanese: 
速度を上げるため 次はデータベースを足しました
データベースのレプリケーションに使ったのは[br]確かSlony-Iというソフトでした
APサーバが1つだったのでリクエストの数が膨大でした
キャッシングは最先端からほど遠く
ほんのアプリケーションレベルでした
これが2台のマシンにヒットするのです
この時最初のタイムラグが発生しました
Slonyが常に2台を同期させようとしますが
スレーブマシンが時々5秒ほど遅れるのです
投稿があったらパーマリンクにリダイレクトして
スレーブマシンにヒットして[br]ユーザに404エラーを出します
投稿の処理はとても面倒でした
この時キャッシュとデータベースへの
書き込みを思い立ちましたが
キャッシュの同期の問題が残っていました
当時はまだmemcachedは使っておらず
1つのホストにメッセージを送ったら[br]それを他のすべてのホストに送ってくれる
Spreadというライブラリを使っていました

Spanish: 
Lo siguiente que hicimos[br]para aumentar la velocidad del sitio,
fue agregar otra base de datos,
usando un software llamado Slony, creo,[br]para replicar nuestra base de datos.
En ese tiempo todavía teníamos[br]un solo servidor de aplicaciones,
y hacíamos muchas solicitudes[br]a la base de datos.
Nuestro almacenamiento caché[br]no era ni siquiera avanzado.
Teníamos uno básico, que solamente[br]estaba al nivel de aplicación.
Esta máquina estaba tocando[br]las dos máquinas PostgreSQL.
Esta fue la primera vez que comprendimos[br]la idea de demora en la replicación,
ya que teníamos[br]estas dos máquinas separadas,
y Slony normalmente[br]las mantendría sincronizadas,
pero a veces, la máquina esclava[br]podía retrasarse unos cinco segundos.
Si recién habías publicado el link[br]y luego te redirigíamos a permalink,
y luego tocábamos la máquina esclava[br]que no tenía el permalink,
enviaríamos al usuario un error 404
lo que es realmente molesto[br]luego que enviaste un trozo de contenido.
Ahí fue cuando comenzamos a pensar[br]acerca de escribir nuestro caché
al mismo tiempo que escribíamos[br]en nuestra base de datos.
También tuvimos el problema[br]con estos dos procesos
de mantener sus cachés sincronizados.
No estábamos usando memcached todavía.
El modo en que manteníamos[br]los cachés sincronizados
era usando la biblioteca llamada Spread
y Spread es una biblioteca de red[br]que básicamente dice
si envías un mensaje a un "host",[br]lo enviará a todos los demás "hosts".

English: 
The next thing we did to increase the speed of the site was we added another database,
and this was using a piece of software called Slony, I believe, to replicate our database.
We still only had one app server at this time, and we made lots of database requests.
Our caching was not nearly as advanced.
We had some basic caching, it was just at the application level.
This machine was hitting both of these Postgres machines.
This is the first time we ran into the notion of replication lag,
because we have these two separate machines, and Slony would normally keep them in sync,
but sometimes, the slave machine could lag by about 5 seconds or so.
If you had just submitted the link and then we redirected you to the permalink,
and then we'd hit the slave machine that didn't have the permalink we would send the user a 404,
which is really annoying right after you submitted a piece of content.
That's when we started thinking about writing to our cache
at the same time as writing to our database.
We also had the issue with these two processes of keeping these caches in sync.
We weren't using memcached yet--the way we kept our caches in sync
was we used the library called Spread, and Spread is this network library that basically says
if you send a message to one host, it will send it to all of these other hosts.

Japanese: 
この頃Pythonを動かすAPサーバを追加し
キャッシュとして使っていた2つのハッシュテーブルを
Spreadで同期していました
キャッシュの同期はこれでうまくいきましたが
スケーリングが難しかったので
APサーバを更に2台増やしました
キャッシュをアップデートする度に
他のすべてのサーバに知らせる必要があったので
膨大なアクセスのキャッシュを同期させるのは[br]本当に大変でした
その結果memcachedに変更したのですが
それはデータベースを書き換えたあとでした
マシンとデータベースの変更後 コメントを足しました
最初のバージョンはデータベーステーブルでした
複雑なことは何もありませんでした[br]テーブルにはリンクIDと
コンテンツと作成者IDがありました[br]どんな行か想像がつくでしょう?
結合もたくさんしました[br]リレーショナルデータベースです
この時データベースをもっと柔軟な構造にしました
なぜなら問題にぶつかった時は必ず
どこかのテーブルに新しいテーブルや
行を足す必要があったからです

Spanish: 
Por entonces fue que agregamos[br]nuestro segundo servidor de aplicaciones
que estaba ejecutando Python también,[br]y usamos Spread
para mantener las dos tablas de hash
que estabamos usando como nuestra[br]suerte de caché sincronizado.
Esto funcionó casi bien en términos[br]de mantener estos dos cachés en sincronía,
pero no iba a a escalar muy bien,[br]porque eventualmente,
podríamos agregar un par más[br]de servidores de aplicaciones
para administrar más carga.
Y Spread, en cada oportunidad
en que uno de estos servidores[br]de aplicaciones actualizara su caché,
tendría que avisarles a todos los demás[br]servidores de aplicaciones de eso,
y se convertiría en un inmenso desastre,
un montón de tráfico de red para mantener[br]todos estos cachés en sincronía.
Fue un desastre total, y eventualmente[br]nos cambiaríamos a memcached,
pero eso no fue hasta antes de reescribir[br]nuestra base de datos.
Poco después cambiamos un par de máquinas[br]y un par de bases de datos,
agregamos comentarios,
y la primera versión de los comentarios
-- era otra tabla de base de datos.
No hay nada complicado en eso
--tenía un ID link[br]acerca de qué link estaba ahí
y tenía algunos contenidos, ID de autor,[br]puedes adivinar las columnas que tendría,
y todavía hacíamos muchos joins[br]--era una base de datos relacional.
Esta vez cambiamos a una arquitectura[br]de base de datos más flexible,
o por lo menos un diseño[br]de tablas más flexible,
debido al desafío que teníamos
cada vez que añadías una nueva característica,[br]podrías tener que agregar una nueva tabla
o quizás agregar una nueva columna[br]a una de estas tablas.

Portuguese: 
Nessa época, adicionamos
o segundo servidor de aplicativos,
também rodando Python, e usamos Spread
para manter as duas tabelas hash
sendo usadas
como forma de sincronizar o cache.
Isso funcionou até que bem para manter
esses dois caches em sincronia,
mas não aguentaria o crescimento,
porque eventualmente, nós adicionaríamos
mais alguns servidores de aplicativos
para lidar com a carga.
Toda vez que um dos servidores
atualizava o cache, a Spread
precisava comunicar isso aos outros--
o que se tornou uma grande bagunça,
muito tráfego de rede mantendo
esses caches em sincronia.
Era uma bagunça total.
Eventualmente, substituímos por memcached,
mas não antes de termos
reescrito nosso banco.
Pouco depois de mudar algumas máquinas
e alguns bancos, adicionamos comentários,
e a primeira versão dos comentários--
era apenas uma nova tabela no banco.
Não tinha nada complicado--
tinha um ID do link a que pertencia
e alguns conteúdos, ID do autor--
você pode imaginar as colunas ali.
Havia muitas ligações,
era uma tabela relacional.
Dessa vez nós mudamos para
uma arquitetura mais flexível
ou, pelo menos, um design mais flexível
de tabelas. O desafio era que,
a cada novo recurso,
teríamos de adicionar uma nova tabela
ou uma nova coluna a uma dessas tabelas.

English: 
Around this time was when we added our second app server
that was running Python on as well, and we used Spread to keep the two hash tables
that we were using as our cache kind of in sync.
This worked sort of okay in terms of keeping these two caches in sync,
but it wasn't going to scale very well, because eventually, we would add
a couple of more app servers to deal with more load and Spread
like every time one of these app servers would update its cache,
you would have to tell all of the other app servers about it and so turned in to the huge mess,
a lot of network traffic keeping all of these caches in sync.
It was a total mess, and so eventually, we would switch to memcached,
but that was not before we rewrote our database.
Shortly after we switched a couple of machines and a couple of databases, we added comments,
and the first version of comments--it was just another database table.
There's nothing complicated about it--it had a link ID of what link it was on
and had some contents, author ID--you can kind of guess the columns it would have,
and we still did lots of joins--it was a relational database.
We changed around this time to a more flexible database architecture,
or at least a more flexible table design, because the challenge we had
was every time we added a new feature, you might have to add a new table
or you might add a new column to one of these tables.

Portuguese: 
Adicionar uma nova coluna tomaria tempo,
poderíamos ter de migrar dados
ou atualizar um índice e adicionar
muito conteúdo. Era só dor de cabeça.
Sentimos que a velocidade de inclusão
de novos recursos era limitada
pela nossa habilidade de atualizar
bancos de dados e fazer grandes migrações.

English: 
Adding a column would take time, and we might have to do a data migration
or update an index and add all these load--it was just a total pain.
We felt like the rate at which we could add features was limited
by our ability to update our database and to do these big migrations.

Japanese: 
それは時間のかかる作業でした　データの移行や
インデックスのアップデートは本当に苦痛でした
当時の私たちの能力では アップデートや
大規模な移行作業は なかなかはかどりませんでした

Spanish: 
Agregar una columna puede tomar tiempo,
y tendríamos que hacer[br]una migración de datos
o actualizar el índice[br]y agregar toda esa carga
--fue un gran problema.
Sentimos que la proporción en que podíamos[br]agregar características estaba limitada
por nuestra capacidad para actualizar[br]nuestra base de datos
y hacer todas esas grandes migraciones.
