サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大そうじへの備え
masayuki038.github.io
自作DBMS Advent Calender 2020 の 20 日目の記事です。 現在、truffle-arrow というクエリエンジンを作っているので、その話を書きます。 『How Query Engines Work』 仕事で Cloudera Impala に触れ、クエリエンジンに興味が湧き、自分で作ってみたいと思うようになって作り始めました。最初はクエリエンジンの作り方が分からなかったので、とりあえず参考書等を探して入り口を探しました。しかしそれらを読んでも実装できる気がしなかったので、まずは Apache Drill のコードを読んでいました。 今年、Apache Arrow の PMC の Andy Groove が『How Query Engines Work』という書籍をリリースしているので、興味のある方は読んでみてください。彼自身も Rust と Apache Arro
Quasar - Fiber, Channel, Actor Quasarは軽量スレッド、GoライクなChannl、ErlangライクなActorや、非同期プログラミングツールを提供するJavaのライブラリです。 今回は、Fiber、Channel、Actorを試してみました。 Bytecode Instrumentation このライブラリを使うには、Instrumentationを使ってバイトコードの書き換えを行う必要があります。この書き換えは、JVMの起動オプションにQuasarが提供するJava Agentを指定して実行時に書き換えを行うか、もしくはAntタスクを使って事前に書き換えを実行してく必要があります。今回はJava Agentを使って試してみました。どちらの使い方も以下のページに記載されています。 GETTING STARTED - Instrumenting Your
前回のmemberlistに続き、今回はserfのコードを読んでみました。 Serf Summery serfは、memberlistを利用してクラスタ内のノードのJoin/Leaveやユーザ定義のイベントをフックし、各イベントにマッピングされたユーザスクリプトを実行します。 Packages serfは以下の3つのpackageで構成されています。 serf memberlistを作成 memberlistのメッセージングの仕組みの拡張 UserEvent ノードの状態をスナップショットとして保存し、リストアする仕組み agent 各ノード上で起動されるプロセス コマンドからのリクエストを受け付けて処理し、結果を返す command CLI 任意のノードのエージェントにリクエストを投げ、レスポンスを表示する Full State Sync Message Expansion serfはm
このところ、Serfのコードを読んでいました。一旦、読んで理解した内容をまとめてみたいと思います。 Packages Serfは大きく次の2つのパッケージに分かれており、各々の役割は以下のようになっています。 memberlist クラスタのノードの状態管理 イベントの発行 serf コマンドの提供 イベントをフックして任意のスクリプトを実行する仕組み クラスタの状態のスナップショットの作成とリストア そして、serfはパッケージはmemberlistパッケージに依存しています。 今回はmemberlistについて分かったことを書いていきます。 Memberlist Summary memberlistはSerfクラスタの各ノード内に1つずつ存在しており、Serfクラスタ内の全ノード情報を保持しています。この保持しているノード情報が、Serfクラスタのノード間でやり取り(full stat
B+Tree And Ruby 以前、java.util.MapをBSONでファイルに保存するFileStoredMapというコレクションクラスを書きました。 今度はそれのTree版を書こうと考えたのですが、Tree自体をこれまでロクに書いたことが無かったので、まずはRubyでB+Treeを書いてみました。こういった作って動かしてみてどういうものか確認するのは、スクリプト言語の方が楽なので。実際、動かしながら作っていくのはなかなか面白い作業でした。 b_plus_tree.rb: 1class AbstractNode 2 @@root = nil 3 4 def initialize(n, keys, parent) 5 @slot = n 6 @keys = keys 7 @parent = parent 8 @@root = self unless @@root 9 end 10 1
Ordered and Ordering Scalaには2値の比較を扱うtraitがあります。一つはComparable[T]を継承しているOredered[T]、もう一つはComparator[T]を継承しているOrdering[T]です。 Comparable[T]はjava.util.Comparable、Comparator[T]はjava.util.Comparatorに対応しており、前者はcompareTo(t)を、後者はcompare(t1, t2)を持っています。つまり自分と他のオブジェクトを比較するか、2つのオブジェクトを比較するか、という点が異なります。 Ordered[T]を扱っていると、たまにOrderingへの変換に失敗した、というコンパイルエラーが出ることがあります。これがどうも気になったので、今回はOrderedとOrderingの関係を調べてみました。 A
Actor model in Scala 先週、ちょっとしたアイデアとアクターモデルの相性が良いことに気がつき、アクターモデルを使ってコードを書いてみたいと思うようになりました。 アクターモデルは、ErlangやScalaのように言語に組み込まれていたり、Akkaのようにライブラリとして提供されています。最近は仕事も仕事以外のコードもJavaで組むことが多いのですが、これを機にErlangかScalaのどちらかを学ぼうと考えました。これまでJavaとJVMに触れている機会が多いことを考え、まずはScalaを学んでみることにしました。 Implicit Conversion 勉強がてら、WEB+DB vol.67の赤黒木のHaskellコードをScalaで書いてみることにしたのですが、何せ命令プログラミング脳なのでなかなか思うように進みません。特に躓くのは、型が合わない際の対処です。Scal
The behaviour of key expiration in Redis Redisのkeyのexpirationを理解する為に、以下のページの「Appendix: Redis expires」を和訳してみました。 EXPIRE - Redis 間違い等あればtwitter(@masayuki)に連絡をください。 Keys with an expire 通常、Redisのkeyは生存期間を持たない。ユーザがDELコマンドを使って明示的に削除しない限り、keyは存在し続ける。 EXPIRE等のコマンドは、本来のkeyのメモリ消費量に少し上乗せする形で、keyに有効期限をつけることができる。keyに有効期限が設定されると、Redisは一定時間経過したkeyを削除するようになる。 keyの生存期間はEXPIREやPERSISTコマンドによって更新または削除される。 Expire accu
configureBlocking(false) 前回のコードで、acceptした後にOP_READでselectorにregisterする直前に、以下のような記述がありました。 SocketChannel channel = serverChannel.accept(); channel.configureBlocking(false); channel.register(key.selector(), SelectionKey.OP_READ); この「channel.configureBlocking(false)」を実行すると、I/Oがノンブロッキングになります。 しかし前回のecho serverを実際に動かしてみると、クライアントからのリクエストをreadする箇所がノンブロッキングで行われている感触がありませんでした。これは、Selector#select()がクライアントから
このページを最初にブックマークしてみませんか?
『masayuki038.github.io』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く