No content

Why Akavache is Fast: how not to use SQLite3 Paul Betts (@paulcbetts) 

No content

“An asynchronous, persistent key-value store” 

Dictionary 

What can we do with Byte Dictionaries? • Arbitrary objects via JSON.NET • Fetching and loading Images and URLs from the Internet • Storing and automatically encrypting User Credentials 

Akavache uses SQLite3 to store data sqlite> .schema CREATE TABLE "CacheElement"( "Key" varchar primary key not null , "TypeName" varchar , "Value" blob , "Expiration" bigint , "CreatedAt" bigint ); 

Akavache uses SQLite3 to store its data • Users anecdotally report that once they move to Akavache, they get a huge app speedup vs SQLite3 • Yet, Akavache is built on SQLite3 

??!?? 

I thought SQLite3 was Fast! 

SQLite3 is fast when you: • Use transactions properly • Access SQLite3 on a single thread • Prepare commands ahead-of-time 

SQLite3 is not fast when you: • Just issue commands (this means every command is a transaction) • Call into SQLite3 from a bunch of background threads at the same time 

Accidentally using SQLite3 is easy 

Accidentally using SQLite wrong is easy 1. Load Messages 2. Every message instantiates a MessageCellViewModel 3. MessageCellViewModel downloads avatar 4. Avatar gets saved in cache 

There is only one disk. 

Make SQLite3 faster, the easy way // NB: Setting journal_mode returns a row, nfi Connection.ExecuteScalar("PRAGMA journal_mode=WAL"); Connection.Execute("PRAGMA temp_store=MEMORY"); Connection.Execute("PRAGMA synchronous=OFF"); 

Make sure we prepare statements • Key-Value stores have pretty predictable query needs • Create them all on startup • Make sure to destroy them or you'll have problems! 

Make sure we prepare statements var result = (SQLite3.Result)raw.sqlite3_prepare_v2( conn.Handle, "INSERT OR REPLACE INTO CacheElement VALUES (?,?,?,?,?)", out insertOp); 

Make sure we prepare statements foreach (var v in insertList) { try { this.Checked(raw.sqlite3_bind_text(insertOp, 1, v.Key)); if (String.IsNullOrWhiteSpace(v.TypeName)) { this.Checked(raw.sqlite3_bind_null(insertOp, 2)); } else { this.Checked(raw.sqlite3_bind_text(insertOp, 2, v.TypeName)); } this.Checked(raw.sqlite3_bind_blob(insertOp, 3, v.Value)); this.Checked(raw.sqlite3_bind_int64(insertOp, 4, v.Expiration.Ticks)); this.Checked(raw.sqlite3_bind_int64(insertOp, 5, v.CreatedAt.Ticks)); this.Checked(raw.sqlite3_step(insertOp)); } finally { this.Checked(raw.sqlite3_reset(insertOp)); } } 

Use less transactions 

First, use transactions! 

First, Akavache added Bulk Operations • Bulk operations let us insert / lookup multiple keys at once • We can insert all of the keys in a single transaction • If one fails, we have to fail them all in a single transaction 

First, Akavache added Bulk Operations IDictionary Get( IEnumerable keys); void Insert( IDictionary keyValuePairs); 

Concurrency still not solved 

Use a Queue! 

Use a Queue! • Every Akavache cache gets a single dedicated worker thread • That thread is the only thread to touch SQLite3 and processes items off the Queue • The queue is a list of "Operation to run + TaskCompletionSource to notify" • Bingo Bango, no concurrency problems 

The Power of TaskCompletionSource • Tasks don't have to have an associated thread running • Tasks != Threads! • They're really just a box for a future value 

The Power of TaskCompletionSource var tcs = new TaskCompletionSource(); return tcs.Task; // Later in another part of town... tcs.TrySetValue(true); // Or tcs.TrySetException(new Exception("Didn't Work!")); 

Use a (Blocking) Queue! 1. Try to fetch a single item and block if there is none 2. If we succeed, try to non-blocking fetch 31 more items at most 3. Create a transaction 4. Run all 32 commands 5. Drop the transaction, complete the associated Tasks 

No content

Let’s think about those 32 operations 

Operation Coalescing Write “bar” Read “foo” Read “bar” Read “baz” 

Operation Coalescing Write “bar” Read “foo” Read “bar” Read “baz” Just return the value we wrote in #1 

Operation Coalescing Read “bar” Delete “foo” Write “bar” 

Operation Coalescing Write “foo” Read “bar” Delete “foo” Just read bar, we don’t need to do the write at all 

Operation Coalescing Gone Wrong Read “bar” Delete “bar” Write “bar” 

Operation Coalescing Gone Wrong Write “foo” Failed Read “foo” Delete “foo” This Read should have worked, but incorrect coalescing made it fail! 

We must respect request ordering 

Key-Value Stores only have data dependencies between identical keys 

What Akavache actually does 1. Write “Bar” 2. Read “Foo” 3. Read “Bar” 4. Read “Foo” 5. Read “Baz” 6. Delete “Bamf” { Bar: [Write Bar, Read Bar], Foo: [Read Foo, Read Foo], Baz: [Read Baz], Bamf: [Invalidate Bamf] } Group by the key, but maintain original order 

What Akavache actually does { Bar: [Write Bar, Read Bar], Foo: [Read Foo, Read Foo], Baz: [Read Baz], Bamf: [Invalidate Bamf] } { Bar: [Write Bar, Read Bar], Foo: [Read Foo, Read Foo], Baz: [Read Baz], Bamf: [Invalidate Bamf] } Dedupe operations that do the same thing in a row 

What Akavache actually does { Bar: [Write Bar, Read Bar], Foo: [Read Foo], Baz: [Read Baz], Bamf: [Invalidate Bamf] } 1. Read [Foo, Baz] 2. Write [Bar] 3. Invalidate [Bamf] Remove the First item in every list, and try to smush them together 

What Akavache actually does { Bar: [Read Bar], Foo: [], Baz: [], Bamf: [] } 1. Read [Bar] Keep doing this, until we run out of items 

Final Result 1. Write "Bar" 2. Read "Foo" 3. Read "Bar" 4. Read "Foo" 5. Read "Baz" 6. Invalidate "Bamf" 1. Read [Foo, Baz] 2. Write [Bar] 3. Invalidate [Bamf] 4. Read [Bar] Six commands down to four, not bad! 

Some Graphs, for Science 

Some Graphs, for Science 

Your app takes advantage of bulk operations Automagically 

Your app takes advantage of transactions Automagically 

No content

Thanks! https://github.com/akavache/akavache @paulcbetts on Twitter / GitHub / etc