タグ

dbに関するbecomingのブックマーク (7)

  • MonetDB

    MonetDB is a high performance relational database system for analytics RobustMonetDB offers a robust SQL compliant database interface, enabling applications ranging from pure analytics to hybrid transactional/analytical processing. It supports common features including keys, joins, views, triggers, and stored procedures, along with full-ACID properties for concurrent transactions. Additionally, Mo

    becoming
    becoming 2008/01/15
  • RDBMSでは不十分

    リレーショナルデータベースはクライアント/サーバモデルに適合するものの、サービスの世界では新しいソリューションが必要である(source)。RDBMSはスケーラビリティの問題に陥りやすい。冗長性や並列性をどのようにして実現すればいいのか(source)? (リレーショナルデータベースは)単一故障点となります。特に複製はささいな事ではありません。疑問に思うのであれば、全く同じデータを必要とする2つのデータベースサーバがあることによって起こる問題を考えて見てください。データを読んだり書いたりするために両方のサーバがあると、同時に変更するのが困難になります。マスターサーバとスレーブサーバがあっても、良くありません。なぜなら、マスターはユーザが情報を書き込む際、沢山の熱を帯びるからです。 また、Assaf Arkin氏も整合性を書くこと(source)はRDBMSが自身の重さで内破してしまう理由で

    RDBMSでは不十分
    becoming
    becoming 2007/12/07
  • サイボウズ株式会社

    サイボウズはクラウドベースのグループウェアや業務改善サービスを軸に、社会のチームワーク向上を支援しています。

    サイボウズ株式会社
  • mixi Engineers’ Blog » Inside Tokyo Cabinet その五

    先日、MySQL Conferenceという催しに行ってきました。そこでMySQLの開発者のBrian Aker氏およびMichael Widenius氏と話をする機会があったのですが、やっぱしトップランナー達と議論するのは刺激になるなぁと思ったmikioです(その時の資料)。さて、一連の連載も今回が感動の最終回で、TCの性能上の蘊蓄をお届けいたします。 なぜdynamic hashingを使わないか Brianさん達とTCの実装についても少し議論したのですが、その際にdynamic hashingをなぜ使わないのかと問われました。その背景として、TCやQDBMではハッシュのバケット数(=格納するレコード数を予測してその数倍に設定すべき値)をデータベース作成時に指定しなければならないという問題があります。バケット数が大きすぎると空間効率が劣化し、小さすぎると時間効率が劣化するというトレード

    mixi Engineers’ Blog » Inside Tokyo Cabinet その五
    becoming
    becoming 2007/09/25
  • 最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro

    ポイント ・高度なインデックスやジョインを利用し,最短経路でデータにアクセス ・メモリー不足を自律的に解消し,キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し,高速化を図る 目的地に早く到着したいなら,最短の経路を最速で行けばよい。これはデータベース(DB)でも同様だ(図1)。インデックスなどを使ってデータへの最短経路を見つけ,メモリー・アクセスを増やして,最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では,(1)データにたどり着く最短の道を選ぶ仕組みと,(2)アクセスのスピードを上げる仕組みの

    最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro
    becoming
    becoming 2007/09/14
  • ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法

    こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー

  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • 1