Author - Zardosht.Kasheff

Explaining Ark Part 4: Fixing Majority Write Concern

This is the fourth post in a series of posts that explains Ark, a consensus algorithm we’ve developed for TokuMX and MongoDB to fix known issues in elections and failover. The tech report we released describes the algorithm in full detail. These posts are a layman’s explanation. This post assumes the reader is familiar […]

Read more

Explaining Ark Part 3: Why Data May Be Lost on a Failover

This is the third post in a series of posts that explains Ark, a consensus algorithm we’ve developed for TokuMX and MongoDB to fix known issues in elections and failover. The tech report we released last week describes the algorithm in full detail. These posts are a layman’s explanation.
In the first post, I discussed […]

Read more

Explaining Ark Part 2: How Elections and Failover Currently Work

This is the second post in a series of posts that explains Ark, a consensus algorithm we’ve developed for TokuMX and MongoDB to fix known issues in elections and failover. The tech report we released last week describes the algorithm in full detail. These posts are a layman’s explanation.
In the first post, I described […]

Read more

Explaining Ark Part 1: The Basics

Last week, we introduced Ark, a consensus algorithm similar to Raft and Paxos we’ve developed for TokuMX and MongoDB. The purpose of Ark is to fix known issues in elections and failover. While the tech report detailing Ark explains everything formally, over the next few blog posts, I will go over Ark in layman’s […]

Read more

Introducing Ark: A Consensus Algorithm For TokuMX and MongoDB

Most of the time, our blog posts explain what’s great about the MongoDB improvements we’ve already shipped in TokuMX. Sometimes, though, it’s fun to talk about what’s coming soon, especially when user feedback would really help get the feature right. In my next series of blog posts, I get to geek out and talk […]

Read more

Why a Partitioned Collection Cannot Be Sharded

In TokuMX 1.5, we introduced partitioned collections for non-sharded clusters. That is, one can have a partitioned collection in a replica set, but one cannot shard a partitioned collection. In this post, I explain why.
As I mentioned here, partitioned collections are useful for time-series data where we would like to keep a rolling period […]

Read more

Use TokuMX Partitioned Collections in Place of TTL Indexes

Take the following scenario. You have a time-series data application for which you would like to store a rolling period of data. For example, you may want to maintain the last six months of traffic logs for a website, in order to analyze activity of different periods of time. Or, you have an application […]

Read more

Best Practices for Partitioned Collections and Tables in TokuDB and TokuMX

In my last post, I gave a technical explanation of the performance characteristics of partitioned collections in TokuMX 1.5 (which is right around the corner) and partitioned tables in relational databases. Given those performance characteristics, in this post, I will present some best practices when using this feature in TokuMX or TokuDB. Note that […]

Read more

Understanding the Performance Characteristics of Partitioned Collections

In TokuMX 1.5 that is right around the corner, the big feature will be partitioned collections. This feature is similar to partitioned tables in Oracle, MySQL, SQL Server, and Postgres. A question many have is “why should I use partitioned tables?” In short, it’s complicated. The answer depends on your workload, your schema, and […]

Read more

Why TokuMX Changed MongoDB’s Oplog Format for Operations

Over several posts, I’ve explained the differences between TokuMX replication and MongoDB replication, and why they are completely incompatible. In this (belated) post, I explain one last difference: the oplog format for operations. Specifically, TokuMX and MongoDB log updates and deletes differently.
Suppose we have a collection foo, with the following element:

Shell

rs0:PRIMARY> db.foo.find()
{ “_id” : […]

Read more