デベロッパーとデータベース管理者は手を取り合うべきだと、マーチン・ファウラー氏
デベロッパーは官僚的なデータベース管理者を嫌って、管理不要のNoSQLデータベースを希望することがあるけれど、両者が手を取り合うことの方が重要だ。マーチン・ファウラー氏は先週、「NoDBA」という記事を自身のWebサイトにポストしました。 デベロッパーによる最新の開発手法の採用とその壁、NoSQLデータベース、DevOpsといったITのキーワードを含むこの記事は翻訳が許可されているため、日本語訳してみました。 NoDBA 多くの組織において、保存が必要なデータは情報部門が集中管理するリレーショナルデータベースに収まることだろう。情報部門が集中管理する理由はそれぞれだが、統合的なデータベースの運用が一般的な理由だろう。データを管理している部門は、変なデータが紛れ込まないか、データベースを遅くするようなクエリが実行されたりしないか、企業全体で一貫性のあるデータモデルが実現されているか、といった
ログ解析を支えるNoSQLの技術
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～ （Kubernetes Meetup Tokyo #33 発表資料） 2020/08/26 NTT DATA Yasuhiro Horiuchi
スキーマレスについてちょっと考えてみた - As a Futurist...
このエントリはたぶんに煽り要素を含めていますが、意図的なものです。僕は NoSQL は素晴らしいと思います。 さて、NoSQL なんて言葉に踊らされてる人は置いといて、最近 RDBMS 以外のデータストアというのが色々でてきてます。今時点で見渡す限りにおいては、安定性、耐障害性、パフォーマンス、情報量、開発者の慣れ、全体のバランスで言えば RDBMS にかなうものはないわけですが、今後どうなっていくかはまぁ分かりません。 一方で、RDBMS がどうしても苦手とする分野というのは存在します。例えば 1 サーバに収まりきらない様な大容量データに対するバッチ処理、リアルタイムなランキング、アクティビティなどのフィード情報、そして構造化されたデータの取り扱い。何でもかんでも NoSQL に置き換えればいいなんて考えは現時点では到底受け入れがたいですが、例として挙げた様なピンポイントな部分ではそれに
NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
