タグ

DataBaseに関するyifeのブックマーク (39)

  • バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い

    db tech showcase Tokyo 2016で使用した資料ですが、発表後に頂戴したコメントなどを参考に内容を一部修正しています。(大枠の骨子に変更はありません) Read less

    バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
  • 持続的なプラットフォームのための難しい決断

    先日フォーラムでお知らせいたしましたが、今まで提供してきたツイートボタンとフォローボタンのデザインを一新すると同時に、今後はツイートボタンにツイート数を表示しなくなります。変更は2015年11月20日までに完了する予定です。Twitterでは、開発上のトレードオフが生じることが度々あります。今回の変更もそのような事情によるもので、ここではその背景を説明いたします。 Twitterの目標の一つは、皆様のウェブサイト、アプリケーション、ビジネスにとって、信頼のおけるプラットフォームを作ることです。また、このプラットフォームがTwitterエンジニアリングチームに確実にサポートされていることも重要です。その結果、APIを廃止することによって生じる問題を抑えるために、永続的なデザインを選択することにしました。多くの皆様と同様にTwitterの開発リソースにも限りがあり、どのプロダクトやパブリックA

    持続的なプラットフォームのための難しい決断
  • sqlmap: automatic SQL injection and database takeover tool

    Introduction sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching from the database, to accessing the und

  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

    先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
  • 分散システムの一貫性に関する動向について

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか? 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性(Eve

    分散システムの一貫性に関する動向について
  • DELETE_FLAG を付ける前に確認したいこと。 - Qiita

    DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

    DELETE_FLAG を付ける前に確認したいこと。 - Qiita
  • Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison :: Software architect Kristof Kovacs

    Hello, I’m Kristof, a human being like you, and an easy to work with, friendly guy. I've been a programmer, a consultant, CIO in startups, head of software development in government, and built two software companies. Some days I’m coding Golang in the guts of a system and other days I'm wearing a suit to help clients with their DevOps practices. While SQL databases are insanely useful tools, their

    yife
    yife 2015/01/08
    力作だ / 明らかにvsで比較できないDBが混ざってるのはご愛敬か
  • ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

    最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 このは、データベースのためのということで、データベース設計、SQLMySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します

  • 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の理由
  • ナチュラルキーとサロゲートキーについての議論

    とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー(代理キー)」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル(≒行)の値を一意に決定することができる属性(≒カラム)の集合」の

    ナチュラルキーとサロゲートキーについての議論
  • LevelDB入門 (基本編) - from scratch

    さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDBGoogle のBigTableをベースにしたアーキテクチャを持

    LevelDB入門 (基本編) - from scratch
  • なぜBTreeがIndexに使われているのか - maru source

    ※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます(特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう?? Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (の最後によみがな順で単語が並べられたりしています

    なぜBTreeがIndexに使われているのか - maru source
  • リレーショナルモデルのドメイン設計についての議論

    リレーショナルモデルを実践するには、ドメイン(≒データ型)を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性(≒カラム)に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

    リレーショナルモデルのドメイン設計についての議論
  • その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント

    最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの

    その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
  • MariaDB Galera Clusterを試す (1)

    カテゴリー DX (2) 一般 (59) 研究会 (6) 働き方 (4) 技術 (352) Edge AI (2) Edge Computing (13) Erlang (1) FIWARE (2) Fog Computing (10) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (5) RealTime Web (14) SRE (3) Webサービス (42) インフラ (8) コンテナ (4) ストレージ (93) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (215) 仮想化 (111) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティン

    MariaDB Galera Clusterを試す (1)
  • スイッチ・セキュリティーソリューション | LAN環境での不正アクセス対策

    近年、インターネットなどのWAN環境だけでなく、LAN環境における不正アクセス対策も重要な課題になりつつあります。サーバーやPCの対策は、セキュリティー対策ソフト等での強化が常識となっていますが、スイッチ等のネットワーク機器を狙った不正アクセスによっても場合によっては企業活動に重大な影響を及ぼします。 ここでは、LAN環境での不正アクセスの実例とアライドテレシスのスイッチ製品のセキュリティー機能で実現する対策について解説します。 スイッチのFDB(Forwarding Database)を枯渇させることによりフレームをフラッディングさせて盗聴を行う攻撃手法です。通常、スイッチはMAC Addressを学習して該当ポートのみフレームを転送する仕組みのため盗聴することはできません。 ただし、FDBが枯渇するとMACアドレスの学習ができなくなるため、枯渇後の未学習フレームは全てのポートにフラッデ

  • データジャーナリズムでやってはいけないこと

    データジャーナリズムの専門家として知られるポール・ブラッドショーさんが、自身の「オンラインジャーナリズム・ブログ」で「データジャーナリズムの倫理学」という連続投稿をしていた。ブラッドショーさんはバーミンガム・シティ大学の准教授で、サイト「データドリブンジャーナリズム」の編集委員も務めている。 データジャーナリズムの手法についての執筆が多いブラッドショーさんだが、ここで述べているのは、「やってはいけないこと」だ。ビッグデータのバブルと同様、キモをしっかり捉えていないと、おかしな方にいってしまう。大事な指摘だ。 ▼データの精度に疑問があれば問い合わせ、場合によっては掲載を見送る Ethics in data journalism: accuracy (Online Journalism blog) 役所が出したデータだからといって、それが100%正しいとは限らない。 実際に、テキサス・トリビュ

    データジャーナリズムでやってはいけないこと
  • Devsの常識、DBAは非常識

    ソーシャルゲーム案件におけるDB分割のPHP実装 ~とにかく分割ですよ。10回じゃ足りない。20回くらい分割。~ 株式会社インフィニットループ 佐々木 亨基 2013/7/15にPHPMatsuri2013内で発表された講演のスライド

    Devsの常識、DBAは非常識
  • InfoQ: Web開発者が知っておくべき八つの分離レベル

    原文(投稿日:2009/3/15)へのリンク ACID特性はデータベース論の基礎の一つです。ACIDではデータベースの信頼性を保つために必要とされる4つの属性を定義しています。原子性(Atomicity)、一貫性(Consistency)、分離性(Isolation)、そして永続性(Durability)です。4つの属性はいずれも重要ですが、とりわけ分離性については最も柔軟に解釈されています。ほとんどのデータベースがいくつかの分離レベルを選択できるようにしていますし、最近は多くのライブラリがより極め細やかな分離レベルを作成するレイヤを追加しています。このように広範囲の分離レベルが存在している主な原因は、緩い分離レベルによって拡張性や性能が数桁のオーダーで異なることにつながるからである。 シリアライズ可能というのは最も古典的で高い分離レベルであり、一般的に使うことが出来るもので、多くの人がそ

    InfoQ: Web開発者が知っておくべき八つの分離レベル
  • TwilioのRedisによる決済サービスの障害、2つの原因 - unknownplace.org

    Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する