Ключ осколки (MongoDB) для большого количества документов

Я разрабатываю веб-приложение, в котором пользователи будут загружать большое количество документов в систему, и в документах будут выполняться различные типы операций, включая агрегацию. Однако количество документов, загружаемых каждым пользователем, варьируется в широких пределах: некоторые могут загружать десятки документов, а некоторые могут загружать миллион документов.Ключ осколки (MongoDB) для большого количества документов

документы выглядят примерно так:

doc{ 
    _id: <self generated UUID>, 
    uid: <id of user who uploaded the document>, 
    ctime: <creation timestamp>, 
    .... 
     <other attributes, etc> 
    .... 
}

Теперь вот проблема в выборе ключа осколка:
1. Если я выбираю UUID в качестве ключа шарда, документы, загруженные тем же пользователем, вряд ли для того, чтобы оказаться в одном и том же порядке, и операции агрегации будут дорогостоящими.
2. Если я использую uid в качестве ключа осколка, тогда данные, хранящиеся в осколках, не будут четными.

Может ли кто-нибудь предложить, который является лучшим способом достичь этого?

Я очень новичок в разделении и очертаниях, и мои исследования в google, а также переполнение стека ничего не дали. При необходимости я могу изменить схему документов, поскольку проект все еще находится на стадии проектирования.

источник

2012-06-28 Jit B

Как вы хотите запрашивать данные? –

Это лучшее руководство, я видел на выбор ключа осколка: http://www.kchodorow.com/blog/2011/01/04/how-to-choose-a-shard-key-the-card-game/

Вы должны решить, как вы хотите, чтобы запросить данные. Возможно, комбинация uid и ctime даст хороший ключ осколка, но я не уверен, что это вызовет у вас горе во время запросов, поскольку вы не получили большого понимания того, как вы планируете запрашивать.

источник

2012-06-28 19:40:25

Спасибо за ссылку. Я иду через него сейчас, но это кажется немного запутанным. Я хочу запросить данные на основе UUID или комбинации (uid, parentid). Это все - в любом случае остальные поля меняются от документа к документу. FYI parent - это идентификатор родительского документа (например, страницы wordpress). Однако я буду запускать некоторые функции, такие как count_child_docs (parentid), которые будут рекурсивно сканировать «дерево». Вот почему я хочу как можно больше данных об одном осколке. Я думал о создании ключа (uid, parentid), но parentid может измениться, поэтому обновления могут быть дорогостоящими. –

Я снова попал в статью и сыграл с демонстрацией, предоставленной там. Я думаю, что лучшим ключом для моего дела будет (uid, UUID). Но я думаю, вам нужно будет уменьшить размер куска, чтобы оптимизировать для пользователя с очень низким количеством загрузок. @ wes-freeman: Как вы думаете? –

Ваша идея звучит неплохо. Определенно стоит дать ему выстрел в тест - убедитесь, что вы тестируете вставки (чтобы убедиться, что они не все идут на один и тот же осколок) и запросы (чтобы убедиться, что они в основном идут на 1-2 осколка и избегают много слияние). Я не думаю, что вам нужно держать размер куска маленьким. Могут ли ваши запросы uuid включать uid, или это неизвестно? –

Вы можете прочитать больше о выборе shardkey и масштабирование

1] книга Кристины Chodrow в "Scaling MongoDB" http://shop.oreilly.com/product/0636920018308.do

2] презентационный Антуана Girbal на шардинге Best Practices http://www.10gen.com/presentations/MongoNYC-2012/Sharding-Best-Practices-Advanced

источник

2012-10-23 11:33:54 frisky

Ключ осколки (MongoDB) для большого количества документов

ответ

Смежные вопросы