Google Scholar
読み込んでいます...現在システムで処理を実行できません。しばらくしてからもう一度お試しください。引用検索オプション検索条件すべてのキーワードを含むフレーズを含むいずれかのキーワードを含むキーワードを含まない検索対象にする箇所記事全体記事のタイトル著者を指定:例: "湯川秀樹"、朝永出典を指定:例: 物理学会、Nature日付を指定: — 例: 1996マイライブラリに保存しました完了論文を削除記事プロフィールプロフィールマイ ライブラリアラート統計情報検索オプション設定ログインログイン記事Scholarプロフィールマイ ライブラリすべての版該当する記事が見つかりませんでした。 プライバシー規約ヘルプGoogle Scholar についてヘルプを検索
職業としてのプログラミング 大規模ファイルを扱うには - 2Gの壁とLSF仕様
32bitの符号付き整数の最大値は2G、符号無しなら4G。それ以上は表せません。そのため、いわゆる2Gの壁、4Gの壁と呼ばれるものがあります。代表的なものはファイルサイズ、そして、メモリサイズです。まだメモリが2GB以上ということはそれほど多くはありませんが、ファイルサイズに関しては2GB以上のものも少なくありません。例えば、TV番組を録画した動画ファイル、DVDのイメージ等々。今回は、2GB以上の大規模ファイルを扱うためLSFについて説明します。 最近のLinuxやBSDだと、デフォルトでカーネルは2GB以上のファイルにLSFとは対応していますし、プログラムも対応しています。NFS(Server/Client)等のデーモン、Appach等のサーバ、cp、cmp等のfileを扱うプログラム等々。そのため、Linuxをデフォルトのままデスクトップとして使っている間は、あまり大規模ファイルのサ
アルゴリズムとデータ構造
プログラムの実例を使って、アルゴリズムやプログラミングをしっかりと理解することを重視。 連結リスト [HTML], [PDF], [PPT] 循環リスト プログラムをダウンロード データファイルをダウンロード 双方向リスト [HTML], [PDF], [PPT] 木の走査 [HTML], [PDF], [PPT] プログラムをダウンロード ソート木 [HTML], [PDF], [PPT] スレッド木 [HTML], [PDF], [PPT] プログラムをダウンロード クワッド木 [HTML], [PDF], [PPT] AVL 木 [HTML], [PDF], [PPT] B+-tree [HTML], [PDF], [PPT] プログラムをダウンロード B+-tree のディスクアクセス [HTML], [PDF], [PPT]
STX B+ Tree C++ Template Classes - panthema.net
Eduard: a) also ich verstehe diesen "Sicherheits"-Einwand auch nicht b) wäre es möglich, den Code unter einer anderen Lizenz zu stellen? LGPL ist eigentlich nur sinnvoll für shared-Libs, bei template-Headers wirkt es ähnlich restriktiv wie die GPL. BSD-ähnliche Lizenzen sind IMHO im allgemeinen brauchbarer, sogar die alte BSD-Lizenz mit Advertising-Klausel. Siehe auch GCC-STL-Headers, stehen unter
B+木 - Wikipedia
B+木（英: B+ tree）は、キーを指定することで挿入・検索・削除が効率的に行える木構造の一種である。動的な階層型インデックスであり、各インデックスセグメント（「ブロック」などと呼ばれる。木構造におけるノードに相当）にはキー数の上限と下限がある。B+木はB木とは異なり、全てのレコードは木の最下層（葉ノード）に格納され、内部ノードにはキーのみが格納される。 B+木は、特にブロック型記憶装置での効率的データ検索に効果を発揮する。ブロックサイズ の記憶装置があるとき、 の倍数個のキーを格納するB+木は2分探索木に比較して非常に効率が良い（2分探索木はブロック型でない記憶装置に適している）。 ReiserFS（UNIX、Linux）、XFS（IRIX、Linux）、JFS2（AIX、OS/2、Linux）、HammerFS（DragonFly BSD）、NTFSといったファイルシステムはいずれ
B+-tree
□ B-tree ではレコードそのものをノードに入れるので，ページに入れられる レコードの数が少ない． これに対して，通常の索引ではキー値とポインタのみであるので，一ページに 入る量が増やせる． この観点から B-tree を改良したのが B-tree で，B-tree よりも 一般的である． □ 図6.8 (p. 116) に索引部が 次の B-tree と同様で， leaf ノードのエントリ数が 最大 3 のものを示す． B-tree と異なり，データレコード自体は leaf にのみ記録されるので， v キー値の出現の様子を見ると，重複がある．(例: 25 や 16 など．) leaf ノードは 一般にポインタでつながれているので，レコードをキー順に アクセスするのは，B-tree の走査よりも簡単である． □ 格納できるエントリ数の違いを見ておく． レコードサイズが 256 で，ペー
MySQL
MySQL HeatWave MySQL HeatWave is a fully managed database service for transactions, real- time analytics across data warehouses and data lakes, and machine learning services, without the complexity, latency, and cost of ETL duplication. It is available on OCI, AWS, and Azure. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical suppo
MySQL
MySQL HeatWave MySQL HeatWave is a fully managed database service for transactions, real- time analytics across data warehouses and data lakes, and machine learning services, without the complexity, latency, and cost of ETL duplication. It is available on OCI, AWS, and Azure. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical suppo
MySQL :: MySQL 4.1 リファレンスマニュアル :: E.4 ロック方法
ISAM/MyISAM および HEAP テーブルのテーブルロック、BDB テーブルのページレベルロック、InnoDB テーブルの行レベルロックのみが、MySQL で現在サポートされています。 See 項5.3.1. 「MySQL のテーブルロック方法」。 INSERT ステートメント間に競合がない場合（レコードまたはデータの削除による空き領域を埋めるのではなく、テーブルファイル末尾に追加する場合はいつでも）、MyISAM テーブルでは INSERT と SELECT をロックなしで自由に組み合わせることができます。 バージョン 3.23.33 からは、システムにおけるテーブルロックの競合を Table_locks_waited および Table_locks_immediate 環境変数を確認して分析できるようになりました。 テーブル型を行レベルロックと共に使用するかどうかを決定するには
無料サービスを使え！ – 役立つ無料サービスのレビュー、まとめ、比較記事を紹介
コンテンツへスキップ 無料で使える！HubSpotの顧客リストの活用法 無料のアンケート作成ツール 比較／まとめ 無料「Excel」 テンプレート 比較／まとめ 無料で使えるノートアプリ比較 (Evernote / OneNote / Google Keep) おすすめの無料Web会議システム5選 WebP Converter 徹底解説！初心者でも直ぐに使える HubSpot は、マーケティング、セールス、サービスのためのCRM（Continue reading 多くの人の声を聞くことで改善できることも多い 企業や団体など運営していContinue reading 就職・転職には必須となる履歴書・職務経歴書 これから就職活動をスタートContinue reading 便利なノートアプリで効率的な仕事をしよう いつの時代も仕事をしていてメContinue reading 近年、リモートワーク
http://www.t3.rim.or.jp/~matsuuch/COMP/btree.htm
という大小関係になっています。また、ページを指していないbranchは、NULL値になっています。 厳密に言うとページは、次のようなキビしい条件を満たします。ページ１つについてのキーの個数が最大2M個だとすると、 ページ当たりのキーの個数n は M ≦ n ≦ 2M を満たす。つまり、各ページは少なくとも半分埋まっていなければいけない。ただし、根（一つだけある）については 0 ≦ n ≦ 2 Mでよい。 各ページ上のキーは昇順にならべる（ key[0] ＜ key[1] ＜…＜ key[n-1] ） ポインタ branch[k] （ k ＞ 0 ）の指すページが含むすべてのキーは key[k-1] より大きい ポインタ branch[k] （ k ＜ n ）の指すページが含むすべてのキーは key[k] より小さい 木の高さはいたるところ一定。つまり、根から末端のページ（葉）に至るポインタ
物理的な格納方式
□ 計算機で使われるデータは必ず何がしかの記憶媒体上に置かれる． □ レジスタ (registers) CPU 内部に置かれた記憶装置 プログラムからのアクセスは高速 (CPU の動作クロックに合わせる必要があるため．) アーキテクチャの一部なのでサイズは固定されている ( が普通) 揮発性 (volatile): つまり電源が切れると内容が消えてなくなる □ 主記憶 (main memory, MM) CPU の外に置かれた記憶装置 プログラムからは直接読み書き可能 読み書きにかかる時間は今のところ 60ns 程度が主流 容量は可変で，現在は 数百 MB 〜 数 GB 程度が普通 揮発性 (volatile) □ 二次記憶装置 (secondary storage) CPU の外に置かれた記憶装置であるが， プログラムからは直接読み書きできないもの． 例: フロッピーディスク (FD)，
第4回 memcachedの分散アルゴリズム | gihyo.jp
株式会社ミクシィの長野です。第2回、第3回と前坂がmemcachedの内部について紹介しました。今回は内部構造から離れて、memcachedの分散についての紹介をいたします。 memcachedの分散 連載の1回目に紹介しましたが、memcachedは「分散」キャッシュサーバと言われていますが、サーバ側には「分散」の機能は備わっていません。サーバ側には当連載の第2回、第3回で前坂が紹介したメモリストレージの機能のみが組み込まれており、非常にシンプルな実装となっています。では、memcachedの分散はどのように実現しているのかと言うと、すべてクライアントライブラリによって実現されます。この分散方法はmemcachedの大きな特徴です。 memcachedの分散とは ここまで数度「分散」という言葉を用いてきましたが、あまり詳しく触れてきませんでした。ここでは各クライアントの実装に共通する大ま
mixi Engineers’ Blog » 圧縮データベースを使おう
チャリンコ通勤による滝のような汗で、朝からTシャツがシースルーになってしまうmikioです。さて今回は、Tokyo Cabinet（TC）のデータベースを各種のアルゴリズムで圧縮して利用する方法についてご紹介します。 圧縮B+木 B+木とは、比較関数の値による順序が近いレコード群を単一のページにまとめ、各ページにB木（multiway balanced treeの略であり、二分木（binary tree）とは違います）の索引を張ったものです。理論的にはレコードの探索も更新も O(log n) の時間計算量で行え、内部ノード（B木）の操作をキャッシュすると実質的には O(1) の時間計算量で探索や更新が行えるという、かなり安定した性能を備えるデータ構造です。その上、レコードが一定の順序に基づいて並べられているので、数値の範囲検索や文字列の前方一致検索が高速に行えたり、カーソルによって順序に基
第2回 memcachedのメモリストレージを理解する | gihyo.jp
株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミング/C,C++/2GBより大きなファイルの扱い - PukiWiki
B+ Tree Tutorial | PDF | Business
http://www.cecs.csulb.edu/~monge/classes/share/B%20TreeIndexes.html
MySQL :: MySQL 8.0 Reference Manual :: 17.6.1.6 AUTO_INCREMENT Handling in InnoDB
https://dl.acm.org/citation.cfm?id=301973