Sharding by ObjectID, czy to właściwa droga?

Question

Jestem tak, jak wielu innych myśli o poprawnym podejściu do moich kolekcji w Mongo. Główne pytanie brzmi: w jaki sposób działa automatyczne dzielenie?

Oficjalny dokument mówi: "MongoDB skaluje się w poziomie poprzez architekturę automatycznego dzielenia (partycjonowania)" i "Aby podzielić kolekcję, określamy wzór klucza odłamkowego". z uwagą "Ważne jest, aby wybrać odpowiedni klucz odłamu do kolekcji" :).
http://www.mongodb.org/display/DOCS/Sharding+Introduction#ShardingIntroduction-ShardKeys
http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key

Nasuwa się pytanie - "czy to prawy klawisz" (sharding przez objectID)?

db.runCommand({ shardcollection : "test", key : { _id : 1 }}) 

Co dzieje się wewnętrznie w Mongo? Jak Mongo podzieli dane na porcje w tym przypadku? Zakładając, że początkowo mam 10 milionów rekordów z 2 serwerami odłamkowymi - co dzieje się po stronie Mongo, kiedy chciałbym dodać jeszcze 2 serwer odłamków, gdy kolekcja osiągnie 20 milionów rekordów? Nie mogłem znaleźć takiego poziomu szczegółów w źródłach związanych z Mongo.

Biorąc pod uwagę charakter losowy wygenerowany automatycznie _id i jego struktura,

... http://www.mongodb.org/display/DOCS/Object+IDs ...

chciałbym shard przez najmniej znaczący bajt (zlecenia RTL) z kawałkami podzielona przez wartość 2-3 bajty - w ten sposób można łatwo odstąpić od 2^N serwerów odłamkowych - 2, 4, 8, .., 256 serwerów odłamkowych z mniej lub bardziej równomiernym obciążeniem każdego fragmentu i minimalną wymaganą konfiguracją. O ile rozumiem, Mongo obsługuje tylko sharding/chunking według ściśle określonych zakresów i że mój pomysł nie zadziała. Czy to prawda?

Answer 1

Nowością w wersji 2.4 jest to, że indeks Hashed jest obsługiwany i może być używany jako Shard Keys. Tak więc odpowiedź na twoje główne pytanie "Sharding by ObjectID, czy to właściwa droga?" może być teraz tak!

Więcej referencje są w oficjalnych dokumentów:

hashed Shard Keys

http://docs.mongodb.org/manual/core/sharded-cluster-internals/#hashed-shard-keys

hashed Index

http://docs.mongodb.org/manual/core/indexes/#hashed-index

Answer 2

Generalnie nie jest dobrym pomysłem użycie domyślnego identyfikatora obiektu jako klucza kryptograficznego, ponieważ ma wbudowany znacznik czasu i monotonicznie rośnie w czasie. Może to działać dobrze, jeśli wykonujesz wiele aktualizacji, tak aby dotykały starych i nowych dokumentów w równomierny sposób. Jednak jest to naprawdę zła wiadomość, jeśli twoja aplikacja jest ciężka na wstawki, ponieważ większość twoich zapisów trafi do jednego fragmentu. Dzieje się tak, ponieważ zapisy trafią do fragmentu będącego właścicielem kawałka [nearCurrentTimestamp -> infinity].

Każdy monitor mongos zapisuje ruch do odłamków i używa bardzo prostego heurystyki do określenia, czy porcja stała się zbyt duża i musi zostać podzielona (rozmiar progu można skonfigurować za pomocą chunkSize).

Po dodaniu nowego odłamka do klastra, wyważarka (http://www.mongodb.org/display/DOCS/Sharding+Administration#ShardingAdministration-Balancing) zobaczy brak równowagi kawałka i rozpocznie migrację porcji do nowych odłamków.

Mongo obsługuje sharding oparty na odległościach, co jednak nie oznacza, że ​​zakresy są stałe, ponieważ kawałki mogą być podzielone na mniejsze zakresy i przemieszczane wokół klastra w czasie.