|
|
|
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
Кто-нить работал с MongoDB. Как впечатления?
|
|||
|
||||
gcc |
|
||||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: нет Всего: 17 |
ну это типо как memchahe?
только после выключение компа memchahe свой кэш удаляет тут можно сериализировать структуры/объекты (в json) исключительно по одному id и вставлять в эту базу id | data
http://ru.wikipedia.org/wiki/MongoDB
Это сообщение отредактировал(а) gcc - 14.6.2010, 20:34 |
||||
|
|||||
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
||||
|
||||
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
Сейчас переделываю в проекте модель и меняю SQL запросы на запросы к МонгоДБ. На моё удивление получаемый код выглядит даже немного более наглядно, чем SQL.
|
|||
|
||||
gcc |
|
||||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: нет Всего: 17 |
а как с полнотекстовым поиском?
где нужно хранить текст для возможности поиска по нему? UPD: вот вроде бы можно Sphinx http://highload.com.ua/index.php/2010/05/2...3%D1%8F-sphinx/ (в PgSQL можно сделать полнотекстовый поиск с релевантностью и с морфологией русской, PgSQL даже на больших таблицах хорошо работает, говорят...)
еще 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
mongodb вродебы тоже DBM, но это не много другое.... mongodb на 32-битных машинах mongodb как и DBM, тоже, имеют ограничение в размер базы на 2 Гб Это сообщение отредактировал(а) gcc - 14.6.2010, 20:50 |
||||
|
|||||
Gluttton |
|
|||
Начинающий Профиль Группа: Завсегдатай Сообщений: 1170 Регистрация: 28.8.2008 Где: Феодосия Репутация: нет Всего: 54 |
Wowa, а можно пожалуйста наглядный пример рационального использования MongoDB.
Почитал бегло обзорные статьи по нему, а в чем вкусности так и не понял. -------------------- Слава Україні! |
|||
|
||||
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
Для меня наиболее важны эти вкусности: Document-oriented storage Replication & High Availability Auto-Sharding Map/Reduce Подробнее здесь: http://www.mongodb.org/ |
|||
|
||||
Gluttton |
|
|||
Начинающий Профиль Группа: Завсегдатай Сообщений: 1170 Регистрация: 28.8.2008 Где: Феодосия Репутация: нет Всего: 54 |
Wowa, спасибо за информацию!
Меня больше мучает вопрос не столько явных характеристик (т.к. эти страшные слова мне ни о чем не говорят ), сколько способ их применения на практике. Я конечно же понимаю, что могу с таким вопросом нарваться на грубость , но все же... Приведите пожалуйста практическую задачу, решить которую, на Ваш взгляд, было бы целесообразней с использованием MongoDB (а не, например, моего любомого Firebird'a )? -------------------- Слава Україні! |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: нет Всего: 17 |
Gluttton, если предположить
то можно: допустим, есть архитектура таблиц(ы)... есть главная таблица user
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 |
|||
|
||||
former |
|
|||
MEMS Expert Профиль Группа: Завсегдатай Сообщений: 1166 Регистрация: 1.3.2006 Где: Россия Репутация: нет Всего: 17 |
gcc, ну тык получается, что MongoDB лучше использовать для web, документальных ИС.... В случаях, когда преобладает структурированная информация (или есть четкое требование), то все же целесообразно использовать реляционную модель.
-------------------- Достаточно снизить уровень мышления, чтобы иные почувствовали почву под ногами. |
|||
|
||||
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
former, имхо релияционки имеет смысл использовать, когда нужны трасакции(т.к. монгодб их не поддерживает) или же join.
|
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: нет Всего: 17 |
говорят, что структуры быстро десириализируется с JSON
и в вебе, на странице в браузере в js отправляют страуктуру в JSON запросом в скрипт... для сериализации я использую Storable + Mime64, а по тестам написано везде что разные модули для JSON быстрее не много будут... Это сообщение отредактировал(а) gcc - 19.6.2010, 00:40 |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: нет Всего: 17 |
http://search.cpan.org/~mlehmann/JSON-XS-2.29/XS.pm#SPEED
|
|||
|
||||
Skynin |
|
|||
Опытный Профиль Группа: Участник Сообщений: 359 Регистрация: 1.7.2007 Где: Харьков Репутация: нет Всего: 10 |
Реляционки нужны когда есть большие массивы однотипных данных с "водопадными" иерархиями подчинения/включения. Нужны когда основное представление данных - таблица, куб, с итогами по измерениям (утрировано - табличное хранение появилось потому что "отчет по складу", "продажам" - таблица, а не потому что по "математике" так удобней) Конечно, на реляционной базе можно смоделировать любой сложности данные, но нужно ли, когда есть альтернатива? Второй недостаток - у реляционной базы проблемы с изменением схемы данных во время эксплуатации. А транзакции как и прочее входящее в 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 |
|||
|
||||
Бонифаций |
|
|||
Опытный Профиль Группа: Участник Сообщений: 827 Регистрация: 15.9.2005 Где: Brisbane Репутация: нет Всего: 40 |
Skynin, Это конечно круто, но что делать, например с много <-> много отношениями? как их в nosql загнать?
Например врачи - пациенты. Один врач может лечить кучу пациентов, каждый пациент может лечиться у нескольких врачей. В случае реляционной модели - все ясно. Как это будет в mongodb? -------------------- Бонифаций. |
|||
|
||||
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | NoSQL | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |