
東京大学生産技術研究所喜連川研究室は2014年7月9日、国から41億円の助成金を受けた研究プロジェクト「FIRST喜連川プロジェクト」の成果報告会を開いた。同プロジェクトでは、既存技術に比べて1000倍の高速で動作する「非順序型データベースエンジン技術」を開発。中心研究者である東大の喜連川優教授(写真1)は「ディスクでもフラッシュでも、商用ソフトでもオープンソースソフトウエア(OSS)でも、同じように高速化する技術ができた」と成果を語った。 FIRST喜連川プロジェクトの正式名称は、内閣府最先端研究開発支援プログラム(FIRST)の「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」で、2010年3月から2014年3月末までの4年間で、非順序(アウト・オブ・オーダー)型実行原理に基づく超高速DBエンジン技術(非順序型DBエ
●既存のDB技術と一線を画すデータ検索技術を生み出す ●ゼロベースで発想しOSの基本機能に着目 ●ストップウオッチ片手に高速化を追求 ソフト開発ベンチャーのHOWSが、これまでにないデータ管理・検索技術「ISSEI」を開発した。HOWSは現在、ISSEIを次世代Web基盤技術として特許を出願している。 「ユーザー企業がデータを有効活用するためには、既存のリレーショナルデータベース(RDB)と一線を画す技術を編み出すほかないと考えた」。HOWSのCTO(最高技術責任者)である庄司渉副社長は、ISSEIを開発した思いを語る。 ユーザー企業の多くは現在、社内システムを整備し、テキストや画像、音声などさまざまな種類のデータを大量に蓄積している。その一方で「データを業務に有効活用できていない」と嘆くCIO(最高情報責任者)が多いのも事実だ。 その理由について庄司副社長は、「現在主流のRDBが限界に近
社内で少し話題になったので。 運用上の話はfujiwaraさんの MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店 MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店 をみてください。 最近、新しくサービスができたり、新規機能でデータベースを追加する際には必ず全ての参照をmasterに向けてもらっています。理由は上記のエントリを読んでください。このような構成が取れるのはもちろん性能的にそれで問題ないからです。 新しいハードウェアに、設定されたMySQL、問題のないように書かれたSQLであれば、数千QPSは余裕に、また少し頑張れば数万QPSを一台で賄えます。なので大体のサービスはmaster一台で十分です。 さらにこの考え方を進めて、Webアプリケーションの中で sub d
プロジェクトの遅延回復策として行われる人員投入。しかし、単に人員投入をしただけではさらなる遅延を招いてしまう……。その打開策とは? 遅れているプロジェクト(銀河系のすべてのソフトウェア開発プロジェクトの120%が該当します)の遅延回復対策として、優れているものから順番に「スケジュールの延長」「トリアージュ(野戦病院方式)」「人員投入」「ダイハード方式」の4つがあると前回のコラム「震災地ボランティアと遅延プロジェクトの回復」で述べました。 「寝ないでコーディングしろ!」「土日も出社してデバッグだぁ!!」という長時間労働のみに頼るダイハード方式は論外にしても(しかし、現実には確実に失敗するこの方法を強制されることが少なくありません。特に、時間的な制約が非常に厳しい組み込み系のソフトウェア開発では顕著です)、遅延回復対策として“助っ人”を投入するプロジェクトは多いでしょう。 そこで今回は、『人員
「スイッチを入れるだけで、これまでのクエリー処理が100倍速くなる」---2013年9月22日(米国時間)に幕を開けた米Oracleの年次カンファレンス「Oracle OpenWorld San Francisco 2013」、同社のラリー・エリソンCEOは基調講演でこう宣言した(写真1)。エリソンCEOが紹介したのは、「インメモリー・オプション」と呼ぶ、Oracle Database 12cで利用可能な追加機能。データベース内でデータをカラム(列)型で保持し、しかもインメモリーで操作することで、桁違いのスピードでクエリーが処理できるという。 「Oracleを含め多くのRDBMSはロー(行)単位でデータを操作してきたが、レポートを高速に作りたいなどのニーズに応えるため、最近はカラム型を採用する製品が増えている」。エリソンCEOは、カラム型に注目した背景をこう説明する。必要なデータをカラム単
2013年9月22日~26日に米国で開催された「Oracle OpenWorld 2013」には、世界中から6万人が参加登録した。 最も注目を集めたのが、OLTPとデータウエアハウス(DWH)を一つのDBで高速に処理できる、インメモリーDBの発表だ。バッチ処理やインデックスを不要にするなど、これまでの常識を覆すポテンシャルを秘める。 クラウド関連の発表も相次いだ。「Oracle Cloud」に、DBクラウドやJavaクラウドなど新たに10種類を追加。ワンストップで顧客のニーズに応えようと、SaaSからPaaS、IaaSまで全てのレイヤーでサービスを充実させている。「OpenStack」への対応も見逃せない。 クラウドの品ぞろえを増やし、DBのカバー領域を広げることで、企業ユーザーの業務を全てオラクル製品に取り込む。“総取り”に向かって突き進む、オラクルの最新動向をつかもう。 Oracle
Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない(解放まで多少遅延する)ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ(要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか?なぜ(べき、べきでない)のか?どういう要請でそうなのか?と言う問いに僕は答えられません。 2013-09-04 09:31:22
先日をもって無事に読了しました。記念に記録しておきます。 読んだ本はこれ Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery http://www.amazon.co.jp/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088/ref=sr_1_1?ie=UTF8&qid=1370746124&sr=8-1&keywords=transactional+information+systems 始まったのが、2011年の秋からだったので、ほぼ一年半かかりました。スタート時点は10名ほどいたメンバーも徐々にいなくなり、最後は不動の4人のレギュラー
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "Java Persistence API" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2021年6月) Java Persistence API(JPA)とは、関係データベースのデータを扱うJava SEおよびJakarta EE(旧・Java EE)のアプリケーションを開発するためのJava用フレームワークである。 JPAは、以下の3つの部分から成る。 API(javax.persistence パッケージで定義されている) Java Persistence Query Language オブジェクト/関係メタデータ JPAのリ
データベースをまるごとメインメモリ上で処理することにより、従来のハードディスクベースのリレーショナルデータベースよりも劇的な高速化を実現するインメモリデータベースであるMemSQLの最新版「MemSQL 2.0」が公開されました。 MemSQL 2.0はインメモリのスピードとSQLでの問い合わせ、スケールアウト機能、そしてエンタープライズ対応の可用性など、4つの特徴を持つと説明されています。 In-memory architecture Ad hoc SQL-based analytics Horizontal scale-out on commodity hardware Enterprise-grade durability and high availability スケールアウトでデータウェアハウスに対応 MemSQL 2.0はインメモリデータベースの特徴である高速な処理に加えて、
チラシの裏的な雑記です。 サービスに新しいデータストアを選ぶ際にこの辺を情熱を持って説明してくれる人が好き、という話です。 そのデータストアを使う理由はなんですか?みんなが使い慣れている物から変える理由は「有名な会社が使っていて^^」「他のチームが使っていて^^」とかではなくて、既存の物では解決出来ない問題を解決するアプローチになっていますか? もし単純にキャッチアップしておきたいというレベルなら、あなたの趣味で作るシステムで運用する、では欲求を満たせませんか? 同じようなプロダクトは他にもあると思いますが、そのプロダクトで無ければいけない理由はなんですか? まだ新しいプロダクトだった場合、あなたはそのコードを読んで、バグを報告して、必要であればパッチを書く覚悟を持っていますか? あなたはチーム内でそのプロダクトの第一人者になる、という覚悟がありますか?他のメンバーへの啓蒙や情報共有を率先
Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、本格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMSサ
Oracle TimesTen In-Memory Database is an in-memory, relational database management system with persistence and high availability. Originally designed and implemented at Hewlett-Packard labs in Palo Alto, California, TimesTen spun out into a separate startup in 1996 and was acquired by Oracle Corporation in 2005.[1] TimesTen databases are persistent and can be highly available. Because it is an in-
How TimesTen works TimesTen is a lightweight, fully persistent, and highly available in-memory relational database that delivers microsecond response and high throughput for OLTP applications. You can use TimesTen as a database of record or as a cache for Oracle Database. Because the TimesTen database resides in physical memory rather than a file system, access to data is more direct, resulting in
2013/2/21収録 『SQLアンチパターン』(オライリー・ジャパン刊・オーム社発売) 刊行記念トークセッション データベースを巡る世代間闘争 和田卓人(監訳者・子)×和田省二 (監修者・父) リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗(アンチパターン)があります。本セッションではそのようなアンチパターンを避けるための指針となる新刊『SQLアンチパターン』の内容を紹介しつつ、監訳者親子の設計論議(データ中心設計とオブジェクト指向設計の間の世代間闘争)の再現を試みます。世代間のインピーダンスミスマッチは『SQLアンチパターン』を通じて解消されるのか、御期待ください。 ◆講師紹介◆ 和田 卓人(わだ たくと) 本書監訳者。タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。学生時代にソフトウェア工学を学び、オブジェクト指向分
デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか? と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン![/追記] 内容: はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使
『分散オブジェクト・アーキテクチャ/ドメイン指向アーキテクチャ』について考えるなかで、「永続化」への理解が深まった。というか、このアイデアについて人と話してもかみ合わない理由が分かった。とどのつまり、ぼくが独特な感覚を持つマイノリティだったのだ。 たぶん、ふつうのプログラマから見れば、おそろしくどうでもいいことにこだわっている、ように見えるだろう。 信仰告白 ぼくは現在主流の「データベースを使った永続化」が大嫌いだったんだ。ORMとか一体何なんだ。知らんわな。なんでプログラムを書くのにSQLを書かなきゃならんのだ。(※個人的な感じ方の問題です) 「RDBからSQLでデータをとってきてHTMLで整形して出力するPHPプログラミング」なんて二度とごめんだ。データベースのために働いてるみたいじゃないか。(※個人的な感じ方の問題です) 「データベースを使った永続化」が行き過ぎると「データベース中心
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く