最適なサイレント(静音)タクタイルキースイッチとは? – 打鍵感との両立を求めて

最適なサイレント(静音)タクタイルキースイッチとは? – 打鍵感との両立を求めて

最適なサイレント(静音)タクタイルキースイッチとは? – 打鍵感との両立を求めて   オフィスだけでなく、リモートワークのオンラインミーティングで利用するキーボードは、打鍵感だけではなく、静音性も重要なポイントです。最近では、気分転換をかねて出社やコワーキングスペースの利用の機会も増えてきており、静音キーボードの見直しのため、打鍵感の良いタクタイルを中心に、静音スイッチを色々試してみました。 静音キーボードの難しいところは、静音性と打鍵感がトレードオフになるところです。リモートワーク時代に求められるキーボードには、静音性を確保しつつ、打鍵感に疲労感を加えた3軸での最適化が必要となります。 結論としては、許容できる静音性は、時間と場所により異なるため、一択になるまでは絞り込めませんでした。静音性の制約の中で、最適解となる複数の静音キーボードを準備して、使い分けるのが最善となりそうです。 評価基準 – 打鍵感と静音性との両立 自宅では、打鍵感重視でスタンダードな青軸系や、Holy Pandaに代表されるEarly Bump系のタクタイル感の強いスイッチをメインとしています。打鍵感重視だとアーリータクタイル軸、軽快感重視だとクリッキー軸が好みといったところです。 自宅でのメインスイッチを青色の背景として、一覧を以下に示します。いわゆるClackyやThockyに分類されるスイッチ[1][2][3]が好みですが、いずれもオフィスで利用するには静音性に課題があります。 改めて好みのキースイッチを一覧にしてみると、自宅では静音性は気にせずに、押下感のみを重視している事がわかります。自宅で利用しているスイッチを、クリッキーな軽快感と、タクタイル感による打鍵感の両軸で整理してみると、以下の図になります。 元々、職場と自宅共に、USB普及期まではクリッキーなIBM PS/2キーボード、USB普及後はタクタイル強めなHHKB Lite系をメインにしてきたため、リニア軸の底打ち感は苦手です。 HHKB Lite系以降は、リモートワークと重なる原点回帰で、軽い打鍵感と明確な打鍵音のクリッキー軸を主体としていましたが、最近は、Holy Pandaに代表されるEarly Bump系の、タクタイル感の強いスイッチに比重を移しつつあるといった感じでしょうか。 評価対象 – 静音タクタイルキースイッチの選定 静穏化が最優先であれば、構造的にはリニア軸の選択が最適ですが、都度試してみても、相変わらずリニア軸の底打ち感や、押下圧の低いスイッチは苦手感があります。そのため、今回はリニア軸は対象外とし、相反する打鍵感と静穏化を両立を目的に、評判の良さそうな静音系のタクタイルスイッチ[4][5][6][7][8][9][10][11]をメインに試してみました。今回評価した静音スイッチの一覧を以下に示します。 今回は、評価基準で示した青色背景のスイッチを基準として、評価する静音タクタイルスイッチを色々と探してみました。好みとする自宅環境を、如何にオフィスでも再現できるかを目的とした評価となります。 評価結果 – 打鍵感、静音性、疲労感の3軸評価…

Read more

Rustアプリケーションの実装効率と性能評価 – C言語・Go実装との比較

Rustアプリケーションの実装効率と性能評価 – C言語・Go実装との比較

Rustは、安全性と高速性の両立を目的にデザインされた言語[1]であり、近年では業務に採用されるプロフェッショナル言語としての、更なる飛躍が期待されています[3][8]。 ただし、2021年のアンケート結果[3]でも、仕事での利用率は前年の42%から59%に大きく向上している反面、業界での採用実績面の少なさが、Rustの将来性の最大の懸念(38%)に挙げられており、現時点では実績不足な面は否めません。 今回は、Rustの実用性を判断するために、データベース(Redis)とIoT(ECHONET Lite)の2つ分野の同一アプリケーション実装を評価対象とし、Go言語やCなど他プログラミング言語での実装と比較することで、Rust実装の効率と性能評価を試みました。 結論としては、Better Cの観点からはGoがCの後継として最適と考えています。Rustは安全性とスピードを提供しますが、生産性、相互運用性、プログラミングの柔軟性に限界があります。反面、Goは実装の効率性と安定した性能で際立っており、汎用的なアプリケーションに安心して使える選択肢と判断しています。 評価① – Databaseアプリケーション (Redis) 本評価は、データベース分野のRedis[19]仕様を同一アプリケーションとして、C言語、Rust、Goによる実装を評価します。Redisの公式実装[19]はC言語であり、RustおよびGo実装は非公式なサブセット実装になります。 Rust実装はTokio[20]ライブラリの学習用として公開されたmini-redis[21]、Go実装は拙作のRedis互換データベース実装のgo-redis[23]のサンプル実装(go-redis-server)での評価となります。 なお、Redisの公式実装[19]と比較し、mini-redis[21]、go-redis[23]についてはサブセット実装となるためLOC(Lines of code)による実装効率は評価せずできず、性能評価のみとなります。 評価ベンチマーク 評価したベンチマークプログラムは、Redis公式ベンチマークツールである「redis-benchmark」で実施しました。実行するベンチマークはフルセットではなく、SET/GETコマンドのみに限定し、標準の50スレッドにて10,000回毎繰り返した結果を用いています。 基本的なSET/GETコマンドのみに限定されている理由は、mini-redis[21]がSET/GETコマンドなどの最小限のコマンド実装に留まっており、mini-redis[21]でのベンチマークパラメータ[22]を踏襲したためです。なお、mini-redis[21]は評価時の最新版、環境は「Mac mini (2018) + macOS 12.6」での評価となります。 実行性能評価 – C > Go > Rust…

Read more

Redis プロトコル実装調査 – RESPの課題と現状について

Redis プロトコル実装調査 – RESPの課題と現状について

Redisは、インメモリのキーバリューストアとして2009年に登場し、現在でも活発に機能拡張が継続されているプロダクトです。特に、2020年に登場したRedis 6系では、Rediの通信プロトコルであるRESP (REdis Serialization Protocol)[1]がRESP 3[2]として刷新され、大幅な機能拡張が実現されました。 本家のRedis自信も進化を続けていますが、最近ではRedisと互換性のあるRESPプロトコルに対応した大規模なRedis互換プロダクトが相次いで登場しています[4][5]。今回は、Redis互換プロダクトの互換性担保の基本ともなる、RESP (REdis Serialization Protocol)[1]の通信プロトコルを中心に、実装上の利点などや課題を踏まえて解説してみます。 RESP (REdis Serialization Protocol)の概要 RESPは「実装が簡単」「解析が高速」「ヒューマンリーダブル」を設計思想[1]とする通信プロトコル仕様です。通信パケットの起点となる共通ヘッダは、メッセージ種別を示す1バイトのみで、CRLFをメッセージの終端とする、非常に単純な仕様です。 項目 データ型 補足 メッセージ識別子 byte\<1>  ’+’, ‘-‘, ‘:’ など メッセージ部 –  メッセージ種別毎に規定 メッセージ終端 byte\<2> CR…

Read more

Keychron Q1の導入とカスタマイズ

Keychron Q1の導入とカスタマイズ

廃盤になったHHKB Lite2から、Keychron[1]やDrop[2]の65%キーボードに移行できたので、その延長線上でKeychronのQ1を選んでみました。Keychron K2に移行して感じていた課題[1]は、Windows環境ではDrop ALTの導入で解決[2]できたのですが、今回はMac環境の課題を解決するためのQ1の導入です。 Mac環境についてはWindow環境ほどカスタマイズは必要なく、ほぼKeychronK2/K3への移行に満足していました[1]。ただし、Windows環境のDrop ALTでのカスタマイズ[2]により、Fnキーの位置や、Fnキーを併用したWASDによるカーソルキーの配置など、Mac環境との操作性に差異が発生してきました。 K2でも非公式なQMK対応はあるものの[3]、Q1はKeychron公式にQMK/VIA対応した製品です。今回のQ1の導入により、Window環境との差分[2]に加えて、電源(Power)キーがない不便[1]も解消できました。 Q1のカスタマイズ Q1については、現時点では通常版とノブ(Knob)版の2種類販売されており、今回購入した通常版については「キー打鍵時の金属音」や「キーキャップの互換性」が話題となっていました。現在では、Q1のノブ(Knob)版も登場しており、特にキーキャップの互換性は解消されていますが、自分も先人を参考に色々とカスタマイズを試してみました。 金属音対策 購入当初は、打鍵時の金属音は気にならなかったのですが、キーキャップを交換している中で、相性の問題もあるのか、甲高い金属音が鳴るようになりました。そのため、已むを得ず、静穏化のカスタマイズとなりました。 ケースの改善 – Force Break Mod (丸ラベル版) まずは、多くのQ1ユーザーが実践している[3][4][5][6][7][8]、通称、Force Break Modeと呼ばれる打鍵時の金属音の抑制のために、上下の金属ケースの接触面にラベルを貼る手法です。今回は、テープではなく、エーワン(A-one)の丸型9mmのラベルでの代用を試してみました。 実践されているテープの厚みは0.1〜1.6mm程度で、重ねる枚数も人それぞれで異なります[3][4][5][6][7][8]。エーワン(A-one)の丸型ラベル1枚の厚みは0.1mmでしたが、組み立て後にケース上部を叩くと、明らかに1枚より2枚重ねの方が消音効果がありました。Force Break Modの効果は高く、ケース上部を叩いた時の金属音が、自転車で言えばアルミフレームが、カーボンフレームのような音に変わります。そのため、丸型ラベルは2枚重ね(0.2mm)としました。 スタビライザーの改善 – Tape Mod (丸ラベル版) 本来であれば、Force Break…

Read more

Drop ALT (HHKB Lite2の後継探し) – 3ヶ月ほど使ってみて

Drop ALT (HHKB Lite2の後継探し) – 3ヶ月ほど使ってみて

HHKB Lite2は、残念ながら2019年で廃盤となりました。職場と自宅でかれこれ10年以上愛用してきたLite2でしたが、ふと「HHKBに拘る必要はないのかも」と思い始め、移行先のキーボードとして標準的な英語配列のコンパクトキーボード、Drop ALTを試してみました。 HHKB Lite2の廃盤から、いったん通常の英語コンパクトキーボードに移行してみたものの[1]、やはりHHKBに依存していたところも再認識できたので、それを踏まえてのDrop ALTへの移行です。現時点では、Windows/Linux環境での移行の問題点が、ほぼ解消できている状況です。 Drop ALTを選んだ理由 HHKB的な延長だと、DropのHHKBスタイルの「Tokyo60」が順当かもしれませんが、今回もHHKB Lite2からの移行の観点でDrop ALTを選択してみました。Drop ALTを選んだ理由を列記してみます。 カスタマイズ可能 (QMK対応) KeychronのK6(65%)を購入してから気が付いたのですが、チルダ(~)キーが独立でないとWindows環境ではかなり不便です[1]。Drop ALTは、公式にQMK対応でカスタマイスが可能です。また、複数台でのキーボード利用が前提となるために、個人的にはソフトウェアではなくハードウェアでの対応が必須です。 カーソルキーが独立 現行のHHKBに移行できない理由は、カーソルキーの不備があります。また、Drop ALTもKeychron K2/K3と同じく右SHIFTキーは1.75Uでやや特殊なものの、他のキーは標準サイズで、キーキャップの選択幅も広がりそうです。現時点では、Razerのキーキャップを試しています。 フローティングデザイン HHKB Lite2は背面のネジを外すだけで分離でき、キーキャップ部が簡単に丸洗いできます。Drop ALTは、さすがに丸洗は難しいものの、フローティングデザインで、ある程度は掃除はし易そうです。 USBハブ機能 (Type-C) Lite2はUSBハブ機能がありましたが、現行のHHKBではUSBハブ機能が省かれています。Drop ALTには、USBハブ機能があり、2つあるUSB Type-Cのコネクタの空いているコネクタはUSB 2.0のハブとして機能します。…

Read more

Keychron K2/K3 (HHKB Lite2の後継探し) – 3ヶ月ほど使ってみて

Keychron K2/K3 (HHKB Lite2の後継探し) – 3ヶ月ほど使ってみて

HHKB Lite2は、残念ながら2019年で廃盤となりました。職場と自宅でかれこれ10年以上愛用してきたLite2でしたが、ふと「HHKBに拘る必要はないのかも」と思い始め、移行先のキーボードとして標準的な英語配列のコンパクトキーボード、KeychronのK2/K3を試してみました。 Keychron K2/K3を選んだ理由 HHKB登場時はともかく、現在ではテンキーレス(TKL)80%以下の、コンパクトなキーボードは色々な選択肢があります。個人的には、現行のHHKBはLite2後継の対象とはならず、いったん標準的な英語配列のKeychoron K2/K3への移行を試してみました。 Mac/Windows対応 Lite2では、Windows(Linux)とMac環境で1台ずつ購入して使っていましたが、Keychronのキーボードは1台でMac/Windowsに対応しています。Windows/Macそれぞれのキーキャップも付属しているのも、有り難いところです。 切り替えは、側面のスイッチで、簡単にMac/Windowsの切り替えが可能です。ただし、キーキャップの交換などの手間もあり、結局はLite2と同じくWindowsとMac環境で1台ずつの揃えることになりました。 チルダ(~)キーが独立 KeychronにはHHKBに近いキーボードとしてKeychronにもK6(65%)がありますが、チルダ(~)キーが独立ではありません。K6では、FNキーとESCの組み合わせでチルダ(~)キーの入力となります。 実は、K6を購入してから気が付いたのですが、Macではまだ許容できるものの、Windowsでは言語切り替えにALTキーにチルダ(~)キーを多用するため、3重押しを回避するための、チルダ(~)キーのあるK2/K3に落ち着きました。 カーソルキーが独立 現行のHHKBに移行できない理由は、カーソルキーの不備があります。HHKBも日本語キーボードにはカーソルキーがありますが、今まで英語キーボードメインだったので、ちょっとコスト感があります。Keychronは、右SHIFTキーが1.75U、スペースキー右横が1Uキー3個と標準からは若干変則的ですが、カーソルキーが標準で配置されています。 スイッチが選択できる Lite2はメンブレインでメカニカルな爽快感はないものの、押下圧55gでタクタイル感が強めです[1]。個人的には、HHKBのようの低めの押下圧や赤軸のリニア感が苦手な感があります。 Lite2に移行する前は、職場と自宅共にIBMのキーボードをメインキーボードとしていましたので、Gateronの青軸、外出も考えて茶軸も選択して、原点回帰してみました。 HHKB Lite2からの移行してみて キーボードについては、自宅では有線接続、外出先では無線接続メインの利用環境です。また、コロナ禍で自宅での利用機会がメインとなっていますが、しばらくHHKB Lite2から移行してみての感想をまとめてみたいと思います。 キーの感覚 (茶軸・青軸が良い) 今回購入したGateronの茶軸は、Lite2と同じ押下圧55gのタクタイルです。個人的には押し比べてみても違いは僅かで、茶軸については同じ感覚で全く違和感がありません。 とは言え、打鍵感は、断然Gateronの青軸です。押下圧60gとやや重めになりますが、打鍵感は以前のIBMキーボードに近しく、やや軽い印象もありますが、非常に軽快です。打鍵音は、IBMキーボードのようなガチャ感のあるメカニカル音はせず、軽快で静かです。 バックスペース(BS)キーの位置が違う 最初は、HHKBより1段上の位置にバックスペース(BS)キーがあるので、HHKBの感覚が抜けきれませんでした。単純に打ち間違いが多いのと、遠い違和感がなかなか抜けきれませんでした。 ただ、位置に関しては、1週間もすると違和感が消えていきました。いずれにしても、標準の英語キーボードと同じ位置なので、選択肢の多い標準キーボード配列に戻れる意味合いでも良かったです。 最右列の押し間違い HHKBより右にもう1列あるコンパクトキーボードのため、BSキーやRETURNキーを押した時に、間違えて隣接するページキーやホームキーを一緒に押してしまうことがあります。…

Read more

自己設計(Self-Design)における設計連続体(Design Continuums)の概念について

自己設計(Self-Design)における設計連続体(Design Continuums)の概念について

自己設計システムとは、システム内の選択可能なプリミティブから、データベースのワークロードとハードウェアに最適な組み合わせを自動的に生成するという概念のものです[1]。今回は、この自己設計システムのコンセプトの著者の、キーバリューストアを題材とした直近の論文を紹介してみます[2]。 自己設計によるカスタマイズ (Customization through Self-Design)とは? 自己設計(Self-Design)は中世の原子論的に、基礎となる設計要素を組み合わせ、最適な組み合わせとなるシステムを構成する概念のものです。選択可能なプリミティグには、ハードウェアだけではなく、分散システムのパーティショニング方法(例: ハッシュ分割、レンジ分割)やデータアクセス方法(例: スキャン、ソート済検索など)などのソフトウェア(アルゴリズム)も含まれます [3]。 自己設計による最適化手法には、学習コストモデルを用いた最適化や機械学習が用いられ、新しい組み合わせが未知のアルゴリズムやデータ構造を生み出すことで、パフォーマンスを大幅に向上させる可能性があります[1][3]。本論文では、具体的な評価対象システムとしてキーバリューストアを題材に、自己設計(Self-Design)における手法を提案しています。 キーバリューストアとは? キーバリューストアは、キーと値のペアを格納するデータ構造を実装したものです。キーバリューストアは、ソーシャルメディアのグラフ処理、アプリケーションデータのキャッシング、NoSQLストレージ、オンライントランザクション処理などの、多種多様なアプリケーションの基盤として活用されています[2]。 また、近年のリレーショナルデータベースであるGoogleのSpannerや、RockDBをMySQLのバックエンドストレージとしたMyRocks、FoundationDBをバックエンドストレージとしたデータウェアハウスのはSnowflakeなども、バックエンドにキーバリューストアが採用されています [2][5]。 主要なKey-Valueデータ構造 キーバリューストアのデータ構造については、読み取り・書き込み・メモリ消費量には常にトレードオフが存在し、この3つ全てを最適とするデータ構造は存在しません[2]。結論としては各目的に応じたデータ構造が必要となるのですが、現時点で代表的なデータ構造として、B+Tree、LSMツリーなどが存在しています。 B+Tree B+Treeは、RDBMSやファイルシステムでも採用されている主要なツリー構造で、合理的なメモリ消費量で読み取りと書き込み性能のバランスに優れ、現在はOracleの製品であるBerkeleyDBや、近年でもMongoDBの標準ストレージエンジンとなったWiredTiger、FoundationDBなどのキーバリューストアに採用されています。 LSMツリー LSMツリー(Logs-structured merge-tree)は、高速な書き込みと読み取り性能を共存させるデータ構造で、GoogleのLevelDBやBigTable、FacebookのRocksDB、Apache CassandraやHBase、さらにはMySQLやSQLiteなどのRDBMSの主なキー管理などにも採用されています。ただし、B+ツリー構造より書き込み性能は優れますが、読み込み性能は悪化する場合があります。 その他 (LSHテーブル、ハイブリッドな構成など) 近年はRiakのBitCaskやSpotifyのSparkeyに用いられているLSHテーブル(Log-Structured Hash-table)などの新しい構造もあります。また、アプリケーションに適切なパフォーマンスを提供するため、複数のデータ構造を排他的に提供する場合もあります。例えば、MongoDBのWireTigerでは、B+TreeとLSMツリー実装を排他的に個別にサポートしており、RocksDBでは部分的にハッシュテーブル構造を取り入れて最適化しています。 多くの最新のキーバリューストアは、相互に排他的なスワップ可能なデータレイアウト設計のセットで構成され、多様なパフォーマンス特性を提供します。たとえば、WiredTigerはBツリーとLSMツリーの実装を個別にサポートして読み取りまたは書き込みをそれぞれ最適化しますが、RocksDBファイルはソートされた文字列レイアウトまたはハッシュテーブルレイアウトをサポートして、範囲の読み取りまたはポイントをさらに最適化しますそれぞれ読み取ります。 自己設計(Self-Design)の目的 自己設計(Self-Design)の長期的な研究課題は、例えば前述のキーバリューストアの場合、対象の問題に最適なデータ構造を、簡単または自動的に選択できるかが重要な課題となります。自己設計は、対象となるドメイン知識となる原則を導き出すことを目的としており、今回の論文では、自己設計を実現するものとして、連続体(Design Continuums)の概念を提唱しています。…

Read more

VR黎明期を振り返る – 「VR原論」のその後

VR黎明期を振り返る – 「VR原論」のその後

最近、「人工現実感の世界[1]」のリニューアル版として「VR原論[2]」の刊行がありました。時期的には、1990年にホールアース研究所により開催されたサイバーソン(Cyberthon)[3][4]前後の、当時のVRの雰囲気をまとめた書籍です。 「人工現実感の世界」は、VR黎明期当時のVRを取り巻く状況を取材したものであり、その刊行時期において「思考のための道具」などでも著名なラインゴールド(Howard Rheingold)氏の「Virtual Reality(邦訳:バーチャル・リアリティ)[5][6]」に匹敵する、VR黎明期の状況をまとめた先駆的な書籍であると思います。 「VR原論」では、「人工現実感の世界」が発刊された1990年前後の状況についての対談形式での補足があり、今回の記事はその対談に触発されてものです。私自身も「人工現実感の世界」の発刊に感銘をうけた世代でもあり、なんとも懐かしく読んでしまいました。 「VR原論」の冒頭にもありますが、黎明期のVRが忘れ去られているのは、驚きでもあり残念でもあります。考えてみれば、VR黎明期は、いまのようにインターネットやデジタルカメラが普及しておらずデジタルコンテンツは残りづらく、「人工現実感の世界」がそうであったように書籍も絶版になっているため、致し方ないことかもしれません。 私自身は、1990年代のVR黎明期から2000年のVRML盛衰頃までは、仕事も趣味もどっぷりVR/3Dに浸かった生活だったのですが「HMDとグローブをしながらプログラミングしていた」なんて話をすると驚かれてしまい、こちらも驚いてしまいます。 今回は「人工現実感の世界」の発刊以降の1991年から、インターネットが普及する1995年ぐらいまでの、VR黎明期の失われた時代の状況を、手持ちの資料や関連書籍を参考にしつつ、振り返ってみたいと思います。 「Reality Engine Builders」たちのその後 「人工現実感の世界」は、1990年前後の米国と日本のVRの状況を取材した書籍で、その中に「Reality Engine Builders」として紹介されている米国のVRベンチャーが紹介されています。以下の写真は、その当時よく引用されていたVR黎明期のNASAエイムズ研究所の写真[10]でNASAのHMDとVR原論に登場するVPL社のデータグローブを装着しています。まずはVR原論で紹介されていたベンチャーのその後を補足してみたいと思います。 VR原論に登場する米国のVRベンチャーは、いずれも低価格のVRシステムやVR専用のSDK(Software Development Kit)の商用販売に挑戦していきます。 ただ、結末としては、これらの米国のVRベンチャー達は、1995年以降のPC/3Dグラフィックス性能の劇的な向上および、OpenGLやDirect3Dなどの3DAPIの標準化の影響もあり、彼らのVR専用システムおよびSDK(独自3DグラフィックスAPI + VRデバイス対応)は、徐々に姿を消すことになります。 VPL Research 実質的な活動期間は短かったとしても、VPL (Virtual Programming Languages) Researchおよび、ジャロン(Jaron Lanier)氏が、現在につながるVR(Virtual Reality)の概念および名称を一般にさせ、黎明期のVRブームの立役者であることは、皆さんの異論のないところだと思います。 世界初となるデーターグローブやアイフォンを商品化したVPL…

Read more

MongoDB プロトコル実装調査 – v3.6以降の実情

MongoDB プロトコル実装調査 – v3.6以降の実情

MongoDB プロトコル実装調査 – v3.6移行の現状について MongoDBは、DB-Enginesの2019年8月のランキング[1]で第5位と、近年でも安定した人気を得ているドキュメントデータベースです。また、マイクロソフトのCosmosDBや、FoundationDBの「Document Layer」に代表されるように、既存のデータベースでもMongoDBインターフェースを互換APIで対応する動向も見受けられます[2][3]。 ただし、2019年8月現在、MongoDB公式の最新バージョンは4.0系であるにも関わらず、CosmosDBはv3.2ベース、Document Layerはv3.0ベースの実装に留まっています。 今回は、このようなMongoDB互換APIの実装背景を理解する上で必要となる、MongoDBの基本通信プロトコルであるWire Protocol[4]の概要と、MongoDB公式のv3.6以降の通信プロトコル実装状況についての調査結果をまとめてみます。 MongoDB Wire Protocolの概要 MongoDB Wire Protocolは、MongoDBの基礎となる要求応答の通信プロトコル仕様です。 MongoDBクライアントは、TCP/IPソケットでMongoDBサーバーと接続し、この基本プロトコルを用いて通信しています。 共通ヘッダ MongoDBの通信プロトコルのWire Protocloでは、通信メッセージの共通ヘッダが規定されています。共通ヘッダは、メッセージ総合計バイト数(Message Length)、メッセージ要求識別子(RequestID)、メッセージ応答識別子(ResponseTo)、メッセージ種別(OpCode)の4種類の整数(int32)から構成されます。 メッセージ総合計バイト数(Message Length)のデータ形がini32であるため、仕様的には2GB以上のデータの送受信にはメッセージの分割必要となります。MongoDB公式の標準的な実装としては46MB(48,000,000byte)[5]程度を上限としているようです。 なお、Wire Protocloの整数型は、TCP/IPヘッダのバイトオーダーとは異なり、リトルエンディアン順序での送受信となります。エンディアン選択については、BSON仕様[6]と同じ経緯で、実装効率メインで仕様が決定された感があります。 メッセージ種別 (OpCode) MongoDBのメッセージ種別(OpCode)は、廃止(Deprecated)されたものを含めると、現在まで以下の11種類の送受信メッセージが規定されています。 OpCoce 値…

Read more

時系列データクラスタリングとk-Shape

時系列データクラスタリングとk-Shape

最近ある時系列データの因果関係が分析できればと、手始めに時系列データの相関解析やクラスタリングの手法を調査しています。 今回は、時系列データクラスタリング手法の動向と、2015年に論文が発表された正規化相互相関手法を用いた形状ベース(Shape-based)の時系列クラスタリング手法であるk-Shape[3]についてまとめてみます。 クラスタリングとは? クラスタリングとは、対象となるグループに対する高度な知識がなくとも、類似のデータを関連するグループや同種のグループに分割するデータマイニングの手法です。クラスタリングは、科学的データの探査、情報検索とテキストマイニング、CRMやマーケティング、医療診断などの、データマイニングの手法として実用的に用いられています [1]。 研究的な観点からも、クラスタリングは、統計、パターン認識、機械学習などの分野で、現在も活発に研究されています。機械学習的な観点では、クラスタリングは一般的には教師なし学習であり、クラスタリングは、多様な属性を持つ膨大なデータセットを分類したり、潜在するパターンの発見に役立ちます[1] [2]。 k-meansとは k-means(k-平均法)は、現在、科学および産業分野で最も広く使用されているクラスタリングアルゴリズムです。名称は、クラスタの平均(または加重平均)を用いてk個のクラスタに分類する手法に由来しています[3]。 クラスタリングにおいて、すべての可能な組み合わせを確認することは計算上実行不可能(NP困難)な問題です。k-meansは、貪欲法的に局所的最適解を求めて、それを反復して最適化する手法です。 具体的には、k-meansは対象データを表す点を、最初にランダムにk個のクラスタに割り当てます。各クラスタに含まれる点の平均を計算した後に、各クラスタのメンバーが不変になるまで、以下の2つのステップを反復して実行します。 STEP1 : 各対象データを、その重心に最も近い重心のクラスタに移動 STEP2 : 各クラスタの平均を再計算 反復による最適化は、各クラスタのメンバーに移動がなくなり収束した場合、または最大反復回数に達した場合に終了します。 時系列クラスタリングとは クラスタリングの手法は、時系列データの解析にも用いられており、主に時系列データセット内の潜在的、興味深いパターンの発見に利用されます。解析事例としては、株価などの時系列間の相関検出、天気予報などの関数近似と組み合わせた予測、店舗などのアイテム間の関連性の検出などがあります [2]。 時系列クラスタリングの手法 時系列クラスタリング手法を大別すると、モデルベース(Model-based)、特徴ベース(Feature-based)、形状(Shape-based)ベース手法および、その組み合わせの手法に大別されます。以下の図に、各手法に用いられるコンポーネントを示します [2]。 モデルベース(Model-based) モデルベースの手法は、時系列データを対象のモデルデータのパラメータに変換し、モデルで定義されている距離関数および(通常は従来の)クラスタリングアルゴリズムにを用いています。一般的に、モデルベースの手法はクラスタが接近している場合に性能が劣化するなど、スケーラビリティの問題が指摘されています [2]。 特徴ベース(Feature-based) 特徴ベースの手法は、時系列データが低次元の特徴ベクトルに変換され、、従来のクラスタリングアルゴリズムが適用されます。一般的に特徴ベクトルは正規化されており、ユークリッド距離などを用いたクラスタリング手法が用いられます [2]。…

Read more