ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

IO: All content tagged as IO in NoSQL databases and polyglot persistence

SSD vs Spinning Disk Benchmark With Bonnie

Tim Bray published the results of running Bonnie, a filesystem benchmark, against an SSD and a spinning disk both mounted on a MacBook Pro:

SSD vs Spinning Disk Benchmark

Now keep in mind that this is not a benchmark for raw speed, but rather a comparison of the file system and bus and disk access.

Original title and link: SSD vs Spinning Disk Benchmark With Bonnie (NoSQL database©myNoSQL)

via: http://www.tbray.org/ongoing/When/201x/2012/06/04/Maxed-Book


Fusion-Io: One Billion IOPS

The Verge reporting from DEMO Enterprise Disruption:

This massive performance boost comes courtesy of a new way of using NAND flash as a non-volatile memory solution, known as Auto Commit Memory. ACM is a software layer which allows developers to send and receive data stored on Fusion-io’s ioDrive cards directly to and from the CPU, rather than relying upon the operating system. Because of this, massive applications and databases can run with much lower latency — crucial for the cloud-based world we’re heading towards.

Original title and link: Fusion-Io: One Billion IOPS (NoSQL database©myNoSQL)

via: http://mobile.theverge.com/2012/1/6/2686627/fusion-io-one-billion-iops


RAID and Acunu Randomised Duplicate Allocation Disk Layout

Acunu guys explain one piece of their distribution of Apache Cassandra:

our product […] uses a layout known as Randomised Duplicate Allocation (RDA).  In the 2-RDA mode, each block of data is duplicated, and the 2 copies allocated at random among the available devices (other schemes can use more than 2 copies, or a variable number of copies depending on the popularity of the data and space constraints).

As opposed to what’s happening in the Hadoop world, Acunu is not just repackaging Cassandra:

The Acunu Core (“Castle”) is at the heart of our distribution for Apache Cassandra. It comprises a rewrite of the Linux storage stack that offloads much of the storage work from Cassandra. […] It includes optimized OS caching and buffering schemes, new storage algorithms with direct access to disks, SSD-aware storage layout algorithms (coming in V2) and an alternative RAID scheme that rebuilds 2TB disks in 30 minutes.

Original title and link: RAID and Acunu Randomised Duplicate Allocation Disk Layout (NoSQL database©myNoSQL)

via: http://www.acunu.com/blogs/dr-andrew-byde/faster-disk-rebuilds/


De-Confusing SSD

Great post by Pythian’s Gwen Shapira explaining different aspects of SSD:

SSD is fast for reads, but not for writes. Its fast for random writes, but not for sequential writes. You shouldn’t use it for redo, except that Oracle do that on their appliances. SSD gets slow over time. SSD has a limited lifespan and is unreliable. Performance depends on exactly which SSD you use. You can have PCI or SATA or even SAN. You can use SSD for flash cache, but only specific versions, maybe. You can have MLC or SLC. It can be enterprise or home grade.

Remember that storing your data shouldn’t be a black-and-white decision on using RAM vs SSD vs spinning disks.

Original title and link: De-Confusing SSD (NoSQL database©myNoSQL)

via: http://www.pythian.com/news/28797/de-confusing-ssd-for-oracle-databases/