[B! db] stealthinuのブックマーク

An in-process SQL OLAP database management system

We are holding our user community conference, DuckCon #5, in Seattle on August 15. DuckDB is a fast in-process analytical database DuckDB supports a feature-rich SQL dialect complemented with deep integrations into client APIs. DuckDB v1.0.0 was released in June 2024. Installation Documentation

stealthinu 2024/06/22

SQLiteとかプログラムに組み込んで使う系のSQLエンジン。インメモリでめちゃ速いらしい。そして色々と柔軟な書式を採用している。 ●db ●SQL

リンク

ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は？［PR］

ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は？﹇PR﹈日常的に多数の同時アクセスが発生し、大量のデータが蓄積されるオンラインゲームのバックエンドは、データベースにとってもっとも過酷な環境の1つだといえます。このバックエンドデータベースとしてよく使われているのがMySQLデータベースです。しかしその使われ方は一般的なMySQLとは異なり、データベースを細かく分割して多数のサーバに負荷を分散するシャーディングと呼ばれる仕組みを構築するなど、複雑なシステム構築と運用が行われているのが現実です。そこで急速に注目度を高めているのが、MySQL互換でありつつ分散データベースの機能を備え、シンプルなクラスタ構成で高い負荷に耐える、いわゆる﹁NewSQL﹂と呼ばれる分野の代表的なデータベースの1

stealthinu 2023/11/14

TiDBというソシャゲなど超大規模で多数のシャーディングが必要になるようなDBに有効そうなDB。ソシャゲ界隈のDB規模ってそういう感じなんだな。

開発
db

リンク

SQLの実行計画の読み方 |

今回は、SQLを書く上で特にパフォーマンスに影響のあるSQLの実行計画の読み方について解説します。実行計画はデータベース製品によってさまざまに差異がありますが、ここでは比較的どのデータベース製品でも共通する内容について解説します。実行計画とは記述したSQLが実際にデータベースの内部でどのように処理されて結果を返すか、その処理方法を記述した情報です。 A5:SQL Mk-2では、SQLエディタで実行計画を見たい SQL の上にキャレットがある状態でメニューから [SQL(S)] – [SQLの実行計画(J)] または、Ctrl+E で表示できます。表示の仕方はデータベース製品ごとに異なりますが、多くのデータベース製品ではツリー状の情報として表現されます。︵このため A5:SQL Mk-2でもツリービューで実行計画を表示します。︶ツリーのリーフ︵端︶から処理が行われ、ルート︵根︶に向かっ

stealthinu 2023/05/07

A5からSQLの実行計画を確認出来る

db
開発

リンク

みずほ銀行窓口業務ストップの真相、DC切り替えをためらい障害が長期化

みずほ銀行で2021年8月20日、営業店の窓口業務が全面停止するトラブルが発生した。前日の19日午後8時53分ごろに営業店端末と勘定系システムをつなぐサブシステムで、データベース︵DB︶サーバーがディスク装置の故障をきっかけに停止したためだ。待機系DBサーバーへの切り替えも失敗、副データセンター︵DC︶に処理を切り替えた。副DCへの切り替えに着手するまで11時間超を要し、業務開始に間に合わなかった。みずほ銀行で2021年8月20日、全463店舗で営業店端末や店頭のタブレット端末が使用不能になった。午前9時の開店から午前9時45分までは全ての店頭取引ができなくなり、その後も午前11時58分まで融資や外国為替︵外為︶の一部取引ができなくなった。営業店端末などと勘定系システム﹁MINORI﹂をつなぐサブシステム﹁業務チャネル統合基盤﹂が前日の8月19日午後8時53分ごろに停止したためだ。業務

stealthinu 2021/09/24

これはつらい。こりゃ運が悪いなと思うが、銀行みたいなところだとそういう状況すら想定しとかんといかんのだろうから、想定の運用手順書が甘かったのが問題なのだろう。

server
db

リンク

MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス技術戦略部ブログ]

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDB DB設計インデックスこんにちは、羽山です。今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な

stealthinu 2021/09/01

これはぜんぜん知らなかった。UUIDだとというか時系列じゃないIDでまんべんなくデータが置かれるとディスクキャッシュヒット率が下がるため大幅な性能低下が起こると。ULID使えば良い。

mysql
db

リンク

本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita

起きた事本番環境のデータ調査の依頼を受けた。その調査を受ける前に、それとは別で不要データを本番DBから削除する作業をMySQL Workbenchで行っていた。本番DBで、データ調査を行う際にMySQL WorkbenchでSQLのselectと間違えてdeleteを実行してしまい、Tableを1つ丸ごとDeleteしてしまった。 ON DELETE CASCADEが親テーブルに設定されてしまっていたため、さらに4つのTable dataが芋づる式に消えてしまった。 ON DELETE CASCADEの説明としては、この記事がわかりやすかったです。 https://www.dbonline.jp/mysql/table/index11.html テーブルの構成(テーブル名などは例として挙げていて、実際のものとは多少異なります) 正しい設定 usersテーブルでuserを削除した時に、そ

stealthinu 2020/12/03

drop tableしたんじゃなくてdeleteで全データ削除しちゃったのね。んでon delete cascadeが双方向！に設定されててみな消えたと…　そら頭真っ白になるな。

リンク

100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本心 in せろ部屋

要約技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある

stealthinu 2020/08/13

Postgresでフェッチサイズ指定しないと検索結果全件持ってきてしまう。そしてauto commitがtrueだとフェッチサイズ指定しても効果ない。知らんかった。なるほどこれはハマりやすい。 ●java ●db

リンク

RDBMS in Action

RDBMS 理解度の壁: プロダクションや運用保守で困らないシステムを作れる知識＜＜＜それっぽく動くものを作れる知識実際のシステムで遭遇・見聞きした事象をもとに、上記のスキマにある各種 RDBMS 知識を説明します。 RDBMS 本体の運用よりも、現実のアプリケーションにおける設計・実装上のハマリどころが中心。

stealthinu 2019/12/11

RDB利用した開発時に気をつけることまとめ。ブコメより微妙に間違いもあるとのこと。

リンク

【旧版・説明欄参照ください】サーバーレスアプリケーション向きの DB 設計ベストプラクティス

【2019/09/12 追記】この資料は旧版であり、最新版が存在します。 2019/09/12 にアップロードしたものをご参照ください最新版 → https://www.slideshare.net/AmazonWebServicesJapan/db-20190905 --------（元の文）------------------- 2019/05/09 に #AWSLoft Tokyo で開催されたイベント、「イチから理解するサーバーレスアプリ開発」における講演資料の一つです。・サーバーレスアプリケーションにおいて Amazon DynamoDB が利用しやすい理由・RDB と DynamoDB の設計プロセス・考え方の対比・明文化・実例に沿った DynamoDB の設計プロセス解説とサンプル例題などを含みます。イベント: https://understandingbasi

stealthinu 2019/05/10

DynamoのようなNoSQLの場合は通常横に並べるデータを縦にしてカラム名とデータとをもたせるようなデータ構造にするとよいと。

lambda
db

リンク

https://developer.hatenastaff.com/entry/2019/01/15/120431

stealthinu 2019/01/16

すばらしい知見だった。これ4.0->5.6じゃなくても古いMySQLから上げる時に大変参考になる資料だろう。これで4.x系からのアップデート案件来ても怖くない。いや、無論やりたくないけどね…

リンク

MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。

ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQLNDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その

stealthinu 2018/05/07

CTE導入。文字コードがUTF8mb4標準に。寿司ビール問題に対応するため﹃日本語を扱いたい場合には、utf8mb4_ja_0900_as_cs_ksを利用すると良い﹄などなど。 ●db ●mysql

リンク

奥野幹也『理論から学ぶデータベース実践入門』はどこがダメなのか - 檜山正幸のキマイラ飼育記 (はてなBlog)

言い訳から始めます。この記事を︵途中まででも︶読んだ人は、次のように言いたくなるでしょう。﹃理論から学ぶデータベース実践入門﹄は良い本なのか悪い本なのか、いったいどっちなんだよ?!この本は間違いや説明不足があり、誤読されやすい表現も多く、その点では残念な本です。しかし、面白いアイディア、するどい観察も含まれていて、行間を補い深読みすれば、多くの示唆を得られる本でもあります。よって、﹁良い／悪い﹂の二択では答えられません。良い点と悪い点の両方を、できるだけ客観的に記述するしかないのです。それをした結果、長い記事となりました。内容‥ ことの発端‥ zhanponさんの批判奥野本擁護と奥野本批判僕の擁護・批判の方針 zhanponさんの指摘の再検討 1. 論理的な矛盾とデータの不整合を混同している 2. 命題論理の限界についての説明がおかしい 3. 古典論理の定義を間違えている 4.

stealthinu 2017/10/12

これ読書会でしっかり読んでなかったら全くわからん話だった。論理学の人からみるとこんな感じに読めるのか…　あの本と２章のお陰でデータベースへの見方がかわった人なので素人には意味はある、と思うのです。

本
db

リンク

Amazon Aurora 事例祭り（20170307）に行ってきたメモ | Hori Blog

Hori Blogフリーランスでバックエンドエンジニアとして活動している Ryota Hori のブログです。最近はテック系記事より雑記ブログ気味。 Amazon Aurora 事例祭りに行ってきたので、メモを公開します。社内共有で Slack に貼ろうと思っていたメモなのですが、長くなったのでブログに公開します。概要 Amazon Aurora 事例祭り︵2017 年3月7日開催︶ | AWS セッション内容 Amazon Aurora を使いこなすためのベストプラクティスと最新アップデート @con_mame さんデータベースソリューションアーキテクト登壇資料: [Aurora 事例祭り]Amazon Aurora を使いこなすためのベストプラクティス開発サイドからの知見と今後の展望PostgreSQL For Aurora でるよ！ 9.6.4 と互換My

stealthinu 2017/03/14

auroraへの移行がらみの色々tips

リンク

Sequelのトランザクション内でタイムアウトするとCOMMITされてしまう - tmtms のメモ

ちょっと前にハマったのでメモ。 Sequelでトランザクションを使う時は次のように transaction メソッドにブロックを渡します。 require 'sequel' require 'logger' db = Sequel.connect('mysql2://user:passwd@localhost/test') db.loggers = [Logger.new($stdout)] db.transaction do db[:test].insert(id: 123) end I, [2017-03-12T22:34:51.946849 #27932] INFO -- : (0.000119s) SET @@wait_timeout = 2147483 I, [2017-03-12T22:34:51.947047 #27932] INFO -- : (0.000133s) SET

stealthinu 2017/03/14

これはこわい罠だ…　ひっかかった後に調べるのが大変そう。

db
ruby

リンク

パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合

MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、インデックスをつけるだけでカバー出来る場合が多い。パーショニングを使わずに、単にテーブルを分けてしまえばいい。テーブルが巨大にならないとあまり効果を実感できない。使い方を間違えると性能が落ちてしまう。などの問題があるからだろう。そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類︵分散具合︶のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を

stealthinu 2017/02/13

パーティショニングをHASH使ってやる例。確かにこういう場合はHASH使いたいな。

mysql
db

リンク

Amazon Auroraを真に理解するための性能検証 | 外道父の匠

今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。目次楽しい検証になって長くなりましたので、目次を置いておきます。はじめにクエリのレスポンスタイムクエリキャッシュ CPU利用率とIOPSの性質データ容量とストレージ性能の関係インスタンスタイプとストレージ性能の関係運用面の色々何がボトルネックになるかはじめにいくつか前提的なものを。ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行していますデ

stealthinu 2017/02/10

auroraの色んなベンチマーク値。auroraすげえじゃん。クエリキャッシュがすげえ効く。自前のしょぼいサーバでmysql動かすくらいならaurora使えよって感じだな。お金があるなら。 ●aws ●db

リンク

MySQLアンチパターン

2018/01/26 第2回オープンソースデータベース比較セミナー https://osscons-database.connpass.com/event/74688/

stealthinu 2017/02/03

あるあるネタ。サブクエリとか5.0の頃の感覚と5.7の感覚では全然違うよなあ。あと﹁誰でもroot﹂ってたぶん自分がこないだはまってたことでは。 ●mysql ●db ●ネタ

リンク

MySQLの文字コード事情 2017版

こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk

stealthinu 2017/02/02

エンコードと文字集合は別物なのか。その意識はなかった。例のUTF-8mb4問題についてのまとめ。 ●mysql ●db

リンク

Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT

平素よりQA＠ITをご利用いただき、誠にありがとうございます。QA＠ITは﹁質問や回答を﹃共有﹄し﹃編集﹄していくことでベストなQAを蓄積できる、IT エンジニアのための問題解決コミュニティー﹂として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日︵金︶15:00をもちましてQA＠ITのサービスを終了することにしました。これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。QA＠ITの7年間で皆さまの知識

stealthinu 2017/01/19

2012年のエントリーだがその時点でもうPostgresへの移行トレンドが指摘されてる。最近はだいぶPostgresの流れが強くなってきた感がある。でもMySQLも2012年当時からだいぶ進化したから今後わからんなあ。

mysql
db

リンク

我々はいかにして技術選択を間違えたのか？ 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ

どうも！アプリケーション基盤チームの横田(@yokotaso)です！ kintoneなどで利用していたJavaフレームワークのSeasarのEOLに伴い、S2Daoからの脱却を試みたのですが、パフォーマンス問題や障害を発生させてしまうなど問題を多々発生させてしまいました。同じ過ちを繰り返さないという強い決意のもと、今回の失敗をブログで公開いたします。失敗をあえて公開する点で斬新かつ濃いブログ記事となっております！失敗体験の公開は恥だが役に立つ！移行先の選定の失敗移行先として選定したプロダクトは Hibernate*1です。 Hibernateを選んだ理由としては Spring Framework を選定した Spring FrameworkでInterface + アノテーションでプログラミングするならSpring Data JPA が有力 JPAに準拠したのORMの中でも、H

stealthinu 2016/12/28

つらみがある話。間違えないように注意して選択したのに間違う。見えてないところに落とし穴がある。 ●java ●db

リンク

はてなブックマーク

タグ

関連タグで絞り込む (50)

dbに関するstealthinuのブックマーク (122)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス