■データベースのセキュリティで情報を保護することの意義 RDBMSにおける情報保護、いわゆるデータベース・セキュリティは2004年、個人情報保護法の完全施行を前にして多くの漏洩事件が明るみに出た時期を大きなターニングポイントとして、速くて止まらず管理しやすければ良いというだけはなくセキュリティが確保されているということが同時に強く求められるようになったと言えるだろう。 内部犯行による意図的な情報漏洩事件について考えるときにやっかいな問題のひとつは「情報を盗んでも窃盗ではない」ということであるが、この問題を解決する方法の一つとして期待されているのが不正競争防止法の改正である。2009年4月に改正案が国会で可決・成立しており、2011年に入って実際の検挙事例も出てきた。この不正競争防止法では「不正の利益を得る目的」で「営業秘密を記録した媒体等を横領する行為、無断で複製する行為」が処罰対象と
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
もう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
クラウドコンピューティング環境のような“massively concurrentな世界”で使えるデータベースを目指すDrizzle。その開発の方向性からこれからのWebシステムで求められるデータベースのあり方が見えるかもしれない。一足先にDrizzleに触れてみよう（編集部） Drizzleとは Drizzle とは、MySQLのもともとの目標である、使いやすさ、信頼性、そしてパフォーマンスに重点を置いたMySQLの派生プロジェクトで、Brian Aker氏（米サン・マイクロシステムズ CTO/Labs：元MySQL Director of Architecture）によって立ち上げられました。 MySQLと比較して機能面におけるDrizzleの大きな違いは、サーバアーキテクチャをマイクロカーネルにすることで、サーバ（MySQLでいうmysqld）には必要最小限の機能しか搭載せず、代わりに
すごい良い記事。 知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey 知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey 頼まなくてもこういう記事を書いてくれる人が増えている（頼まれてないっすよね？）のは、SFDCにとって、デベロッパーマーケティングとして成功だと思う。大事にしてくださいね。 スキーマについて 上記記事では、データベースの物理スキーマについて、公開情報をもとに分析されています。 掟破りのスキーマ セールスフォースのアプリケーションで扱われるすべての数字や文字のデータは、Dataテーブルに保存される。このことがセールスフォースのデータベーススキーマの核心です。 Dataテーブルはどんなデータでも受け入れられるよう、次のようなスキーマになっています。恐らく、データベースに詳し
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
2009/05/12 既存データベースサーバのハードディスクをSSDに置き換えた場合、どの程度パフォーマンスが向上するのか？ この問いへの回答の1つとなり得るベンチマークテストを、“MrBenchmark”を名乗るサン・マイクロシステムズのチーフ・エンジニアのBenoit Chaffanjon氏が5月11日付けのブログで公開している。 ベンチマークは2種類。1つはオンメモリで処理が完了するもの、もう1つはキャッシュメモリに乗り切らずにドライブ（HDD/SSD）へのアクセスが発生するもの。テストに用いたサーバのコンフィギュレーションは以下の通り。 Solaris 10 Update 6 Oracle 10.2.0.2 Java 1.7 build 38 SLAMD 1.8.2、iGenOLTP Sun Blade X6270（Xeon X5560@2.8GHz×2、DDR3 32GB） In
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年に
About Groonga Groonga is an open-source fulltext search engine and column store. It lets you write high-performance applications that requires fulltext search. Characteristic The latest release 14.1.1 is the latest release. It had been released at 2024-12-03. Install Source The latest posts PGroonga (zero ETL fast full text search module for PostgreSQL) 3.2.5 has been released (2024-12-05) Groonga
FactoryTalk Optix Cloud Manufacturing Software For manufacturers interested in a powerful, open, scalable, HMI visualization platform FactoryTalk Optix can help improve your process, efficiency and deliverables – in one easy to access tool. Take advantage of new levels of collaboration, scalability and interoperability to achieve your HMI vision. New SaaS-enabled workflows will enable your team to
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）最高技術責任者
バイナリーとテキストの本当の違い、それは「終わり」にある。 ・「終わり」がはじめにわかるのが、バイナリー。 ・「終わり」が来るまで「終わらない」のが、テキスト。 本質的な違いは、これだけである。 果たしてそうだろうか。 例えばテキストデータとバイナリデータを用いて、データをファイルに記録する場合を考えよう。バイナリデータは予め構造が決まっているのに対して、テキストデータは任意の順番でデータが並んでいる可能性がある。つまり、テキストデータにはコンテキストが存在するのである。 バイナリデータがどのような構造になっているかは、プログラムだけが知っているという場合が多い。もしくは仕様書に書いてあるとか。バイナリデータそのものはデータの構造について、情報を持っていないのである。典型的なバイナリデータとして思い浮かぶのは、IPパケットのヘッダとかSCSIコマンドとか画像ファイルとか動画ファイルとか。こ
［ITproカンファレンス：Amazonクラウド］クラウド時代のDB技術はこうして作られた--- NTT未来ねっと研の井上氏 2009年4月10日に開催されたITproテクノロジ・カンファレンス「徹底理解『Amazonクラウドサービス』」で講演のトリを飾ったのは，NTT未来ねっと研究所 研究主任の井上武氏（写真）。現在クラウドサービスに利用されているデータベース技術は，伝統的なリレーショナル・データベースからどのように進化したか，順序立てて説明した。 まず井上氏は，従来のリレーショナル・データベースの特徴に言及。データの不整合性を排除するリレーショナル（関係）モデルや，経過的な状態を排除するためのトランザクション処理は「データベースが主に金融機関の帳票データを保管していた時代のニーズに合致したものだった」（井上氏）と説明した。 「データベースが進化するきっかけは，管理対象データが変わったこ
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く