rocksdb-native 0.0.0 → 0.0.1

package/vendor/rocksdb/USERS.md

@@ -1,165 +0,0 @@
-This document lists users of RocksDB and their use cases. If you are using RocksDB, please open a pull request and add yourself to the list.
-
-## Facebook
-At Facebook, we use RocksDB as storage engines in multiple data management services and a backend for many different stateful services, including:
-
-1. MyRocks -- https://github.com/MySQLOnRocksDB/mysql-5.6
-2. MongoRocks -- https://github.com/mongodb-partners/mongo-rocks
-3. ZippyDB --  Facebook's distributed key-value store with Paxos-style replication, built on top of RocksDB.[1] https://www.youtube.com/watch?v=DfiN7pG0D0khtt
-4. Laser -- Laser is a high query throughput, low (millisecond) latency, key-value storage service built on top of RocksDB.[1]
-4. Dragon -- a distributed graph query engine. https://code.facebook.com/posts/1737605303120405/dragon-a-distributed-graph-query-engine/
-5. Stylus -- a low-level stream processing framework writtenin C++.[1]
-6. LogDevice -- a distributed data store for logs [2]
-
-[1] https://research.facebook.com/publications/realtime-data-processing-at-facebook/
-
-[2] https://code.facebook.com/posts/357056558062811/logdevice-a-distributed-data-store-for-logs/
-
-## Bilibili
-[Bilibili](bilibili.com) [uses](https://www.alluxio.io/blog/when-ai-meets-alluxio-at-bilibili-building-an-efficient-ai-platform-for-data-preprocessing-and-model-training/) Alluxio to speed up its ML training workloads, and Alluxio uses RocksDB to store its filesystem metadata, so Bilibili uses RocksDB.
-
-Bilibili's [real-time platform](https://www.alibabacloud.com/blog/architecture-and-practices-of-bilibilis-real-time-platform_596676) uses Flink, and uses RocksDB as Flink's state store.
-
-## TikTok
-TikTok, or its parent company ByteDance, uses RocksDB as the storage engine for some storage systems, such as its distributed graph database [ByteGraph](https://vldb.org/pvldb/vol15/p3306-li.pdf). 
-
-Also, TikTok uses [Alluxio](alluxio.io) to [speed up Presto queries](https://www.alluxio.io/resources/videos/improving-presto-performance-with-alluxio-at-tiktok/), and Alluxio stores the files' metadata in RocksDB.
-
-## FoundationDB
-[FoundationDB](https://www.foundationdb.org/) [uses](https://github.com/apple/foundationdb/blob/377f1f692da6ab2fe5bdac57035651db3e5fb66d/fdbserver/KeyValueStoreRocksDB.actor.cpp) RocksDB to implement a [key-value store interface](https://github.com/apple/foundationdb/blob/377f1f692da6ab2fe5bdac57035651db3e5fb66d/fdbserver/KeyValueStoreRocksDB.actor.cpp#L1127) in its server backend.
-
-## Apple
-Apple [uses](https://opensource.apple.com/projects/foundationdb/) FoundationDB, so it also uses RocksDB.
-
-## Snowflake
-Snowflake [uses](https://www.snowflake.com/blog/how-foundationdb-powers-snowflake-metadata-forward/) FoundationDB, so it also uses RocksDB.
-
-## Microsoft
-The Bing search engine from Microsoft uses RocksDB as the storage engine for its web data platform: https://blogs.bing.com/Engineering-Blog/october-2021/RocksDB-in-Microsoft-Bing
-
-## LinkedIn
-Two different use cases at Linkedin are using RocksDB as a storage engine:
-
-1. LinkedIn's follow feed for storing user's activities. Check out the blog post: https://engineering.linkedin.com/blog/2016/03/followfeed--linkedin-s-feed-made-faster-and-smarter
-2. Apache Samza, open source framework for stream processing
-
-Learn more about those use cases in a Tech Talk by Ankit Gupta and Naveen Somasundaram: http://www.youtube.com/watch?v=plqVp_OnSzg
-
-## Yahoo
-Yahoo is using RocksDB as a storage engine for their biggest distributed data store Sherpa. Learn more about it here: http://yahooeng.tumblr.com/post/120730204806/sherpa-scales-new-heights
-
-## Tencent
-[PaxosStore](https://github.com/Tencent/paxosstore) is a distributed database supporting WeChat. It uses RocksDB as its storage engine.
-
-## Baidu
-[Apache Doris](http://doris.apache.org/master/en/) is a MPP analytical database engine released by Baidu. It [uses RocksDB](http://doris.apache.org/master/en/administrator-guide/operation/tablet-meta-tool.html) to manage its tablet's metadata.
-
-## CockroachDB
-CockroachDB is an open-source geo-replicated transactional database. They are using RocksDB as their storage engine. Check out their github: https://github.com/cockroachdb/cockroach
-
-## DNANexus
-DNANexus is using RocksDB to speed up processing of genomics data.
-You can learn more from this great blog post by Mike Lin: http://devblog.dnanexus.com/faster-bam-sorting-with-samtools-and-rocksdb/
-
-## Iron.io
-Iron.io is using RocksDB as a storage engine for their distributed queueing system.
-Learn more from Tech Talk by Reed Allman: http://www.youtube.com/watch?v=HTjt6oj-RL4
-
-## Tango Me
-Tango is using RocksDB as a graph storage to store all users' connection data and other social activity data.
-
-## Turn
-Turn is using RocksDB as a storage layer for their key/value store, serving at peak 2.4MM QPS out of different datacenters.
-Check out our RocksDB Protobuf merge operator at: https://github.com/vladb38/rocksdb_protobuf
-
-## Santander UK/Cloudera Profession Services
-Check out their blog post: http://blog.cloudera.com/blog/2015/08/inside-santanders-near-real-time-data-ingest-architecture/
-
-## Airbnb
-Airbnb is using RocksDB as a storage engine for their personalized search service. You can learn more about it here: https://www.youtube.com/watch?v=ASQ6XMtogMs
-
-## Alluxio
-[Alluxio](https://www.alluxio.io) uses RocksDB to serve and scale file system metadata to beyond 1 Billion files. The detailed design and implementation is described in this engineering blog:
-https://www.alluxio.io/blog/scalable-metadata-service-in-alluxio-storing-billions-of-files/
-
-## Pinterest
-Pinterest's Object Retrieval System uses RocksDB for storage: https://www.youtube.com/watch?v=MtFEVEs_2Vo
-
-## Smyte
-[Smyte](https://www.smyte.com/) uses RocksDB as the storage layer for their core key-value storage, high-performance counters and time-windowed HyperLogLog services.
-
-## Rakuten Marketing
-[Rakuten Marketing](https://marketing.rakuten.com/) uses RocksDB as the disk cache layer for the real-time bidding service in their Performance DSP.
-
-## VWO, Wingify
-[VWO's](https://vwo.com/) Smart Code checker and URL helper uses RocksDB to store all the URLs where VWO's Smart Code is installed.
-
-## quasardb
-[quasardb](https://www.quasardb.net) is a high-performance, distributed, transactional key-value database that integrates well with in-memory analytics engines such as Apache Spark.
-quasardb uses a heavily tuned RocksDB as its persistence layer.
-
-## Netflix
-[Netflix](http://techblog.netflix.com/2016/05/application-data-caching-using-ssds.html) Netflix uses RocksDB on AWS EC2 instances with local SSD drives to cache application data.
-
-## TiKV
-[TiKV](https://github.com/pingcap/tikv) is a GEO-replicated, high-performance, distributed, transactional key-value database. TiKV is powered by Rust and Raft. TiKV uses RocksDB as its persistence layer.
-
-## TiDB
-[TiDB](https://github.com/pingcap/tidb) uses the TiKV distributed key-value database, so it uses RocksDB.
-
-## PingCAP
-[PingCAP](https://www.pingcap.com/) is the company behind TiDB, its cloud database service uses RocksDB.
-
-## Apache Spark
-[Spark Structured Streaming](https://docs.databricks.com/structured-streaming/rocksdb-state-store.html) uses RocksDB as the local state store.
-
-## Databricks
-[Databricks](https://www.databricks.com/) [replaces AWS RDS with TiDB](https://www.pingcap.com/case-study/how-databricks-tackles-the-scalability-limit-with-a-mysql-alternative/) for scalability, so it uses RocksDB.
-
-## Apache Flink
-[Apache Flink](https://flink.apache.org/news/2016/03/08/release-1.0.0.html) uses RocksDB to store state locally on a machine.
-
-## Dgraph
-[Dgraph](https://github.com/dgraph-io/dgraph) is an open-source, scalable, distributed, low latency, high throughput Graph database .They use RocksDB to store state locally on a machine.
-
-## Uber
-[Uber](http://eng.uber.com/cherami/) uses RocksDB as a durable and scalable task queue.
-
-## 360 Pika
-[360](http://www.360.cn/) [Pika](https://github.com/Qihoo360/pika) is a nosql compatible with redis. With the huge amount of data stored, redis may suffer for a capacity bottleneck, and pika was born for solving it. It has widely been used in many companies.
-
-## LzLabs
-LzLabs is using RocksDB as a storage engine in their multi-database distributed framework to store application configuration and user data.
-
-## ProfaneDB
-[ProfaneDB](https://profanedb.gitlab.io/) is a database for Protocol Buffers, and uses RocksDB for storage. It is accessible via gRPC, and the schema is defined using directly `.proto` files.
-
-## IOTA Foundation
- [IOTA Foundation](https://www.iota.org/) is using RocksDB in the [IOTA Reference Implementation (IRI)](https://github.com/iotaledger/iri) to store the local state of the Tangle. The Tangle is the first open-source distributed ledger powering the future of the Internet of Things.
-
-## Avrio Project
- [Avrio Project](http://avrio-project.github.io/avrio.network/) is using RocksDB in [Avrio ](https://github.com/avrio-project/avrio) to store blocks, account balances and data and other blockchain-releated data. Avrio is a multiblockchain decentralized cryptocurrency empowering monetary transactions.
-
-## Crux
-[Crux](https://github.com/juxt/crux) is a document database that uses RocksDB for local [EAV](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model) index storage to enable point-in-time bitemporal Datalog queries. The "unbundled" architecture uses Kafka to provide horizontal scalability.
-
-## Nebula Graph
-[Nebula Graph](https://github.com/vesoft-inc/nebula) is a distributed, scalable, lightning-fast, open source graph database capable of hosting super large scale graphs with dozens of billions of vertices (nodes) and trillions of edges, with milliseconds of latency.
-
-## YugabyteDB
-[YugabyteDB](https://www.yugabyte.com/) is an open source, high performance, distributed SQL database that uses RocksDB as its storage layer. For more information, please see https://github.com/yugabyte/yugabyte-db/.
-
-## ArangoDB
-[ArangoDB](https://www.arangodb.com/) is a native multi-model database with flexible data models for documents, graphs, and key-values, for building high performance applications using a convenient SQL-like query language or JavaScript extensions. It uses RocksDB as its storage engine.
-
-## Milvus
-[Milvus](https://milvus.io/) is an open source vector database for unstructured data. It uses RocksDB not only as one of the supported kv storage engines, but also as a message queue.
-
-## Kafka
-[Kafka](https://kafka.apache.org/) is an open-source distributed event streaming platform, it uses RocksDB to store state in Kafka Streams: https://www.confluent.io/blog/how-to-tune-rocksdb-kafka-streams-state-stores-performance/.
-
-## Solana Labs
-[Solana](https://github.com/solana-labs/solana) is a fast, secure, scalable, and decentralized blockchain.  It uses RocksDB as the underlying storage for its ledger store.
-
-## Others
-More databases using RocksDB can be found at [dbdb.io](https://dbdb.io/browse?embeds=rocksdb).

package/vendor/rocksdb/Vagrantfile

@@ -1,39 +0,0 @@
-# Vagrant file
-Vagrant.configure("2") do |config|
-
-  config.vm.provider "virtualbox" do |v|
-    v.memory = 4096
-    v.cpus = 2
-  end
-
-  config.vm.define "ubuntu14" do |box|
-    box.vm.box = "ubuntu/trusty64"
-  end
-
-  config.vm.define "centos65" do |box|
-    box.vm.box = "chef/centos-6.5"
-  end
-
-  config.vm.define "centos7" do |box|
-    box.vm.box = "centos/7"
-    box.vm.provision "shell", path: "build_tools/setup_centos7.sh"
-  end
-
-  config.vm.define "FreeBSD10" do |box|
-    box.vm.guest = :freebsd
-    box.vm.box = "robin/freebsd-10"
-    # FreeBSD does not support 'mount_virtualbox_shared_folder', use NFS
-    box.vm.synced_folder ".", "/vagrant", :nfs => true, id: "vagrant-root"
-    box.vm.network "private_network", ip: "10.0.1.10"
-
-    # build everything after creating VM, skip using --no-provision
-    box.vm.provision "shell", inline: <<-SCRIPT
-      pkg install -y gmake clang35
-      export CXX=/usr/local/bin/clang++35
-      cd /vagrant
-      gmake clean
-      gmake all OPT=-g
-    SCRIPT
-  end
-
-end

package/vendor/rocksdb/WINDOWS_PORT.md

@@ -1,228 +0,0 @@
-# Microsoft Contribution Notes
-
-## Contributors
-* Alexander Zinoviev https://github.com/zinoale
-* Dmitri Smirnov https://github.com/yuslepukhin
-* Praveen Rao  https://github.com/PraveenSinghRao
-* Sherlock Huang  https://github.com/SherlockNoMad
-
-## Introduction
-RocksDB is a well proven open source key-value persistent store, optimized for fast storage. It provides scalability with number of CPUs and storage IOPS, to support IO-bound, in-memory and write-once workloads, most importantly, to be flexible to allow for innovation.
-
-As Microsoft Bing team we have been continuously pushing hard to improve the scalability, efficiency of platform and eventually benefit Bing end-user satisfaction.  We would like to explore the opportunity to embrace open source, RocksDB here, to use, enhance and customize for our usage, and also contribute back to the RocksDB community. Herein, we are pleased to offer this RocksDB port for Windows platform.
-
-These notes describe some decisions and changes we had to make with regards to porting RocksDB on Windows. We hope this will help both reviewers and users of the Windows port.
-We are open for comments and improvements.
-
-## OS specifics
-All of the porting, testing and benchmarking was done on Windows Server 2012 R2 Datacenter 64-bit but to the best of our knowledge there is not a specific API we used during porting that is unsupported on other Windows OS after Vista.
-
-## Porting goals
-We strive to achieve the following goals:
-* make use of the existing porting interface of RocksDB
-* make minimum [WY2]modifications within platform independent code.
-* make all unit test pass both in debug and release builds. 
-  * Note: latest introduction of SyncPoint seems to disable running db_test in Release.
-* make performance on par with published benchmarks accounting for HW differences
-* we would like to keep the port code inline with the main branch with no forking
-
-## Build system
-We have chosen CMake as a widely accepted build system to build the Windows port. It is very fast and convenient. 
-
-At the same time it generates Visual Studio projects that are both usable from a command line and IDE.
-
-The top-level CMakeLists.txt file contains description of all targets and build rules. It also provides brief instructions on how to build the software for Windows. One more build related file is thirdparty.inc that also resides on the top level. This file must be edited to point to actual third party libraries location.
-We think that it would be beneficial to merge the existing make-based build system and the new cmake-based build system into a single one to use on all platforms.
-
-All building and testing was done for 64-bit. We have not conducted any testing for 32-bit and early reports indicate that it will not run on 32-bit.
-
-## C++ and STL notes
-We had to make some minimum changes within the portable files that either account for OS differences or the shortcomings of C++11 support in the current version of the MS compiler. Most or all of them are expected to be fixed in the upcoming compiler releases.
-
-We plan to use this port for our business purposes here at Bing and this provided business justification for this port. This also means, we do not have at present to choose the compiler version at will.
-
-* Certain headers that are not present and not necessary on Windows were simply `#ifndef OS_WIN` in a few places (`unistd.h`)
-* All posix specific headers were replaced to port/port.h which worked well
-* Replaced `dirent.h` for `port/port_dirent.h` (very few places) with the implementation of the relevant interfaces within `rocksdb::port` namespace
-* Replaced `sys/time.h` to `port/sys_time.h` (few places) implemented equivalents within `rocksdb::port`
-* `printf %z` specification is not supported on Windows. To imitate existing standards we came up with a string macro `ROCKSDB_PRIszt` which expands to `zu` on posix systems and to `Iu` on windows.
-* in class member initialization were moved to a __ctors in some cases
-* `constexpr` is not supported. We had to replace `std::numeric_limits<>::max/min()` to its C macros for constants. Sometimes we had to make class members `static const` and place a definition within a .cc file.
-* `constexpr` for functions was replaced to a template specialization (1 place)
-* Union members that have non-trivial constructors were replaced to `char[]` in one place along with bug fixes (spatial experimental feature)
-* Zero-sized arrays are deemed a non-standard extension which we converted to 1 size array and that should work well for the purposes of these classes.
-* `std::chrono` lacks nanoseconds support (fixed in the upcoming release of the STL) and we had to use `QueryPerfCounter()` within env_win.cc
-* Function local statics initialization is still not safe. Used `std::once` to mitigate within WinEnv.
-
-## Windows Environments notes
-We endeavored to make it functionally on par with posix_env. This means we replicated the functionality of the thread pool and other things as precise as possible, including:
-* Replicate posix logic using std:thread primitives.
-* Implement all posix_env disk access functionality.
-* Set `use_os_buffer=false` to disable OS disk buffering for WinWritableFile and WinRandomAccessFile.
-* Replace `pread/pwrite` with `WriteFile/ReadFile` with `OVERLAPPED` structure.
-* Use `SetFileInformationByHandle` to compensate absence of `fallocate`.
-
-### In detail
-Even though Windows provides its own efficient thread-pool implementation we chose to replicate posix logic using `std::thread` primitives. This allows anyone to quickly detect any changes within the posix source code and replicate them within windows env. This has proven to work very well. At the same time for anyone who wishes to replace the built-in thread-pool can do so using RocksDB stackable environments.
-
-For disk access we implemented all of the functionality present within the posix_env which includes memory mapped files, random access, rate-limiter support etc.
-The `use_os_buffer` flag on Posix platforms currently denotes disabling read-ahead log via `fadvise` mechanism. Windows does not have `fadvise` system call. What is more, it implements disk cache in a way that differs from Linux greatly. It's not an uncommon practice on Windows to perform un-buffered disk access to gain control of the memory consumption. We think that in our use case this may also be a good configuration option at the expense of disk throughput. To compensate one may increase the configured in-memory cache size instead. Thus we have chosen  `use_os_buffer=false` to disable OS disk buffering for `WinWritableFile` and `WinRandomAccessFile`. The OS imposes restrictions on the alignment of the disk offsets, buffers used and the amount of data that is read/written when accessing files in un-buffered mode. When the option is true, the classes behave in a standard way. This allows to perform writes and reads in cases when un-buffered access does not make sense such as WAL and MANIFEST.
-
-We have replaced `pread/pwrite` with `WriteFile/ReadFile` with `OVERLAPPED` structure so we can atomically seek to the position of the disk operation but still perform the operation synchronously. Thus we able to emulate that functionality of `pread/pwrite` reasonably well. The only difference is that the file pointer is not returned to its original position but that hardly matters given the random nature of access.
-
-We used `SetFileInformationByHandle` both to truncate files after writing a full final page to disk and to pre-allocate disk space for faster I/O thus compensating for the absence of `fallocate` although some differences remain. For example, the pre-allocated space is not filled with zeros like on Linux, however, on a positive note, the end of file position is also not modified after pre-allocation.
-
-RocksDB renames, copies and deletes files at will even though they may be opened with another handle at the same time. We had to relax and allow nearly all the concurrent access permissions possible.
-
-## Thread-Local Storage
-Thread-Local storage plays a significant role for RocksDB performance. Rather than creating a separate implementation we chose to create inline wrappers that forward `pthread_specific` calls to Windows `Tls` interfaces within `rocksdb::port` namespace. This leaves the existing meat of the logic in tact and unchanged and just as maintainable.
-
-To mitigate the lack of thread local storage cleanup on thread-exit we added a limited amount of windows specific code within the same thread_local.cc file that injects a cleanup callback into a `"__tls"` structure within `".CRT$XLB"` data segment. This approach guarantees that the callback is invoked regardless of whether RocksDB used within an executable, standalone DLL or within another DLL.
-
-## Jemalloc usage
-
-When RocksDB is used with Jemalloc the latter needs to be initialized before any of the C++ globals or statics. To accomplish that we injected an initialization routine into `".CRT$XCT"` that is automatically invoked by the runtime before initializing static objects. je-uninit is queued to `atexit()`. 
-
-The jemalloc redirecting `new/delete` global operators are used by the linker providing certain conditions are met. See build section in these notes.
-
-## Stack Trace and Unhandled Exception Handler
-
-We decided not to implement these two features because the hosting program as a rule has these two things in it.
-We experienced no inconveniences debugging issues in the debugger or analyzing process dumps if need be and thus we did not
-see this as a priority.
-
-## Performance results
-### Setup
-All of the benchmarks are run on the same set of machines. Here are the details of the test setup:
-* 2 Intel(R) Xeon(R) E5 2450 0 @ 2.10 GHz (total 16 cores)
-* 2 XK0480GDQPH SSD Device, total 894GB free disk
-* Machine has 128 GB of RAM
-* Operating System: Windows Server 2012 R2 Datacenter
-* 100 Million keys; each key is of size 10 bytes, each value is of size 800 bytes
-* total database size is ~76GB
-* The performance result is based on RocksDB 3.11.
-* The parameters used, unless specified, were exactly the same as published in the GitHub Wiki page. 
-
-### RocksDB on flash storage
-
-#### Test 1. Bulk Load of keys in Random Order
-
-Version 3.11 
-
-* Total Run Time: 17.6 min
-* Fillrandom: 5.480 micros/op 182465 ops/sec;  142.0 MB/s
-* Compact: 486056544.000 micros/op 0 ops/sec
-
-Version 3.10 
-
-* Total Run Time: 16.2 min 
-* Fillrandom: 5.018 micros/op 199269 ops/sec;  155.1 MB/s 
-* Compact: 441313173.000 micros/op 0 ops/sec; 
-
-
-#### Test 2. Bulk Load of keys in Sequential Order
-
-Version 3.11 
-
-* Fillseq: 4.944 micros/op 202k ops/sec;  157.4 MB/s
-
-Version 3.10
-
-* Fillseq: 4.105 micros/op 243.6k ops/sec;  189.6 MB/s 
-
-
-#### Test 3. Random Write
-
-Version 3.11 
-
-* Unbuffered I/O enabled
-* Overwrite: 52.661 micros/op 18.9k ops/sec;   14.8 MB/s
-
-Version 3.10
-
-* Unbuffered I/O enabled 
-* Overwrite: 52.661 micros/op 18.9k ops/sec; 
-
-
-#### Test 4. Random Read
-
-Version 3.11 
-
-* Unbuffered I/O enabled
-* Readrandom: 15.716 micros/op 63.6k ops/sec; 49.5 MB/s 
-
-Version 3.10
-
-* Unbuffered I/O enabled 
-* Readrandom: 15.548 micros/op 64.3k ops/sec; 
-
-
-#### Test 5. Multi-threaded read and single-threaded write
-
-Version 3.11
-
-* Unbuffered I/O enabled
-* Readwhilewriting: 25.128 micros/op 39.7k ops/sec; 
-
-Version 3.10
-
-* Unbuffered I/O enabled 
-* Readwhilewriting: 24.854 micros/op 40.2k ops/sec; 
-
-
-### RocksDB In Memory 
-
-#### Test 1. Point Lookup
-
-Version 3.11
-
-80K writes/sec
-* Write Rate Achieved: 40.5k write/sec;
-* Readwhilewriting: 0.314 micros/op 3187455 ops/sec;  364.8 MB/s (715454999 of 715454999 found)
-
-Version 3.10
-
-* Write Rate Achieved:  50.6k write/sec 
-* Readwhilewriting: 0.316 micros/op 3162028 ops/sec; (719576999 of 719576999 found) 
-
-
-*10K writes/sec*
-
-Version 3.11
-
-* Write Rate Achieved: 5.8k/s write/sec
-* Readwhilewriting: 0.246 micros/op 4062669 ops/sec;  464.9 MB/s (915481999 of 915481999 found)
-
-Version 3.10
-
-* Write Rate Achieved: 5.8k/s write/sec 
-* Readwhilewriting: 0.244 micros/op 4106253 ops/sec; (927986999 of 927986999 found) 
-
-
-#### Test 2. Prefix Range Query
-
-Version 3.11
-
-80K writes/sec
-* Write Rate Achieved:  46.3k/s write/sec
-* Readwhilewriting: 0.362 micros/op 2765052 ops/sec;  316.4 MB/s (611549999 of 611549999 found)
-
-Version 3.10
-
-* Write Rate Achieved: 45.8k/s write/sec 
-* Readwhilewriting: 0.317 micros/op 3154941 ops/sec; (708158999 of 708158999 found) 
-
-Version 3.11
-
-10K writes/sec
-* Write Rate Achieved: 5.78k write/sec
-* Readwhilewriting: 0.269 micros/op 3716692 ops/sec;  425.3 MB/s (837401999 of 837401999 found)
-
-Version 3.10
-
-* Write Rate Achieved: 5.7k write/sec 
-* Readwhilewriting: 0.261 micros/op 3830152 ops/sec; (863482999 of 863482999 found) 
-
-
-We think that there is still big room to improve the performance, which will be an ongoing effort for us.
-