Ограничения шардинга зоны MongoDB - диапазоны тегов - PullRequest
Новая
       38

Ограничения шардинга зоны MongoDB - диапазоны тегов

0 голосов
/ 20 февраля 2020

Пн go DB поддерживает зонное разбиение (, как описано здесь ), связывая каждый шард с зоной sh.addShardTag(<shard name>, "ZONENAME") и применяя диапазоны чанков зоны, основываясь на значениях ключей шардирования с sh.addTagRange().

Вопросы:

  1. Существуют ли ограничения для sh.addTagRange()?
  2. Влияет ли большое количество таких диапазонов на производительность в любом случае? ?

  3. Можно ли, например, иметь 60000 диапазонов тегов или они рассчитаны на десятки?

    Не можете найти ответ в документации и форумах сообщества

, чтобы дать больше контекста по варианту использования:

например, в системе есть 10K учетных записей. Существует осколок inventory коллекции. Каждый элемент связан с inventoryClass (80К типов). Каждая учетная запись создает огромное количество предметов инвентаря (SKU) разных типов. В закрытом кластере 3 зоны. Осколок ключа: {accountId: 1, inventoryClass: 1}. Цель: иметь распределение зон для определенного списка учетных записей (домашняя зона определена для учетной записи вручную). Например, учетные записи 

[1, 294, 906847 ...] -> zone "A", 
[7879079, 852 ...] -> zone "B",
[3457, 45...] -> zone "C"

Сам документ элемента инвентаризации не содержит явного значения для сопоставления зоны (только неявное отношение accountId -> сопоставление зоны). Это означает, что каждые accontId данные должны быть связаны с зоной путем добавления соответствующего диапазона тегов с sh.addShardTag(), например, 

sh.addTagRange(
  "inventory",
  { "accountId" : 1, "inventoryClass" : MinKey },
  { "accountId" : 1, "inventoryClass" : MaxKey },
  "A")
....
sh.addTagRange(
  "inventory",
  { "accountId" : 294, "inventoryClass" : MinKey },
  { "accountId" : 294, "inventoryClass" : MaxKey },
  "A")

, так что 1 диапазон тегов на 1 учетную запись. И это приводит к диапазонам тегов == счетчик счетов

...