UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス
Why Uber Engineering Switched from Postgres to MySQL
We’ve represented the old version in red and the new row version in green. Under the hood, Postgres uses another field holding the row version to determine which tuple is most recent. This added field lets the database determine which row tuple to serve to a transaction that may not be allowed to see the latest row version. With Postgres, the primary index and secondary indexes all point directly
Server Side React with PostgreSQL — そこはかとなく書くよん。 ドキュメント
Server Side React with PostgreSQL¶ Reactjsいいですよね。うちでもすでにReactで書いたサービスを動かしています。 さて、Reactjsの売りの一つはServer Side Renderingだと思います。すでに各種言語で動かしている方がいらっしゃいます。一例: Java: http://www.slideshare.net/makingx/reactjs-meetupjavassr go: https://github.com/olebedev/go-react-example python: https://github.com/markfinger/django-react でも、ちょっと待って下さい。サーバー側でレンダリングするなら別にAppサーバーにやらせる必要はないですよね。むしろ、データを保持しているDBにやらせれば、データの移動がな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
