-
Notifications
You must be signed in to change notification settings - Fork 25
Feature: merge tables #204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 26 commits
9ad650c
943401f
87a4d06
5e29c6d
678caf0
50235d0
bb9558f
638b511
2dfed3d
3a64e60
5b93586
9b3c243
0530517
4b7b046
d0ec2e0
dcf303d
bc77027
b5869c9
c763062
e6341ad
bc58223
c3d7dc7
721e62c
6cfc37b
b311a1a
8f16439
04a971a
239a926
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -57,6 +57,40 @@ Transactions for each shard are replicated independently. | |
| Currently transaction can only modify tables in one shard. | ||
| Usually it is a good idea to group all tables that belong to a particular OTP application in one shard. | ||
|
|
||
| ## Merge tables | ||
|
|
||
| Tables where every entry includes ID of the node that created the record are called "merge tables". | ||
|
|
||
| How to create such tables: | ||
|
|
||
| ```erlang | ||
| mria:create_table(my_merged, [ {type, ordered_set} | ||
| , {rlog_shard, shard_id} | ||
| , {node_pattern, #my_record{key = {'_', '$1'}, _ = '_'}} | ||
| , {merge_table, true} | ||
| , {auto_clean, boolean()} %% Optional, default = false | ||
| ]) | ||
| ``` | ||
|
|
||
| 1. All tables in the shard must have `merge_table` property = `true`. | ||
| 2. `node_pattern` property is mandatory. | ||
| Its value must be an ets match pattern with one free variable: `'$1'`. | ||
| Mria verifies that this value is set to `node()` for each record. | ||
| 3. `auto_clean` is an optional property that allows a downstream node to clean all records owned by an upstream node when the latter disconnects. | ||
|
|
||
| Unlike regular tables, | ||
| both cores and replicants use local writes to update such tables. | ||
| In a clustered setup, | ||
| the contents of the merge table consist of records from all reachable peer nodes. | ||
| Records from remote nodes are read-only. | ||
|
|
||
|
Comment on lines
+75
to
+93
|
||
| ### Limitations | ||
|
|
||
| - Only `ram_copies` storage is currently supported. | ||
|
|
||
| - Importing of data from remote nodes is always done using dirty operations. | ||
| `mria:transaction` and `mria:ro_transaction` interfaces do not guarantee atomicity when reading data from the remote nodes. | ||
|
|
||
| ## Enabling RLOG in your application | ||
|
|
||
| It is important to make the application code compatible with the RLOG feature by using the correct APIs. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,7 +19,8 @@ | |
| gen_rpc, | ||
| replayq, | ||
| snabbkaffe, | ||
| optvar | ||
| optvar, | ||
| gproc | ||
| ]}, | ||
| {modules, []}, | ||
| {licenses, ["Apache 2.0"]}, | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.