Skip to content
This repository was archived by the owner on Apr 15, 2022. It is now read-only.

Support SQLite as default datastore #27

Open
milton0825 opened this issue Jan 1, 2017 · 4 comments
Open

Support SQLite as default datastore #27

milton0825 opened this issue Jan 1, 2017 · 4 comments
Assignees

Comments

@milton0825
Copy link
Owner

milton0825 commented Jan 1, 2017

Scope

In some scenarios, we want to use Plano as a standalone application without a remote database server (client/server). Plano should be able to work with an embedded database to store requests on local machine.

Note: SQLite will be the default data store.

@milton0825 milton0825 added this to the SQLite Support milestone Jan 1, 2017
@milton0825 milton0825 self-assigned this Jan 19, 2017
@milton0825
Copy link
Owner Author

https://www.draw.io/#DPlano_Sqlite_ER ER diagram.

@milton0825
Copy link
Owner Author

milton0825 commented Feb 8, 2017

Single table vs. multiple tables

Use multiple tables (normalized) Preferred

Pros

  • Normalized schema is more scalable and abstraction of data increases readability.
  • No duplicates. Save disk space.

Cons

  • Hard to achieve atomic read, write, update, and delete operations?
  • Higher read latency.

Use a single table (denormalized)

Pros

  • Lower read latency.

Cons

  • Duplicates. Duplicated payload will consume too much space.

@milton0825
Copy link
Owner Author

milton0825 commented Feb 8, 2017

How to guarantee atomicity when interacting with multiple tables?

Lock each request. You will have to hold the lock before read, update, and delete.

  • How to handle lock unavailability?
    • Throw exception when lock unavailable
    • Retry
  • Optimistic locking
  • Pessimistic locking

Transaction

  • read/write to multiple table in single transaction.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant