This a guest post by Anshu Prateek, Tech Lead, DevOps at Aerospike and Rajkumar Iyer, Member of the Technical Staff at Aerospike. In our first post we busted the myth that cloud != high performance and outlined the steps to 1 Million TPS (100% reads in RAM) on 1 Amazon EC2 instance for just $1.68/hr. In this post we evaluate the performance of 4 Amazon instances when running a 4 node Aerospike clu
Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi
A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak By Sergey Bushik, senior R&D engineer at Altoros Systems Inc., special to Network World October 22, 2012 04:26 PM ET "The more alternatives, the more difficult the choice." -- Abbe' D'Allanival In 2010, when the world became enchanted by the capabilities of cloud systems and new databases designed to serve them, a
CassandraのLeveled Compactionについて調べる
Cassandra 1.0でLeveled Compaction Strategy (LCS)がサポートされたが、DataStaxのドキュメントを読んでも今一つ動作が理解できない。 http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra 他にあまりドキュメントも整備されていないので、LCSの元になったGoogle LevelDBのほうを調べてみた。 http://leveldb.googlecode.com/svn/trunk/doc/impl.html 以下おおざっぱな翻訳 Files The implementation of leveldb is similar in spirit to the representation of a single Bigtable tablet (section
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
Cassandraのスループットの変化を調べた結果を図2に示した。Cassandraのノード（サーバー）数が2、4、6台のそれぞれにおいて、実行する検証用アプリケーションのスレッド数を徐々に増やした。各スレッドで、書き込み、または読み出しを繰り返し実行し、スレッド数を増やしていくことで、Cassandraの負荷を高めていった。 Cassandraに対する負荷を高めていくと、スループットは曲線を描いて向上していくことが分かった。負荷の増加に対して、十分に性能が向上しなくなったポイントを探し、2、4、6ノードの場合を比較した。検証用の機器は、プリファードインフラストラクチャーから貸与を受けた まず分かったのは、アクセス負荷を高めたとき、Cassandraのスループットは曲線を描いて、向上していくことだ。RDBなど多くのデータベースは負荷を高めていくと、スループットはほぼリニアに伸び、あるしきい
As we've worked towards 1.0 over the past year, Cassandra's performance has improved spectacularly. Compared to the current release this time in 2010, we've increased our write performance a respectable 40%. But the real area we wanted to focus on improving was read performance, which we succeeded in increasing a phenomenal 400%! Reads There are actually two different execution paths for reads in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
