セキュリティを盾に一点突破。どうもかわしんです。最近 Rust で SQLite を実装してます。 以前の記事で HTTP Parser を Rust で実装しようとしたものの、すでに実装されていたので断念しましたが、いい題材を見つけました。SQLite です。開発中のリポジトリはこれです。 github.com 今の時点では、Read Only で1つの WHERE 句を持った SELECT 文しか処理できないですが、以下の機能を実装しています。 sqlite3 で生成された database ファイルの読み取り (cursor.rs, btree.rs, record.rs) SQL 文の解析 (token.rs, parser.rs) テーブルとインデックスのメタデータのパース (schema.rs) 動的なファイルの読み込み (pager.rs) SQL クエリとスキーマ情報を元に

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

#DataMigrationNight にて発表したスライドです

4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

弟子が珍しくまともなことを言っていたので記録しておく。 データのバックアップ方式云々について、話し合っていたときのことである。バックアップ周辺機能というと、おおよそ運用時にトラブルが発生しやすく、議論は慎重に進めなければならない。我々はチーム総出で、ああでもないこうでもないと頭を悩ませていた。 おおよそ要件がまとまり始めたころ、弟子はおもむろに口を開いた。 「そういう要件なら、バックアップデータっていうのは、リストアできることを確認したデータであるべきですよね。そうじゃないなら、バックアップって言っちゃいけないですよ」 弟子の発言はあまりにも正しかった。それまでの流れでは、バックアップデータの取得方法や保存方法に論点が集中しており、本来はバックアップと同時に語られるべきリストアについて、少々おざなりになっていたのである。 まさに私が言い出すかどうか迷っていた部分でもあった。アドリブに弱い私

C34 ニッチだけど、社会インフラを支えるデータベース、HiRDB ～HiRDBを選ぶ人、選ばない人、その選択基準とは～ by Taichi Ishikawa

あれは、僕がデータベースを扱ううち最初から３件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆

日立のデータベース製品「HADB」が、DBシステムのベンチマークテスト「TPC-H」で世界で初めて“100テラバイト級”として認定された。 日立製作所（以下、日立）のデータベース（DB）製品「Hitachi Advanced Data Binder プラットフォーム」（HADB）が、DBシステムの業界標準ベンチマークテスト「TPC-H」で世界で初めて“100テラバイト級”として認定された。日立が10月21日に発表した。 HADBは、日立が東京大学との共同研究に基づき製品化したDB製品。データ入出力要求の発生順序とは無関係な順序で非同期にデータを処理する「非順序型実行原理」によってDB処理を高速化したのが特徴で、HDD構成／SSD構成のストレージ環境の両方で、従来型のDBエンジンと比べて約100倍のデータ検索処理性能を確認したとしている。 今回、TPC-Hの最大規模である100テラバイト級の

国立情報学研究所は、情報系・コンピュータサイエンスの研究者を中心とした文部科学省系の研究所です。そのほかに、大学や国の研究機関のネットワークも扱っており、環境系のネットワークも管理しています。 私自身は、データベースというより、データベースを実行する分散システムといわれているもののインフラが専門ですので、本日はデータベースというより、データベースの外側からこれからどういう技術が起きて、それがデータベースにどう影響するのかという話をさせていただきます。 本日のセミナーのサブタイトルに「ビッグデータ」とありますが、ビッグデータの話になると、必ずデータ量が増えているという話になります。例えば、2020年になるとデータ量は2011年の50倍になります。しかし、皆様の関心事は、世の中のデータが増えるか増えないかということより、皆様の企業やお客様のデータがどれだけ増えていくのか、そのデータがどのように

テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注

本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。 本書への称賛の声 監訳者まえがき はじめに I部 データベース論

複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら

「Google BigQuery Service」をGoogleのクラウド経由で利用することで、中小企業でもテラバイト級のビッグデータの分析が可能になる。 米Googleは11月14日（現地時間）、同社のクラウド上でいわゆる「ビッグデータ」を分析する企業向けサービス「Google BigQuery Service」のプレビュー版を公開したと発表した。正式版は有料になる見込みだが、現在は無料で利用できる。 BigQueryは、同社が2010年の開発者向けカンファレンス「Google I/O」で発表したクラウド分析サービス。これまでは一部の企業を対象にクローズドなプレビュー版を提供していた。 ユーザーはGoogleのクラウドストレージサービス「Google Cloud Storage」に分析したいデータをアップロードし、Webブラウザ経由で分析できる。同社は10月にクラウドデータベース「Goo