@@ -53,11 +53,60 @@ crud.unflatten_rows(res.rows, res.metadata)
53
53
** Notes:**
54
54
55
55
* A space should have a format.
56
- * By default, ` bucket_id ` is computed as ` vshard.router.bucket_id_strcrc32(key) ` ,
57
- where ` key ` is the primary key value.
58
- Custom bucket ID can be specified as ` opts.bucket_id ` for each operation.
59
- For operations that accepts tuple/object bucket ID can be specified as
60
- tuple/object field as well as ` opts.bucket_id ` value.
56
+
57
+ ** Sharding key and bucket id calculation**
58
+
59
+ * Sharding key* is a set of tuple field values used for calculation * bucket ID* .
60
+ * Sharding key definition* is a set of tuple field names that describe what
61
+ tuple field should be a part of sharding key. * Bucket ID* determines which
62
+ replicaset stores certain data. Function that used for bucket ID calculation is
63
+ named * sharding function* .
64
+
65
+ By default CRUD calculates bucket ID using primary key and a function
66
+ ` vshard.router.bucket_id_strcrc32(key) ` , it happen automatically and doesn't
67
+ require any actions from user side. User can calculate bucket ID on outside and
68
+ pass it as an option to CRUD methods that accepts tuple or object (see option
69
+ ` bucket_id ` below).
70
+
71
+ Starting from 0.10.0 users who don't want to use primary key as a sharding key
72
+ may set custom sharding key definition as a part of [ DDL
73
+ schema] ( https://github.com/tarantool/ddl#input-data-format ) or insert manually
74
+ to the space ` _ddl_sharding_key ` (for both cases consider a DDL module
75
+ documentation). As soon as sharding key for a certain space is available in
76
+ ` _ddl_sharding_key ` space CRUD will use it for bucket ID calculation
77
+ automatically. Note that CRUD methods ` delete() ` , ` get() ` and ` update() `
78
+ requires that sharding key must be a part of primary key.
79
+
80
+ Table below describe what operations supports custom sharding key:
81
+
82
+ | CRUD method | Sharding key support |
83
+ | -------------------------------- | -------------------------- |
84
+ | ` get() ` | Yes |
85
+ | ` insert() ` / ` insert_object() ` | Yes |
86
+ | ` delete() ` | Yes |
87
+ | ` replace() ` / ` replace_object() ` | Yes |
88
+ | ` upsert() ` / ` upsert_object() ` | Yes |
89
+ | ` select() ` / ` pairs() ` | Yes |
90
+ | ` update() ` | Yes |
91
+ | ` upsert() ` / ` upsert_object() ` | Yes |
92
+ | ` replace() / replace_object() ` | Yes |
93
+ | ` min() ` / ` max() ` | No (not required) |
94
+ | ` cut_rows() ` / ` cut_objects() ` | No (not required) |
95
+ | ` truncate() ` | No (not required) |
96
+ | ` len() ` | No (not required) |
97
+
98
+ Current limitations for using custom sharding key:
99
+
100
+ - It's not possible to update sharding keys automatically when schema is
101
+ updated on storages, see [ #212 ] ( https://github.com/tarantool/crud/issues/212 ) .
102
+ However it is possible to do it manually with
103
+ ` require('crud.sharding_key').update_sharding_keys_cache() ` .
104
+ - CRUD select may lead map reduce in some cases, see
105
+ [ #213 ] ( https://github.com/tarantool/crud/issues/213 ) .
106
+ - No support of JSON path for sharding key, see
107
+ [ #219 ] ( https://github.com/tarantool/crud/issues/219 ) .
108
+ - ` primary_index_fieldno_map ` is not cached, see
109
+ [ #243 ] ( https://github.com/tarantool/crud/issues/243 ) .
61
110
62
111
### Insert
63
112
0 commit comments