Поиск:

Ответ в темуСоздание новой темы Создание опроса
> MongoDB. Впечатления? MongoDB  
:(
    Опции темы
Wowa
Дата 14.5.2010, 15:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
Group Icon


Профиль
Группа: Админ
Сообщений: 15017
Регистрация: 14.9.2000
Где: Винград

Репутация: нет
Всего: 290



Кто-нить работал с MongoDB. Как впечатления?
PM WWW   Вверх
gcc
Дата 20.5.2010, 05:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Агент алкомафии
****


Профиль
Группа: Участник
Сообщений: 2691
Регистрация: 25.4.2008
Где: %&й

Репутация: нет
Всего: 17



ну это типо как memchahe? 

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

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

id | data

Цитата

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

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

Цитата

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


Это сообщение отредактировал(а) gcc - 14.6.2010, 20:34
PM WWW ICQ Skype GTalk Jabber   Вверх
Wowa
Дата 20.5.2010, 10:12 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
Group Icon


Профиль
Группа: Админ
Сообщений: 15017
Регистрация: 14.9.2000
Где: Винград

Репутация: нет
Всего: 290



Цитата(gcc @  20.5.2010,  04:18 Найти цитируемый пост)
только после выключение компа memchahe свой кэш удаляет

она сбрасывает каждую минуту на диск данные. Кроме того репликация используется.
PM WWW   Вверх
Wowa
Дата 7.6.2010, 03:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
Group Icon


Профиль
Группа: Админ
Сообщений: 15017
Регистрация: 14.9.2000
Где: Винград

Репутация: нет
Всего: 290



Сейчас переделываю в проекте модель и меняю SQL запросы на запросы к МонгоДБ. На моё удивление получаемый код выглядит даже немного более наглядно, чем SQL.
PM WWW   Вверх
gcc
Дата 14.6.2010, 20:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Агент алкомафии
****


Профиль
Группа: Участник
Сообщений: 2691
Регистрация: 25.4.2008
Где: %&й

Репутация: нет
Всего: 17



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

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 Гб


Это сообщение отредактировал(а) gcc - 14.6.2010, 20:50
PM WWW ICQ Skype GTalk Jabber   Вверх
Gluttton
Дата 15.6.2010, 00:39 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Начинающий
***


Профиль
Группа: Завсегдатай
Сообщений: 1170
Регистрация: 28.8.2008
Где: Феодосия

Репутация: нет
Всего: 54



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


--------------------
Слава Україні!
PM MAIL   Вверх
Wowa
Дата 15.6.2010, 02:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
Group Icon


Профиль
Группа: Админ
Сообщений: 15017
Регистрация: 14.9.2000
Где: Винград

Репутация: нет
Всего: 290



Цитата(Gluttton @  14.6.2010,  23:39 Найти цитируемый пост)
а в чем вкусности так и не понял. 

Для меня наиболее важны эти вкусности:
Document-oriented storage 
Replication & High Availability
Auto-Sharding
Map/Reduce
Подробнее здесь: http://www.mongodb.org/
PM WWW   Вверх
Gluttton
Дата 16.6.2010, 01:31 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Начинающий
***


Профиль
Группа: Завсегдатай
Сообщений: 1170
Регистрация: 28.8.2008
Где: Феодосия

Репутация: нет
Всего: 54



Wowa, спасибо за информацию!

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


--------------------
Слава Україні!
PM MAIL   Вверх
gcc
Дата 16.6.2010, 04:20 (ссылка) |   (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Агент алкомафии
****


Профиль
Группа: Участник
Сообщений: 2691
Регистрация: 25.4.2008
Где: %&й

Репутация: нет
Всего: 17



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 - нет.



Это сообщение отредактировал(а) gcc - 16.6.2010, 04:22
PM WWW ICQ Skype GTalk Jabber   Вверх
former
Дата 18.6.2010, 09:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


MEMS Expert
***


Профиль
Группа: Завсегдатай
Сообщений: 1166
Регистрация: 1.3.2006
Где: Россия

Репутация: нет
Всего: 17



gcc, ну тык получается, что MongoDB лучше использовать для web, документальных ИС.... В случаях, когда преобладает структурированная информация (или есть четкое требование), то все же целесообразно использовать реляционную модель. 


--------------------
Достаточно снизить уровень мышления, чтобы иные почувствовали почву под ногами.
PM MAIL   Вверх
Wowa
Дата 18.6.2010, 10:10 (ссылка) |  (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
Group Icon


Профиль
Группа: Админ
Сообщений: 15017
Регистрация: 14.9.2000
Где: Винград

Репутация: нет
Всего: 290



former, имхо релияционки имеет смысл использовать, когда нужны трасакции(т.к. монгодб их не поддерживает) или же join.
PM WWW   Вверх
gcc
Дата 19.6.2010, 00:06 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Агент алкомафии
****


Профиль
Группа: Участник
Сообщений: 2691
Регистрация: 25.4.2008
Где: %&й

Репутация: нет
Всего: 17



говорят, что структуры быстро десириализируется с JSON 

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

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



Это сообщение отредактировал(а) gcc - 19.6.2010, 00:40
PM WWW ICQ Skype GTalk Jabber   Вверх
gcc
Дата 19.6.2010, 00:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Агент алкомафии
****


Профиль
Группа: Участник
Сообщений: 2691
Регистрация: 25.4.2008
Где: %&й

Репутация: нет
Всего: 17



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.

PM WWW ICQ Skype GTalk Jabber   Вверх
Skynin
Дата 7.7.2010, 17:23 (ссылка) |   (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 359
Регистрация: 1.7.2007
Где: Харьков

Репутация: нет
Всего: 10



Цитата(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


Это сообщение отредактировал(а) Skynin - 8.7.2010, 09:09
PM MAIL WWW ICQ Skype GTalk YIM MSN   Вверх
Бонифаций
Дата 13.8.2010, 04:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 827
Регистрация: 15.9.2005
Где: Brisbane

Репутация: нет
Всего: 40



Skynin,  Это конечно круто, но что делать, например с много <-> много отношениями? как их в nosql загнать?

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

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

 


--------------------
 Бонифаций.
 
PM MAIL ICQ Skype GTalk Jabber YIM   Вверх
Ответ в темуСоздание новой темы Создание опроса
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | NoSQL | Следующая тема »


 




[ Время генерации скрипта: 0.1725 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.