Что именно можно хранить в NOSQL базах данных?

Question

[medbrat13]

Всем привет. Разрабатывая очередной свой проект, я призадумался, что пора попробовать что-то новое, окромя стандартного стека LNMP. Добавились несколько типов данных (лайки, чаты), насчет которых я не уверен. Поэтому прошу знающих, гур и всех тех, кто разбирается в NoSQL ответить на один вопрос: что можно хранить в nosql базах данных?

Я немного почитал про отличия и то, какие типы данных можно хранить, но мне не понятно, о каких именно данных идет речь. Что за документы имеются ввиду в доке MongoDB?
А что, например, можно хранить в Redis, Cassandra?

Немного перефразировать вопрос можно так: зачем мне может понадобиться nosql-база? Для какой цели конкретно?

Answer 1

[Saboteur]

Все можно хранить. Но nosql базы бывают разные, заточенные под разные задачи.
Надо уточнять для чего вам база.
memcached, например, тоже можно сказать что это Nosql база. Используется для ускорения доступа.

А mongodb это скорее объекты, а не документы.

Например, вам нужно хранить такие поля
имя, фамилия, телефон
имя, адрес
фамилия, инициалы, год рождения
телефон, адрес, описание

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

А в mongodb,например, можно просто хранить объекты как есть:
Имя: Вася, Фамилия: Пупкин, телефон 02
Имя: Петя, адрес: "Останкино, 1"
Имя: Вера, инициалы: "В.Б.", год рождения: нескажу
телефон: "красненький", адрес: "Останкино, 1", описание: "что-то где-то"

И каждый объект хранится ровно с теми полями, которые в нем есть.
При этом поля могут быть разного типа.
При этом можно нормально пользоваться запросами и разными функциями.

Да, тут нет joins, зато монго оптимизирована для работы с подобным и размеры коллекций ее не слишком будут смущать.

Comments

[d'Ivan]

Альтернативой концепции schema-less Mongodb в реляционных СУБД является колонка типа JSON.

[Saboteur]

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

[d'Ivan]

Не работал с Mongodb плотно, может чего-то не знаю. Я помню, что нужно было создавать индексы на поля вручную, как и в РСУБД.

[Saboteur]

Скажем так, для своей задачи - реляционная база данных архитектурно рассчитана на работу с таблицами, и лочит их обычно по таблицам или по столбцам.
В той же монги такого понятия нет, оверхеда по этому поводу тоже нет.
Поэтому при работе со структурой типа объект, монго будет работать быстрее.
Естественно что эта скорость будет заметна на больших объемах. Мегабайты можно в любой базе примерно со одинаковой скоростью обрабатывать. Но когда счет идет на сотни гигабайт - тут можно подобрать носкл базу, которая лучше подходит под задачи.

[d'Ivan]

Поэтому при работе со структурой типа объект, монго будет работать быстрее.

А на примере двух запросов в обеих СУБД?

[Saboteur]

Роман Мирр, ну это не вопрос. Это задача поднять две базы, забить их хотя бы 100-гбайтными данными, при этом сопоставимую структуру и мерять. Уж цифры не приведу.

Благодаря индексам, SQL базы могут делать быстрые выборки. Но постройка индексов обходится недешево, и там где sql быстрее выберет, монго НАМНОГО быстрее обновит или вставит, а это бывает зачастую важнее - успеть быстро сохранить данные.

SQL имеет преимущество в join, это мощная штука.

Answer 2

[d'Ivan]

NoSQL бывают разных видов:

• ключ-значение
  Могут применяться для получения сериализованного объекта по строковому ключу. Могут присутствовать операции над списками, счетчики и пр. Memcached, Redis, Tarantool - работают полностью в RAM, поэтому особо не разгуляться.
  Есть персистентные: RocksDB, BerkeleyDB, ...
  
• Графовые
  Удобно использовать когда в случаях, если в SQL запросах есть много JOIN и это все медленно работает из-за множества взаимосвязанных моделей
  
• документо-ориентированные
  Когда есть необходимость работать со сложными структурами данных и в них нужно обновлять какие-то поля.
  Saboteur в целом описал преимущества.
  Но не испробовав тип JSON в РСУБД, я бы не стал сходу менять на документо-ориентированную.
  
  
• колоночные
  Хороши для аналитических запросов
  https://m.habr.com/ru/post/95181/
  
  

https://database.guide/nosql-database-types/