タグ

DBとdbに関するikosinのブックマーク (228)

  • InnoDBのすゝめ(仮)

    InnoDBの特性など考慮しつつ、ゲーム向けのDBSQLを設計する上でのヒントや、注意するポイントなどです。Read less

    InnoDBのすゝめ(仮)
  • 可変データ構造をRDBに保存する方法について

    質問をすることでしか得られない、回答やアドバイスがある。15分調べてもわからないことは、質問しよう!新規登録して質問してみよう

    可変データ構造をRDBに保存する方法について
  • リレーショナル・データベースの世界

    序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記:その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み

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

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

    100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
    ikosin
    ikosin 2020/08/13
    原因追求の手順が参考になる
  • データベースのドキュメント管理を自動化した話 - estie inside blog

    こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie(オフィス探しサービス)とestie pro(不動産事業者向けデータプラットフォーム)の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する

    データベースのドキュメント管理を自動化した話 - estie inside blog
  • ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ

    JJUG-CCCJavaユーザーズグループクロスコミュニティカンファレンス 2018/12 登壇資料です。Read less

    ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
    ikosin
    ikosin 2020/07/31
  • 履歴テーブルについて - 一休.com Developers Blog

    この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの

    履歴テーブルについて - 一休.com Developers Blog
  • データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3

    初心者向けにMongoDBの基を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。 This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python ba

    データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
  • 履歴、世代、そして削除についての究極の疑問の答え - kawasima

    履歴や世代、データの削除すべてをリレーショナルデータベースだけで扱う方法。実用上はオーバーキルになることも多いと思われるので、あくまでもインデックスを効かせ整合性制約をすごくちゃんとやるとしたらこうなるよ、程度の知識として捉えてください。

    履歴、世代、そして削除についての究極の疑問の答え - kawasima
    ikosin
    ikosin 2020/03/11
    設計][SQL]
  • イミュータブルデータモデル - kawasima

    CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。

    イミュータブルデータモデル - kawasima
  • 27. 論理削除とは何か?どのような解法があるのか? w/ twada | fukabori.fm

    話したネタ 論理削除とはそもそも何か? 物理削除とは? なぜ、論理削除が生まれてくるのか? SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か? なぜ、論理削除はアンチパターンとして捉えられるのか? 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か? テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか? 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか? ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft

    27. 論理削除とは何か?どのような解法があるのか? w/ twada | fukabori.fm
  • サロゲートキーと「とりあえずID」の違い - 設計者の発言

    サロゲートキー(代理キー)は慎重になされる限り、有用なテクニックである。いっぽう、すべてのテーブルに機械的にIDを置く「とりあえずID(IDリクワイアド)」の設計スタイルでは、複雑なデータ要件を扱った途端にひどい目にあう(とくに保守担当者が)。両者の違いをしっかり理解しておこう。 何でもいいのだが、ここでは生産管理システムで見かけそうなシンプルなモデルを使って説明しよう(図1)。「作業区・品目」は、それぞれの作業区で生産可能な品目の組み合わせと、その品目を扱った際の生産性(時間あたり生産数)の管理簿である。 <図1> [工程]工程id,工程名,扱い単位 +   ̄ ̄ ̄ |   001 切削  個 |   002 加工  m | └―∈[作業区]工程id,行番,作業区名,標準生産性 +    ̄ ̄ ̄ ̄ ̄ ̄ |    001 01  切削1号 1000/hr |    001 02  切削2号 2

    サロゲートキーと「とりあえずID」の違い - 設計者の発言
  • SELECT文で本番環境を落としたお話 - Qiita

    (この記事は 地平線に行く とのマルチポストです) 番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために番データベースのデータを確認することになりました。 (個人情報が格納されているようなシステムではなかったので、必要であれば番データベースへのアクセスが許されていました) もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ

    SELECT文で本番環境を落としたお話 - Qiita
    ikosin
    ikosin 2019/12/27
    やらかしへの対策が他の現場に導入されて新たなやらかしの火種になった感じ
  • Go でトランザクションをフルスクラッチで実装した - kawasin73のブログ

    一歩ずつ一歩ずつ前へ進んでいく、確実に。どうも、かわしんです。 到底 1 記事に収まるような内容ではなく長いので、トランザクションの作り方に興味のない方は途中の「なぜ Go なのか」まで読んでいただければ嬉しいです。 この記事は、Go2 Advent Calendar 2019 の 7 日目と セキュリティキャンプ 修了生進捗 #seccamp OB/OG Advent Calendar 2019 の 7 日目を兼用しています。 さて、僕の興味は必要になったライブラリやミドルウェアなどを自作して、作りたいプロダクトを完成させることです。必要なコンポーネントがないからといってプロダクトを作るのを諦めたり妥協したりはしたくありません。 多くのアプリケーションではデータベースは重要なコンポーネントです。大抵のアプリケーションは MySQL や Postgres、Redis など既存のデータベース

    Go でトランザクションをフルスクラッチで実装した - kawasin73のブログ
    ikosin
    ikosin 2019/12/13
  • データ指向アプリケーションデザイン

    監訳者まえがき はじめに 第I部データシステムの基礎 1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション 1.1 データシステムに関する考察 1.2 信頼性 1.2.1 ハードウェアの障害 1.2.2 ソフトウェアのエラー 1.2.3 ヒューマンエラー 1.2.4 信頼性の重要度 1.3 スケーラビリティ 1.3.1 負荷の表現 1.3.2 パフォーマンスの表現 1.3.3 負荷への対処のアプローチ 1.4 メンテナンス性 1.4.1 運用性:運用担当者への配慮 1.4.2 単純さ:複雑さの管理 1.4.3 進化性:変更への配慮 まとめ 2章 データモデルとクエリ言語 2.1 リレーショナルモデルとドキュメントモデル 2.1.1 NoSQLの誕生 2.1.2 オブジェクトとリレーショナルのミスマッチ 2.1.3 多対一と多対多の関係 2.1.4 ドキュメントデータベース

    データ指向アプリケーションデザイン
  • TablePlus | Modern, Native Tool for Database Management

    Modern, native, and friendly GUI tool for relational databases: MySQL, PostgreSQL, SQLite & more

    TablePlus | Modern, Native Tool for Database Management
    ikosin
    ikosin 2019/12/10
  • GitHub - apache/datasketches-website: Website for DataSketches.

    The website is published directly from a specially named asf-site branch. The content of this branch is generated automatically by Jekyll from the master branch whenever changes are detected in the master branch. One should never modify the content of the asf-site directly. The master branch consists primarily of GitHub compatible MarkDown documents, which hold all the written content. There are t

    GitHub - apache/datasketches-website: Website for DataSketches.
  • DBMSをGoで実装してみた - Sansan Tech Blog

    こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか? データベースの内部実装はどうなっているのか? トランザクションとはどのようなアルゴリズムで実現されているのか? NoSQLが遅いのはなぜか? 古典的なデータベースとは内部的にどのように違うの? データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかのやサイトを調べていたのですが、なかでもCMU(カーネギーメロン大学)のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そしてブログでは、上記の講義

    DBMSをGoで実装してみた - Sansan Tech Blog
  • はじめてのB2B SaaSデータモデリング in 吉祥寺.pm#18

    Compose UI for... a light switch? (KotlinConf 2024)

    はじめてのB2B SaaSデータモデリング in 吉祥寺.pm#18
  • MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比べてどんな利点や欠点がありますか? - Quora

    回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...

    MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比べてどんな利点や欠点がありますか? - Quora