Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する
Customized Welcome GreetingA welcome message is a crucial part of any chatbot experience. It is quite literally the first interaction a user has with your chatbot. Sample QuestionsHaving chatbot sample questions helps users understand what to ask by providing clear examples of the types of queries the chatbot can understand and respond to effectively. Voting Thumbs Up/DownThe "thumbs up/thumbs dow
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
FriendFeedのBret Taylorが、スキーマレスなデータ（スキーマ（型）に制約されないデータ）をMySQLに格納する方法を紹介している。実際にFriendFeedで使っている方法で、最新のものらしい。 Bret Taylor's blog - How FriendFeed uses MySQL to store schema-less data http://bret.appspot.com/entry/how-friendfeed-uses-mysql MySQLを通常のRDB的な方法でなくストレージ的に使い、JOINを使わないでスケールさせるというもの。CouchDBなどにも近い、最近有力になりつつあるアプローチだ。これを、実績もあり普及しているMySQLを使って実現し、言語はPythonで実装している。 メインのテーブルは次のようなもの。 CREATE TABLE ent
今流行のkey-value storageの利点と欠点など。小さいデータをたくさん扱うタイプで、単純なkey-value型のデータモデルを持つ分散KVSについて。 Webアプリをとりまく最近のKVS事情、雑感を読んで、ちゃんと整理して把握しておかないといけないな、と思ったので少し整理。 それは違うぞーという事があったらコメントくださいm(_ _)m ※2009-11-17 追記：現在、KVSという用語の意味は定義されておらず、使う人によって揺れています。ここで言うところの分散KVSは、Dynamo や kumofs や ROMA など を想定しています。 分散KVSの利点 スケールアウトできる 簡単にサーバーを追加して性能を上げられる 単体の性能が高い スキーマレス 最初は少ない台数で安く、後からサーバーを足してスケールアウト！という運用ができる。アプリケーションに影響せずに、ストレージ側
分散KVSが苦手なトランザクションの「ACID特性」 RDBのように、テーブルとテーブルを結合（SQLでいうJOIN文）して複雑な条件検索や集計処理を一発でこなすような芸当はできません。また、トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。 RDBが不得意な分散／拡張 そのため、これらの不足をアプリケーション側で補うためのさまざまな工夫やフォローが必要となります。その一方で、分散KVSはデータストア全体をいくらでも多くのサーバに分散（スケールアウト）できるのが最大の特徴です。 一方でこれは、RDBが最も不得意とするところです。RDBでは、その長所であるテーブル結合やACIDの確保がボトルネックとなり、複数のサーバにスケールアウトさせることが「原理的」に容易ではありません。そのため、負荷分散や高可用性を低コストで実現することが困難です。 RDBで負荷分散させようとす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
