Glueでcsvファイルをparquet形式に変換してみた - Qiita
AWS DASの勉強で初めてGlueを触ったのでメモ Parquet形式とは AWSドキュメントより Apache Parquet や ORC は、データを高速に取得できるように最適化された、AWS 分析アプリケーションで使用されている、列指向ストレージ形式です。 列指向ストレージ形式には以下の特性があるため、Athena での使用に適しています。 列のデータ型に合わせて選択された圧縮アルゴリズムによる列ごとの圧縮で、Amazon S3 のストレージ領域を節約し、ディスク容量とクエリの処理中における I/O を削減します。 Parquet および ORC での述語プッシュダウンにより、Athena クエリが必要なブロックのみを取得できるようになり、クエリパフォーマンスが向上します。Athena クエリがデータから特定の列値を取得すると、データブロック述語からの統計 (最大値や最小値など)
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
MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #１．基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスクアクセスに時間がかかるため、InnoDBエンジンがメモリ上でレコードを更新し、redo log bufferに記録したら、レコード更新操作が完了とします。この仕組みは、WAL（Write Ahead Logging）といいます。別の専用スレッドが適当のタイミ
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互換）でutf8→utf8mb4変換にSELECT INTO OUTFILE S3／LOAD DATA FROM S3を使うMySQLAWSAurora 今更ながら、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 を使う→ロック競合で詰まるのが怖い・トリガで拾えない更新が
RDSでDBをスナップショットから復元する - Qiita
こんにちはみなさん サービスを更新するとき、ときには現時点でのデータベースのデータ構造に手を入れる必要が出てくるかもしれませんが、そんなときは必ずバックアップをとっておくものです。 随分前であれば、mysqldumpとかを使って生のダンプファイルを取っておいて、復旧時はそのダンプファイルを入れ直すというふうにやっていたと思うのですが、AWSのRDSではスナップショットを定期的に、もしくは能動的に取得することができ、このスナップショットからDBを復元するという手段があるので、それを頼りにする場合があるでしょう。 私の場合は、コンテナ運用時にはそもそもRDSへ直接アクセスする手段を封じていますので、スナップショットによる復元以外には (セキュリティグループの設定を変えたりしない限り) 方法がありません。 そんなわけで、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
TensorFlowのような機械学習にはデータベースは必要不可欠です。ただ、このデータベースについての知識がゼロでしたので、まずはRDBMSからNewSQLまでの初心者向けの知識を簡単にまとめてみました。データベースに関わっている人からすれば当たり前の内容です RDBMS RDBMS(リレーショナルデータベース管理システム)は、下記のMySQLなどに代表されるRDB管理のための専用ソフトウェアです。RDBは、データを「行」と「列」からなる２次元の表（テーブル）形式で表し、複数の表と表の間でデータ同士を関連付け（リレーションシップ）を行うことができます。 MySQL PostgreSQL MariaDB Oracle Databasr SQL Server DB2 また、汎用的かつ高機能なSQLと呼ばれる言語が使用でき、ACIDなトランザクションが行えることが特徴です。ACIDとは、次の４つ
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)からなる構造をもつデータベース 大量のオ
FirebaseのRealtime Databaseのざっくり概要 - Qiita
個人的に作っているアプリで簡単にリアルタイムにデータが同期される機構を組み込みたく調べていたところ、Firebaseにたどり着いたのでまずはざっくり概要をまとめました。 Firebaseとは Googleが運営しているMBaasです。 Firebaseの特徴としては、他のMBaasと同じ様に、オンラインでサインアップするだけで、オンラインのデータベースにデータを保存 / 取得ができることに加え、 HTML / CSS / JS / 画像などの静的ファイルをホスティングし、CDNを通じSSLで提供するとこまでを提供するFirebaseHostingやユーザーの行動を分析するFirebase Analyticsなど、Googleさまさま(?)な強力な機能も利用することができます。 Firebaseの機能一覧 サービス 概要 対応プラットフォーム
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の多くのプ
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
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〜
MySQLのテーブルの更新履歴を履歴テーブルに残す方法 - Qiita
CREATE TRIGGER orders_insert_trigger AFTER INSERT ON orders FOR EACH ROW insert into orders_log ( id,memo,customer_id,canceled_at,applied_at,log_time,ins_flag ) VALUES (NEW.id,NEW.memo,NEW.customer_id,NEW.canceled_at,NEW.applied_at,now(),1); CREATE TRIGGER orders_update_trigger AFTER UPDATE ON orders FOR EACH ROW insert into orders_log ( id,memo,customer_id,canceled_at,applied_at,log_time,ins_flag
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDS(Mysql)のMaxConnection数 - Qiita
