関係情報：情報通信関連：情報通信白書
情報通信統計データベースについて 情報通信統計データベースは、総務省の実施する情報通信業に関わる産業の実態について、分野別データ、統計調査データ、関係情報の３項目に分けて掲載しています。 ○新着情報：情報通信統計データベースの更新状況等を掲載 ○情報通信統計データベースからのお知らせ：情報通信関連統計調査の実施状況等を掲載 ●情報通信統計データベース管理者： 総務省 情報流通行政局 情報通信政策課 情報通信経済室 統計企画係 TEL:03-5253-5744 ●分野別データ等に関しては、各ページにデータのお問い合わせ先を掲載しておりますので、データの詳細についてはこちらをご利用下さい。 情報通信統計データベース掲載データ等の取扱いについて
データベース・セキュリティの実装 第1回 アクセスコントロールと権限管理 | oracletech.jp
■データベースのセキュリティで情報を保護することの意義 RDBMSにおける情報保護、いわゆるデータベース・セキュリティは2004年、個人情報保護法の完全施行を前にして多くの漏洩事件が明るみに出た時期を大きなターニングポイントとして、速くて止まらず管理しやすければ良いというだけはなくセキュリティが確保されているということが同時に強く求められるようになったと言えるだろう。 内部犯行による意図的な情報漏洩事件について考えるときにやっかいな問題のひとつは「情報を盗んでも窃盗ではない」ということであるが、この問題を解決する方法の一つとして期待されているのが不正競争防止法の改正である。2009年4月に改正案が国会で可決・成立しており、2011年に入って実際の検挙事例も出てきた。この不正競争防止法では「不正の利益を得る目的」で「営業秘密を記録した媒体等を横領する行為、無断で複製する行為」が処罰対象と
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
もう1つの、DBのかたち、分散Key-Valueストアとは
もう1つの、DBのかたち、分散Key-Valueストアとは：分散Key-Valueストアの本命「Bigtable」（1）（1/3 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
Drizzleプロジェクトの目指すもの、その先を読む（1/3） － ＠IT
クラウドコンピューティング環境のような“massively concurrentな世界”で使えるデータベースを目指すDrizzle。その開発の方向性からこれからのWebシステムで求められるデータベースのあり方が見えるかもしれない。一足先にDrizzleに触れてみよう（編集部） Drizzleとは Drizzle とは、MySQLのもともとの目標である、使いやすさ、信頼性、そしてパフォーマンスに重点を置いたMySQLの派生プロジェクトで、Brian Aker氏（米サン・マイクロシステムズ CTO/Labs：元MySQL Director of Architecture）によって立ち上げられました。 MySQLと比較して機能面におけるDrizzleの大きな違いは、サーバアーキテクチャをマイクロカーネルにすることで、サーバ（MySQLでいうmysqld）には必要最小限の機能しか搭載せず、代わりに
Good Bye MySQL 6.0
MySQL 6.0.11-alphaがリリースされた。が、アナウンスレターには気になる記述がひとこと。「これはMySQL 6.0の最後のリリースです」と。寝耳に水かも知れないがこの話は本当だ。実はこれが最後のMySQL 6.0のリリースになる。つまり、MySQL 6.0の開発はこれでストップするのだ。 などと心配しないで頂きたい。MySQLの開発はちゃんと継続される。開発の方針が変更されることになったからMySQL 6.0のリリースが見送られただけである。（ちなみに、次期バージョンはMySQL 5.4で、MySQL 6.0はその次のバージョンになる予定だったものである。といっても、MySQL 5.4は後から間に挿入された形なのだが。）理由は、ここのところMySQLの新バージョンのリリーススケジュールが遅れがちだったり色々と問題があったからだ。（何かが変更されるときは大抵その背景には問題があ
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
東京都公立図書館横断検索
条件項目は館により無効の場合があります 詳細 検索結果は別画面に表示されます。 検索した資料の利用方法についてはこちらを必ずお読みください。 検索した資料の利用については、資料の所蔵館ではなく、 ふだん利用されている図書館にお尋ねください。
LINEAR HASHパーティショニングってなんだ？
MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事（パーティショニングの使用例 - http session情報）を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...
無いから作った人たち
データベース技術の世界に新顔が次々と登場している。米Danga Interactiveの「memcached」、ミクシィの「Tokyo Cabinet」と「Tokyo Tyrant」、楽天の「ROMA」、グリーの「Flare」などだ。いずれも半導体メモリーを使って大規模データベースを高速処理する技術である。面白いのは、4社ともIT製品を開発するメーカーではないことだ。 4社は、Webを使ったサービス事業を手掛ける企業であり、本来であればメーカーが開発した製品や技術を使う立場である。ところが、こうした「ユーザー企業」が自ら基盤技術を開発し、それを利用している。 memcachedやTokyo Cabinet/Tyrant、ROMA、Flareの中では、memcachedが一番古い。Danga Interactiveが自社のブログ・サービス「LiveJournal」を改善するために2003年に
Tokyo Cabinet
Our team of highly trained cybersecurity professionals provides expertise in compliance, tool assessments, threat hunting, incident response and more. Critical Start is leading the way in Managed Detection and Response (MDR) services. With a unique approach that treats every security alert as equal, Critical Start's proprietary Trusted Behavior Registry allows security analysts to resolve every al
OPC Diary: Key-Value Store(s)という流れ
« CanonはCAPTプリンタの64bit版ドライバーを出せ!! | メイン 2009年02月27日 Key-Value Store(s)という流れ はじめは大規模なWebサービスを提供する現場の工夫に始まった分散キャッシュ技術、これが最近ではキャッシュのみならずデータのレプリケーション、永続化も可能となりKey-Value Store(KVS)と言われるようになった。 実質的にOracleやIBMのくそ高いインメモリデータベースにかなり近づいてきているが、それらがメモリ上にRDBMSを構築する物であるのに対し、KVSはキー値とデータというもっと単純なデータ構造を持つのが大きな違いだ。 スケールアウトによる負荷分散を前提とする大規模なWebサービスやユーティリティコンピューティングにとってRDBMSを前提とするOLTPの考え方はそれがボトルネックになり、パフォーマンスと冗長性に
key-value stores: Anti-RDBMS: A list of distributed key-value stores | Richard Jones, Esq.
Please Note: this was written January 2009 - see the comments for updates and additional information. A lot has changed since I wrote this. Perhaps you’re considering using a dedicated key-value or document store instead of a traditional relational database. Reasons for this might include: You're suffering from Cloud-computing Mania. You need an excuse to 'get your Erlang on' You heard CouchDB was
「キー・バリュー型データストア」開発者が大集合した夜
「発表者が自分よりも若い人ばかりだ」。外見が20代にしか見えない東京工業大学の首藤一幸准教授（1973年生）の驚くさまが、少し面白かった。2009年2月20日の夜、多くのWeb企業が注目する「キー・バリュー型データストア」を開発する若手技術者が、東京・六本木のグリー本社に一堂に会した。 キー・バリュー型データストア（またはキー・バリュー型データベース）は、大量のユーザーとデータを抱え、データベースのパフォーマンス問題とコスト高に頭を悩ませるWeb企業が注目する技術である。記者は同日に開催された「Key-Value Store 勉強会」に参加させてもらった。午後7時から11時まで、キー・バリュー型データストアを開発・研究する若手技術者が立て続けに登場し、1人15分の持ち時間で成果を発表し、議論を重ねるという集まりだ。 呼びかけ人であるプリファードインフラストラクチャー（PFI）最高技術責任者
バイナリvsテキストに関するオトコの見解
バイナリーとテキストの本当の違い、それは「終わり」にある。 ・「終わり」がはじめにわかるのが、バイナリー。 ・「終わり」が来るまで「終わらない」のが、テキスト。 本質的な違いは、これだけである。 果たしてそうだろうか。 例えばテキストデータとバイナリデータを用いて、データをファイルに記録する場合を考えよう。バイナリデータは予め構造が決まっているのに対して、テキストデータは任意の順番でデータが並んでいる可能性がある。つまり、テキストデータにはコンテキストが存在するのである。 バイナリデータがどのような構造になっているかは、プログラムだけが知っているという場合が多い。もしくは仕様書に書いてあるとか。バイナリデータそのものはデータの構造について、情報を持っていないのである。典型的なバイナリデータとして思い浮かぶのは、IPパケットのヘッダとかSCSIコマンドとか画像ファイルとか動画ファイルとか。こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLをダウンロード&インストールしよう
moved
GREE Engineering
kai