Кто знает замену MongoDB?

Question

[recloudor]

В mongoDB двухуровневая модель организации данных: коллекции > JSON документы.
Это ок для небольших ресурсов, скажем, для блога, где идут только посты.
А если у каждого пользователя свои посты? Все посты пихать в одну коллекцию или в один массив? Если нужно реализовать что-то более менее нормальное, приходится писать костыль на костыле.
Нужна хотя бы трёхуровневая модель.

Вставлять документ в коллекцию можно только в конец.
К примеру, вставляю пост в коллекцию, и мне нужно взять посты по дате добавления.
Можно конечно по поиску всё это сделать, либо же написать костыль со skip, limit.

Если бы можно было всё вставлять в начало коллекции, было бы намного проще.

MySQL? Potgresql? REDIS? Любая другая?
Подскажите, пожалуйста, кто знает лучшую альтернативу.

Comments

[Дмитрий]

Зачем использовать монго для чего она не предназначена ?

Answer 1

[Александр Аксентьев]

В чем проблема-то? Вы что-то не то делаете, и проблема не в монго, а как говорится в прокладке между стулом и монитором.

коллекция юзеры -> id, email, password
коллекция посты -> id, user_id, post_content

var user = users.find(1);
var posts_by_user = posts.find({ user_id: user._id });

Comments

[recloudor]

Коллекция посты пользователей -> id username -> 1000 постов в одном массиве?

[Александр Аксентьев]

recloudor: а в чем проблема с количеством постов? skip/limit в помощь. Почему стандартная пагинация, которая есть в любой БД это костыль?

[recloudor]

Александр Аксентьев: skip лимит, это для документов в коллекции. Мне что для каждого пользователя коллекцию создавать? Понятно же что это не для этого создано

[Александр Аксентьев]

recloudor: там у вас одна коллекция с постами всех пользователей, только у каждого поста в коллекции есть user_Id которому принадлежит пост. Делаете выборку по user_id и лимиты. На выходе пагинация по постам одного пользователя. Вы что-то не понимаете видимо.

[recloudor]

Александр Аксентьев: А это нормально, то что все посты в одной коллекции? Если постов 100к?

[Александр Аксентьев]

recloudor: а если 200к?) Вы пользовались mysql или другой реляционной базой? Там вообще миллионы лежат. В много тоже можно миллионы хранить, но это уже совсем другая история.

[recloudor]

Александр Аксентьев: Ладно. Наверно на монге останусь

[recloudor]

Александр Аксентьев: Спасибо

Answer 2

[Алексей Черемисин]

Ну могу посоветовать, как альтернативу, Elasticsearch. Но, боюсь, она вам еще больше не понравится, хотя на мой взгляд очень даже. По моему, у вас просто что-то не то с организацией данных, да и какие проблемы выбрать последние 10 по дате? Это же обыкновенный поиск по индексу, все должно очень быстро работать.

PS.
recloudor: И да, как альтернативу сортировке, предлагаю использовать для этого REDIS. При добавлении поста в монгу, добавлять id поста дополнительно и в list REDIS.
rpush user_posts:id1234 321
Из редиса доставать ОДНИМ запросом идентификаторы последних n-записей
lrange user_posts:id1234 10 -1

Comments

[recloudor]

Почему всё не может быть проще? Можно по timestamp только поиск сделать же

[Алексей Черемисин]

это сложно?!
db.foo.find().sort({_id:1}).limit(50);

[Алексей Черемисин]

recloudor: Я так понимаю, вас смущает сортировка? Ну так вы плотно не работали с реляцилонными базами данных!!! Там данные вообще-то не всегда база данных отдает последовательно! Особенно если она в кластере, особенно если перед эти сделать удаление кучи записей!
Как пример, добавляет тыщ сто записей, удаляем из них 50 тыщ, пишем снова. Многие записи попадают на освободившиеся пустые места. И так повторяем раз 10-15. Делаем выборку без сортировки и удивляемся :-)

[Алексей Черемисин]

recloudor: И да, как альтернативу сортировке, предлагаю использовать для этого REDIS. При добавлении поста в монгу, добавлять id поста дополнительно и в list REDIS.
rpush user_posts:id1234 321
Из редиса доставать ОДНИМ запросом идентификаторы последних n-записей
lrange user_posts:id1234 10 -1

Answer 3

[index0h]

А если у каждого пользователя свои посты? Все посты пихать в одну коллекцию или в один массив?

Почему же? Посты в одной коллекции - это вполне ок. Юзвери в другой коллекции это тоже ок.

Если нужно реализовать что-то более менее нормальное, приходится писать костыль на костыле.

Не пишите костыль на костыле, сначала спроектируйте БД так, что бы избежать этого.

Вставлять документ в коллекцию можно только в конец.

И в чем проблема (я вам по секрету: так происходит практически в каждой СУБД)? Какая вам разница, где оно будет вставляться? Делайте выборку с сортировкой.

К примеру, вставляю пост в коллекцию, и мне нужно взять посты по дате добавления.

RTFM

написать костыль со skip, limit.

Какой нехороший человек вам такую дичь сказал? Если у вас записей 10кк, у вас просто оперативки не хватит делать подобные выборки без skip/limit.

Если бы можно было всё вставлять в начало коллекции, было бы намного проще.

Вы пытаетесь вырвать гланды через анус, причем другого человека.

Подскажите, пожалуйста, кто знает лучшую альтернативу.

Еще раз, вы придумали проблему и пытаетесь ее героически решить, но проблема заключается в том, что вы не правильно используете средства предлагаемые mongo, и другая БД вам ни как не поможет

Comments

[index0h]

Александр
Связей будет по меньше, чем в реляционке, так как в документ можно запихнуть "embedded" данные, относящихся конкретно к нему (без фанатизма конечно же). В случае реляционки ему потребуется больше таблиц и больше джойнов.

Я не спорю, под его кейс вероятно реляционка подойдет лучше, но проблемы, которые он выдвинул решаются принципиально по другому.
В том же MySQL что вставка будет в начало таблицы? Может limit/offset использовать не придется?

Answer 4

[Фаёзжон Бердиев]

Чем Вас не устраивает MongoDB?
Мы как то делали сервис realtime на nodejs loopback + mongoDB
Много пользователей, миллионы записей, более 6000 запросов в секунду. И все летает

Comments

[recloudor]

А системные характеристики какие?

[Фаёзжон Бердиев]

recloudor: У нас на Амазоне, вроде оперативы на 2 гига брали с увеличением до 6 в пик

Answer 5

[sim3x]

Potgresql