Showing entries 61 to 70 of 283
« 10 Newer Entries | 10 Older Entries »
Displaying posts with tag: mongodb (reset)
MongoDB with Percona TokuMXse – experimental build RC5 is available!

While our engineering team is working on finalizing the TokuMXse storage engine, I want to provide an experimental build that you can try and test MongoDB 3.0 with our storage engine.

It is available here
percona.com/downloads/TESTING/Percona-TokuMXse-rc5/percona-tokumxse-3.0.3pre-rc5.tar.gz

To start MongoDB with TokuMXse storage engine use:

mongod --storageEngine=tokuft

I am looking for your feedback!

The post MongoDB with Percona TokuMXse – experimental build RC5 is available! appeared first on MySQL Performance Blog.

MongoDB’s flexible schema: How to fix write amplification

Being schemaless is one of the key features of MongoDB. On the bright side this allows developers to easily modify the schema of their collections without waiting for the database to be ready to accept a new schema. However schemaless is not free and one of the drawbacks is write amplification. Let’s focus on that topic.

Write amplification?

The link between schema and write amplification is not obvious at first sight. So let’s first look at a table in the relational world:

mysql> SELECT * FROM user LIMIT 2;
+----+-------+------------+-----------+-----------+----------------------------------+---------+-----------------------------------+------------+------------+
| id | login | first_name | last_name | city      | country                          | zipcode | address                           | password   | birth_year | …
[Read more]
Percona Acquires Tokutek : My Thoughts #3 : Fractal Tree Indexes

Last week I wrote up my thoughts about the Percona acquisition of Tokutek from the perspective of TokuDB and TokuMX[se]. In this third blog of the trilogy I'll cover the acquisition and the future of the Fractal Tree Index. The Fractal Tree Index is the foundational technology upon which all Tokutek products are built.



 So what is a Fractal Tree Index? To quote the Wikipedia page:
"a Fractal Tree index is a tree data structure that keeps data sorted and allows searches and …

[Read more]
LinkBenchX: benchmark based on arrival request rate

An idea for a benchmark based on the “arrival request” rate that I wrote about in a post headlined “Introducing new type of benchmark” back in 2012 was implemented in Sysbench. However, Sysbench provides only a simple workload, so to be able to compare InnoDB with TokuDB, and later MongoDB with Percona TokuMX, I wanted to use more complicated scenarios. (Both TokuDB and TokuMX are part of Percona’s product line, in the case you missed Tokutek now part of the Percona family.)

Thanks to Facebook – they provide LinkBench, a benchmark that emulates the social graph …

[Read more]
Percona Acquires Tokutek : My Thoughts #2 : TokuMX and TokuMXse

A few days ago I wrote up my thoughts about the Percona acquisition of Tokutek with respect to TokuDB. In this blog I'm going to do the same for TokuMX and TokuMXse. And in a few days I'll wrap up this trilogy by sharing my thoughts about Fractal Tree Indexes.

Again, when I'm writing up something that I was very involved with in the past I think it's important to disclose that I worked at Tokutek for 3.5 years (08/2011 - 01/2015) as VP/Engineering and I do not have any equity in Tokutek or Percona.

Since much of the MySQL crowd might be hearing about Tokutek's "other products" for the first time I'll provide a little history of both of the products before I dive in deeper.

TokuMX is a fork of MongoDB …

[Read more]
Comparing LevelDB and RocksDB, take 2

I previously explained problems to avoid when comparing RocksDB and LevelDB. I am back with more details and results because someone is wrong on the Internet. The purpose for the test was to determine whether we created any regressions after reading a comparison published by someone else where RocksDB had some problems. Note that the LevelDB and RocksDB projects have different goals. I expect RocksDB to be faster, but that comes at a cost in code and configuration complexity. I am also reluctant to compare different projects in public. The good news is that I didn't find any performance regression in RocksDB, it is faster as expected but the overhead from performance monitoring needs to be reduced.

I made a few changes to LevelDB before running tests. My changes …

[Read more]
Much ado about nothing

Kyle does amazing work with Jepsen and I am happy that he devotes some of his skill and time into making MongoDB better. This week a new problem was reported as stale reads despite the use of the majority write concern. Let me compress the bug report and blog post for you, but first this isn't a code bug this is expected behavior for async replication.

  1. MongoDB implements asynchronous master-slave replication
  2. Commits can be visible to others on the master before oplog entries are sent to the slave

The problem occurs when transaction 1 commits a change on the master, transaction 2 views that change on the master, the master disappears and a slave is promoted to be the new master where the oplog entries from transaction 1 …

[Read more]
Why Percona Acquired Tokutek: by Peter Zaitsev

It is my pleasure to announce that Percona has acquired Tokutek and will take over development and support for TokuDB® and TokuMX™ as well as the revolutionary Fractal Tree® indexing technology that enables those products to deliver improved performance, reliability and compression for modern Big Data applications.

At Percona we have been working with the Tokutek team since 2009, helping to improve performance and scalability. The TokuDB storage engine has been available for Percona Server for about a year, so joining forces is quite a natural step for us.

Fractal Tree indexing technology—developed by years of data science research at MIT, Stony Brook University and Rutgers University—is the new generation data structure which, for many workloads, leapfrogs traditional B-tree technology which was invented in 1972 (over 40 years ago!).  It is also often …

[Read more]
How to win at IO-bound benchmarks

I spend time evaluating database performance on IO-bound workloads and have learned a few things that can help you to get much better results on benchmarks than will occur in production. But this is really about benchmarketing.

The tips are:

  • Load the database in key order to avoid a fragmented B-Tree index or a randomized LSM tree. If there is a secondary index then create it after the load to avoid fragmentation there. This makes the database smaller and can make searches faster.
  • Only use 10% of the storage device. This reduces the average seek latency for disks. This also reduces the overhead from flash GC because there is less live data to copy out during erase block cleaning. This also makes it less likely that erase block cleaning will be needed during the test. Erase-block cleaning can also be avoided by …
[Read more]
How to Purchase [Benchmarking] Hardware on a Budget

One of my goals at Acmebenchmarking is make sure I'm running on hardware that is representative of real-world infrastructure, while at the same time doing it as inexpensively as possible.

To date I've been running on two custom built "desktops" (for lack of a better term). Both have an Intel Core i7 4790K processor (quad core plus hyperthreading, 4Ghz), 32GB RAM (dual channel), and a quality SSD. They are named acmebench01 and acmebench02.

Alas, it is time to expand. MUST...PURCHASE...MORE...HARDWARE!

In order to maintain the inexpensive theme I tend to buy used hardware, my goal on this purchase was to achieve many more cores and greater memory bandwidth than my existing machines can provide. Keep in mind that used hardware is great for benchmarking (and likely development and QA environments) but you might want to avoid it for production. For years now I've been purchasing used hardware …

[Read more]
Showing entries 61 to 70 of 283
« 10 Newer Entries | 10 Older Entries »