Speeding up inserts in blob storage

[aravindsrinivasan]

I'm finding that inserting data into a table is quite slow when it's backed by blob storage (Azure blob storage in my case). I've tried:

• Single insert of entire dataset at table creation time
• Batched insert (Table.add) post table creation
• Multi-threaded insert (is the Table object thread safe?)

All of them seem to be equally slow. What's the best way to speed this up?

[wjones127]

Hi @aravindsrinivasan, thanks for trying out LanceDB.

The methods you are using to insert all seem reasonable. I don't think you are using LanceDB in a way that would make it slow.

I think the most productive thing you could do here is quantify how fast you are able to write on Azure with LanceDB vs some other library. For example, you can time how long it takes to insert 100,000 vectors. Then if you vectors are say 1024 dimensions, then you can estimate the data you wrote is about 100,000 * 1024 dim * 4 bytes ~= 400MB. (If there are other columns, you will have to account for the size of those as well.) Divide that by the number of seconds it took and you get an estimate of how much throughput you are getting from writing with LanceDB. For comparison, it would be useful to know how slow that is compared to using the Azure CLI to upload a file directly (like this).

[aravindsrinivasan]

@wjones127 thank you for the response. Turns out my internet was the culprit -- plugging in the ethernet cable made it 10x faster.

Generally speaking, what has your team found to be the fastest way to upload into an index? Parallelization didn't seem to work as well as sequential inserts with a large batch size. This feels counter intuitive to me so curious if this is to be expected

[wjones127]

Parallelization didn't seem to work as well as sequential inserts with a large batch size. This feels counter intuitive to me so curious if this is to be expected

Writing in batches is much more efficient in LanceDB. You could write batches of 10-100k in parallel, and that might work well. But writing <1k rows in parallel will perform poorly and produce a bad table layout, which would need to be fixed by calling compact_files.

[aravindsrinivasan]

Thanks @wjones127.