パリから戻ってきました。DotScale 2015は非常に興味深いカンファレンスでした。出発前はunstableブランチでSentinelに取り組んでいて、主な作業はコネクション共有に関するものでした。簡単に言えば、少数のSentinelで多数のマスターを監視できるようにスケールさせる機能です。出発前から、そして戻ってきた今も、Redis 3.2の基盤となる一連の機能を「確保」することに努めてきました。今後数週間はこれらの機能の開発に集中する予定なので、できるだけ早くこのリストを皆さんと共有する価値があると思いました。

GeoハッシュAPI: この取り組みは、もともとRedisのフォークであったArdbに端を発し（https://github.com/yinqiwen/ardb）、その後Matt Stancliff氏によってRedisへ移植される形で抽出・改善されました（https://matt.sh/redis-geo）。オープンソースって素晴らしいと思いませんか？ 現在のコードはソート済みセットの実装の一部を重複しているため、リファクタリングが必要です。APIについてもいくつか変更する可能性は否定できませんが、現時点では未定です。修正すべき点があれば修正します。ただ重要なのは、これは素晴らしい機能だということです。Matt氏がもうRedisにコントリビュートしていない今、この成果を失ってしまう大きなリスクがあるため、Redis 3.2の最初のタスクとしてリファクタリング、レビュー、そしてマージに取り組むつもりです。RedisのAPIにとって非常にエキサイティングな追加になると考えています。

Bloom filter: 3.2ではBloom filterを導入します。HyperLogLogのようにString型の機能として実装するかどうかはまだ未定ですが、おそらく新しい専用の型として実装することになるでしょう。自明でないセマンティクスを新しい型として提供する方が容易だと考えているからです。Bloom filterについては多くの設計アイデアがありますが、APIから精度と容量のトレードオフを制御できるようにしたいとほぼ確信しています。おそらくビット数やハッシュ関数の数を指定するような低レベルな方法ではなく、より高レベルな方法で実現したいと考えています。このAPIでもう一つ実現したいのは、Bloom filterが自動的に自身をクリーンアップする機能（複数のローテーションするフィルターを使うといった方法）です。利用可能な文献をすべて読み、何をすべきか決めるつもりですが、この機能は3.2で必ず提供します。

メモリ関連のPR: Redisのメモリ使用量を改善する、RedisLabsからの2つの重要なPRがあります。どちらもマージする予定です。

メモリ introspectionコマンド: LATENCYコマンドのメモリ使用量版のような、メモリに関する情報を提供するコマンドです。どこでメモリが消費されているか、単に過去のピーク時のメモリ使用量のせいでRSSが高いだけなのか、クライアント出力バッファが使用しているメモリ量についてのヒント、必要に応じてメモリを節約するためにハッシュテーブルをリサイズする機能などを提供します。

Redis ClusterのマルチDCサポート: おそらくClusterのスレーブに対する「static」オプションという形になるでしょう。マスター障害時に昇格に参加しないようにするものです。これにより、CLUSTER FAILOVER TAKEOVERを使って、少数派パーティション内のすべてのスレーブを昇格させることが可能になります。

新しいList型の操作: LMERGEのようなO(1)のリスト操作や、通常はNが非常に小さい状態で使われるためほとんどの場合O(1)操作となるO(N)操作、例えばN個の要素をあるリストから別のリストへ移動させる操作などを追加します。

AOFの安全性に関する機能: https://github.com/antirez/redis/pull/2574

AOFのリライト時にオプションでRDBプリアンブルを使用できるようにし、AOFの書き換えと起動時の内容の再読み込みを高速化します。

SPOPのCOUNTオプション（すでに実装済みで、3.2がこれを含む最初の安定版となります）

Redis Clusterのredis-trib rebalanceコマンド。ノード間でより均一なメモリ使用量になるように、キーを自動的に再ハッシュします。

もともと3.2向けに計画されていたいくつかの機能は、安全だったため3.0に前倒しで導入されました。最近の例では、NXやXXといったオプションをサポートしたZADDがあります。一般的に、既存の型に関するいくつかのコマンドがさらにRedis 3.2に追加される可能性もあります。基本的にこのバージョンは、しばらくRedisの運用面に重点を置いてきたこともあり、API面でもっと充実させてほしいと考えていた人々を満足させるために設計されたものです。

ETAについてですが、作業は月曜日に開始し、最初のRCが公開される9月末までに完了することを願っています。RCになってからのRCから安定版への移行期間は決まっておらず、重大なバグの報告状況次第です。数週間にわたって深刻な問題が報告されなければ、安定版へ移行します。

上記で挙げた個々の項目については、GeoハッシュのことやBloom filterの最終的な実装とAPIの説明など、今後のブログ投稿で詳しくお伝えします。

それまでは、Redis 3.0をお楽しみください！