GitHub - lancedb/lance: Modern columnar data format for ML and LLMs implemented in Rust. Convert from parquet in 2 lines of code for 100x faster random access, vector index, and data versioning. Compatible with Pandas, DuckDB, Polars, Pyarrow, with more i
Lance is a modern columnar data format that is optimized for ML workflows and datasets. Lance is perfect for: Building search engines and feature stores. Large-scale ML training requiring high performance IO and shuffles. Storing, querying, and inspecting deeply nested data for robotics or large blobs like images, point clouds, and more. The key features of Lance include: High-performance random a
複合インデックスで範囲検索が遅いとき - （ひ）メモ
DDLとデータは末尾に示しますが、複合インデックスが効くはずのクエリなんだけどナめてる行数が多くて困ったというお話です。(MySQL 5.1.55) このクエリで返ってくる行数は246件なんですが、それにしてはナめてる行数(rows)がやたら多いです。where句で使っているageとlast_updateとで複合インデックスを張っているのに、です。 between使用: explain extended select id from betweeeeen where age between 30 and 35 and last_update >= 946612000 \G ↓ id: 1 select_type: SIMPLE table: betweeeeen type: range possible_keys: i1 key: i1 key_len: 10 ref: NULL rows
3 ways MySQL uses indexes
I often see people confuse different ways MySQL can use indexing, getting wrong ideas on what query performance they should expect. There are 3 main ways how MySQL can use the indexes for query execution, which are not mutually exclusive, in fact some queries will use indexes for all 3 purposes listed here. Using index to find rows The main purpose of the index is to find rows quickly – without sc
索引と索引構成表
3 索引と索引構成表 この章では、表の行へのアクセスを高速化できるスキーマ・オブジェクトである索引と、索引構造に格納される表である索引構成表について説明します。 この章の内容は、次のとおりです。 索引の概要 索引構成表の概要 索引の概要 索引は、表または表クラスタに関連するオプションの構造であり、索引によってデータ・アクセスを高速化できる場合があります。表の1つ以上の列に索引を作成することによって、場合によって、ランダムに分散している行の小さなセットを表から取得できるようになります。索引は、ディスクI/Oを削減するための様々な手段のうちの1つです。 ヒープ構成表に索引がない場合、そのデータベースでは、値の検索に全表スキャンを実行する必要があります。たとえば、索引がない場合、hr.departments表の位置2700の問合せでは、データベースは、すべての表ブロックのすべての行でこの値を検索
索引構成表 - オラクル・Oracleをマスターするための基本と仕組み
索引構成表（IOT:Index Organized Table） 索引構成表 とは、簡単に説明するとデータ全体を最初から B-Tree インデックス に格納しているものである。表と主キーのインデックスとの共用体（⇔ C言語における構造体）になっているようなものである。 実際は B-Tree インデックスにはキーと ROWID が格納される程度なので、索引に入っているのではない。他のデータも入れることができるように拡張した表のことである。 通常であれば、表＋ 主キー（インデックス）の２つのデータ領域が必要なところを索引構成表のみで実現できるため Index Only Table と書かれたドキュメントもある。 通常表・ヒープ表 索引構成表と対比して、通常の表は「ヒープ表（Heap organized Table）」と呼ばれる形式であり、データの配置（並び順）についての 「しばり」 がないため
Reduce I/O with Oracle cluster tables
Reduce I/O with Oracle cluster tables Oracle Tips by Burleson Consulting Experienced Oracle DBAs know that I/O is often the single greatest component of response time and regularly work to reduce I/O. Disk I/O is expensive because when Oracle retrieves a block from a data file on disk, the reading process must wait for the physical I/O operation to complete. Disk operations are about 10,000 times
Oracle index blocksize tuning
Update: For the latest consensus on using multiple blocksizes in Oracle, see The latest consensus on multiple blocksizes. The benefits of a large blocksize The benefits of large blocksizes are demonstrated on this OTN thread where we see a demo showing 3x faster performance using a larger block size: SQL> r 1 select count(MYFIELD) from table_8K where ttime >to_date('27/09/2006','dd/mm/y 2* and tti
Use a large database block size
Because the database block size is fixed at database creation, this is one decision that is important to get right the first time. For file system based datafiles, without direct I/O, the database block size must match the file system buffer size exactly, as explained here. However, if your database is raw, or if direct I/O is available, then you have the luxury of choosing a larger database block
Oracle の B*Tree インデックスの内部構造についてお勉強中（その３）
このリーフは必ずソートされて状態で管理されているがために、データの挿入、更新でリーフ分割によるインデックスのパフォーマンス劣化が発生するわけです。また、この解析からわかるように同一ブロック内もしくは近くのブロック内には第一キーが同じものがかたまって存在します。それゆえ、複合索引の場合は、第一キーのみによる SELECT 文でも、効率よくアクセスが可能（ INDEX RANGE SCAN ）で、逆に第二キーのみによる SELECT 文では、いくつものブロックを読む（ INDEX SKIP SCAN もしくは TABE FULL SCAN ）必要がでてくるわけです。 見ての通り、同一ブロック内の第一キーの同一値がほぼ全て網羅されています。Oracle はブロック単位で I/O 管理されているため、上記の例だと where ID=1 のように第一キーの等価評価による絞り込みを行う場合、ブロックを
Oracle の B*Tree インデックスの内部構造についてお勉強中（その２）
まずは前エントリで書いた Oracle のインデックス構造図解を再掲から。 本題です。Oracle のインデックスの内容をダンプする TreeDump の使い方と解析方法について説明をします。これも定型文なので、覚えておいて損はないかと思います。特にインデックスに関して深追いするなら必須のテクニックです。参考にしたページは下記の２つです。 Bツリーインデックスに最高のパフォーマンスを（1/4） − ＠IT パフォーマンス劣化はインデックスのせいなのか!? をみっちり検証 − ＠IT 特に株式会社インサイトテクノロジーの記事が秀逸です。この会社の Oracle スキルは尋常じゃぁありませんね。お仕事で見ている DB システムでは、同社が開発している Performance Insight というツールを導入して Oracle を運用管理しているのですが、パフォーマンスチューニング、障害監視な
Bツリーインデックスに最高のパフォーマンスを
Bツリーインデックスの問題 更新が頻繁に起きるとどのようにインデックスが変化していくか、図5で見ていきましょう。 図5 更新が頻繁に起こるときのBツリーインデックスの変化 ※DBAの値として記載している「DBA1…」はアドレスを示す例である ※ROWIDの値として記載している「ROWID1…」はアドレスを示す例である 新規データである「18」は、空きリーフ行が存在していて既存データ「20」が入っているリーフではなく、リーフ分割し新規リーフ内に挿入されます。更新前データ「50」が存在していたリーフは完全に空きリーフとなってしまいます。このような更新が繰り返されると、リーフが散在することになります。前項で削除されたリーフ行の割合を見たとおり、削除されたリーフ行が大量に発生していくことになります。 Bツリーインデックスの問題解決 削除されたリーフ行が大量にあるインデックスを使って、SQLによる検
インデックス分割ツール IndexSplitter (3.0) | 関口宏司のLuceneブログ
一定期間更新がないため広告を表示しています
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.1 MySQL のインデックスの使用の仕組み
インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。 インデックスがないと、MySQL は関連する行を見つけるために、先頭行から始めてテーブル全体を読み取る必要があります。 テーブルが大きいほど、このコストが大きくなります。 テーブルに問題のカラムのインデックスが含まれている場合、MySQL はすべてのデータを調べる必要なく、データファイルの途中のシークする位置をすばやく特定できます。 これはすべての行を順次読み取るよりはるかに高速です。 ほとんどの MySQL インデックス (PRIMARY KEY、UNIQUE、INDEX、および FULLTEXT) は B ツリーに格納されます。 例外: 空間データ型のインデックスは R ツリーを使用します。MEMORY テーブルはハッシュインデックスもサポートします。InnoDB は FULLTEXT インデックスの逆のリスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nmslib/python_bindings at master · nmslib/nmslib
More mastering the art of indexing
GitHub - daniel-nichter/hackmysql.com: Deprecated tools from HackMySQL.com
http://www.res-system.com/item/550
http://tech.blog.klab.org/archives/50253823.html
http://tech.blog.klab.org/archives/50277350.html