Как стать автором
Обновить

Комментарии 51

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

Какова производительность операции group?
Не сильно замедляет, но не измерял. Производительность довольно высокая, хотя злоупотреблять конечно не стоит, надо эту операцию над куском лога делать один раз и запоминать готовые данные, но я ради простоты примера не стал этого делать, иначе бы сложно было для понимания. Производительность зависит от всего — от reduce-функции, от индексов, от железа… посмотрите сами на своем железе и задаче.
Если Вы правильно вставили код, то график уже есть, поскольку после редактирования вы сразу попадаете на страницу с постом и график создается ;-)
НЛО прилетело и опубликовало эту надпись здесь
Это для тех кто копирует адрес картинки и открывает в броузере )
Насколько быстро бд работает по сравнению с другими?

Впечатляет, кстати, Ваш труд.
Затормозить или разогнать можно что угодно, вопрос лишь в приспособленности архитектуры к шардингу и работе без затыков. На мой взгляд, у MongoDB хорошая гибкая архитектура, которая в то же делает прозрачной работу с СУБД, и не позволяет программисту особо сильно накосячить. С другой стороны, в ней отсутствует транзакционная модель, даже не знаю хорошо это или плохо.
Конкретно узнать насколько можно лишь на реальном железе и реальных тестах, попробуйте если интересно, это вовсе несложно.
Спасибо, я рад.
Даёшь GridFS в след. статье :)
Намёк понял :-) Будет.
Что ещё? Достаточно ли сказано о масштабировании?
Статья немного плохо структурирована, что опасно для Веба. Про мастабирование лучше отдельную статью написать с How To и графиками :).
раскажите подробнее о репликациях и вообще подходе их к этому.

Также у 10gen есть еще пара проектов, например, свой сервер приложений (с которого компания и начинала пока не переключилась на базу)
про масштабирование сказано мало.
Нужен реальный пример и workaround'ы
По поводу _id: как указано, его можно формировать самому. По полю _id индекс есть всегда. Если системное значение _id для вас некритично и есть потребность в индексе по какому-либо одному или нескольким полям (комбинация которых будет уникальна) — можете формировать id сами по нужным правилам. На этом можно сэкономить один индекс на отдельно взятом поле или группе полей, а также быстро адресоваться к конкретной записи по заранее известному значени.
Например для получения объекта { _id: «1234_4456»; a: 1234; b: 4456 }, мы используем $collection->find( array( "_id" => «1234_4456» ) ), что, теоретически, должно быть быстрее, чем $collection->find( array( «a» => 1234, «b» => 4456 ) ).
НЛО прилетело и опубликовало эту надпись здесь
Manual — на английском.
Что имеется в виду под интеллектуальным поиском? Что такое сетевая БД?
НЛО прилетело и опубликовало эту надпись здесь
Достаточно хранить коллекцию связей видаи id -> [id,weight], и повесить индекс на id.
НЛО прилетело и опубликовало эту надпись здесь
А где-нибудь есть сравнение другими KV-хранилищами? Меня в частности интересуют Java-проекты Cassandra(Facebook) & Voldemort(LinkedIn), Hadoop(Apache).
Hadoop разве KV?
Сам я с ним не работал, но HBase в какой-то степени я думаю можно к ним отнести.
С Tokyo Cabinet и Tokyo Tyrant наверное еще интересней.

Еще бы бенчмарки в сравнении.
Идея.
У меня давно есть идея распределенной отказоустойчивой платформу как у Google или круче, на которой и поисковик можно написать, и армию ботов поднять не проблема.
Скажите, была бы вам интересна статья об этом? HOWTO повторить Google, с некоторой долей теории, исследований и рассуждений.
Да. Особо интересно как работает MapReduce на таких объемах данных.
Отлично пишите!

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

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

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

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

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

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

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

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

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

С MySQL бывало и похуже, это нормально. Во-первых сервер не может просто так перезагрузиться — по крайней мере за год работы этого продакшена ни разу не было, во-вторых, два или три сервера уж точно одновременно не навернуться, но если это произошло — восстанавливать и вперед.
НЛО прилетело и опубликовало эту надпись здесь
Есть. `mongo [dbname]`, а большего и не надо. Правда.
Хотя я слышал, что какие-то энтузиасты делают проект для просмотра и редактирования коллекций через веб-интерфейс, но мне даже смотреть не захотелось.
Интересно.
А сортировку он поддерживает?
Возможно ли на нем сделать подобное:
ORDER BY RAND()*hosts DESC LIMIT 5

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

А этот пистолет стреляет? А ногу у меня получится себе отстрелить?
Не стоит так все воспринимать.

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

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

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

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

Вторая задача (про баннерную систему): думаю я бы инкрементил клики в Memcached, и скидывал бы изменения в MongoDB раз в минуту, например. А выборку баннера сделал бы по индексу само собой.
Спасибо!
Очень поверхностно пока знаком с Mongo.
Как я понял rnd это моя фунцкция?

А возможно подобной схемой вытаскивать сразу 5-7 баннеров одним махом?
Я тоже пока поверхностно :-)
Да, это Ваша функция которая выполняется в программе и возвращает количество для skip'а.
Неа, нельзя, но это ничего.
А с Cassandra Вы не сравнивали?
Тема очень интересная, особенно практические комментарии и примеры.
Буду рад видеть продолжение :-)
Нет, не сравнивал. Меня и Mongo вполне удоволетворяет :-)
А почему не CouchDB? Скорость?
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
Я прочёл идеологию, меня не вставило. CouchDB решает другие задачи.
Прошу развить ответ.
Не подскажете по вопросу ссылок:
Как я понял, ссылок на объекты в MongoDB нет. Как нам поступать на примере тех же комментариев, когда надо вытащить логин каждого автора коммента (разумеется, логин может изменяться, а привязка идет по id).

Спасибо!
Вторым $in-запросом по коллекции пользователей. Ссылки там изначально были, но потом от них отказались. Однако можно сделать свою хранимую процедуру на Javascript.
Вот интересно как раз насколько это быстрее чем join на mysql
Не подскажите где написано, от них отказались? На mongodb.org/display/DOCS/DB+Ref и php.net не нашел.
Когда будут следующая статья о Mongo? Наверняка нашлись новые минусы.
Спасибо.
расскажите про файловую систему на монго
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории