diff options
| author | Bryan Newbold <bnewbold@robocracy.org> | 2019-01-04 17:41:27 -0800 |
|---|---|---|
| committer | Bryan Newbold <bnewbold@robocracy.org> | 2019-01-04 17:41:27 -0800 |
| commit | 084e476957ce80b456dcf0575de4efc7331d34f9 (patch) | |
| tree | 5377ef32c140ef6a0b73d67296eeacf17edcabc9 /notes/thoughts.txt | |
| parent | d7b0a156d2a3a21e2bf5afc3e4b97e7cf1044248 (diff) | |
| download | fatcat-084e476957ce80b456dcf0575de4efc7331d34f9.tar.gz fatcat-084e476957ce80b456dcf0575de4efc7331d34f9.zip | |
clean up notes a tiny bit
Diffstat (limited to 'notes/thoughts.txt')
| -rw-r--r-- | notes/thoughts.txt | 32 |
1 files changed, 0 insertions, 32 deletions
diff --git a/notes/thoughts.txt b/notes/thoughts.txt deleted file mode 100644 index c01c0d37..00000000 --- a/notes/thoughts.txt +++ /dev/null @@ -1,32 +0,0 @@ - -Instead of having a separate id pointer table, could have an extra "mutable" -public ID column (unique, indexed) on entity rows. Backend would ensure the -right thing happens. Changelog tables (or special redirect/deletion tables) -would record changes and be "fallen through" to. - -Instead of having merge redirects, could just point all identifiers to the same -revision (and update them all in the future). Don't need to recurse! Need to -keep this forever though, could scale badly if "aggregations" get merged. - -Redirections of redirections should probably simply be disallowed. - -"Deletion" is really just pointing to a special or null entity. - -Trade-off: easy querying for common case (wanting "active" rows) vs. robust -handling of redirects (likely to be pretty common). Also, having UUID handling -across more than one table. - -## Scaling database - -Two scaling issues: size of database due to edits (likely billions of rows) and -desire to do complex queries/reports ("analytics"). The later is probably not a -concern, and could be handled by dumping and working on a cluster (or secondary -views, etc). So just a distraction? Simpler to have all rolled up. - -Cockroach is postgres-like; might be able to use that for HA and scaling? -Bottlenecks are probably complex joins (mitigated by "interleave"?) and bulk -import performance (one-time?). - -Using elastic for most (eg, non-logged-in) views could keep things fast. - -Cockroach seems more resourced/polished than TiDB? |