GoとDynamoDBを用いた開発で反省していること | フューチャー技術ブログ
はじめにTIG真野です。失敗談をテーマにした連載で、ちょうどプロダクト開発的に良い区切りのタイミングでもあるため、振り返りがてら、DynamoDB,Go,AWS Lambdaの技術要素について自分自身の理解・見込みの甘さについて反省します。 DynamoDBのシステム項目created_atとかupdated_atのタイムゾーンはJSTにすれば良かったDynamoDBは日付型を直接サポートしておらず、文字列型で保存することになります。 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes.String データサイズや諸々の理由でUnixTime 勢力もあるかもしれませんが、アプリケーションから直接参照
Dynamo: Amazon’s Highly Available Key-value Store
Dynamo: Amazon’s Highly Available Key-value Store Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels Amazon.com ABSTRACT Reliability at massive scale is one of the biggest challenges we face at Amazon.com, one of the largest e-commerce operations in the world; even the slightest out
ビッグデータだけじゃない Amazon DynamoDBの活用事例
概要：弊社が運用するWebAPIサービスをオンプレミス環境からAWSクラウド環境へ移行させた取り組みについてご紹介します。 弊社が持つデータベースはレコード数が巨大であるものの、いわゆる「ビッグデータ」的ではないデータ構造や負荷パターンを持っています。これをAmazon DynamoDB上に展開してシステムを構築しましたが、結果としてデータの特性とAmazon DynamoDBの仕様とがうまくフィットして機能していると思います。 移行にあたって感じたAWSそのものやAmazon DynamoDBの特徴のほか、コスト面・運用面での変化についてもご紹介します。典型的なユースケースについては他のスペシャリストの方にお任せするとして、「こんな使い方もできるのか」というヒントをお伝えできればと思っています。Read less
NoSQLのAmazon DynamoDBがJSONドキュメントに対応、25GB/月間2億リクエストまで無料枠も拡大
NoSQLのAmazon DynamoDBがJSONドキュメントに対応、25GB/月間2億リクエストまで無料枠も拡大 Amazonクラウドが提供している「Amazon DynamoDB」は、フルマネージドのNoSQLデータベースです。ほぼ無限にデータベースをスケールさせることができるため容量のことを気にする必要がなく、固定されたスキーマを持たない柔軟性と、SSDを利用することによる高いスループットを実現。NoSQLでありながら一貫性を制御するオプションも備えています。 まさにクラウドの特長を活かしたサービスであるDynamoDBが、JSONドキュメントをデータ型としてサポートしたと発表されました。 これでDynamoDBのスケーラビリティや性能はそのまま、キーバリュー型だけでなくJSONドキュメントも扱えるようになりました。 キーバリューに加えてJSONドキュメントも JSONとは、Jav
AmazonのDynamoの論文を読んでみた(1/3) - 工場長のブログ
Amazonが社内で開発し、サービスで利用しているDynamoというストレージサービスがあるのだけど、これについての論文が公開されていたので読んだのでまとめてみる。 この論文を書いたメンバーにはAmazonのCTOであるWerner Vogelsや、AWSでDynamoDBやElastiCache、SQS、SNSなどの製品のマネージメントをしているSwami Sivasubramanianらが含まれている。 Dynamoをひとことで表すと分散型でKey Valueストレージで、データの一貫性に関しては結果整合性を保証するサービスだ。なお、AWSで提供されているDynamoDBとは別物なので注意。 原文はこちらから参照できる。今回のポスト中の引用(図や文問わず)はすべてこちらから引用している。 また、既に日本語訳をされている方もいらっしゃるので原文をそのまま日本語でよみたい人はこちらを参照の
Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話（２） 〜DynamoDB導入事例〜 - Tech Blog
CTOの椎名アマド ( @ima_amataro) です。 前回の記事：「Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話（１）」 前回はRedisをチャットのプライマリのストレージとして使う上での問題点と、 Amazon DynamoDB の特徴などを紹介しました。 今回はDynamoDBの詳細説明と、実際の移行作業と、その際にハマった点をお話していきます。 DynamoDBのテーブル構成 まずは DynamoDB 上のテーブル構成を考えるところから。 Redisにおいてはシンプルな list にチャットを保存していて、 chat.room.{room_id} {timestamp}:{user_id}:{urlencode(message)} {timestamp}:{user_id}:{urlencode(message)} {tim
Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話（１） - Tech Blog
CTOの椎名アマドです。 今回は、Pairyのチャットデータを全てRedisからAmazon DynamoDBに移行した話をしたいと思います。 我々が 2012年6月に カップル専用アプリ Pairy をリリースした時には、 データベースは MySQL と Redis の両方を利用するところで始めました。 Redis の役割は： 1. MySQLレスポンスのキャッシュ 2. プッシュ通知等のキュー 3. チャットのデータを全保管 サービスローンチ直後はまだ Appサーバー(EC2)１台と、MySQL & Redisを両方走らせてる DBサーバー(EC2)１台で十分だという判断で、しばらくはそんな構成でやってました。（S3などは省略） しかし、いざサービスが成長してくるともちろん MySQL & Redis を１台でまかなうのはキツくなり、MySQL と Redis を別々のEC2インスタン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
