Категорично не съм съгласен с автора на избрания отговор, че Няма автоматично нарастване на id в MongoDB и има основателни причини . Не знаем причините, поради които 10gen не насърчава използването на автоматично увеличаващи се идентификатори. Това е спекулация. Мисля, че 10gen направи този избор, защото е просто по-лесно да се гарантира уникалността на 12-байтовите идентификатори в клъстерна среда. Това е решение по подразбиране, което пасва на повечето новодошли, следователно увеличава приемането на продукта, което е добре за бизнеса на 10gen.
Сега нека разкажа на всички за моя опит с ObjectIds в търговска среда.
Изграждам социална мрежа. Имаме приблизително 6 милиона потребители и всеки потребител има приблизително 20 приятели.
Сега си представете, че имаме колекция, която съхранява връзката между потребителите (кой кого следва). Изглежда така
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
на който имаме уникален съставен индекс {user_id, followee_id} . Можем да оценим размера на този индекс на 12*2*6M*20 =2GB. Това е индекс за бързо търсене на хора, които следвам. За бързо търсене на хора, които ме следват, имам нужда от обратен индекс. Това са още 2 GB.
И това е само началото. Трябва да нося тези документи за самоличност навсякъде. Имаме клъстер за дейности, където съхраняваме вашия канал за новини. Това е всяко събитие, което правите вие или вашите приятели. Представете си колко място заема.
И накрая един от нашите инженери взе несъзнателно решение и реши да съхранява препратките като низове, които представляват ObjectId, което удвоява размера му.
Какво се случва, ако даден индекс не се побира в RAM? Нищо добро, казва 10gen:
Когато индексът е твърде голям, за да се побере в RAM, MongoDB трябва да прочете индекса от диска, което е много по-бавна операция от четенето от RAM. Имайте предвид, че индексът се побира в RAM, когато вашият сървър има налична RAM за индекса, комбиниран с останалата част от работния набор.
Това означава, че четенията са бавни. Състезанието за заключване нараства. Пишенето също става по-бавно. Виждането на конкуренция за заключване в 80%-ниш вече не е шокиращо за мен.
Преди да се усетите, вие се оказахте с клъстер от 460 GB, който трябва да разделите на фрагменти и който е доста труден за манипулиране.
Facebook използва 64-bit long като user id :) Има причина за това. Можете да генерирате последователни идентификатори
- използване на Съвет на 10gen .
- използване на mysql като хранилище на броячи (ако се притеснявате за скоростта, погледнете handlersocket )
- използване на услуга за генериране на ID, която сте създали, или използване на нещо като Snowflake от Twitter.
Ето моят общ съвет към всички. Моля, направете данните си възможно най-малки. Когато пораснете, ще ви спести много безсънни нощи
