タグ

dbに関するairj12のブックマーク (31)

  • MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

    こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

    MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
  • TechCrunch | Startup and Technology News

    The National Democratic Alliance (NDA) has emerged victorious in India’s 2024 general election, but with a smaller majority compared to 2019. According to post-election analysis by Goldman Sachs, JP Morgan,… The tech layoff wave is still going strong in 2024. Following significant workforce reductions in 2022 and 2023, this year has already seen 60,000 job cuts across 254 companies, according to i

    TechCrunch | Startup and Technology News
    airj12
    airj12 2015/07/08
    MRPや管理会計とかに良い感じだったりする?
  • あなたが知らない リレーショナルモデル

    1. あなたが知らない リレーショナルモデル @dbtech showcase tokoy 2014 奥野 幹也 Twitter: @nippondanji mikiya (dot) okuno (at) gmail (dot) com 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● ブログ 今日は個人として 参加しています。 – 漢のコンピュータ道 – http://nippondanji.blogspot.com/

    あなたが知らない リレーショナルモデル
  • リレーショナルな正しいデータベース設計

    北海道データベースDAYで使用した資料です。db tech showcaseの内容に、いくつかの説明を加えています。(講義時間90分)Read less

    リレーショナルな正しいデータベース設計
  • A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール

    A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL

  • 『アメーバピグにおけるDB構成&対応記』

    2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな

    『アメーバピグにおけるDB構成&対応記』
    airj12
    airj12 2014/05/23
    6台で参照3万,更新7千/秒のIOをあっさり捌くとかioDrive Duoぱねえ / percona-toolkitいいなあ
  • 今まで見たもっともクソなテーブル設計 - 何か着ていればいいよ

    あれは、僕がデータベースを扱ううち最初から3件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆

    今まで見たもっともクソなテーブル設計 - 何か着ていればいいよ
    airj12
    airj12 2014/03/06
    抽象化ちゃう / この定義でViewもなくアクセスしてるC++のコードってどんな事になるんだろう… / とりあえず対応表をテーブル化してJOINするでしょ
  • データベース技術の羅針盤

    PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)NTT DATA Technology & Innovation

    データベース技術の羅針盤
  • ORMがアンチパターンである11の理由

    サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの(激しい)返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益

    ORMがアンチパターンである11の理由
    airj12
    airj12 2013/10/22
    最初から全要件を見通せればORMもアリなんだろうけど
  • データベース設計の煩雑な作業を自動化する「ERMaster」

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

  • DDLレベルの外部キー制約は不要 - 設計者の発言

    テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注

    DDLレベルの外部キー制約は不要 - 設計者の発言
    airj12
    airj12 2013/02/22
    同意。
  • SAP、ERPのデータベースを自社で提供開始。「SAP Business Suite powered by SAP HANA」発表

    SAP、ERPのデータベースを自社で提供開始。「SAP Business Suite powered by SAP HANA」発表 SAPジャパンは2月20日、インメモリデータベースのSAP HANAと、同社のフラッグシップ製品でもある基幹業務向けアプリケーションのSAP Business Suiteを組み合わせた「SAP Business Suite powered by SAP HANA」を発表しました。 インメモリデータベースは、データをメインメモリ上に置いて処理をすることで極めて高速な処理を行えるデータベースとして、特にここ数年、サーバの搭載メモリ量が増大したことにより注目されています。しかしこれまでは証券取引や大規模データ分析など、高速性を活かしたニッチ分野向けと見られてきました。 それが、企業の基幹業務向けアプリケーション、しかもERPの代名詞ともいえるSAP ERP(旧SAP

    SAP、ERPのデータベースを自社で提供開始。「SAP Business Suite powered by SAP HANA」発表
    airj12
    airj12 2013/02/21
    「HANA側のインメモリデータベース内のストアドプロシージャとして処理」そりゃさぞかし速かろう…
  • 「SQLアンチパターン」。監訳者 和田卓人氏自身による書籍紹介

    アンチパターンに名前を付けることで、コンテキストを共有できて議論がしやすくなる。2月14日、15日に都内で開催されたイベント「Developers Summit 2013」、通称デブサミにおいて、書籍「SQLアンチパターン」の監訳をした和田卓人氏は書の意義をこう強調しました。 「SQLアンチパターン」は、データベースにおける設計からアプリケーションに関わるレイヤまで、開発者が陥りやすいミスや誤解に名前を付けたうえで原因と解決策を詳しく解説しています。 和田氏が指摘するように、これまでデータベースに関するデータ設計などのミスを指摘したり議論するには、その背景を共有するための面倒な説明が必要でした。SQLアンチパターンの登場は、そうした背景を暗黙のうちに共有する手段を与えてくれることになります。書はデータベース分野の古典になる資格を十分に備えているのではないでしょうか。 書籍の監訳者自身が

    「SQLアンチパターン」。監訳者 和田卓人氏自身による書籍紹介
  • DBの世界に起こる変革 | エンタープライズエンジニアの独り言

    エンタープライズシステムのエンジニアをやって10年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化(CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど)するのにディスク(ストレージ)が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて

    airj12
    airj12 2013/01/07
    ODB流行ってくんないかな
  • nabokov7; rehash : O/Rマッパーはなぜ悪か

    December 07, 201208:49 カテゴリプログラミングmysql O/Rマッパーはなぜ悪か タイムラインで「SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?」ってのを見かけて居ても立ってもいられなくなったので、既出を承知で反論しておきたい。 スライドだけから話の内容を推測すると、 -- 販売成績上位10個を抽出 select * from sales where deleted = false order by amount desc limit 10 といったSQLを Sales.active().top(10).all() のように、細かく分解した部品を組み合わせて表現できた方が便利だし構造的でしょ?という話のようだ。 これは確かに一見美しいのだが、これこそが「敷居を下げすぎて、dbの性質を分かってない人まで気軽にSQLをいじるようになった結

    airj12
    airj12 2012/12/07
    最近のO/Rマッパーはもうちっと賢いだろうとは思いつつも気持ちはわかる / SQLServerがLINQを直解釈し始めたら呼んで下さい
  • A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道

    元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。(尚、当然ですが、内容が正確かどうかは

    A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
  • dbpatterns.com

    This domain may be for sale!

    airj12
    airj12 2012/10/17
    育ったら面白そう
  • 1台から500台までのMySQL運用(YAPC::Asia編)

    6. Recent CPAN modules • Apache::BumpyLife • Twiggy::Prefork • Module::Install::ShareFile • App::LoadWatcher • File::RotateLogs • Plack::Middleware::AxsLog • Proclet • DBIx::DSN::Resolver [new!] 7. Proclet minimalistic supervisor use Proclet::Declare; env( PLACK_ENV => 'development', LM_COLOR => 1, ); service('web', 'plackup -p 9413 app.psgi'); service('memcached', qw!/usr/bin/memcached -p 11211!)

    1台から500台までのMySQL運用(YAPC::Asia編)
    airj12
    airj12 2012/09/30
    1コマンド移行すてき///
  • Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道

    最近、トランザクションの再勉強を始めていて、先日クラウド温泉でも発表させてもらった手前、ちょうどいいので一回まとめておく。はじめに断っておくと自分は別にDBやTXの専門家ではない。なので以下の内容の正確性については保証しない。内容については自分で勉強してくださいね。 1.「なんでまたTXなのか」 まずもって何故にTXなのか?というお話から始めます。もう枯れてんじゃないか?今頃RDBMSでもないだろう。それはそうですが、以下の流れは無視できません。 ・RDBMSの特許切れ NIIの佐藤先生の指摘にもあるように、1980-90年代のRDBMS関連の特許が切れ始めます。これにより商用一辺倒で、OSSではどうしても勝てなかったRDBMSでの技術革新や、その技術を応用した別のもの(RDBMSとは限りません)が登場してくる可能性が高いです。各ベンダーもそれを見越して、一斉にRDBMS関連への「逆張り」

    Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道
  • エンタープライズクラウドでも破壊的イノベーションを

    昨日の記事はちょっとわかりにくかったと思うので補足したい。 RDB不要論 浅海先生よりコメントをいただいた。(ありがとうございます) CQRSも、伝統的なオンラインとバッチによるアプリケーション・アーキテクチャに新しく名前をつけたと考えると過去との技術の連続性も見えてきて面白いところ。よく考えてみると昔から普通にやってきたことだよなぁ、と。もちろん登場人物が変わってきているので新しい革袋に入れなおす必要はある。 — 浅海智晴さん (@asami224) 6月 28, 2012 全くおっしゃるとおりで、「昔から普通にやってきたこと」で今でも大変有効な技術は多いと思う。ISAMやVSAMのKSDSにしても昔は実際にオンライン処理をやっていたわけだからできないはずがない。というより、もしかしたらRDBより向いているんじゃないか?というのが私の率直な印象。結局のところ、データの集計や分析では、わざ

    エンタープライズクラウドでも破壊的イノベーションを
    airj12
    airj12 2012/06/29
    プログラミング言語が発展してくるにつれてRDBが鬱陶しくなってきてはいる