Aurora のスナップショット（デフォルトKMSキーで暗号化されてる）を別アカウントに共有する 1 - Qiita
弊社では会社全体で１つのアカウントを共有していましたが「管理が面倒！どの部署がどれを使っているのかさっぱり分からん！」という苦情が増えてきたため、部署ごとにアカウントを分ける事になり Aurora 移行の作業を振られたため手順をまとめました。 AWS マニュアルを確認 マニュアル見てると手動スナップショットを共有するだけっぽいので簡単だな！と思っていましたが当然そんなに上手く行かず…デフォルトKMSキーで暗号化されていたため、別アカウントへの共有が不可になっていました。あと KMS キーも別途発行して別アカウントに共有しておく必要があるっぽい。 デフォルトの Amazon RDS 暗号化キーを使用しない、暗号化された手動スナップショットは共有できます。ただし、まず AWS Key Management Service (AWS KMS) キーを、スナップショットを共有するアカウントと共有す
Glueでcsvファイルをparquet形式に変換してみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS DASの勉強で初めてGlueを触ったのでメモ Parquet形式とは AWSドキュメントより Apache Parquet や ORC は、データを高速に取得できるように最適化された、AWS 分析アプリケーションで使用されている、列指向ストレージ形式です。 列指向ストレージ形式には以下の特性があるため、Athena での使用に適しています。 列のデータ型に合わせて選択された圧縮アルゴリズムによる列ごとの圧縮で、Amazon S3 のストレージ領域を節約し、ディスク容量とクエリの処理中における I/O を削減します。 Parque
ORC について最初に知っておきたかったこと - Qiita
数テラバイト越えあたり or パーティション数大量になったあたりで、ORC ファイルについて詳しくなったけど最初から知っておきたかった事。 がまとまったので書いておくけど、もう一桁増えると更に知っておきたかった事が増える気がする。随時更新。 BigData を扱うデータフォーマット ORC とは Hive / Spark / Presto 等と言った（以下 Hive 等）のビッグデータ基盤で使えるカラムナデータフォーマットだ。 MySQL では、実際のデータファイルは .idb ファイル等の形式で保存されるが、Hive 等ではフォーマットを複数選ぶことができ、ORC はデファクトスタンダートだ。次点に Perquet1 等がある。 HDFS に収納されて Hive 等 Query 対象となることが多い。 Reference Primary 公式サイト - https://orc.apach
MySQLのbinlogとredo logについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #１．基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスク
Amazon DynamoDB の論文を読んでいく - Qiita
概要 AWS で人気のサービス DynamoDB についての論文が公表され巷で噂になっていたと思う。 今回は、その論文を読み込んでいき、ざっくりまとめていくという記事になります。 完全趣味な記事なので、興味ある人がいれば幸いです笑 Abstract まず論文のタイトルですが、「Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service」と題したものとなっています。 Amazon DynamoDB は、NoSQL とよばれる部類のデータベースサービスです。 一貫した耐久性、可用性、パフォーマンスを提供してくれるマネージドなサービスなのが特徴ですね。 冒頭、2021年に66時間にわたる「Amazon Prime Day」中にピーク時8920万リクエスト/秒をさばいてい
Aurora（MySQL互換）でutf8→utf8mb4変換にSELECT INTO OUTFILE S3／LOAD DATA FROM S3を使う - Qiita
今更ながら、Aurora（MySQL 5.6 互換）上のデータをutf8からutf8mb4に変換することになったので、タイトルの通りSELECT INTO OUTFILE S3とLOAD DATA FROM S3を使ってテストしてみました。 この方法を選んだ理由 端的に言えば**「他に思いついた方法に問題点があったから」**です。 ALTER TABLEで文字コードを変える→長時間更新ロックが掛かる（db.r4.2xlarge で 300GiB 未満でも 10 時間！）・不意に失敗することがある（実際にエラーが出た） pt-online-schema-change を使う→ロック競合で詰まるのが怖い・トリガで拾えない更新がある gh-ost を使う→外部キーなどサポートしていない機能を使っている mysqldumpしたものをリストアする→時間が掛かる DMS を使う→そもそも DMS がu
RDSでDBをスナップショットから復元する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちはみなさん サービスを更新するとき、ときには現時点でのデータベースのデータ構造に手を入れる必要が出てくるかもしれませんが、そんなときは必ずバックアップをとっておくものです。 随分前であれば、mysqldumpとかを使って生のダンプファイルを取っておいて、復旧時はそのダンプファイルを入れ直すというふうにやっていたと思うのですが、AWSのRDSではスナップショットを定期的に、もしくは能動的に取得することができ、このスナップショットからDBを復元するという手段があるので、それを頼りにする場合があるでしょう。 私の場合は、コンテナ運用時
MySQL(InnoDB)でのDeadLock調査 - Qiita
最近MySQLでDeadLock問題にハマったのでその時の調査メモ 背景 とあるバッチプログラムで多数のBULK INSERT/UPDATEを行う処理の検証を行った際、 並列数を上げるとDeadLockが発生するという問題に直面。 一処理で同時に発行するSQLが多すぎてアプリのログからは原因が追いきれなかった。 （＜この時点でアプリの処理やログ出力を見直す必要がありそうだが、それはひとまず置いといて ^^;） その原因調査に役立った情報やMySQLの仕様などを備忘。 原因調査 まずはロックの原因を特定するためにInnoDB ロックモニターを有効化 mysql> SHOW ENGINE INNODB STATUS; -- (省略) -- ===================================== 2017-09-30 06:06:40 0x7f215046a700 INNOD
いまさらMySQL 8.0で共通テーブル式（CTE : Common Table Expressions） - Qiita
先にウィンドウ関数（Window Functions）を取り上げたのでMySQL 8.0でのサポート順とは逆になりますが（CTEは8.0.1）、いまさらながらCTE（Common Table Expressions）を試してみました。 0. CTEとは メインのSQLの問い合わせを実行するために補助的に使う、一時テーブルを（WITH句を使って）定義するものです。 …というと、派生テーブル（FROM句のサブクエリ）と何が違うの？となりますが、（非再帰のCTEはWITH句を使うか使わないか等の書式の違いを除いて、派生テーブルとほぼ同じようなものですので）実質的な違いは「再帰的に書ける」ところです。 MySQL 8.0でのCTEの使い方については、以下の記事・資料が参考になります。 13.2.11.9 WITH Syntax (Common Table Expressions)（MySQL 8.
ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
データベース事始め - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TensorFlowのような機械学習にはデータベースは必要不可欠です。ただ、このデータベースについての知識がゼロでしたので、まずはRDBMSからNewSQLまでの初心者向けの知識を簡単にまとめてみました。データベースに関わっている人からすれば当たり前の内容です RDBMS RDBMS(リレーショナルデータベース管理システム)は、下記のMySQLなどに代表されるRDB管理のための専用ソフトウェアです。RDBは、データを「行」と「列」からなる２次元の表（テーブル）形式で表し、複数の表と表の間でデータ同士を関連付け（リレーションシップ）を行う
NoSQLについて勉強する。 - Qiita
と名だたるIT企業が立て続けにRDBMS製品をリリースし、この時期にリリースされた上記のDBによって現在のRDBMSシェアは9割を超えると言われています。 このように、多数のデータベース製品がリリースされた背景には、1970年～1990年頃においてビジネスフィールドへのITシステム導入が急速に進んだことがありました。 この時代ではまだ世の中はパソコン/インターネット時代には到達していないため、この時代のITの中心は正にこうしたデータベースによる情報管理そのものにあったと言っても過言ではありませんでした。 広義のDBMS(データベース管理システム)としてはリレーショナル型の他にネットワーク型、カード型、階層型などがありますがビジネスモデル(トランザクションの必要性など)に最もよく合致したのがRDBMSでした。RDBMSにおける"リレーショナル"とは 個々のデータ(レコード)がいくつか属性(カ
Amazon Neptuneを使ってみる - Qiita
KIT Developer Advent Calendar 2018 10日目の記事になります. Amazon Neptuneを使ってみます. この記事では, まだ使ってみたなどが少ないAmazon Neptuneを使ってみます. それと同時に, グラフ型データベースとはどのようなものかも記載していきます. 研究にて, グラフ型データベースを使用する機会があり, 自分用のメモとして残そうと考え, 書いています. Amazon Neptuneって耳にしたことありますか? ざっくりいうと, Amazon NeptuneはAWS(クラウド)のグラフ型データベースサービスです. Amazon Neptuneの説明をする前に, 簡単にグラフ型データベースとは何かについて書いていきます. グラフ型データベースとは 頂点(Node, Vertex)と辺(Edge)からなる構造をもつデータベース 大量のオ
TypeORMはNode.js開発のスタンダードになるか？ - Qiita
こんにちはGAOGAOの代表をしております @tejitak です。GAOGAOアドベントカレンダー 17日目の記事です。GAOGAOのスタートアップスタジオにて、最近お手伝いしている海外のお客様案件にてTypeORMを導入しています。 今回の記事では、TypeORMとはなんぞや？という方を対象として、まだ比較的日本語記事が少ないTypeORMについてのご紹介します。 Node.jsのORM Node.jsでサーバーサイドを実装する際にはExpressを使うことが多いと思います。ExpressはサーバーサイドのWebフレームワークで、データベースを扱うORMは自由に導入することができます。以下代表的なORMを紹介します。 mongoose 公式ドキュメント： https://mongoosejs.com/ MongoDBはJavaScriptとの相性の良さから昔からNode.jsの多くのプ
tblsでデータベースドキュメントを生成する（1.ドキュメント生成編） - Qiita
ドキュメント生成編 テーブル情報補完編 CI連携編 tblsを使うと、1コマンドでデータベースドキュメントを生成できます。 tbls とは tblsのKey featuresには以下のように記載しています Document a database automatically in GFM format. Output database schema in many formats. 1コマンドで、Markdown形式で生成されますので、そのままGitHubなどのリポジトリにコミットして閲覧することができます（ドキュメントも更新履歴が残ったほうがいいですからね）。 上記以外にもスキーマをPlantUMLやJSON、Excelファイルで出力する機能などもあります Single binary = CI-Friendly. Goで書かれているため、バイナリポン置きで利用できます。つまり、CIに組み込
3分でわかるマテリアライズド・ビュー -使い所と問題点を考える- - Qiita
想定読者 マテリアライズド・ビューという言葉を聞いたことはあるがその意味や仕組みを知らない方 集計処理を実現する一つの手段としてマテリアライズド・ビューを検討している方 マテリアライズド・ビューの実装にあたり必要な知識・注意点を把握したい方 前提 以降の記載は以下のDBMSの使用を前提としています。 Oracle Database 10g, 11g, 12c 集計処理という敵とマテリアライズド・ビューという武器 システム開発を進める中で、何らかの集計処理が必要になることが多々あると思います。 例えば、売上高の集計処理（地域ごと・店舗ごと・期間ごとなど）や、特定の条件を満たす顧客の集計処理（商品名◯×を購入した顧客の合計数など）などです。 SQLで集計処理を実装すればよいのですが、実際に実装してみると以下のような問題が生じることがあります。 集計処理が遅い（複数テーブルの結合などに起因する処
カーディナリティについてまとめてみた - Qiita
カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば１年間の日付なら1〜
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDS(Mysql)のMaxConnection数 - Qiita
FirebaseのRealtime Databaseのざっくり概要 - Qiita
本当にあったやらかしDB設計シリーズ一覧 - Qiita
