data-format-lab
「もう、わっかんないよ！」から、「ちょっとだけ分かるかも」へ。
CSV、TSV、JSONL、Parquet、Lance、Vortex、TsFile、FastLanesなどを実際に動かし、データを正しく復元できることを確認してから、容量、速度、メモリ使用量、LLMトークン数を比較するプロジェクトです。
Project links
- GitHub Repository
- README — English
- README — 日本語
- v0.1.0 — Benchmark Evidence Summary
- v0.1.0 — Release
Overview
The problem
データ形式が多すぎて、どの用途にどの形式を選べばよいのか分からない。
The approach
同じ型付きデータを各形式へ保存し、型、NULL、値、行数、検索結果、ハッシュが一致することを確認してから、性能を測定しました。
What makes it different
- 正しくデータを復元できなければ、速度や容量のランキングに入れない
- macOS ARMとLinux x86_64の測定結果を混ぜない
- 保存容量や速度だけでなく、LLMへ渡すときのトークン数も測定
- 未対応、ビルド失敗、クラッシュ、タイムアウトも削除せず記録
- 全文検索、時系列検索、高速スキャンなど、形式の得意分野も個別に検証
Key results
Compact TSV used fewer tokens
今回のデータでは、Compact TSVは93,377 tokens、array JSONLは105,886 tokens、object JSONLは148,736 tokensでした。
Parquet zstd-19 produced the smallest fair-storage artifact
今回のfair storageでは、Parquet zstd-19が176,713 bytes、Vortex compactが183,576 bytesでした。
The smallest format was not always the fastest to write
Parquet zstd-19は小さく保存できましたが、default Parquetより書き込みコストが高くなりました。
Vortex performed strongly in its scan workloads
今回のVortex向けワークロードでは、複数のscan条件でParquetより短い測定時間を記録しました。
TsFile stored time-series data compactly, with slower writes
1,000,000行の時系列データでは、TsFileは313,744 bytes、Parquetは5,777,023 bytesでした。一方、TsFileの書き込みにはより長い時間がかかりました。
There was no universal winner
保存容量、読み込み、書き込み、検索、LLMトークン数では、それぞれ有利な形式が異なりました。
How to read this submission
Why I built it
Read: Inspiration
What the project does and measures
Read: What it does
Technical implementation and verification flow
Read: How we built it
Environment problems, crashes, and AI-assisted development
Read: Challenges we ran into
The achievements I am proud of
Read: Accomplishments that we're proud of
Benchmark findings and format differences
Read: What we learned
Future datasets, semantic search, and UI plans
Read: What's next for data-format-lab
Inspiration
In this section: data-format-labを作ろうと思った背景について。
data-format-labを作ったきっかけ。
データ形式って、マジで複雑。
ベンチマーク結果をChatGPTへ渡して、 「この用途なら、どの形式がおすすめ？」 と簡単に聞けるようになったら便利だな。と。
調べれば調べるほど形式が出てくる。
サービスごとに使っているデータベースも違う。
そのうえ、新しい形式が今も開発され続けている。
なんで、これで世の中のサービスが成り立ってるんだ？
だったら、自分で動かして比べてみよう。
もうわっかんないよ！、分からなすぎて、何が何だか分かlance。
CSVは知ってんねん。
でもな、ならTSVは、何が違うねん。JSONLは、読みにくいんじゃい。
Parquetが良いって、どっかの偉い人が言ってました。
行志向？ 列志向？ 「志向」って、趣味でええやないかい！
Arrow、Lance、Vortex、TsFile、FastLanes……。orz もう訳が分からないよ！!!
速いって、読み込み？ 書き込み？ 検索？
小さいって、ファイル容量？ 圧縮後のサイズ、、、etc。
What it does
In this section: 比較した形式、測定項目、正しさの検証方法について。
data-format-labは、
1.データ形式やデータベースに関する性能上の主張を、できるだけ再現可能な条件で検証する研究プロジェクトとのことです。(他人事)。
2.ベンチマーク結果をChatGPTへ渡して、 「この用途なら、どの形式がおすすめ？」 と簡単に聞けるようになったら便利だな。と
3.それを僕が作れるか、上手く指示出し出来るかの、トレーニングです。マッチョになれます。
CSV、TSV、JSONL、Parquetなどの耳にした形式に加えて、Lance、Vortex、TsFile、
FastLanesなど、比較的新しい形式や用途特化型の形式も調査した？いや、そんなに、してないけどね。
同じ条件で比較できる形式には、同じ型付きデータを保存します。(理想)
そして、型、NULL、値、行数、検索結果、ハッシュが一致することを確認してから、容量や速度を測定しました。(ここら辺は、もう半分くらい分かってない。)
行数だけ合っていてもダメです。(え、そうなの？) 速く読み込めても、中身が変わっていたら比較になりません。(確かに。なるほど。)
全文検索、時系列検索、高速スキャンなどは、形式ごとに得意分野が違うため、それぞれ専用の条件で検証しました。(得意分野が違うのは、GPTに聞きました。)
主に調べたのは、次の項目だそうです。(もはや、データ形式比較してって頼んだだけとは、言えない。)
- ファイル容量
- 読み込み速度と書き込み速度
- メモリ使用量
- LLMへ渡すときのトークン数
- データを正しく復元できるか
- ビルド失敗、クラッシュ、タイムアウト
- macOSやLinuxなどの検証環境で利用できるか
動かなかった形式も、なかったことにはしていません。(この部分に関しては、その方が良いですよって提案された。)
このプロジェクトは、単一の「最強形式」を決めるものではありません。(え？最強形式が知りたかっただけなんだが🤣)
それぞれが、どの条件で強く、どの条件で苦戦するのかを調べています。(🤔いったい、何を言ってるんだ。)
How we built it
In this section: Python、uv、Nix、Rust、テストツールを使った実装について。
主要なベンチマークCLIは、Python 3.12で作りました。
uvでPythonの依存関係を固定し、NixでPython、Rust、C/C++のツールを含む開発環境を再現できるようにしました。
(Chatgptに、再現出来るようにしてって頼みました。)
コード量が増えるにつれてバグも増えたため、pytest、Ruff、Pyright、tyも導入しました。
最初から、きれいな構成が完成していたわけではありません。(バグが、出まくってるから、適当に直しといてって、作業をぶん投げました。)
バグが出る。
ツールを追加する。
今度は設定でエラーが出る。(全て、Chatgptの仕業です。)
主要実装はPythonですが、Vortexなどのネイティブテストでは、Rustツールチェーンやcargo-fuzzも利用しています。
各形式は、次の流れで検証します。
DISCOVERED
→ ENCODED
→ ROUNDTRIP_VERIFIED
→ BENCHMARKED
→ REPORTED
(その流れが良いとの事です。)
まず、その形式を利用できるか確認します。 次にデータを書き込み、正しく読み戻せるかを検証します。(へぇ)
性能を測るのは、そのあとです。(🤔知らんかった。) 「速いけれど、データが壊れている」という結果を成功扱いしないためです。(確かに。)
Challenges we ran into
In this section: OS差分、ネイティブ依存関係、ビルド失敗、AIとの開発について。
一番苦労したのは、環境差分です。(あと、Chatgpt、Codexへの指示出しです。)
Pythonだけで動く形式もあれば、Rust、C++、Java、ネイティブライブラリ、Pythonバインディングが必要な形式もあります。
macOSでは動くのに、Linuxでは動かない。
インストールできたのに、実行すると落ちる。
Pythonのエラーに見えたのに、原因はネイティブライブラリだった。
新しいデータ形式でも、「とりあえず実装してみて」と頼むと、コードを書き始められます。 分からないことを聞きながら作業できたので、学習面ではとても助かりました。 一方、コード量が増えたり、Nixやネイティブ依存関係が絡んだりすると、バグや再現できない修正も増えました。(GPTがバグを増やしました。僕じゃないです。)
結局、公式ドキュメントやソースコードを自分で確認したほうが早い場面も多かったです。(1次ソースを参考にしてって、頼むと良いですよ！)
最終的には、LLMの説明よりも、公式資料と実際の実行結果を優先しました。(だそうです。)
FastLanesなどでは、ビルド失敗やクラッシュ、内部エラーも発生しました。(おい、そうなのか?!、え、マジで？(-_-;))
それらも削除せず、どの条件で失敗したのかを記録しています。(削除しなかったのは、偉い。)
Accomplishments that we're proud of
In this section: 比較方法、再現性、失敗結果を残した理由について。
ベンチマークの数値だけでなく、 「どう比較すれば、相手に伝わるのか」 を考えるきっかけになりました。
自分が実際に使うPCで測定し、macOS ARMとLinux x86_64の結果を分けて記録しました。 異なる環境の数値を、無理に同じランキングへ混ぜていません。
成功した形式だけでなく、未対応、ビルド失敗、クラッシュ、タイムアウトも残しました。 動かなかったことも、形式を選ぶ人にとっては重要な情報だからです。
また、Python、Nix、テスト、型チェック、ネイティブツールなど、開発を通して自分の技術スタックも広がりました。
AIがどこで間違えたのか。
どんな指示でバグが増えたのか。
次はどう防ぐのか。
そうした失敗の記録も、次の開発に使える自分の資産になりました。
What we learned
In this section: トークン数、容量、速度、検索性能から分かったことについて。
一番予想外だったのは、LLMへ渡すデータフォーマット形式によって、トークン数がかなり変わることです。
今回の条件では、Compact TSVがarray JSONLやobject JSONLより少ないトークン数になりました。
Object JSONLは、各行にキー名を持ちます。 人間には分かりやすい一方で、容量やトークン数は増えやすくなります。(いや、分かりにくいけどね。)
CSVとTSVを比べる過程では、区切り文字や引用符もトークン数に影響すると分かりました。
CSVでは、値の中にカンマが含まれると、引用符が必要になる場合があります。 TSVはタブ区切りなので、その影響を受けにくい場合があります。 ただし、TSVが必ずCSVより有利とは限りません。
データの内容やトークナイザーによって、結果は変わります。 Compact TSVという名前を最初に見たときは、 「TSVをコンパクトにするって、なんやねん」 と思いました。
Vortexは、今回の一部のテストで、速度や圧縮率の面でParquetに迫る結果を示しました。 将来性を感じた形式の一つです。
Lanceは、全文検索で印象に残りました。 LanceDBを含め、AIやLLM向けの検索、ベクトルデータ、記憶システムとの相性にも期待しています。
ただし、今回測定したのは全文検索です。 意味検索やベクトル検索の精度までは評価していません。(評価してって言いました。指示ミスですね。)
TsFileは、時系列データを小さく保存できましたが、書き込みには時間がかかりました。 Parquetも、高圧縮設定ではファイルを小さくできますが、その分だけ書き込みコストが増えます。 つまり、全部に勝つ形式はありませんでした。 (最強を決めたかっただけなのに。。)
保存に向いた形式と、LLMへ渡すのに向いた形式も、必ずしも同じではありません。 開発前は、CSV、JSON、SQLを、あまり深く考えずに選んでいました。
今なら、Compact TSV、JSONL、Parquet、Vortex、Lanceなどから、扱うデータ、用途、実行環境を見て選ぶと思います。
What's next for data-format-lab
In this section: 複数データセット、ベクトル検索、意味検索、UIの今後について。
初心者に使ってほしいと思って作り始めたのに、現在のリポジトリは、あまり初心者向けではありません。 ここは、改善したいです。(いや、改善指示をまだ出してないだけだもん🥺)
v0.1.0は、一つのデータセットを中心に測定しています。(GitHubで、Stepieさんがスターを付けているリポジトリを分類したもの。)
そのため、数値の一般性や比較の公平性には、まだ不安があります。(いえ、それをデータに使った僕の倫理観の問題です。すみません。)
現在は、複数の公開データセットを検証できる次のバージョンを開発しています。
今後は、ログ、時系列、分析、テキストなど、用途別の比較も増やしたいです。(え？まだ増やすんですか？聞いてないよ!!勝手に仕事を増やさないでくださいね(´；ω；｀))
ベクトル検索、意味検索、部分列の読み込み、オブジェクトストレージ、複数トークナイザーでの比較にも取り組みたいと考えています。(上手い風に言ってますが、要は、AI用です。)
結果を見るだけで初心者でも判断できるように、UIやUXも強化したいです。(言ってるだけです。)
最後に、。
In this section: このプロジェクトを通して変わったことについて。
データフォーマットの種類、多すぎる！
対応環境も、開発言語も違う！
Pythonもコードが大きくなると大変！
でも、
「もう、わっかんないよ！」
から、
「ちょっとだけ分かるかも」
には変わったかな。。
参加できてよかったです。Thanku OpenAI。
Log in or sign up for Devpost to join the conversation.