ストレージエンジン「Spider」が目指す世界
スパイラルアーム、オランダに事務所開設 小幡さんと斯波さん 小幡：「斯波(しば)」って珍しい名字だよね。 斯波：室町時代の守護大名で管領になれる家系だったそうです。うちは分家で関係ないですけど。 小幡：そう言われれば、しゃべり方が大名っぽい！ 斯波：いやいや、しゃべり方は引き継いでいません（笑）。 小幡：この前、オランダ アムステルダムのMariaDBイベントに参加したら、中国で時価総額がアリババを超えたというゲーム会社Tencentのメンバーが熱く発表しているセッションがあったの。それが斯波さんのSpider。Tencentはすごい規模でSpiderを使っている（データは100TB、Spiderは396台、データノードは2800台）。分析基盤で… 斯波：ゲームの基盤です。 小幡：そうだそうだ。なんとかプラットフォームって言ってた。前にSpiderの話を聞いたときはイマイチ頭に入ってこなか
Jepsen: Aerospike
Previously, on Jepsen, we reviewed Elasticsearch’s progress in addressing data-loss bugs during network partitions. Today, we’ll see Aerospike 3.5.4, an “ACID database”, react violently to a basic partition. [Update, 2018-03-07] See the followup analysis of 3.99.0.3 Aerospike is a high-performance, distributed, schema-less, KV store, often deployed in caching, analytics, or ad tech environments. I
Aerospike で 大量のトランザクション処理をさばく
https://atnd.org/events/71301 での発表資料です。
Microsoft PowerPoint - PODC-keynote
1 PODC Keynote, July 19, 2000 PODC Keynote, July 19, 2000 Towards Robust Towards Robust Distributed Systems Distributed Systems Dr. Eric A. Brewer Dr. Eric A. Brewer Professor, UC Berkeley Professor, UC Berkeley Co Co- -Founder & Chief Scientist, Inktomi Founder & Chief Scientist, Inktomi PODC Keynote, July 19, 2000 PODC Keynote, July 19, 2000 Inktomi at a Glance Inktomi at a Glance Company Overvi
NoSQLの現状
NoSQLは、たった4、5年で50から150の新しいデータベースを増やしました。nosql-database.orgは、そのようなデータベースを150程紹介しています。その中には、Object Databaseのように、非常に古いけれども、まだ強力な時代遅れのものも含まれていました。そして、もちろん、いくつかの興味深い合併があり、CouchDBとMembaseはCouchBaseになりました。この記事では、主要なシステムについて後ほど触れたいと思います。 多くの人々は、NoSQLの世界では大きな合併が起きていると考えてきました。ところが、本当はそうではありません。NoSQLは、ただ急激に増えただけであり、まだ増え続けています。プログラミング言語のようなコンピュータサイエンスのすべての分野と同様に、非常に多くのデータベースのギャップはますます広がっています。これはインターネット、ビッグデータ
NoSQLの現状。これまでの成功と失敗
NoSQLの登場は、「データベースといえばリレーショナルデータベース」という状況を大きく変えました。リレーショナルデータベースと比べて高速でスケーラビリティに優れたNoSQLデータベースは登場当初から注目されましたが、一方でいまに至るまでさまざまな種類の製品が登場して混沌としているようにも見えます。 （作者 Stefan Edlich、翻訳者 大田 緑 - (株)チェンジビジョン、投稿日 2013年1月1日） NoSQLは厳しい批判に少なくとも4年間さらされてきました。そして、今、NoSQLの現状について中間報告する時がやって来ました。NoSQLの周辺ではいろいろなことが起こったため、全体像をつかんで、どのような目的を達成したか、また、NoSQLはどこで失敗したかを評価するのは簡単なことではありません。 様々な分野において、NoSQLは産業的にも学問的にもかなり成功をおさめてきました。大学
Cassandraのはじめ方─手を動かしてNoSQLを体感しよう 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
住所データSQL - 仕様【住所.jp】
全国約１２万５千件の住所データ、郵便番号辞書としてお使いいただけます。 日本郵便株式会社の郵便データに基づき、全国の郵便番号を網羅。約２万件の事業所データも含みます。 住所は 都道府県・市区町村・町域・字丁目の４つの項目に分け、それぞれのカナも記載。 また、都道府県・市区町村・町域にコードを付加しています。 事業所の住所は 都道府県・市区町村・事業所住所（町域以下、番地まで）の４つの項目に分かれます。 １レコード毎に住所コードを付加しています。 日本語コードはUTF-8を使用しています。 提供ファイルは、全国版(1)、地方版(6)、都道府県版(47)の54種類です。 全て無料です。ただし、ご利用上の注意をよく読みお使いください。ご利用上の注意はこちら。
ETL処理とELT処理の違い ～ビッグデータ処理の新トレンド～ - GiXo Ltd.
ELT処理はクラウドデータベースだから可能になった荒業 皆さんは「ELT処理」をご存知でしょうか？ 決して「Every Little Thing」ではありません。 ELT処理は、ETL(Extract/Transform/Load)処理の変換・加工(Transform)とデータロード(Load)の手順を入れ替えた「Extract/Load/Transform」から作られた新しいデータ分析用語です。一昔前まではETL処理がデータベースへのインポートの常識とされていましたが、近年のクラウドデータベースなどの進化によって、無作法とされてきたELT処理で行った方がスマートになるケースが増えてきました。今回はELT処理とその背景にあるクラウドデータベースなどのサービスについて説明したいと思います。 参考：[graffe.jp]ETLとは～あらゆるデータファイルを理解してデータベース化する～ ELT処
唐突にデータウェアハウス（DWH）の設計をすることになったので、DWHの設計周りを調べた - Qiita
前提 筆者のスペック SQLが書ける程度でデータベースに詳しいかと言われるとそうではない新卒1年目のエンジニア（の卵）。 DWHとかデータウェアハウスって聞いたことあるけど具体的に何かはわからない。 DWHに加えてデータマートとやらが必要らしいとは知っていたが、具体的にデータマートが何かわからない。 DWHの4特性を知らなかった。 もちろんDWHの3つのアーキテクチャを知らなかった。 データベースよりむしろフロントエンドの方が好き。 今回の取り組みの目的 DWHの設計方法を理解し、要件に沿った最適な設計が可能になること。（2日で） 以上。 要件 複数のデータソースを元にBIツールでの分析がしたい。そのために必要なDWH・データマートを設計すること。 分析自体の要件は決まっているため、データソースを元にDWH・データマートをどのような設計にするか決定することがゴール。 データウェアハウス(D
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
データベース事始め - Qiita
TensorFlowのような機械学習にはデータベースは必要不可欠です。ただ、このデータベースについての知識がゼロでしたので、まずはRDBMSからNewSQLまでの初心者向けの知識を簡単にまとめてみました。データベースに関わっている人からすれば当たり前の内容です RDBMS RDBMS(リレーショナルデータベース管理システム)は、下記のMySQLなどに代表されるRDB管理のための専用ソフトウェアです。RDBは、データを「行」と「列」からなる２次元の表（テーブル）形式で表し、複数の表と表の間でデータ同士を関連付け（リレーションシップ）を行うことができます。 MySQL PostgreSQL MariaDB Oracle Databasr SQL Server DB2 また、汎用的かつ高機能なSQLと呼ばれる言語が使用でき、ACIDなトランザクションが行えることが特徴です。ACIDとは、次の４つ
今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...
長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、本質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散
最近話題の「カラム型データベース」とはどんな仕組みのデータベースか？
トランザクション処理を重視する一般的なデータベースは、1行ごとにデータを扱う。カラム型データベースはそれとは異なり、列方向にまとめでデータを扱うことで集計作業などを得意とし、データウェアハウス用途などに用いられている。 「カラム型」あるいは「カラムストア型」「列指向型」などと呼ばれるデータベースの話題が目立つようになってきました。 例えばSAPのHANA、IBMが買収したNetezza、ヒューレット・パッカードが買収したVertica、オラクルのExadata、それにNoSQLの代表的なデータベースCassandraなどがカラム型データベースの機能を備えています。また、マイクロソフトの次期SQL Serverにもカラム型データベース機能が統合されると伝えられています。 とはいえカラム型データベースは最近登場した技術ではなく、Sybase IQでは10年以上前から採用されていた仕組みでした。
シャーディングされたシステムをAuroraに集約してリソースの消費を削減 | Amazon Web Services
Amazon Web Services ブログ シャーディングされたシステムをAuroraに集約してリソースの消費を削減 リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。 難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Planet MySQL :: Planet MySQL - Archives - The CAP theorem and MySQL Cluster
Aerospike Real-time Data Platform
高速NoSQLデータベースと超高速SSDの融合 | db tech showcase
ソフトウェアエンジニアに知ってほしいAerospike
