×Закрыть

MongoDB — ужас-ужас?


Хотел вот использовать MongoDB в одном из pet projects, но как-то часто слышу мнения что MongoDB время от времени портит БД, да так что она потом не подлежит восстановлению. И вообще, дескать, падучая дальше некуда.

У кого MongoDB в продакшене работает? Расскажите что и как.

Например, вот: bolknote.ru/2013/04/23/~3950/#07

Человек просто «не умеет готовить», или все реально так плохо?

Как альтернативу рассматриваю CoucnDB.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А мне кажется что если Вам попробовать свой pet — так вот несколько сервисов mongohq.com/, mongolab.com или objectrocket.com.
Спрячте доступ к БД за ORM/ODM (Например waterline). А когда дорастете до production сможете легко перейти на любую другую БД.
К сожелению сам не имею Mongo в production, но сейчас активно пилю свой pet на Mongo.
Судя по статьям Александра Белецкого Likeastore тоже построен на MongoDb.

github.com/...​onnectionStatus.java#L213

if (!((_ok) ? true : (Math.random() > 0.1))) {
return res;
}

Ну і казати «все, готово, записано!», коли реквест ше по клієнтському сокету не вийшов, це епічно...Так, це змінили. Вже. Але втрачати дані з монго, час від часу, походу доведеться..
На aphyr.com трохи розписано, не все, тіки часткові випадки, але...Якшо погуглити то статей на тему монго, в такому ж дусі, вистачає
П.С все ІМХО, досвіду використання в продакшені нема.

www.mongodb.org/...on-deployments ,

загалом є поняття write concern при записі, ступінь ризику визначає розробник

Я тут немного не в тему, но у кого был какой опыт с RethinkDB? Есть живые или pet проекты?
Ребята заявляют много интересного внутри, и там присутствует write concern, в отличие от монго.
Сами ребята из Rethink легко идут на контакт и отвечают на вопросы не перекрытые документацией.

Термин относится к согласованности данных. При weak write concern монга скажет ОК в момент получения запроса (даже если сам запрос не выполнился), при strong, — когда запрос віполнился и данные записаны.

Только оракл, только PL/SQL, только 15к$ в месяц!!

Еще немного ужастиков из интернетов:
aphyr.com/...e-maybe-mongodb

Тут человек много и интересно рассказывает о минусах mongodb: hackingdistributed.com/...01/29/mongo-ft
fair warning: он работает над другим nosql проектом

Эпичный пост. Оказалось автор не знает многих фич монги

fair warning: я тоже не эксперт, один раз прочитал книгу и написал для саморазвития ORM для MongoDB

>Оказалось автор не знает многих фич монги

а где и как это оказалось?

WriteConcern. Он в конце поста оправдывался

>More on REPLICAS_SAFE and MAJORITY levels of concern in a future blog post; it’s subtle, so it requires its own detailed writeup.
Это — оправдывание?

Это софизм. Вся статья о том, что монга не обеспечивает strict consistency, когда в нее пишут с не предназначенным для этого write concern. Это как жаловаться на то, что отверткой не получается заворачивать гвозди. При этом правильное решение, запись с MAJORITY, автор «оставляет на потом».
Статья определенно носит демагогический характер.

Лично я сторонник SQL + файловая система. SQL удобен для поиска и индексации, файловая система — для хранения и бэкапа. И подобные схемы на редкость живучие, в том плане что легко переживёт переезд на другой SQL, смену логики работы, интеграцию, и всемирный потоп.

MongoDB неприятен ошибкой человеческого фактора. Одна ошибочка в {казнить нельзя помиловать} — и ты сам похоронишь если не базу, то новогодние праздники.

Лично я сторонник SQL + файловая система. SQL удобен для поиска и индексации, файловая система — для хранения и бэкапа.
А как эксперты горизонтально масштабируют свои базы данных?

Банально. Ростом количества полей таблиц. Ключевые изменения в основном касаются таблиц с небольшим количеством записей. В случае действительно серьёзных перестроек — добавляют новые таблицы.

Да, если проект проживёт 10 лет, появится процент мёртвых таблиц. Которые не используются. И некислое количество мёртвых файлов, до которых никому нет дела. Вот тут самое время приглашать админа на оптимизацию, а до тех пор — спать спокойно и не думать.

Главное в базах данных — не форма, и не платформа. А документирование! Хватит пары-тройки недокументированных правок — и это уже могила времени разработчика. И поверьте, есть разница когда эти правки в SQL, а когда — в документо-ориентированной базе.

Я не считаю преимуществом отход от типизации и стандартизации. И да, предпочитаю пожертвовать десятком гектар диска на избыточность, чем на живом продакшене проводить расследования под давлением трёхэтажного руководства ASAP.

База данных по сути это что? Именнованные массивы. Их логика повторяет человеческую, а потому файловые системы — идеально подходят для документо-ориентированных баз. Плюс к тому, фаловые системы в большей мере стандартизированы, легки для бэкапа/переноса, и в особенности — для кеширования!

Но... я против SQL как такового, считаю что он устарел. Тем более при общении с ним через многослойные абстракции. Я бы хотел базу данных, которая являлась бы продолжением языка программирования, и позволяла бы просто и незатейливо иметь медленное хранилище. С той же логикой избыточности и оптимизации.

Вообще я бы хотел, чтобы база данных была операционной системой. Честно стартовала бы на железе, минуя всякого рода абстракции, имела бы свою файловую систему, и скорее всего — своё, более дешёвое железо. И чтобы её можно было купить как SATA-носитель (либо RAID), вместе с софтом на борту и дополнительным софтом для апгрейда на более дорогой носитель.

Фактически, это и была бы файловая система. Но другая. И насколько я слышал, Империя добра такого зверя имеет. Но мы — не гуглы, и нам бы ограничиться стабильными схемами. Немного доплатив за избыточность. Однако, с каким же рвением мы бежим за модой на новые технологии. И как же хорошо они «забытые старые».

Вот это пациент

И да, предпочитаю пожертвовать десятком гектар диска на избыточность
Горизонтальное масштабирование становится актуальным когда у тебя база террабайт 10, и трафик 1000qps, а не десяток гигабайт

Вот на такие цели MongoDB стоит задействовать. Когда данных много, а работы над самими данными проводится сравнительно мало (и ночью). Для таких целей он и создавался.

Согласись, когда база набирает терабайтные объёмы, проект уже в серьёзном продакшене. И админ уже может предсказать, что с ним случится дальше, какие данные какой обработке подлежат. Я считаю, только тогда следует думать о переходе на MongoDB — при первом и последующих рефакторингах проекта. Либо если проект заведомо является клоном, и его поведение известно заранее.

Переход может быть достаточно плавным, если не сказать вечным. Часть структуры вероятно так и останется на SQL. То самое горизонтальное масштабирование. На больших проектах архитектура чаще многозвенная, и поддерживается достаточно большим объёмом кода. Это даёт ей живучесть. И этот код без проблем позволит проводить рефакторинг частями.

Я считаю, не стоит прыгать на Монго всем подряд и на авось. У него своя ниша, и как минимум нужно почитать что оно зачем. Ключевая его польза даже не в масштабировании, а в лёгкости дробления. Иголка в стоге сена — вот на что похожа его работа!

И ещё раз повторюсь, файловая система дефакто является тем же самым, вопрос лишь в удобстве организации и последующей индексации. С файлами однозначно проще и привычнее работать в плане хранения и кеширования — их поддерживает операционка и туева хуча софта. Но если идёт работа с мелкими частями файлов — операционка пасует по производительности.

Такой подход тоже имеет право на жизнь, но требует значительных инженерных инвестиций во время прыжка с rdbms в nosql.

только тогда следует думать о переходе на MongoDB — при первом и последующих рефакторингах проекта
Проектированием/анализом не занимайся/прототипов не создавай — сразу пиши код.
Переход может быть достаточно плавным, если не сказать вечным. Часть структуры вероятно так и останется на SQL. То самое горизонтальное масштабирование.
Вы только что произнесли новое слово в понятии «горизонтальное масштабирование». Я в восторге.

Но ведь каждый стартап обязательно будет страдать от проблем BigData уже сразу после первого миллиона пользователей

До миллиона пользователей надо дожить. А то я постоянно слышу в разных проектах про миллионы пользователей и миллиарды запросов. Горе-архитекторы выдумывают крутые слои абстракции и хитрые схемы масштабирования. А потом потыкаешь палочкой, а оно на 10 залетевших дятлах пользователях падает.

Есть много проектов в которых и на первом пользователе появляется биг дата и много запросов в batch pipeline, например поисковики

А, это согласен, сейчас что не студент, то с амбициями на новый гугл.
А потом как я и говорил:

А потом потыкаешь палочкой, а оно на 10 залетевших дятлах пользователях падает.

Мой код вонюч, могуч и волосат.

Не страдаем, вовсе. Я даже не уверен что у нас есть BigData поскольку нигде не читал его определений. Но 1млн уникальных посетителей в сутки есть. Правда монго и не используется.

Я петросянил по поводу итоговой смерти почти всех стартапов, которые при этом поголовно с первого дня считают себя фейсбуками

считаю что он устарел
Уже лет 5 так говорят, но все же юзают
База данных по сути это что? Именнованные массивы
Как-то про реляционную алгебру ты совсем забыл, наверное её забыли задокументировать и она стала могилой времени для джавадевелопера в забугорье
при общении с ним через многослойные абстракции
Так юзай raw-sql, фигач меткие и лаконичные запросы, где дух молодости и вседозволенности?
Фактически, это и была бы файловая система. Но другая. И насколько я слышал
hdfs, hbase и все что дальше? Ну вообще оно как бе вполне опенсруц.
Я бы хотел базу данных, которая являлась бы продолжением языка программирования
ZODB? Cache? Если погуглить, можно еще несколько примеров вспомнить.

как-то худо у вас там в забугорье с доступом к техблогам и гуглам

Вседозволенность — верно. Именно вседозволенность заставляет задаваться вопросом, а стоит ли ставить упомянутый ужас-ужас. И разве не вседозволенность, вопреки «техноблогам и гуглам» заставила создать базу данных, которая по тем меркам была ни рыба ни мясо?

В теории все хороши. Но как только появляются реальные проблемы — перерасход времени на разработку, сложности поддержки, чудеса репликации, случайный развал базы и... всеми любимый ASAP — почему-то разработчик остаётся один на один со «своими» проблемами. Ещё хуже, когда админ, уже без разработчика. А бывает когда и админа нет, и проект умирает.

Многие ли из вас, прежде чем что-то новое ставить, спросили на ДОУ? MongoDB заслуживает пристального внимания. И уйти потом куда-то, отказаться от подобной абстракции в будущем — будет практически невозможно в короткие сроки. Для живых проектов, это будет значить заплатить за нестыковки из своего кармана, и смириться с ними. И это — ужас, обратная сторона вседовзоленности.

Ещё хуже, когда админ, уже без разработчика. А бывает когда и админа нет, и проект умирает.
Печально наблюдать тенденцию, когда «програмысты» лезут писать код без понимания того, что происходит в системе их поделие исполняющей.
А разработчик не разбирающийся в администрировании целевой платформы — говно, а не специалист,
Многие ли из вас, прежде чем что-то новое ставить, спросили на ДОУ
DOU — не технический ресурс.
уйти потом куда-то, отказаться от подобной абстракции в будущем — будет практически невозможно в короткие сроки
У каждого ухода должна быть обоснованная причина. Пока что это напоминает причитания церковной бабки о необходимости шапочек из фольги и излучении из космоса.

Скажу кратко — там грабли! Оданко «туда не ходи» — не наш метод, наоборот — узнавайте больше.

Большинство проектов не ведутся создателем пожизненно. Им живучесть необходима как вохздух. Я сам наблюдал смерть интересных мне ресурсов, и ничего не мог сделать. Владельцы не верят, когда я говорю: это не «маленькие проблемы» и не «проблемы пользователя» — ресурс [имя] умирает.
Конкретно в случае MongoDB ключевой фактор — огромный размер. Если он планируется, преимущества превысят недостатки. Если нет — будет как в анекдоте, когда на Запорожец прицепили дворники от Белаза.

PS. DOU таков, каким его делаем. Согласен, лично я бы использовал sql.ru или rsdn — доу лишён подобного комьюнити. Может так случиться, я этого захочу — и оно появится :)

будет как в анекдоте, когда на Запорожец прицепили дворники от Белаза.

Напомните анекдот? :-)

Дождь. Едет Запорожец. Запорожец мотает по всей дороге из стороны в сторону. Его останавливает гаишник.
— Почему так едем!?
— Дык, дворников в продаже не было, я от Белаза поставил!

// анекдот времён перестройки

имела бы свою файловую систему
нну это можно устроить, что оракл (с версии 3 и или 7) что мускуль (вроде как) может использовать разделы

но имея опыт под параллельной нагрузкой, я могу сказать что основная проблема баз — локи, ибо если два потока (запроса) хотят поменять одну страницу данных, то один из потоков будет ждать
совершенно эпично это выглядит на ненастроенных базах — загрузка процев 5% а база нереально тормозит

Что есть — то есть. И рефакторингу места в базах немало...

Но Mongo проблемы сама по себе не решит. Хотя не спорю, потребует более грамотно отнестись к архитектуре, и больше подумать.

ну за монгу я ничего не скажу, ибо не тестил

но имея опыт под параллельной нагрузкой, я могу сказать что основная проблема баз — локи, ибо если два потока (запроса) хотят поменять одну страницу данных, то один из потоков будет ждать
совершенно эпично это выглядит на ненастроенных базах — загрузка процев 5% а база нереально тормозит
Криворукие программисты?
Криворукие программисты?
скорее мало опытных

Видео бы еще :/

Ну хотя бы текст нашел
maurits.vanrees.org/...ar-with-mongodb

I don’t want to do this again. I want to use Postgres.

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

до этого ещё на одном проекте использовал, для хранения агрегированной статистики, работло очень хорошо, но в бекенде ещё postgres сидел и хранил более сырые данные, а самые сырые хранились в кубиках mssql

в целом хочу отметить, что с ней очень просто работать, но продумывать структуру стоить тщательней, чем для sql баз, очень уж много соблазнов из-за schemaless, которые могут вылиться потом в очень непростые запросы :)

CouchDB и MongoDB очень разные базы. Если весь предыдущий опыт связан с реляционками и хочется комбинации реляционных связей + пощупать мап-редьюс — то однозначно монго. С коучем никакого подобия реляционности в пределах базы нет. Есть возможность выгребать подчиненные документы, но это отдельная история. В чем хорош коуч — это в скорости выборки по несложному набору ключей (условий) однотипных(!) документов. Что делает его привлекательным в, например, накоплении статистики и отображении ее. Любая запись в базу автоматически индексируется и выборка происходит очень быстро: наподобие materialized view в том же оракле или мсскле или постгресе или мускуле с определенным расширением. НО, если вы вдруг захотите добавить еще одну выборку в продуктовую базу (расширить дизайн-документ) и в вашей базе уже несколько миллионов записей, то будьте готовы к нескольким десяткам минут (часам) даунтайма, когда достать данные из базы вы сможете только по айди документа и никаких выборок по составным ключам/по полям вам не светит. Также интересный момент в коуче — это сортировка. Если не надо сложных сортировок и устраивает вполне стандартная сортировка по ключам — то вопросов нет. НО если воспользоваться list-функцией для более изощеренной сортировки/группировки/трансформации результата — то скорости куда более плачевные чем в мускуле. Еще важным моментом являются способы подключения к базе. У коуча только хттп/рест. У моного — бинарный протокол (как в муцкуле и подобных). Поэтому если вы создаете приложение с интенсивной нагрузкой на базу, которое, к примеру, делает кучу движений к базе чтоб уподобиться работе с реляционкой — то выбор не в пользу коуча. Шардинг — в коуче либо все, либо ничего. С расширениями (сам не пробывал) вроде можно добиться такого же (почти) результата как в монго. Если хочеться романтического чтива — почитайте книжку Seven Databases in Seven Weeks. В ней довольно доступно описан коуч, раяк, и даже нео4дж. По монго можно глянуть что-то типа MongoDB in Action (Manning — 2012)

На couchdb его создатели уже давно забили, и давно уже пилят новый велосипед: couchbase, и говорят что он супербыстрый и прочие блаблабла.

CouchDB is a document database providing replication, MapReduce and an HTTP API. Couchbase uses CouchDB as its backend, “wrapping” it with advanced features like caching, and is designed to be clustered

Это конкуренты дизинформируют, вот здесь написано что они взяли за основу membase, перетащили туда куски кода из couchdb, и переписали что бы достигнуть хорошей производительности: www.couchbase.com/...base-vs-couchdb

Для пет-проекта использую mongoHQ пока не падало и не теряло, но там данные смешные по объему.

На монгу косо смотрю после одного видео с описанием мытарств, когда бд вырастает из ОП.

Если думать, что проект не на выброс идет, то не стоит экспериментировать — постгрес/мускул ваш товарищ.

А если упороться, то code.google.com/p/leveldb

постгрес/мускул ваш товарищ.

Хочу documented-oriented DB. Именно поэтому и возник вопрос про MongoDB & CouchDB

В деле выбора главное заранее не навешивать ярлыки: лучше сделать список хотелок, что от базы нужны и желательны, а потом сверять с тем что у БД есть.

В постгресе, допустим, есть www.postgresql.org/...tic/hstore.html

Опять же, лучше самому один раз попробовать, чем 100 раз услышать

Ну, вот я с монго поигрался — мне вполне нравится подход document-oritented и map/reduce в рамках моих «хотелок». Проще и прозрачнее, чем в традиционной парадигме SQL & relational DB.

Более подробные хотелки и плюсы/минусы вылезут уже в процессе «ваяния». Меня в данном случае волновал вопрос стабильности и капризности монги.

Хорошая вещь при таких случаях использовать Sybase SQL Anywhere

А что есть беслатная версия, не обрезанная по самое «не балуй»? Бесплатная версия думаю и sqlite-у сольёт.

Чуваки, а вы вопрос вообще читали?...

Мы сюда не читать пришли, а писать.

Да, но хотелось бы как-то писанины по теме.

Firebird — вероятность падения баз даже с выключением сервера через выдергиванием кабеля питания — стремится к нулю. Кроме того даже рухнувшая база элементарно чинится автоматически или вручную (100$ за восстановление базы в 10GB+ где админом был школоло).

Единственный способ гарантированно убить базу — установить на fat32 и чтобы база набрала более 4 гб размера (перетирается заголовок и не стоит защита от этого).

А какие нынче базы убиваются выдергиванием кабеля? Помоему все отлично рекаверятся из WAL-a автоматически при старте без 100-а баксов.

С Ораклом знаю много проблем было при внезапном падении сервера. Собственно мнение сообщества, что Firebird по надежности топ, практически неубиваемая. Если настроить теневые копии базы то при падении оборудования довольно быстро даже без кластера поднять базу.
www.firebirdsql.org/...fix-shadow.html

Ну и кластер на ней строится без усилий, но уже не бесплатно (репликатор денег стоит).

С Ораклом знаю много проблем было при внезапном падении сервера.
/dev/hands device is corrupted видимо
Ну и кластер на ней строится без усилий, но уже не бесплатно (репликатор денег стоит).
А у остальных бесплатно, и даже с автоматическим failover и master to master replication.

Ну для FB тоже есть бесплатный, но он не особо www.meta.com.au/...structure_id=40

Все пользуются платным IBReplicator так как надежность, скорость и поддержка. Причем кластер на 50+ машин для него держать как нефиг делать.
www.ibphoenix.com/...re/ibreplicator

Просто база очень уж быстрая, так что необходимости в репликаторе практически нет, проще поставить 4-8-ядерный процессор чтобы легко обрабатывала в день 500 млн запросов.

Причем кластер на 50+ машин для него держать как нефиг делать.
Шота сомневаюсь, это походу какой то statement based репликатор, который по определению тормознее binary logs replication, ну и он не поддерживает автоматический failover и master to master репликацию, т.е. это технология уровня 90-ых годов
Просто база очень уж быстрая
Неплохо было бы приложить бенчмарки сравнения с другими решениями

Я это все к чему, непонятно зачем использовать firebase на который все давно забили, он не развивается, имеет ограниченную поддержку архитектур, без рынка админов, если postgres делает больше и имеет огромное сообщество.

Postgres сложнее. Кроме того у FB есть одна уникальная фича очень нужная для локальных приложений — можно поднять локальный сервер внутри процесса приложения, причем работать с ним как с сетевой версией. Поэтому многое ПО сейчас использует для хранения локальных данных именно FB.

Тоесть сейчас FB это нечто среднее между SQLite и тем же Постгресом. По эффективности и скорости рвет в ошметки все Express версии платных серверов.

По эффективности и скорости рвет в ошметки все Express версии платных серверов.
Ну я же просил бенчмарки?

Постгрес за 4 года значительно прибавил в обработке конкурентных запросов: rhaas.blogspot.com/...w-about-64.html

А можно подробнее про такие проблемы с ораклом, которых файерберд успешно избегает?

Блин, ну и зачем мне информация про Firebird?

Блин, ну и зачем мне информация про Firebird?
Одумайсо заблудшая душа! Ты еще можешш перейти на Делфу и другие «продвинутые» технологии! :)

Ага, осталось призвать в тему патриотов Украины и специалистов по зарплатам в Америке...

Собственно, FB очень неплохо используется и для Java проектов, так как очень легкий движок и идеально сочетается с легким JavaEE типа Томката.

FB очень неплохо используется и для Java проектов
А зачем? Что он может такого чего не могут __мейнстримовые__ БД? Или чем он интересен так же как и модные сейчас НоСКЛ?
идеально сочетается с легким JavaEE типа Томката.
Поясните данной утверждение подробнее.

Используется, например, для очень облегченного веб-сервиса устанавливаемого в один клик, типа управления сетевыми принтерами.

Что он может такого чего не могут __мейнстримовые__ БД?

Может не падать 10 лет у тетеньки бухгалтерши, где админом работают обычно школьники 8-10 классов. Тоесть надежность как у советской танковой рации, где можно их сложить в кучу метнуть гранату и все будет продолжать работать. Ну и скорость где-то даже на 5-10% выше чем у PostgreSQL.

Кроме того можно провернуть такую штуку, как старт сервера внутри самого процесса Tomcat, тоесть для сервера не нужны дополнительные порты и на компьютер может быть установлено 100500 разных версий оного, не мешающих друг-другу.
embedded-firebird.blogspot.com

Может не падать 10 лет у тетеньки бухгалтерши, где админом работают обычно школьники 8-10 классов.
MySQL, H2 тоже так умеют.
Кроме того можно провернуть такую штуку, как старт сервера внутри самого процесса Tomcat
H2 (HSQLDB). При том она чисто на джаве.
При том у этих БД есть мега-плюс — они мейнстримовые.
H2 (HSQLDB).

Где-то были тесты, что Firebird в 15000% быстрее чем HSQLDB для баз более 2Гб.

Где-то были тесты, что Firebird в 15000% быстрее чем HSQLDB для баз более 2Гб.
Шикарно.
1) Где это так же интересно. Но куда важнее Когда? До где-то 2010 она была полу-мертвой (поэтому и появилась H2)
2) Любые тесты ситуативны, приведите ссылки посмотрим.
3) Допустим таки медленнее. Абсолютные цифры и задачу привести можете. Что за задача была?
------
А теперь самое важное:
При том у этих БД есть мега-плюс — они мейнстримовые.
Банально зайдите на линкедИн и посмотрите скилы и статистику связанные с Firebird, MySQL, PostgreSQL или даже H2. А потом задайтесь целью найти джависта который будет поддерживать код под фаербирд.
надежность как у советской танковой рации, где можно их сложить в кучу метнуть гранату и все будет продолжать работать

Это преувеличение. А вот давеча купил КВ4 — знаю о чем говорю.

попробуйте тесты на коаче погонять,я когда пробовал — было катострофически медленно

Как раз вот собрался этим заняться.

Насколько я понимаю, MongoBD быстрее потому как стремится все что нужно запихнуть в RAM — в то время как CouchDB дергает HDD. Скорость, конечно, хорошо, — но и бесконечное пожирание памяти не есть хорошо. Если на CouchDB поставить SSD, то может быть будет и не так все медленно. Собственно, это я буду пробовать.

Но меня вот больше пока смущает нытье про развалившиеся базы на MongoDB. Причем, нытье достаточно свежее. Особенно, если сервер в силу каких-то причин был внезапно перезагружен. Я погонял базу пару недель — вроде бы все хорошо, все нравится, ничего не разваливается.

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

Ставить дополнительные реплик-сервера сугубо под DB — как-то выглядит излишним для небольшого проекта.

в то время как CouchDB дергает HDD
Думается couch тоже имеет какие то буферы из которых тащит данные без дергания диска. К тому же монгодб ничего не стремится, он mmap-ает файлы данных и дальше обо всем заботится ОС
Не хотелось бы просто все сделать, перевязать ленточкой, — а потом через полгода обнаружить что из-за Mongo все умерло однажды и навсегда.
Ну тогда уже брать проверенные временем MySQL/PortgreSQL
сервер в силу каких-то причин был внезапно перезагружен
Я встречал даже жалобы на ext3 fs, которая внезапно теряла старые файлы в таких ситуациях. Это все «детские болезни» проектов.
Ну тогда уже брать проверенные временем MySQL/PortgreSQL

Вопрос был не в выборе БД вообще, а в выборе «document-oriented DB»

Видимо в этом и проблема, что сейчас нету document oriented DB, которые были бы стабильны и одновременно удобны в использовании.

Меня удивляет больше другое — то что на ДОУ никто их вообще не использовал. Всего 1-2 ответа по теме. Украинский аутсорс такой аутсорс...

Тут таки принято обсуждать зарплаты ;/

Напрашивается закономерный вывод: buzzwords/keywords.

а что вы хотели? Если ответы- то проще на редите такое спросить
а с поболтать на технические темы на доу довольно глухо как по моему опыту

А что такое «Старая версия биткоина работала»? Ты имеешь в виду какой то конкретный клиент или биржу?

Извиняюсь, попутал с Berkley DB,
MongoDB в версиях биткоина не использовалась вообще!

Ты имеешь в виду какой то конкретный клиент

да, локальный клиент версии 7.2 вроде,

в определенный момент времени запись не была внесена в базу из-за чего произошел сплит биткоина на 2 независимые базы с версиями 7.2 и 8.0. Одну из которых к счастью аккуратно прибили ...

рекомендую LevelDB
А как может embedded key value база заменить распределенную document oriented базу со всякими плюшками вроде вторичного индекса, full text search, map reduce, aggregation framerworks, etc.

Технически, я как хардварщик не могу оценить сложность «переезда» однако ...
я рекомендовал Level DB отталкиваясь от критериев надежность / производительность. С функционалом конечно вопрос интересный ...

nosql.mypopescu.com/...fit-for-mongodb

вже дость довго(близько півтора року) mongodb використовую як основну бд, наразі мав певні проблеми з тим що нема транзакцій. Більше нарікань нема.

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

Александр Соловьев (solovyov.net) использует. Отзывался плохо. Из серии «у нас с ней проблем больше, чем со всем остальным вместе взятым». В целом нагуглить десятки статей на тему mongo sucks можно за секунды, в камментах к статьям что на Proggit, что на HN полно аналогичных историй и советов по тому, как облегчить боль. В целом, если ожидается нагрузка, то Монгу лучше не брать, а взять что-то более bullet-proof, вроде Postgre или MySQL, если нужен Query Language, или Riak, HBase или Cassandra, если нужна производительность.

К вам вопрос: нафига вам оно? «Не думать о базе» — не вариант, думать надо.

К вам вопрос: нафига вам оно

Буду краток: захотелось

«Не думать о базе» — не вариант, думать надо

Имелось ввиду «один раз настроить и не возвращаться». Наверное, кому-то нравится по ночам не спать и думать о базе и, наверное, это очень круто и лелеет ЧСВ; но мне так не надо, спасибо.

с базой так не бывает если предвидятся нормальные нагрузки. придется думать.

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

Во-вторых, я же по-русски написал: «pet project». Я не строю новый фейсбук.

Приятно, конечно, что на ДОУ концентрация специалистов по highload выше чем где бы то ни было в мире, — но вопрос был ведь не об этом.

Это сейчас постгрес «перестал» требовать внимания. В 7-х версиях забыл настроить вакууминг по расписанию и прощайся со скоростью после пары дней хорошей нагрузки

Ты забыл добавить что в те времена монго и в проекте не было

Используем на продакшине больше года, есть свои плюсы и минусы.

портит БД
 — не было ни разу
падучая дальше некуда.
— было 2 раза когда монго не поднялась после аварийного выключение питания в датацентре (спасибо «воле»), запустилась после минутного ручного вмешательства.
Используем в реплике, что и всем рекомендую.

Из недостатков самый существенный — отсутствие транзакций (кривоватые костыли не в счет). Также важно учесть что требуется другое мЫшление после реляционных БД, если от map/reduce начинает закипать мозК — лучше не связываться.

На момент выбора (года полтора назад) CouchDB под виндой тупо не захотела запускаться, потанцевали пару часов с бубном и списали её в утиль...

Из недостатков самый существенный — отсутствие транзакций
В монго никогда и не заявлялась поддержка транзакционности. Она как бы eventual consistent и вообще async write делает. Это не недостаток, это by design.
В нашем проекте используется связка mongodb для хранения сложных структур + postgresql, для данных, требующих транзакционный подход записи/обновления.
Некое подобие транзакций в монго, если так уж хочется стать ближе к этому подходу — использование «вложенных» документов
async write
можно и отключать, это не константа

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

провал производительности будет эпичный

Плюс-минус до скорости rdbms

Очень минус, многие rdbms делают fsync по умолчанию сильно позже коммита транзакции, иначе машем ручкой буферам, отложенной записи и прочей оптимизации производительности.

многие rdbms делают fsync по умолчанию сильно позже коммита транзакции
Пруфлинк? Или опять откровения школоты?

А где там конкретно подверждение того что ты написал? Можешь пожалуйста процитировать?

О, чудесная тема. Так все-таки можем мы увидеть пример реляционных СУБД, где по умолчанию журнальный компонент не ожидает подтверждения от файловой системы на запись?
А заодно пролейте свет на вот эти вот особенности реализации — «буфера, отложенной записи и прочей оптимизации производительности».
Очень просим)

Хотя вариант погонять это дело на SSD еще может быть интересным. Но на SSD гораздо симпатичнее использовать тот же PostgreSQL. Для сравнения — у нас 437 тестов на mbp с ssd прогоняются секунд за 17-20, в то время как на обычном десктопе это занимает около 2.5 минут

Про монговский map-reduce написано уже много, производительность у него плачевная, по сравнению даже с ветхой CouchDB. Гораздо приятнее там выглядит aggregation framework.

Из свежих плюшек — full-text search там работает прикрученном СLucene, но в итоге — синхронное создание индексов, отсутствие стемминга и забудьте про ранкинг, проще сбоку поставить elasticsearch или вообще использовать его вместо MongoDB (кстати, есть попытки такого подхода в продакшне, с шардингом и отказоустойчивостью всё на много приятнее)

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

Ок, я тут перечитал доку, действительно — отсутствие стемминга существует только для keyword search, но природа стеммера, который используется в text-search пока неясна, как настраивать с stopwords и прочие прелести для не-английских языков — тоже пока не сильно очевидно. Так что остаемся с elasticsearch в любом случае (:

Могу сказать что знаю несколько проектов где она нормально себе работает. По Интернету циркулируют обрывки титанического флуда годичной (или двухлетней) давности, большинство технических претензий там, сейчас уже невалидны. Я бы сравнил ее с MySQL — ну может каких-то фич в сравнении с постгресом или дб2 и нет, и менее надежна, зато проста в обслуживании и самая распространенная из NoSQL, так что все используют, ну и так как ее все используют — она развивается быстрее.

Да вот мне и хотелось бы «поставить и забыть». С той же MySQL так вполне получается. Я не хочу чтобы БД постоянно требовала внимания. Однако, вот по ссылке товарищ жалуется на ужас. Недавно еще что-то из свежего пролетало у кого-то. Теперь сомнения меня одолевают...

«поставить и забыть»
с монго может не получится при некоторых сценариях использования

Ну, у меня сценарий, по идее, достаточно простой. Это просто небольшой pet project с целью «попробовать в деле».

Для pet project — отличный вариант. Проблемы могут быть с большой постоянно обновляемой базой при ограниченных ресурсах сервера.

В данном случае — насколько «большой» и «ограниченных»? Хотя бы в попугаях.

Грубо:
Идеально — база влазит в память, хорошо — индексы влазят в память, нормально — индексы влазят в выделенное «окно» памяти, терпимо — часто используемые индексы влазят в «окно».
На диске желательно чтобы был хотя бы 3-5 кратный запас места по сравнению с текущим размером базы.
Если ресурсы позволяют — сразу ставить реплику с базами хотя бы на разных дисках (лучше — серверах), это позволит шаманить с базой без даунтаймов, включая обновление на новые версии что случается довольно часто, монго все еще активно развивается

Коллекция на 24 с половиной ляма документов:
Индекс на одно поле занимает занимает около 1,1 гиг памяти.
Индекс по двум полям в той же коллекции занимает места почти два гига памяти.

поставить и забыть
1) только на выделенную ноду/инстанс — при mmap с ростом объема данных увеличится потребение памяти.
2) простейшие выборки на малом объеме данных без индексов тормозить не будут, с ростом объема хранимых документов нужно будет об этом заботиться
3) map-reduce в монго — лучше бы его там не было, выполняются в одном потоке, производительность: на шарде из 3-х серверов обработка 10М документов заняла 15 минут

Тащемта, если твой pet удовлетворится объемом до 500к документов, то можно полетать и так

зато проста в обслуживании
А остальные сложны? Помоему монго не выигрывает в простоте например у кассандры.
так что все используют, ну и так как ее все используют — она развивается быстрее.
Какой то неочевидный вывод, развивают прогаммисты которые ее пишут а не сообщество. Тот же постгрес обгоняет mysql в развитии.

Ты, как возглавивший ТОП троллей — не хочешь высказаться по топику? :)

У меня нету опыта работы с монго продакшне, поэтому сказать особо нечего, я не знаю портит ли она данные и насколько стабильна.

постгрес обгоняет mysql в развитии
Пруфлинк? Или опять откровения школоты?

Ну для меня киллеp фичами были транзакционный полнотекстовый поиск, GIST, online transactional ddl, hot backup. А ты можешь хоть одну фишку mysql назвать которой не хватает postgres, школота?

Хоть одну — welcome: insert on duplicate update. (решается на встроенных процедурах но имхо — костыль)
Человеческая репликация аналогично — до 9-й версии была сторонним решением

Хоть одну — welcome: insert on duplicate update. (решается на встроенных процедурах но имхо — костыль)
Да ну, следующий код легко делает то что тебе нужно.
UPDATE table SET field=’f’ WHERE id=1;
INSERT INTO table (id, field)
SELECT 1, ’f’
WHERE NOT EXISTS (SELECT 1 FROM table WHERE id=1);
Человеческая репликация аналогично — до 9-й версии была сторонним решением
А что плохого в сторонних решениях? Постгрес как тру open source проект в отличие от mysql-a это вообще колекция сторонних патчей.

2 запроса вместо одного. Второй с двойной вложенностью. Круто чо.

А что плохого в сторонних решениях
абсолютно ничего (: перечитай свои вопросы, школота.
запроса вместо одного. Второй с двойной вложенностью. Круто чо
Т.е. то что нужны какие то костыльные хранимые процедуры ты согласен что сзвиздел? Ну и что ты думаешь делает под капотом mysql что бы обеспечить такую же семантику для множества движков хранения?
абсолютно ничего (: перечитай свои вопросы, школота.
Слив как он есть
Т.е. то что нужны какие то костыльные хранимые процедуры ты согласен что сзвиздел?
Ок, у нас есть 2 косых варианта реализации этой штуки. Одно ты нагуглил, второе выглядит как-то так:
CREATE FUNCTION merge_db(key INT, data TEXT) RETURNS VOID AS
$$
BEGIN
LOOP
UPDATE db SET b = data WHERE a = key;
IF found THEN
RETURN;
END IF;
BEGIN
INSERT INTO db(a,b) VALUES (key, data);
RETURN;
EXCEPTION WHEN unique_violation THEN
END;
END LOOP;
END;
$$
LANGUAGE plpgsql;
Слив как он есть
Лососни тунца, ты просил примеры, тебе их привели, дальше ты тупо увёл тему. Кто слил?
Ок, у нас есть 2 косых варианта реализации этой штуки. Одно ты нагуглил, второе выглядит как-то так:
И что ты сказать хотел? В mysql нельзя написать зачем то совсем необязательную процедуру для таких же целей? Тренируй логику, школота?
Лососни тунца, ты просил примеры, тебе их привели, дальше ты тупо увёл тему. Кто слил?
Школота, твои же примеры неправильные оба, я обьяснил почему.
твои же примеры неправильные оба, я обьяснил почему.
Конечно, я принял к сведению мнение воинствующего школьника
И что ты сказать хотел?
У вас отличный скилл гугления же

А вообще был запрошен пруф

Тот же постгрес обгоняет mysql в развитии.
Конечно, я принял к сведению мнение воинствующего школьника
О, опять слив, я сегодня в ударе.
У вас отличный скилл гугления же
А вообще был запрошен пруф
Тот же постгрес обгоняет mysql в развитии.
Ну я тебе привел список фич, или вы еще в школе какие то аспекты чтения не проходили? Тогда извини.
О, опять слив, я сегодня в ударе.
Ты почему-то решил, что привел контрпримеры реализации несуществующей фичи, по-сути костыли/обходные решения.
Ты конечно мастак оправдывать разработчиков постгри, но пойми же наконец, нету этого функционала там из коробки.
Да, чуваки молодцы, что к 9-й версии пришли к репликации, когда у всех нормальных продуктов она давно уже есть. О чем это говорит? Догоняют, малацца,
но не задают темп. Это как «вечная невеста» линупса.
я тебе привел список фич
Ты как-то резво присвоил себе чужие заслуги? Где и какой список фич ты привел? Ответил костыльным решением с переходом наличности? Да я смотрю ты мастер аргументации. Чему вас только в школе учат
Ты почему-то решил, что привел контрпримеры реализации несуществующей фичи, по-сути костыли/обходные решения.
Ты конечно мастак оправдывать разработчиков постгри, но пойми же наконец, нету этого функционала там из коробки.
Какую именно функциональность ты имеешь в виду? Конкретнее выражайся.
Да, чуваки молодцы, что к 9-й версии пришли к репликации, когда у всех нормальных продуктов она давно уже есть. О чем это говорит? Догоняют, малацца,
но не задают темп. Это как «вечная невеста» линупса.
Понимаешь, некоторые продукты развиваются модульным путем. Вот линукс это по сути только ядро, который без сторонних дополнений или доработки напильником не запустится вообще, но у тебя же не повернется надеюсь язык набросить что он догоняет винду на серваках? Так и с постгре и репликацией. Хотя для школоты такие мысли могут оказаться сложноватыми согласен.
Ты как-то резво присвоил себе чужие заслуги? Где и какой список фич ты привел? Ответил костыльным решением с переходом наличности? Да я смотрю ты мастер аргументации. Чему вас только в школе учат
Я ответил тебе в первом же ответе на твой вопрос про пруфлинк, но ты похоже не только школота но и жирный троль.
проста в обслуживании

Основное все же что они проще в разработке. Причем проще чем реляционки. Ведь большинство OneToMany — это выражение отношения parent child, для который и создан документ MongoDB. Потом получается что вместо 30 таблиц у вас 5 коллекций, с которыми вы работаете вообще как с многоиндексными Map

Подписаться на комментарии