はじめに 本ブログリレーについて 当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の4日目のエントリです。昨日はKitano Yuichiによる「Amazon SES」でございました。 このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。 では、さっそくいってみましょう。本日のテーマは『Amazon DocumentDB』です。 目
export interface Vote { voteDate: string; value: number; } export const Votes: Vote[] = [ {voteDate: '2017-11-10T12:00:12+09:00', value: 345.11 }, {voteDate: '2017-11-11T22:00:12+09:00', value: 102.34 }, {voteDate: '2017-11-12T09:12:45+09:00', value: 345.11 }, {voteDate: '2017-11-13T09:12:45+09:00', value: 312.12 }, {voteDate: '2017-11-14T09:12:45+09:00', value: 267.34 } ]; import {Component, OnIn
こんにちは、臼田です。 DynamoDBの料金体系って難しくてよくわからないと思っている方も多いかもしれません。私もその一人でした。 今回はどのようにすればDynamoDBを安く利用できるのかについて、まとめてみたいと思います。 本ブログのコンセプト DynaomDBをこれから利用する、もしくはとりあえず利用しているが熟知はしていない方向け 利用料金の最適化に必要な範囲の説明を行う キャパシティーユニット等のわかりにくい用語についても少し解説を入れる RDSとの比較などは行わない 大規模であったり、細かいチューニングを伴うような部分は割愛 なお、上級者向けの内容は含まれていませんのでご了承下さい。 RDSとの比較やDynamoDBの詳細な使い方などは、弊社都元が執筆しているコンセプトから学ぶAmazon DynamoDB – シリーズ –がむちゃくちゃ参考になるので、こちらも御覧ください。
どうも！大阪オフィスの西村祐二です。 DynamoDBで提供されている属性の型は大きく分けて スカラー型、ドキュメント型、セット型となっています。 DynamoDBの命名ルールおよびデータ型 そのため、下記画像のように日付と時刻を登録するときは文字列データ型(String型)を使用するのがほとんどだと思います。 ただ、こちらが想定するフォーマット以外でも登録することができてしまい、 登録された時刻をみて、ある処理を実行するときなど 処理が失敗してしまう可能性があります。 今回はLambdaを使って登録されている項目のフォーマットが正しいかチェックしてみたいと思います。 DynamoDBのテーブル作成 今回はCloudFormationを使ってDynamoDBのテーブルを作成します。 テンプレートファイルを作成します。 今回作成するテーブルはプライマリーキー「Date」、ソートキー「Time
よく訓練されたアップル信者、都元です。今回はグローバル・セカンダリ・インデックス（GSI）にフォーカスします。LSIを忘れないうちにGSIいきますよっ。 ローカル・セカンダリ・インデックス（LSI）というのは、ハッシュキーattributeが共通で別のレンジキーattributeを持つ、複合キーテーブルに対するインデックスでした。 グローバル・セカンダリ・インデックス（GSI）とは 例えば、Amazon DynamoDB Developer Guide - サンプルテーブルとデータにあるProductCatalogテーブルは、Idがハッシュキーとなったハッシュキーテーブルです。つまりこのテーブルは、Idを条件としたquery（問い合わせ）しかできません。ハッシュキーテーブルであるが故に、LSIも定義できません。 アプリケーション要件「ProductCategoryで絞り込んだ後、Title
はじめに AWS Lambdaで処理時間が掛かることが想定される場合、どのような対応策があるでしょうか？Lambdaを諦める？(これも１つの選択肢だと思います)、一回のデータ処理量を減らして処理時間を短くする、など色々な方法が考えつくと思います。 今回は１つの対応策として、処理時間が掛かる処理を複数に分割して別Lambda関数として動かす事を考えてみました。処理を分割してQueueに登録し、Queue毎に別Lambda関数を起動するサンプルを作成してみたので、それを中心に書きたいと思います。尚、実装言語はPythonとなります。 処理概要 今回の処理概要を図にすると以下のようになります。 Pythonにより実装したLambda関数、SQS、DynamoDBを組み合わせました。一番左の「main.py」がタスクをQueueに分割してSQSに登録します。定期的に動いている「consumer.p
AWS には NoSQL データベース DynamoDBが存在します。 標準では ウェブ管理画面 AWS CLI SDK を使ったプログラム から操作することもでるものの、地味に面倒です。 今回は DQL を使ってシェルインターフェースから DynamoDB を SQL 操作する方法を紹介します。 DQL とは? DQL は "DynamoDB Query Language" の略で DynamoDB 向けの SQL 風インターフェースです。 DynamoDB テーブルの作成・更新・削除からレコードの追加・参照・更新・削除を SQL 風に操作できます。 サクッと DynamoDB の中を覗く場合には、今回紹介するようなツールを使うのがお手軽ではないかと思います。 インストール DQL は Python で書かれているため pip でインストールします。
「これ、同時にリクエスト飛んできた場合って、どうなるの？」 「2つ登録されちゃいますね…」 はじめに Web APIは、リクエストを受け、処理を終えた後レスポンスを返します。モバイルアプリやウェブアプリとセットで開発しているとつい忘れがちになってしまいますが、同時に同じリクエストが飛んできた場合にどういう挙動をするか ということは常に考慮しておかなくてはなりません。「UI上同時にリクエストが送れないから問題なし」では Web APIの設計が不十分です。別の端末から同時に同じリクエストを送ることも可能ですので、UIとは切り離して考えるべきです。 さて、この状況、GETリクエストについては大きな問題にはならないでしょう。いくらリクエストが来てもサーバ側の状態に変化はないので、負荷対策だけしておけば大丈夫そうです。問題はPUTリクエストやPOSTリクエストといった、サーバ側のリソースに変化を及ぼ
よく訓練されたアップル信者、都元です。DynamoDB楽しいです。みんなもっと使えばいいのにと思って最近のエントリーを書いています。今回は、前回名前だけ触れた「複合キーテーブル」について。DynamoDBについて全くご存知無い方は、まずは下記エントリーを読んで頂ければと思います。 Amazon RDSとの比較で学ぶDynamoDB コンセプトから学ぶAmazon DynamoDB【ハッシュキーテーブル篇】 今回のサンプルデータ フォーラム・スレッド・返信投稿という3要素で構成した掲示板のデータベースとして、それぞれForum, Thread, Reply というDynamoDBのtableがあり、下記のようなitemがそれぞれのtableに入っているようなイメージをしてみてください。 // Forum { "Name": "DynamoDB", "Category": "Amazon We
EC2(Amazon Linux 2015.09)からElastiCache Redisの各Redisノードに接続し、コマンド実行する方法を紹介します。 ElastiCache Redisは2017/10末から通信の暗号化に対応しました。通信を暗号化している場合は次のブログを参照下さい。 Amazon ElastiCache for Redisの通信暗号化とクライアント認証をやってみた Redisノードのエンドポイントを確認 マネージメントコンソール CLI の2通りで確認します。 1.マネージメントコンソールから確認 メニューから「ElastiCache→Cache Clusters」と遷移し、クラスター一覧画面に移動します。 エンドポイントを確認したいクラスターの「Nodes」列をクリックすると、ノード一覧画面に遷移します。 Redisの場合は、1クラスターにつき1ノードだけが存在しま
超おはようございます。最近めっきり暑くなってきましたね。城内です。 今回は、db tech showcase Tokyo 2015に参加してきましたので、セッションレポートを書きたいと思います。 セッション情報 セッション名：NoSQLの必要性と主要プロダクト比較 スピーカー：株式会社野村総合研究所 OpenStandiaチーム 渡部 徹太郎氏 スライド オープンソース サポート 保守 サービス（OSS サポート 保守 サービス）| OpenStandia™（オープンスタンディア） セッション内容 データを取り巻く環境の変化 データのボリュームが肥大化 →GoogleやFacebookの保持データがペタバイト級に データ処理の応答スピードが重要に →Webサイトのアクセス数が秒間10万アクセス データの多様性 →非構造データが増えてきているため、RDBMSでは格納が困難 RDBMSの現状
![[レポート]NoSQLの必要性と主要プロダクト比較 #dbts2015 #be_crazy_about_db_tech | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/539b7624ac59a4ebaeb32fc4fc84b959e66c9b87/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F06%2Fdbtechshowcase_tokyo_2015.png)
よく訓練されたアップル信者、都元です。最近DynamoDBづいております。DynamoDBについて全くご存知無い方は、まずは下記エントリーを読んで頂ければと思います。 Amazon RDSとの比較で学ぶDynamoDB 要するに、即時一貫性・操作の原子性・検索条件の自由度を犠牲にして、可用性と拡張性を手に入れたデータベースがDynamoDBであります。では具体的に、データの読み書きはどのように行うのでしょうか。 DynamoDBにおけるコンセプト DynamoDBには主に「table」「item（項目）」「attribute（属性）」という3つの概念が現れます。それに従属する概念として「キー」「インデックス」が出てきます。まずはこの辺りを整理していきましょう。 tableというのはみなさん分かりやすいでしょう。概ねRDBで言うところのテーブルに相当し、itemの集合体です。itemについて
はじめに Amazon DynamoDBは低レイテンシで安定したスループットもつNoSQLサービスです。コストが低く使いやすいので弊社でも様々な案件で利用しています。 DynamoDBではあらかじめテーブルごとに読み込み/書き込みのスループットを指定することができます。 例えば、参照が多いサービスで利用する場合は読み込み：1000回/秒、書き込み：100回/秒のプロビジョンドスループットを設定するという具合です。 プロビジョンドスループットを超えた操作が発生した場合、バーストキャパシティ(バースト用に貯められている予備キャパシティ)が残っていればそれが利用されますが、バーストキャパシティを使い切っている場合、操作に失敗します。 なので、ある程度余裕を持ったプロビジョンドスループットの設定が必要です。 とはいってもスループットを事前に予測するのは難しいため、予測を超えたスループットが発生した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
