Database Reference
In-Depth Information
Of course, we must also support
removing
users from circles:
def
def
uncircle_user
(
self
,
other
,
circle
):
circles_path
=
'circles.
%s
.
%s
'
%
(
circle
,
other
[
'_id'
])
db
.
social
.
user
.
update
(
{
'_id'
:
self
[
'_id'
] },
{
'$unset'
: {
circles_path
:
1
} })
follower_circles
=
'followers.
%s
.circles'
%
self
[
'_id'
]
db
.
social
.
user
.
update
(
{
'_id'
:
other
[
'_id'
] },
{
'$pull'
: {
follower_circles
:
circle
} })
# Special case -- 'other' is completely uncircled
db
.
social
.
user
.
update
(
{
'_id'
:
other
[
'_id'
],
follower_circles
: {
'$size'
:
0
} },
{
'$unset'
: {
'followers.'
+
self
[
'_id'
} }})
In both the circling and uncircling cases, the
_id
is included in the update queries, so no addi-
tional indexes are required.
Sharding
In order to scale beyond the capacity of a single replica set, we need to shard each of the
collections mentioned previously. Since the
social.user
,
social.wall
, and
social.news
collections contain documents that are specific to a given user, the user's
_id
field is an ap-
propriate shard key:
>>>
>>>
db
.
command
(
'shardcollection'
,
'dbname.social.user'
, {
...
...
'key'
: {
'_id'
:
1
} } )
{ "collectionsharded": "dbname.social.user", "ok": 1 }
>>>
>>>
db
.
command
(
'shardcollection'
,
'dbname.social.wall'
, {
...
...
'key'
: {
'user_id'
:
1
} } )
{ "collectionsharded": "dbname.social.wall", "ok": 1 }
>>>
>>>
db
.
command
(
'shardcollection'
,
'dbname.social.news'
, {
...
...
'key'
: {
'user_id'
:
1
} } )
{ "collectionsharded": "dbname.social.news", "ok": 1 }
It turns out that using the posting user's
_id
is actually
not
the best choice for a shard key for
social.post
. This is due to the fact that queries and updates to this table are done using the
_id
field, and sharding on
by.id
, while tempting, would require these updates to be
broad-
