diff options
| -rw-r--r-- | ydb/docs/ru/core/best_practices/_includes/schema_design.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/ydb/docs/ru/core/best_practices/_includes/schema_design.md b/ydb/docs/ru/core/best_practices/_includes/schema_design.md index 7abc13aad73..172c7d4612f 100644 --- a/ydb/docs/ru/core/best_practices/_includes/schema_design.md +++ b/ydb/docs/ru/core/best_practices/_includes/schema_design.md @@ -31,10 +31,10 @@ Рассмотрим таблицу со схемой ```( timestamp, userid, userevent, PRIMARY KEY (userid, timestamp) )```. В качестве всего первичного ключа или его первой компоненты можно использовать хеш от исходного ключа, например так: ``` -( HASH(timestamp, userid), timestamp, userid, userevent, PRIMARY KEY (HASH(timestamp, userid), userid, timestamp) ) +( HASH(timestamp, userid), timestamp, userid, userevent, PRIMARY KEY (HASH(userid), userid, timestamp) ) ``` -При правильном выборе функции хеширования строки будут распределены достаточно равномерно по всему пространству ключей, что в приведет к равномерной нагрузке на систему. При этом, наличие полей ```userid, timestamp``` в составе ключа после ```HASH(timestamp, userid)``` сохраняет локальность и сортировку данных по времени для конкретного пользователя. +При правильном выборе функции хеширования строки будут распределены достаточно равномерно по всему пространству ключей, что в приведет к равномерной нагрузке на систему. При этом, наличие полей ```userid, timestamp``` в составе ключа после ```HASH(userid)``` сохраняет локальность и сортировку данных по времени для конкретного пользователя. ### Уменьшение количества партиций, затрагиваемых в одном запросе {#decrease-shards} |