Engine.so | Build your knowledge base with NotionTransform your existing Notion pages into a modern, self-service knowledge base for your customers.
Twitter details its Manhattan real-time database – Old GigaOm
Twitter’s service is nothing if not fast-moving, and on Tuesday night the company published a blog post detailing the database that helps it keep up. Called Manhattan, it’s a distributed, real-time database built to serve multiple teams and applications within the company. It’s also something of an indictment against existing open source database technologies, at least when it comes to handling th
データベースの限界性能を引き出す技術 ～NoSQLに飛びつく前に知っておきたい原理と最新テクニック
2014年3月18日紙版発売 2014年3月18日電子版発売 山崎泰史，武吉佑祐 著 A5判／224ページ 定価2,948円（本体2,680円＋税10%） ISBN 978-4-7741-6364-2 ただいま弊社在庫はございません。 Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle 楽天kobo honto この本の概要 「RDBMSだと大規模データをうまく扱えない」といわれ，NoSQLのような代替技術が生まれてきていますが，本当でしょうか？ ビッグデータ時代でもシステムの中核として依然重要なRDBMSの力を100％発揮できれば，開発や運用はもっとラクになります。 本書では，ストレージ，CPU，ネットワークといったあらゆる点から「なぜ，RDBMSは遅くなるのか？」と「どうすれば，性能を最大限引き出せるのか？
筑波大学でデータベースの話をしてきました - kuenishi's blog
筑波大学の川島先生に呼ばれて木、金と情報システム特別講義Dというやつに参加してきた。こんなことになるとは思っていなかったが、あろうことか講師側で呼ばれてしまい、思えば遠くへ来たものだと感慨深い。フリは「RiakとNoSQLの話をしてもらえたら」という非常に自由度の高い内容なので、せっかくなので僕の知っていることを全部詰め込んで話してやろうと思ったら10分延長してさらにスライド10枚分くらいを消化不良で終了という、みっともない感じになってしまった。かなり端折ってポイントだけ説明したので流れが分からず苦労した方も多いと思うが、まあ僕の性格なので許してほしい。データベースの講義をひと通り終えた院生レベルを想定してスライドを作ったので、もしかすると、わりと難しかったり分かりにくかったりするかもしれないので、わからないことがあったら適当に質問してください。 言いたかったことの流れを僕なりにまとめると
The Future of the Database (Infographic) - Innovation Insights
During the first database wars in the early 1980s, it wasn't immediately obvious that the relational database model was superior to existing models. But over time, this model won due the power of SQL programming and ability to simply structure critical business data for back-office automation, e-business, and web-sites. As data growth and transaction loads increased, bigger and more powerful serve
「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 のブログ
私は、ソーシャル系とは縁遠い仕事ばっかりしているのですが、そういう依頼も若干増えてきたので話題になっている「艦これ」をお盆にやってみた。 残念ながら、「艦これ」の魅力は分からなかった。しかし、ミッションを用意されると、「クリアーしたい」という欲求から意地になるのは、何となく理解できました。それより、同時に始めた「Clash of Clans」には嵌まりました。気になっていた「ゲームの中に如何に自然に課金システムを取り入れるか」という課題についても、個人的には「Clash of Clans」の方が上手に解決しているように思います。 「艦これ」は、同時アクセスが10万以上あって、何度かシステム障害があったとのこと（そりゃあるでしょうが……）。私の興味の方向性は、課金システムであったり、システム構成にあるので、「艦これ」のシステム障害の方が強い興味の対象になります（苦笑） というわけで、「ソーシ
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
When is "ACID" ACID? Rarely. | Peter Bailis
RC: read committed, RR: repeatable read, S: serializability, SI: snapshot isolation, CS: cursor stability, CR: consistent read Instead of providing serializability, many these databases provide one of several weaker variants,2 often when marketing material and documentation claim otherwise.3 There is no fundamental reason why a database shouldn’t support serializability—we have the algorithms, and
NoSQLの現状
このため、NoSQLの知識を持つ開発者やアーキテクトに対する需要が高まってきています。最近の調査によると、最近必要とされる開発スキルは次の通りです。 HTML5 MongoDB iOS Android Mobileアプリ Puppet Hadoop jQuery PaaS ソーシャルメディア 技術的要求のトップ10の中で、NoSQLデータベースは2つあります。1つは、iOSよりも上です。これがNoSQLをほめているのでなかったら、何なのでしょう?! しかし、一見したところ、NoSQLはますます速く深いところまで適用されるようになっています。2011年の夏に、有名な報告書の中でOracleは次のように述べました。NoSQL DBがアイスクリームの味のように感じるかもしれないけれど、あまり深入りしない方がいい、NoSQLはそれほど長く残らないかもしれないから。そのわずか2、3ヶ月後、Oracl
インメモリキャッシュで並列にトランザクション処理する「ULFIRE」は何を狙うのか
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます スケールアップかスケールアウトか――。システムをいかにスケールさせるか。つまりはシステムの性能をいかに拡張させるか。この視点でよく議論されるのがスケールアップかスケールアウトかという議論だ。 ただ、スケールアップかスケールアウトかという選択肢は必ずしも二者択一の関係にあるわけではなく、システムがどんなデータをどう処理すべきかという点で補完関係にある。例えばオンライントランザクション処理（OLTP）はデータの一貫性が求められることからスケールアップの方が向いていると言われるし、大量のアクセスをさばかなければならないウェブサーバではスケールアウトの方が向いている。 スケールアウトのメリットは、何よりも処理ノードを追加すればするほど処理性能が
12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
絵で見てわかる 某分散データストア
Python Developers Festa 2012.03 での発表スライドです。Read less
「NoSQL」を上回る性能を目指す次世代型高速SQLデータベース「VoltDB」登場
豊富なメモリやマルチコアCPUを備えたシステムに最適化された次世代型の高速SQLデータベース「VoltDB」がリリースされた。メモリは4Gバイト以上が推奨されるなど利用環境は限定されるが、トランザクション性能はほかのDBMSを圧倒する性能を示しており、今後が注目される。 ベンチャー企業の米VoltDBは5月25日（現地時間）、オープンソースのデータベースシステム「VoltDB 1.0.1」をリリースした。高速、拡張性、ACID順守などを特長とする次世代DBMSとしている。 VoltDBは「Postgres」「Ingres」などのデータベースプロジェクトを共同で創始したマイケル・ストーンブレイカー氏が設計したもので、同氏が非常勤教授を務めるマサチューセッツ工科大（MIT）、ブラウン大学、イェール大学、HP Labsの共同研究「H-Store」がベースとなっている。 VoltDBは豊富なメモリ
京都収納棚：DBMの率直な壱実装 - mixi engineer blog
飲み屋に行くとかなりの確率で荷物を忘れて帰るmikioです。さて、今回はここ2ヶ月ほどで急ピッチで開発した軽量データベースライブラリ「Kyoto Cabinet」について紹介します。 開発の動機 以前から軽量データベースライブラリとしてご好評いただいているTokyo Cabinetですが、DBMとして必要十分な機能と性能を備えていてなかなか良いものだと自負しております。ただ、開発を進める中でいくつか不満な点があったのも事実です。端的に言えば、全てC言語で記述して、標準ライブラリ（とzlib/bzip2）以外の機能は全て自作しているので、最適化がしやすい反面、メンテナンスの難易度が高くなってしまっているというのが不満です。 そこで、多少性能が悪くなってもいいから、私自身としてお気楽に開発およびメンテナンスができて、移植性も高いような実装を作ってみようと思い立ったのが昨年10月頃。様々な検討を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
agilecatcloud.com