MongoDB. Впечатления?

 
0
 
NoSQL
ava
Wowa | 14.05.2010, 16:24
Кто-нить работал с MongoDB. Как впечатления?
Comments (18)
ava
gcc | 20.05.2010, 05:18 #
ну это типо как memchahe?

только после выключение компа memchahe свой кэш удаляет

тут можно сериализировать структуры/объекты (в json) исключительно по одному id и вставлять в эту базу

id | data

Цитата


....не требующая описания схемы таблиц...


http://ru.wikipedia.org/wiki/MongoDB

Цитата


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

ava
Wowa | 20.05.2010, 10:12 #
Цитата (gcc @ 20.5.2010, 04:18 findReferencedText)
только после выключение компа memchahe свой кэш удаляет

она сбрасывает каждую минуту на диск данные. Кроме того репликация используется.
ava
Wowa | 07.06.2010, 03:14 #
Сейчас переделываю в проекте модель и меняю SQL запросы на запросы к МонгоДБ. На моё удивление получаемый код выглядит даже немного более наглядно, чем SQL.
ava
gcc | 14.06.2010, 20:26 #
а как с полнотекстовым поиском?
где нужно хранить текст для возможности поиска по нему?

UPD: вот вроде бы можно Sphinx
http://highload.com.ua/index.php/2010/05/2...3%D1%8F-sphinx/


(в PgSQL можно сделать полнотекстовый поиск с релевантностью и с морфологией русской, PgSQL даже на больших таблицах хорошо работает, говорят...)



Цитата (Wowa @ 7.6.2010, 03:14)
получаемый код выглядит даже немного более наглядно, чем SQL.

еще keys/values можно использовать в MLDBM, DBM (с Berkeley DB)
(в perl связывающиеся переменные)
http://search.cpan.org/~sprout/DBM-Deep-1....ib/DBM/Deep.pod
http://www.welshys.net/docs/weblinux/dbi/ch02_07.htm

Цитата


A unique flat-file database module, written in pure perl. True multi-level hash/array support (unlike MLDBM, which is faked), hybrid OO / tie() interface, cross-platform FTPable files, ACID transactions, and is quite fast. Can handle millions of keys and unlimited levels without significant slow-down.



mongodb вродебы тоже DBM, но это не много другое....
mongodb на 32-битных машинах mongodb как и DBM, тоже, имеют ограничение в размер базы на 2 Гб
ava
Gluttton | 15.06.2010, 00:39 #
Wowa, а можно пожалуйста наглядный пример рационального использования MongoDB.
Почитал бегло обзорные статьи по нему, а в чем вкусности так и не понял.
ava
Wowa | 15.06.2010, 02:53 #
Цитата (Gluttton @ 14.6.2010, 23:39 findReferencedText)
а в чем вкусности так и не понял.

Для меня наиболее важны эти вкусности:
Document-oriented storage
Replication & High Availability
Auto-Sharding
Map/Reduce
Подробнее здесь: http://www.mongodb.org/
ava
Gluttton | 16.06.2010, 01:31 #
Wowa, спасибо за информацию!

Меня больше мучает вопрос не столько явных характеристик (т.к. эти страшные слова мне ни о чем не говорят smile ), сколько способ их применения на практике.
Я конечно же понимаю, что могу с таким вопросом нарваться на грубость smile , но все же...
smile
Приведите пожалуйста практическую задачу, решить которую, на Ваш взгляд, было бы целесообразней с использованием MongoDB (а не, например, моего любомого Firebird'a smile )?
ava
gcc | 16.06.2010, 04:20 #
Gluttton, если предположить

то можно:

допустим, есть архитектура таблиц(ы)...

есть главная таблица user

id | username | pass | created | age | cache1 | cache2 | cache3 и т.д.


1) все или многие запросы идут с этой таблицы....
т.е. все построенно чтобы много раз быстро вынимать с этой таблицы...
!
2) это как memchache, на много быстро идет выборка... и там написано что любой запрос занимает 0.02 s, а как в MySQL примерно может занять 0.2 (но если сравнивать соотношения, наверное)

3) а MySQL и другие СУБД использует реляционную алгебру, (ДНК алгоритмы генетические в PgSQL, какие-то...) (там что-то сложное), а memchache не много по другому

4) cache1 | cache2 | cache2 - это какие-то сериализированные объекты для данного пользователя....
например, если нужно все время показывать последние созданные темы сообщения и т.д. пользователям на сайта (на MySQL нужно сделать новый запрос с другой таблицы, если нужно получитить новые сообщения пользователя, ну или там куда-то кэшировать)

туда можно поставить объекты (которые в программе в ЯП) для данного пользователя которые в программе (шаблонизатора, сессию, каких-то классов и т.д.)

динамический языки тратят ресурсы на инициализацию: объектов, массивов, хэшей и всяких структур...
(когда делать новый SQL запрос - они будут строить массивы и хэши)

5) а в данном случае все очень быстро десириализируется с JSON

6) в MySQL может быть ресурсоемкий запрос, если он с многих таблиц, если там INNER, LEFT JOIN, сложный WHERE и т.д.
а тут сделано чтобы использовать проще и красивее, и можно использовать ассоциативные данные (хэши) (объекты JavaScript в Json)

7) при выключении компа кеш memcache удаляется (хотя там есть другая реализация, которая сохраняет кеш), в mongodb - нет.

ava
former | 18.06.2010, 09:59 #
gcc, ну тык получается, что MongoDB лучше использовать для web, документальных ИС.... В случаях, когда преобладает структурированная информация (или есть четкое требование), то все же целесообразно использовать реляционную модель.
ava
Wowa | 18.06.2010, 10:10 #
former, имхо релияционки имеет смысл использовать, когда нужны трасакции(т.к. монгодб их не поддерживает) или же join.
ava
gcc | 19.06.2010, 00:06 #
говорят, что структуры быстро десириализируется с JSON

и в вебе, на странице в браузере в js отправляют страуктуру в JSON запросом в скрипт...

для сериализации я использую Storable + Mime64, а по тестам написано везде что разные модули для JSON быстрее не много будут...

ava
gcc | 19.06.2010, 00:40 #
http://search.cpan.org/~mlehmann/JSON-XS-2.29/XS.pm#SPEED

Цитата


SPEED



It seems that JSON::XS is surprisingly fast, as shown in the following tables. They have been generated with the help of the eg/bench program in the JSON::XS distribution, to make it easy to compare on your own system.



First comes a comparison between various modules using a very short single-line JSON string (also available at http://dist.schmorp.de/misc/json/short.json).


  {"method": "handleMessage", "params": ["user1",
  "we were just talking"], "id": null, "array":[1,11,234,-5,1e5,1e7,
  1, 0]}



It shows the number of encodes/decodes per second (JSON::XS uses the functional interface, while JSON::XS/2 uses the OO interface with pretty-printing and hashkey sorting enabled, JSON::XS/3 enables shrink. JSON::DWIW/DS uses the deserialise function, while JSON::DWIW::FJ uses the from_json method). Higher is better:


  module | encode | decode |
  --------------|------------|------------|
  JSON::DWIW/DS | 86302.551 | 102300.098 |
  JSON::DWIW/FJ | 86302.551 | 75983.768 |
  JSON::PP | 15827.562 | 6638.658 |
  JSON::Syck | 63358.066 | 47662.545 |
  JSON::XS | 511500.488 | 511500.488 |
  JSON::XS/2 | 291271.111 | 388361.481 |
  JSON::XS/3 | 361577.931 | 361577.931 |
  Storable | 66788.280 | 265462.278 |
  --------------+------------+------------+



That is, JSON::XS is almost six times faster than JSON::DWIW on encoding, about five times faster on decoding, and over thirty to seventy times faster than JSON's pure perl implementation. It also compares favourably to Storable for small amounts of data.



Using a longer test string (roughly 18KB, generated from Yahoo! Locals search API (http://dist.schmorp.de/misc/json/long.json).


  module | encode | decode |
  --------------|------------|------------|
  JSON::DWIW/DS | 1647.927 | 2673.916 |
  JSON::DWIW/FJ | 1630.249 | 2596.128 |
  JSON::PP | 400.640 | 62.311 |
  JSON::Syck | 1481.040 | 1524.869 |
  JSON::XS | 20661.596 | 9541.183 |
  JSON::XS/2 | 10683.403 | 9416.938 |
  JSON::XS/3 | 20661.596 | 9400.054 |
  Storable | 19765.806 | 10000.725 |
  --------------+------------+------------+



Again, JSON::XS leads by far (except for Storable which non-surprisingly decodes a bit faster).



On large strings containing lots of high Unicode characters, some modules (such as JSON::PC) seem to decode faster than JSON::XS, but the result will be broken due to missing (or wrong) Unicode handling. Others refuse to decode or encode properly, so it was impossible to prepare a fair comparison table for that case.

ava
Skynin | 07.07.2010, 17:23 #
Цитата (Wowa @ 18.6.2010, 10:10)
former, имхо релияционки имеет смысл использовать, когда нужны трасакции(т.к. монгодб их не поддерживает) или же join.

Реляционки нужны когда есть большие массивы однотипных данных с "водопадными" иерархиями подчинения/включения.
Нужны когда основное представление данных - таблица, куб, с итогами по измерениям (утрировано - табличное хранение появилось потому что "отчет по складу", "продажам" - таблица, а не потому что по "математике" так удобней)

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

А транзакции как и прочее входящее в ACID есть и у NoSQL баз, или ожидается в ближайших версиях.

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

P.S.
Честное слово, только сегодня прочел:

Проблема в том, что сильная сторона реляционной модели — сама реляционная модель — это и ее самая большая слабость. Большинство разработчиков (что бы они ни использовали — .NET, Java или нечто совершенно иное) после нескольких лет работы может в красках описать, что не все так ладно с «квадратной» моделью таблиц/строк/столбцов. Попытка смоделировать иерархические данные может довести до бешенства даже самых искушенных разработчиков, причем настолько, что о концепции моделирования иерархических данных в реляционной модели была написана целая книга — Джо Келко (Joe Celko) «SQL for Smarties, Third Edition» (Morgan-Kaufmann, 2005). И если к этому добавить базовую «данность», которая заключается в том, что реляционные базы данных предполагают отсутствие гибкости в структуре данных (вспомните схему базы данных), то попытка поддерживать «дополнения» в данные по месту приводит к весьма громоздким и запутанным конструкциям. (Быстро голосуем поднятием рук: кто из вас работал с базами данных, в которых был столбец Notes, или еще лучше, столбцы Note1, Note2, Note3…?)

Куда идет NoSQL с MongoDB
ava
Бонифаций | 13.08.2010, 04:14 #
Skynin, Это конечно круто, но что делать, например с много <-> много отношениями? как их в nosql загнать?

Например врачи - пациенты. Один врач может лечить кучу пациентов, каждый пациент может лечиться у нескольких врачей.

В случае реляционной модели - все ясно. Как это будет в mongodb?

ava
lukas | 23.07.2011, 23:35 #
Цитата (Бонифаций @ 13.8.2010, 04:14 findReferencedText)
Skynin, Это конечно круто, но что делать, например с много <-> много отношениями? как их в nosql загнать?



Например врачи - пациенты. Один врач может лечить кучу пациентов, каждый пациент может лечиться у нескольких врачей.



В случае реляционной модели - все ясно. Как это будет в mongodb?


Решил реанимировать тему.
И ответить на вопрос, была похожая просто ситуация.

А что именно не так? Такой же случай как и с комментариями. У комментария есть свойство ELEMENT_ID к которому он пренадлежит.

Также и у пациента есть его врач, Но допустим если врачей несколько есть масса вариантов.

1. Не забывайте что mongo это иерархическая база данных, и она очень хорошо работает с иерархиями. Поэтому у врача может храниться список ID-ников его пациентов. Но это становится накладно, есть пациентов очень много. Если их еще менее 1000 то годится.

2. Вариант, это хранить список врачей у элемента пациент, но выборки станут сложнее и медленее если доставать всех пациентов одного врача.

3. Дополнительная таблица для множественных связок, классика.


Думаю еще можно совместить 2 варианта, т.е. хранить и там и там - для оптимизации разных запросов. Чтобы запросить всех пациентов врача нужно будет всего лишь 2 запроса и без всяких join'ов.
ava
tishaishii | 13.10.2011, 06:51 #
Не стоит отрицать полностью старый подход в построении БД. Оставить наиболее эффективные и полезные возможности или весь функционал, по возможности. Имею в виду реляционную модель.
Универсальной модели для любой задачи, по-моему, быть не может. Поэтому, модели можно совмещать или подбирать для каждой задачи свои инструменты, которые бы позволяли решить задачу самым простым, надёжным и понятным всем способом.
ava
kshvakov | 26.10.2011, 22:36 #
ava
bl1zzarrd | 02.12.2013, 20:57 #
Есть коллекция пациент, который содержит основную информацию о каждом человеке и отображает человека к patient_id, и коллекция записей, который содержит один документ для каждого теста или процедуры. Один пациент может иметь десятки или даже сотни документов в коллекции записей.
Please register or login to write.
Firm of day
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Contributors
advanced
Submit