Хабрахабр / Комментарии к посту «MongoDB — варим хороший кофе» в блоге «NoSQL»

14.03.2010 18:01:15 stas_agarkov

stas_agarkov — Sun, 14 Mar 2010 18:01:15 GMT

расскажите про файловую систему на монго

29.01.2010 13:31:36 wmw85

wmw85 — Fri, 29 Jan 2010 13:31:36 GMT

Не подскажите где написано, от них отказались? На mongodb.org/display/DOCS/DB+Ref и php.net не нашел.
Когда будут следующая статья о Mongo? Наверняка нашлись новые минусы.
Спасибо.

03.01.2010 17:24:23 benone

benone — Sun, 03 Jan 2010 17:24:23 GMT

Вот интересно как раз насколько это быстрее чем join на mysql

30.12.2009 10:11:25 TravisBickle

TravisBickle — Wed, 30 Dec 2009 10:11:25 GMT

Вторым $in-запросом по коллекции пользователей. Ссылки там изначально были, но потом от них отказались. Однако можно сделать свою хранимую процедуру на Javascript.

29.12.2009 22:21:03 benone

benone — Tue, 29 Dec 2009 22:21:03 GMT

Не подскажете по вопросу ссылок:
Как я понял, ссылок на объекты в MongoDB нет. Как нам поступать на примере тех же комментариев, когда надо вытащить логин каждого автора коммента (разумеется, логин может изменяться, а привязка идет по id).

Спасибо!

17.11.2009 10:50:32 oag

oag — Tue, 17 Nov 2009 10:50:32 GMT

Прошу развить ответ.

16.11.2009 23:31:00 TravisBickle

TravisBickle — Mon, 16 Nov 2009 23:31:00 GMT

Нет, не сравнивал. Меня и Mongo вполне удоволетворяет :-)

16.11.2009 23:29:21 TravisBickle

TravisBickle — Mon, 16 Nov 2009 23:29:21 GMT

Я прочёл идеологию, меня не вставило. CouchDB решает другие задачи.

16.11.2009 06:04:47 oag

oag — Mon, 16 Nov 2009 06:04:47 GMT

А почему не CouchDB? Скорость?
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.

15.11.2009 13:22:23 impersona

impersona — Sun, 15 Nov 2009 13:22:23 GMT

А с Cassandra Вы не сравнивали?
Тема очень интересная, особенно практические комментарии и примеры.
Буду рад видеть продолжение :-)

06.11.2009 18:56:51 TravisBickle

TravisBickle — Fri, 06 Nov 2009 18:56:51 GMT

Я тоже пока поверхностно :-)
Да, это Ваша функция которая выполняется в программе и возвращает количество для skip'а.
Неа, нельзя, но это ничего.

06.11.2009 16:47:11 jiexaspb

jiexaspb — Fri, 06 Nov 2009 16:47:11 GMT

Спасибо!
Очень поверхностно пока знаком с Mongo.
Как я понял rnd это моя фунцкция?

А возможно подобной схемой вытаскивать сразу 5-7 баннеров одним махом?

06.11.2009 16:23:58 TravisBickle

TravisBickle — Fri, 06 Nov 2009 16:23:58 GMT

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

Кстати, в первой задаче (про функцию RAND): индекс на hosts, и find().sort(«hosts»:1).limit(rnd(),1) нужное количество раз. rnd() — Ваша хитрая схема с вероятностями.

Вторая задача (про баннерную систему): думаю я бы инкрементил клики в Memcached, и скидывал бы изменения в MongoDB раз в минуту, например. А выборку баннера сделал бы по индексу само собой.

06.11.2009 14:53:05 eugyn

eugyn — Fri, 06 Nov 2009 14:53:05 GMT

С Tokyo Cabinet и Tokyo Tyrant наверное еще интересней.

Еще бы бенчмарки в сравнении.

06.11.2009 14:46:14 jiexaspb

jiexaspb — Fri, 06 Nov 2009 14:46:14 GMT

Не стоит так все воспринимать.

Представьте, например, баннерную систему.
Миллионы запросов в сутки к скрипту, который отдает баннеры сайтам-партнерам.

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

Для таких задач что нужно использовать?
Поэтому я и поинтересовался насчет Mongo, вдруг она подойдет.

06.11.2009 14:21:53 symbix

symbix — Fri, 06 Nov 2009 14:21:53 GMT

>А сортировку он поддерживает? Возможно ли на нем сделать подобное: ORDER BY RAND()*hosts DESC LIMIT 5

А этот пистолет стреляет? А ногу у меня получится себе отстрелить?

06.11.2009 13:33:55 Snick

Snick — Fri, 06 Nov 2009 13:33:55 GMT

про масштабирование сказано мало.
Нужен реальный пример и workaround'ы

06.11.2009 13:27:59 TravisBickle

TravisBickle — Fri, 06 Nov 2009 13:27:59 GMT

Спасибо.

— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».

С удовольствием напишу.

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

Вы видно перепутали сервер и шард. Если шард полностью упал, то данные уже не спасти (только если из резервных копий), если упал сервер в шарде (их рекомендуется 3 на шард), то всё работает как работало, как только добавляется новый сервер, он без проблем синхронизируется и вступает в бой с клиентами.

— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?

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

06.11.2009 13:17:45 TravisBickle

TravisBickle — Fri, 06 Nov 2009 13:17:45 GMT

Сортировку поддерживает замечательно.
> ORDER BY RAND()*hosts DESC LIMIT 5
Нет. И это огромный плюс… MySQL любит делать фишки удобные для использования, но которые при этом кладут на производительность. Данная конструкция в MySQL вызовет фулскан всей таблицы и положит сервер на немаленькой табличке. Ведь чтобы отсортировать результат и взять сверху 5 элементов, необходимо каждый ряд в таблице проверить и положить в память результат, потом сделать сортировку пузырьком в памяти, а затем уже отпилить маленький кусочек и послать ответ клиенту.
Но есть и правильные пути. Например, задайте индекс по свойству hosts и делайте запросы hosts > min && hosts < max. Где min и max там ограничители выбираемой группы, которые задаются псевдослучайно с задаваемой вероятностью. Еще можно задать какое-то числовое свойство группы (в ней скажем 20 объектов), и выбирать запросом (k IN list) 5 таких групп, а затем выбирать для каждой группы случайный элемент (уже на клиенте). Согласен, может быть не очень красиво, за то это будет хорошо работать и на миллиарде рядов, а вот RAND() загнется куда раньше.
Да, придётся думать, но без этого никуда.

06.11.2009 12:59:33 TravisBickle

TravisBickle — Fri, 06 Nov 2009 12:59:33 GMT

Есть. `mongo [dbname]`, а большего и не надо. Правда.
Хотя я слышал, что какие-то энтузиасты делают проект для просмотра и редактирования коллекций через веб-интерфейс, но мне даже смотреть не захотелось.

06.11.2009 11:16:38 Scala

Scala — Fri, 06 Nov 2009 11:16:38 GMT

Сам я с ним не работал, но HBase в какой-то степени я думаю можно к ним отнести.

06.11.2009 11:05:23 jiexaspb

jiexaspb — Fri, 06 Nov 2009 11:05:23 GMT

Интересно.
А сортировку он поддерживает?
Возможно ли на нем сделать подобное:
ORDER BY RAND()*hosts DESC LIMIT 5

то есть выводить 5 случайных документов, но вероятность показа будет больше у тех, у кого hosts больше.

06.11.2009 07:43:40 xmcdbx

xmcdbx — Fri, 06 Nov 2009 07:43:40 GMT

а есть что-то наподобие phpMongoAdmin?

06.11.2009 04:51:19 nod

nod — Fri, 06 Nov 2009 04:51:19 GMT

Отлично пишите!

Многое есть в оф. документации.
НО ваш личный опыт работы с MONGO ниоткуда не почерпнешь!

— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».

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

— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?

06.11.2009 00:25:05 remal

remal — Fri, 06 Nov 2009 00:25:05 GMT

Да. Особо интересно как работает MapReduce на таких объемах данных.

05.11.2009 20:37:17 TravisBickle

TravisBickle — Thu, 05 Nov 2009 20:37:17 GMT

Идея.
У меня давно есть идея распределенной отказоустойчивой платформу как у Google или круче, на которой и поисковик можно написать, и армию ботов поднять не проблема.
Скажите, была бы вам интересна статья об этом? HOWTO повторить Google, с некоторой долей теории, исследований и рассуждений.

05.11.2009 20:00:17 aleks_raiden

aleks_raiden — Thu, 05 Nov 2009 20:00:17 GMT

Hadoop разве KV?

05.11.2009 19:09:28 creotiv

creotiv — Thu, 05 Nov 2009 19:09:28 GMT

пасибки… опробуем)

05.11.2009 19:03:25 TravisBickle

TravisBickle — Thu, 05 Nov 2009 19:03:25 GMT

Достаточно хранить коллекцию связей видаи id -> [id,weight], и повесить индекс на id.

05.11.2009 18:56:00 creotiv

creotiv — Thu, 05 Nov 2009 18:56:00 GMT

И как я его провтычил??.. савсем заработался) Спасибо огромное)

Интелектуальный поиск это типа раньше вы искали зеленые гардины, а потом ищите кушетку и поиск подбирает кушетку так что бы она подходила под зеленые гардины. В таком вот духи. Эта вся фигня строится на сетевой основе. Тоесть имеем нод, и связанные с ним ноды, каждая связь которых имеет вес.
Сетевые БД это бд которые имеют именно такую структуру.

ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94

05.11.2009 18:50:39 TravisBickle

TravisBickle — Thu, 05 Nov 2009 18:50:39 GMT

Manual — на английском.
Что имеется в виду под интеллектуальным поиском? Что такое сетевая БД?

05.11.2009 18:12:50 Scala

Scala — Thu, 05 Nov 2009 18:12:50 GMT

А где-нибудь есть сравнение другими KV-хранилищами? Меня в частности интересуют Java-проекты Cassandra(Facebook) & Voldemort(LinkedIn), Hadoop(Apache).

05.11.2009 17:17:36 creotiv

creotiv — Thu, 05 Nov 2009 17:17:36 GMT

Был бы очень признателен если опишите возможности данной БД ну или линк на документацию… ибо на итальянском я слабо шарю.

А если конкретно то интересует возможность создания ителектуального поиска на базе данной БД. Или буду рад если посоветуете сетевую БД ибо именно сетевая модель заложена в поиск.

05.11.2009 16:07:54 aleks_raiden

aleks_raiden — Thu, 05 Nov 2009 16:07:54 GMT

раскажите подробнее о репликациях и вообще подходе их к этому.

Также у 10gen есть еще пара проектов, например, свой сервер приложений (с которого компания и начинала пока не переключилась на базу)

05.11.2009 16:06:58 sergey_k

sergey_k — Thu, 05 Nov 2009 16:06:58 GMT

По поводу _id: как указано, его можно формировать самому. По полю _id индекс есть всегда. Если системное значение _id для вас некритично и есть потребность в индексе по какому-либо одному или нескольким полям (комбинация которых будет уникальна) — можете формировать id сами по нужным правилам. На этом можно сэкономить один индекс на отдельно взятом поле или группе полей, а также быстро адресоваться к конкретной записи по заранее известному значени.
Например для получения объекта { _id: «1234_4456»; a: 1234; b: 4456 }, мы используем $collection->find( array( "_id" => «1234_4456» ) ), что, теоретически, должно быть быстрее, чем $collection->find( array( «a» => 1234, «b» => 4456 ) ).

05.11.2009 15:56:05 TravisBickle

TravisBickle — Thu, 05 Nov 2009 15:56:05 GMT

Затормозить или разогнать можно что угодно, вопрос лишь в приспособленности архитектуры к шардингу и работе без затыков. На мой взгляд, у MongoDB хорошая гибкая архитектура, которая в то же делает прозрачной работу с СУБД, и не позволяет программисту особо сильно накосячить. С другой стороны, в ней отсутствует транзакционная модель, даже не знаю хорошо это или плохо.
Конкретно узнать насколько можно лишь на реальном железе и реальных тестах, попробуйте если интересно, это вовсе несложно.
Спасибо, я рад.

05.11.2009 15:44:15 Iskin

Iskin — Thu, 05 Nov 2009 15:44:15 GMT

Статья немного плохо структурирована, что опасно для Веба. Про мастабирование лучше отдельную статью написать с How To и графиками :).

05.11.2009 15:37:05 TravisBickle

TravisBickle — Thu, 05 Nov 2009 15:37:05 GMT

Намёк понял :-) Будет.
Что ещё? Достаточно ли сказано о масштабировании?

05.11.2009 15:22:49 paradoxs

paradoxs — Thu, 05 Nov 2009 15:22:49 GMT

И кстати сервер делается не так уж и сложно

05.11.2009 15:21:29 paradoxs

paradoxs — Thu, 05 Nov 2009 15:21:29 GMT

1. Идеология хоть и другая, но тоже не реляционная
2. Она не только встраиваемая. На основе их документации мы сделали вполне себе настоящий сервер db4o. Конечно с «серверностью» дела там обстоят не очень гладко, но всё решаемо.
3. Аудитории разные, но это же не значит, что о ней не нужно знать