Posts

Parallel Database Systems: The Future of High Performance Database Systems

データベースの処理性能を上げる手段として、特殊なハードウェアをもちいたり、メモリやディスクを共有した複数のコンピュータを使ったりするよりも、安価で単純に実装できることから、汎用的なコンピュータによる水平パーティションのシェアードナッシング構成を支持した。 論文が発表された1992年の時点でTeradataやTandem NonStopなどのパーティンション化されたデータベースがある。

Chain Replication for Supporting High Throughput and Availability

ストレージサーバーに順番をつけ、順にオブジェクトを複製することで、ストレージサービスの一貫性を維持しつつスループットと可用性の向上をはかる。 ここでのストレージサービスは、オブジェクトを保存し、クエリに対して一つのオブジェクトを返し、アトミックに一つのオブジェクトを更新できるものをさす。 また、一貫性は、オブジェクトごとにクエリと更新を直列的に適用し、更新につづくクエリが更新内容結果になることを意味する。 末尾のサーバーがクエリを受信し、該当するオブジェクトをクライアントに返す。 先頭のサーバーが更新リクエストを受信し、順にサーバーのオブジェクトを更新し、末尾のサーバーが更新の結果をクライアントに返す。

Implementing Remote Procedure Calls

Xeroxのプログラミング環境Cedarのために開発されたRPCを解説した84年の論文である。 RPCの開発目的は、分散コンピューティングを簡単に実装できるようにする、通信時間を短くする、通信をセキュアにすることの3点である。 RPCは大部分でMesaが使われた。

Dremel: Interactive Analysis of Web-Scale Datasets

Dremelは2006年からGoogle社内で利用されているDWHで、社外にはBigQueryとして提供されている。 列指向の形式でデータを保存し、SQLに似た言語のクエリでデータを検索できる。 Dremelは、サーバーのクラスタを木構造に組織し、ルートで受理したクエリの処理を下層のサーバに分配し、その結果を集約することで処理を分散し高速化をはかる。

Is Rust Used Safely by Software Developers?

crates.ioに登録された15,097個のクレートにおけるunsafeキーワードの使用状況を調べた。 調査したクレートは、調査を開始した2018年9月時点でcrates.ioに登録された全クレートの81%にあたる。 unsafeを含むクレートは、そのうちの29%だったが、依存するクレートにあるunsafeも対象にすると、50%におよぶ。 crates.ioの総ダウンロード数のうち90%を占める473個の有名なクレートに限定すると、60%のクレートunsafeが含まれる。 2018年9月から2019年6月までの10ヶ月間でunsafeの使用傾向に変化はなく、unsafeの数が少し増えただけであった。 unsafeの用途の大半はunsafeで修飾されたRustの関数を呼び出すためだった。 なお、コンパイラで生成されたunsafeキーワードは集計に含まれていない。

Design Tradeoffs for SSD Performance

HDDの処理性能を測るためのシミュレーションソフトDiskSimをSSD向けに改造し、SSDの設計における選択肢の分類と選択にともなうトレードオフを報告する。 主要な選択肢は、論理アドレスと物理アドレスのマッピング、ページサイズ、オーバープロビジョニング、複数のpackageでcontrollerに接続するピンを共有するgangingがある。

What helped, and what did not? An Evaluation of the Strategies to Improve Continuous Integration

TravisTorrentにある100件のプロジェクトで10種類のCIのテクニックを定量評価した。 テクニックは、不要なビルドやテストをスキップするか、実行順序を優先づけるものかに分かれる。 前者は計算資源の消費を減らすこと、後者は失敗するケースを早めに実行することを目的にする。 もっとも成功するテストやビルドをスキップできたテクニックは、コードに変更のないケースをスキップするものだったが、同時に失敗するテストを多く見落とした。 実行順序を優先付ける手法で最も性能のよかったテクニックは、Thomasらのもので、シグネチャやコメントで学習したトピックモデルを使い直前に実行したテストと違うトピックのテストを実行する。

Don't Do That! Hunting Down Visual Design Smells in Complex UIs against Design Guidelines

マテリアルデザインの公式ドキュメントから93種類の不吉な匂いを洗い出し、71種類の匂いを検出するツールUIS-Hunterを開発した。 2020年5月のドキュメントから"don’t"や"caution"の単語とUIの例があることを条件に不吉な匂いを選び、9,286個のアンドロイドアプリにある7,497のUIを調べたところ、2,587個のアプリから1つ以上の不吉な匂いのあるUIが見つかった。 UIS-Hunterは、FigmaやAndroid Studio Layout EditorなどのモックアップやAndroid UI AutomatorやSeleniumのスクリーンショットから不吉な匂いを解析し、UIのソースコードを必要としない。 9,286個のアプリの60,756のUIで検出性能を評価したところ、precisionが0.81, recallが0.90だった。

An Empirical Analysis of UI-based Flaky Tests

GitHub上の5つのWebアプリケーションと37のAndroidアプリケーションから集めた235件のUIのflaky tests(何度か実行すると成功する不安定なテスト)を調査し、原因と修正を分類した。 大きく原因を、非同期処理の待機、環境依存の動作、DOMのセレクタやテストライブラリの誤用、テスト対象の事前条件を満たしていないテストスクリプトの4つに大別した。 具体例をあげると、環境依存の動作には、IE固有のバグや予期していないレイアウトで画面が表示される場合、テストの事前条件については、テストの実行順序次第で誤ったテストデータが作られる場合がある。 最も多くのテストが分類され、全体の45%を占めたのは、非同期処理の不適切な待機方法だった。 修正のパターンには、待機時間の追加、テスト用APIの誤用の修正やAPIのアップグレード、テストスクリプトのリファクタリング、アニメーションの削除、不要なテストの削除がある。 論文をこちらからダウンロードできます。

A Case Study of Onboarding in Software Teams: Tasks and Strategies

オンボーディングのためのタスクの選び方とタスクの効果を調査するために、マイクロソフトのエンジニアとマネージャーにインタビューした。 まず、新しいチームに入った32人のエンジニアとエンジニアを迎えた15人のマネージャーにインタビューし、特に、チームのことを知る、担当する役割を果たせる自信の醸成、メンバーとの交流の3つを重視し、これらに対するタスクの影響を調査した。 タスクの選び方は、大きく、割り当てるタスクを少しずつ複雑にする、優先度の高いものを選ぶ、曖昧なタスクを選ぶ、の3つがあった。 オンボーディングするエンジニアがジュニアであれば最初の選び方、シニアであれば最後の選び方、アジャイルを採用するチーム、新しいチーム、納期の厳しいチームは優先度でタスクが選ばれやすく、効果的であった。 以上の考察を189名のエンジニアと37名のマネージャに評価してもらい、妥当性を確認した。