Comments 51
Руки чешутся попробовать, MongoDB с каждым обзором всё привлекательнее кажется.
+1
Раз пошла такая пьянка, писать посты про объектные базы, то я скоро напишу про db4o. Уверен она тоже Вам понравится.
+4
Идеология совершенно другая, db4o ведь встраиваемая, как например BDB. Так что целевые аудитории этих продуктов сильно разнятся.
0
1. Идеология хоть и другая, но тоже не реляционная
2. Она не только встраиваемая. На основе их документации мы сделали вполне себе настоящий сервер db4o. Конечно с «серверностью» дела там обстоят не очень гладко, но всё решаемо.
3. Аудитории разные, но это же не значит, что о ней не нужно знать
2. Она не только встраиваемая. На основе их документации мы сделали вполне себе настоящий сервер db4o. Конечно с «серверностью» дела там обстоят не очень гладко, но всё решаемо.
3. Аудитории разные, но это же не значит, что о ней не нужно знать
0
Каковы минусы вешать индексы на все подряд? Насколько это замедлит процесс вставки?
Какова производительность операции group?
Какова производительность операции group?
+1
Не сильно замедляет, но не измерял. Производительность довольно высокая, хотя злоупотреблять конечно не стоит, надо эту операцию над куском лога делать один раз и запоминать готовые данные, но я ради простоты примера не стал этого делать, иначе бы сложно было для понимания. Производительность зависит от всего — от reduce-функции, от индексов, от железа… посмотрите сами на своем железе и задаче.
+1
img src root.loopback.su/habralogger/ в шапке
ждите нового графика…
ждите нового графика…
0
UFO just landed and posted this here
Насколько быстро бд работает по сравнению с другими?
Впечатляет, кстати, Ваш труд.
Впечатляет, кстати, Ваш труд.
0
Затормозить или разогнать можно что угодно, вопрос лишь в приспособленности архитектуры к шардингу и работе без затыков. На мой взгляд, у MongoDB хорошая гибкая архитектура, которая в то же делает прозрачной работу с СУБД, и не позволяет программисту особо сильно накосячить. С другой стороны, в ней отсутствует транзакционная модель, даже не знаю хорошо это или плохо.
Конкретно узнать насколько можно лишь на реальном железе и реальных тестах, попробуйте если интересно, это вовсе несложно.
Спасибо, я рад.
Конкретно узнать насколько можно лишь на реальном железе и реальных тестах, попробуйте если интересно, это вовсе несложно.
Спасибо, я рад.
+1
Даёшь GridFS в след. статье :)
0
Намёк понял :-) Будет.
Что ещё? Достаточно ли сказано о масштабировании?
Что ещё? Достаточно ли сказано о масштабировании?
+2
Статья немного плохо структурирована, что опасно для Веба. Про мастабирование лучше отдельную статью написать с How To и графиками :).
0
раскажите подробнее о репликациях и вообще подходе их к этому.
Также у 10gen есть еще пара проектов, например, свой сервер приложений (с которого компания и начинала пока не переключилась на базу)
Также у 10gen есть еще пара проектов, например, свой сервер приложений (с которого компания и начинала пока не переключилась на базу)
0
про масштабирование сказано мало.
Нужен реальный пример и workaround'ы
Нужен реальный пример и workaround'ы
0
По поводу _id: как указано, его можно формировать самому. По полю _id индекс есть всегда. Если системное значение _id для вас некритично и есть потребность в индексе по какому-либо одному или нескольким полям (комбинация которых будет уникальна) — можете формировать id сами по нужным правилам. На этом можно сэкономить один индекс на отдельно взятом поле или группе полей, а также быстро адресоваться к конкретной записи по заранее известному значени.
Например для получения объекта { _id: «1234_4456»; a: 1234; b: 4456 }, мы используем $collection->find( array( "_id" => «1234_4456» ) ), что, теоретически, должно быть быстрее, чем $collection->find( array( «a» => 1234, «b» => 4456 ) ).
Например для получения объекта { _id: «1234_4456»; a: 1234; b: 4456 }, мы используем $collection->find( array( "_id" => «1234_4456» ) ), что, теоретически, должно быть быстрее, чем $collection->find( array( «a» => 1234, «b» => 4456 ) ).
0
UFO just landed and posted this here
Manual — на английском.
Что имеется в виду под интеллектуальным поиском? Что такое сетевая БД?
Что имеется в виду под интеллектуальным поиском? Что такое сетевая БД?
0
А где-нибудь есть сравнение другими KV-хранилищами? Меня в частности интересуют Java-проекты Cassandra(Facebook) & Voldemort(LinkedIn), Hadoop(Apache).
0
Идея.
У меня давно есть идея распределенной отказоустойчивой платформу как у Google или круче, на которой и поисковик можно написать, и армию ботов поднять не проблема.
Скажите, была бы вам интересна статья об этом? HOWTO повторить Google, с некоторой долей теории, исследований и рассуждений.
У меня давно есть идея распределенной отказоустойчивой платформу как у Google или круче, на которой и поисковик можно написать, и армию ботов поднять не проблема.
Скажите, была бы вам интересна статья об этом? HOWTO повторить Google, с некоторой долей теории, исследований и рассуждений.
+5
Отлично пишите!
Многое есть в оф. документации.
НО ваш личный опыт работы с MONGO ниоткуда не почерпнешь!
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
Многое есть в оф. документации.
НО ваш личный опыт работы с MONGO ниоткуда не почерпнешь!
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
+1
Спасибо.
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
С удовольствием напишу.
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
Вы видно перепутали сервер и шард. Если шард полностью упал, то данные уже не спасти (только если из резервных копий), если упал сервер в шарде (их рекомендуется 3 на шард), то всё работает как работало, как только добавляется новый сервер, он без проблем синхронизируется и вступает в бой с клиентами.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
С MySQL бывало и похуже, это нормально. Во-первых сервер не может просто так перезагрузиться — по крайней мере за год работы этого продакшена ни разу не было, во-вторых, два или три сервера уж точно одновременно не навернуться, но если это произошло — восстанавливать и вперед.
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
С удовольствием напишу.
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
Вы видно перепутали сервер и шард. Если шард полностью упал, то данные уже не спасти (только если из резервных копий), если упал сервер в шарде (их рекомендуется 3 на шард), то всё работает как работало, как только добавляется новый сервер, он без проблем синхронизируется и вступает в бой с клиентами.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
С MySQL бывало и похуже, это нормально. Во-первых сервер не может просто так перезагрузиться — по крайней мере за год работы этого продакшена ни разу не было, во-вторых, два или три сервера уж точно одновременно не навернуться, но если это произошло — восстанавливать и вперед.
0
UFO just landed and posted this here
Интересно.
А сортировку он поддерживает?
Возможно ли на нем сделать подобное:
ORDER BY RAND()*hosts DESC LIMIT 5
то есть выводить 5 случайных документов, но вероятность показа будет больше у тех, у кого hosts больше.
А сортировку он поддерживает?
Возможно ли на нем сделать подобное:
ORDER BY RAND()*hosts DESC LIMIT 5
то есть выводить 5 случайных документов, но вероятность показа будет больше у тех, у кого hosts больше.
0
Сортировку поддерживает замечательно.
> 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
Нет. И это огромный плюс… MySQL любит делать фишки удобные для использования, но которые при этом кладут на производительность. Данная конструкция в MySQL вызовет фулскан всей таблицы и положит сервер на немаленькой табличке. Ведь чтобы отсортировать результат и взять сверху 5 элементов, необходимо каждый ряд в таблице проверить и положить в память результат, потом сделать сортировку пузырьком в памяти, а затем уже отпилить маленький кусочек и послать ответ клиенту.
Но есть и правильные пути. Например, задайте индекс по свойству hosts и делайте запросы hosts > min && hosts < max. Где min и max там ограничители выбираемой группы, которые задаются псевдослучайно с задаваемой вероятностью. Еще можно задать какое-то числовое свойство группы (в ней скажем 20 объектов), и выбирать запросом (k IN list) 5 таких групп, а затем выбирать для каждой группы случайный элемент (уже на клиенте). Согласен, может быть не очень красиво, за то это будет хорошо работать и на миллиарде рядов, а вот RAND() загнется куда раньше.
Да, придётся думать, но без этого никуда.
0
>А сортировку он поддерживает? Возможно ли на нем сделать подобное: ORDER BY RAND()*hosts DESC LIMIT 5
А этот пистолет стреляет? А ногу у меня получится себе отстрелить?
А этот пистолет стреляет? А ногу у меня получится себе отстрелить?
+1
Не стоит так все воспринимать.
Представьте, например, баннерную систему.
Миллионы запросов в сутки к скрипту, который отдает баннеры сайтам-партнерам.
Перед выдачей баннера, скрипт должен выбрать баннер из всех. Учесть кол-во кликов которые нужно отдать и т.д. и взависимости от этого вывести баннер.
Для таких задач что нужно использовать?
Поэтому я и поинтересовался насчет Mongo, вдруг она подойдет.
Представьте, например, баннерную систему.
Миллионы запросов в сутки к скрипту, который отдает баннеры сайтам-партнерам.
Перед выдачей баннера, скрипт должен выбрать баннер из всех. Учесть кол-во кликов которые нужно отдать и т.д. и взависимости от этого вывести баннер.
Для таких задач что нужно использовать?
Поэтому я и поинтересовался насчет Mongo, вдруг она подойдет.
0
Думаю, для таких как и для любых других нужно использовать в первую очередь разум, Mongo конечно подойдет.
Кстати, в первой задаче (про функцию RAND): индекс на hosts, и find().sort(«hosts»:1).limit(rnd(),1) нужное количество раз. rnd() — Ваша хитрая схема с вероятностями.
Вторая задача (про баннерную систему): думаю я бы инкрементил клики в Memcached, и скидывал бы изменения в MongoDB раз в минуту, например. А выборку баннера сделал бы по индексу само собой.
Кстати, в первой задаче (про функцию RAND): индекс на hosts, и find().sort(«hosts»:1).limit(rnd(),1) нужное количество раз. rnd() — Ваша хитрая схема с вероятностями.
Вторая задача (про баннерную систему): думаю я бы инкрементил клики в Memcached, и скидывал бы изменения в MongoDB раз в минуту, например. А выборку баннера сделал бы по индексу само собой.
0
Спасибо!
Очень поверхностно пока знаком с Mongo.
Как я понял rnd это моя фунцкция?
А возможно подобной схемой вытаскивать сразу 5-7 баннеров одним махом?
Очень поверхностно пока знаком с Mongo.
Как я понял rnd это моя фунцкция?
А возможно подобной схемой вытаскивать сразу 5-7 баннеров одним махом?
0
А с Cassandra Вы не сравнивали?
Тема очень интересная, особенно практические комментарии и примеры.
Буду рад видеть продолжение :-)
Тема очень интересная, особенно практические комментарии и примеры.
Буду рад видеть продолжение :-)
0
А почему не CouchDB? Скорость?
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
0
Не подскажете по вопросу ссылок:
Как я понял, ссылок на объекты в MongoDB нет. Как нам поступать на примере тех же комментариев, когда надо вытащить логин каждого автора коммента (разумеется, логин может изменяться, а привязка идет по id).
Спасибо!
Как я понял, ссылок на объекты в MongoDB нет. Как нам поступать на примере тех же комментариев, когда надо вытащить логин каждого автора коммента (разумеется, логин может изменяться, а привязка идет по id).
Спасибо!
0
расскажите про файловую систему на монго
0
Only those users with full accounts are able to leave comments. Log in, please.
MongoDB — варим хороший кофе