RDS と Azure リレーショナル データベース サービス Azure には、AWS の Relational Database Service (RDS) に相当するリレーショナル データベース サービスが何種類かあります。 次の設定があります。 SQL Database Azure Database for MySQL Azure Database for PostgreSQL Azure Database for MariaDB SQL Server、Oracle、MySQL などの他のデータベース エンジンは、Azure VM インスタンスを使用してデプロイできます。 AWS RDS のコストは、インスタンスが使用するハードウェア リソース (CPU、RAM、ストレージ、ネットワーク帯域幅など) の量によって決まります。 Azure データベース サービスでは、コストは、データ
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。(まじで意味不明) いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおk。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。(そのうち消したい) システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ
みなさん、おはようございます! CARTA fluct エンジニア の なっかー@konsent_nakka です。 CARTA TECH BLOG アドベントカレンダー 12/14ということで、普段DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識をざっとまとめてみました。 とりあえずこれだけ読んでおけば最低限は困らない、もし何か困った時にはあそこで出てきた内容をもう少し深く調べて見るか、というきっかけになれば良いなと思います。 厳密な定義よりも普段DBを扱う中でロックについてあまり意識したことがないような人にもすっと入ってくるように簡単な表現を優先して書いていますがご了承ください。 目次 留意事項 排他ロックと共有ロック トランザクション分離レベル SELECTのロックレベルを変更する 共有ロック: LOCK IN SHARE MODE 排他ロ
MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #1.基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスクアクセスに時間がかかるため、InnoDBエンジンがメモリ上でレコードを更新し、redo log bufferに記録したら、レコード更新操作が完了とします。この仕組みは、WAL(Write Ahead Logging)といいます。別の専用スレッドが適当のタイミ
概要 AWS で人気のサービス DynamoDB についての論文が公表され巷で噂になっていたと思う。 今回は、その論文を読み込んでいき、ざっくりまとめていくという記事になります。 完全趣味な記事なので、興味ある人がいれば幸いです笑 Abstract まず論文のタイトルですが、「Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service」と題したものとなっています。 Amazon DynamoDB は、NoSQL とよばれる部類のデータベースサービスです。 一貫した耐久性、可用性、パフォーマンスを提供してくれるマネージドなサービスなのが特徴ですね。 冒頭、2021年に66時間にわたる「Amazon Prime Day」中にピーク時8920万リクエスト/秒をさばいてい
ウィスキー、シガー、パイプをこよなく愛する大栗です。ラスベガスで AWS re:Invent 2022 の Keynote を見ています。 Keynote で Amazon Aurora と Amazon Redshift を ETL 無しで統合できる機能が発表されたためレポートします。 AWS announces Amazon Aurora zero-ETL integration with Amazon Redshift ゼロETL データの分析を行うために様々なサービスを利用しています。AWS ではサービス間の統合を行い ETL を使用せずとも分析や機械学習が簡単に行えるようにしてきました。例えば Redshift と Athena の両方でフェデレートされたクエリ機能を持っています。これをよりデータを移動すること無く、様々なデータベースやデータストアなどでクエリを実行することができ
はじめに 弊社の主な事業はスマホ向けゲームの開発と運営で、DBもゲーム向けのものに関心があります。AWS(Amazon Web Services)とGCP(Google Cloud Platform)でソリューションを検索すると、それぞれDynamoDBとCloud Spannerをゲーム向けと位置づけています。DBの選定はパフォーマンス以外の要因で決まることが多いのですが、純粋なパフォーマンスも知っておきたく、調べてみることにしました。(追記:GCPのサービスのベンチマークを公開する場合は、Googleから書面による同意をもらうなどの要件があります。AWSの方は、再現に必要なすべての条件を公開していれば済みます。) なお本稿はサーバーエンジニアを対象とした内容になっています。 アクセスの種類 スマホ向けゲームはDBアクセスにおいて一般に書込みの割合が多いアプリケーションであり、同時にチー
秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換(コンパイル)の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ
AWS では、異種データベースの移行を予測可能、高速、安全、かつシンプルにするために、2 つのスキーマ変換ソリューションを提供しています。お客様は、次のいずれかを選択することができます。1) AWS Database Migration Service (AWS DMS) コンソールにログインして、AWS DMS Schema Conversion (DMS SC) ワークフローを開始し、フルマネージドな体験をするか、2) AWS Schema Conversion Tool (AWS SCT) ソフトウェアをローカルドライブにダウンロードするか、を選択することが可能です。 どちらのオプションも、ソースデータベースのスキーマと、ビュー、ストアドプロシージャ、関数などのデータベースコードオブジェクトの大部分を自動的に評価し、ターゲットデータベースと互換性のある形式に変換します。自動的に変換で
Amazon Relational Database Service (Amazon RDS) の DBインスタンスのポイントインタイム復元を実行しています。この操作の完了には時間がかかります。 簡単な説明 [Restore to point in time] (特定の時点に復元) オプションを使用すると、自動バックアップを有効にしている特定の時点に DB インスタンスを復元できます。 自動バックアップが有効になっている Amazon RDS インスタンスは、最も早い復元可能時刻まで復元できます。最も早い復元可能時刻は、バックアップ保持期間の範囲で遡ることができるインスタンスの復元可能時刻を指定します。最大保存期間は 35 日、つまり 5 暦週に設定されています。インスタンスを変更して、この値を 0 日から 35 日に変更できます。ポイントインタイムリストアを開始し、保持期間内の任意の日時
こんにちは。コンサル部@大阪オフィスのYui(@MayForBlue)です。 前回、前々回のブログに引き続き、今回はポイントインタイムリカバリ機能を試してみました。 ポイントインタイムリカバリとは? バックアップ保持期間内の特定時点のDBクラスターを別のクラスターとして再作成できる機能です。 公式ドキュメントは以下です。 特定の時点への DB クラスターの復元 早速やっていきたいと思います。 事前準備 元データ確認 リカバリ元のデータベースtest-rds-clusterに検証用のレコードを作成しました。 検証用レコードの作成方法については以前のブログで紹介していますので、今回は割愛します。 test-rds-cluster内の検証用データを確認しました。 MySQL [testdb]> use testdb; Database changed MySQL [testdb]> select
DB インスタンスを特定の時点に復元し、新しい DB インスタンスを作成できます。 DB インスタンスを特定の時点に復元する場合、デフォルトの仮想プライベートクラウド (VPC) のセキュリティグループを選択できます。また、DB インスタンスにカスタム VPC セキュリティグループを適用することもできます。 復元された DB インスタンスは、デフォルトの DB パラメータグループとオプショングループに自動的に関連付けられます。ただし、カスタムパラメータグループとオプショングループは、復元中に指定することで適用できます。 ソース DB インスタンスにリソースタグがある場合は、RDS では復元される DB インスタンスに最新のタグを追加します。 RDS は、DB インスタンスのトランザクションログを 5 分ごとに Amazon S3 にアップロードします。DB インスタンスの復元可能な直近の時
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション(既存データの移行)、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を(テーマは変えて)手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか? バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます! 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く