PostgreSQL 9.4 vs MongoDB
MongoDB в топку или он еще чем-то круче до сих пор?
Igor Golodnitsky, те самые 5k$ в PreciseQ
Facebook
Twitter
LinkedIn
Artem Korn
Сталкивался с MongoDB много раз за последние 3 года на разных работах. Общий вывод — монге нельзя доверить что-то кроме логов или аналогичных некритичных данных. Шардинг в монге — это для совсем ленивых, кому лень встроить в свой проект прослойку для <любимое средство общения с БД в вашем языке/проекте> для собственной реализации шардинга. А сколько я нервов потерял при настройке монги и ее replica set’ов в 2012 году... Сейчас конечно дела обстоят немного лучше, но все равно, до уровня надежности любых SQL-решений монге как до луны раком.
Sergii Kudriavtsev
Bogdan Shyiak
JSONB, SQL, ля-ля, фа-фа, а тем временем монге дали еще 100 лямов techcrunch.com/...funding-filing
Andy W
и один из комментариев там же
I wonder if $80.000.000 can turn mongo into a real database
Ivan Levchenko
anonymous
Ihor Dvoretskyi
Залупа или сыр?
Пахнут-то одинаково!
Kotiki і чай
idOne Арбузный
На малих об’ємах даних, малій інтенсивності запису-читання — байдуже
На великих — постгрес
Біль і розпач — впровадження монго в яндекс диск
events.yandex.ru/...lib/talks/2325
Alexey Vasiliev
PostgreSQL 9.4 vs MongoDBСравниваем теплое с мягким? Контекст задачи использования решает.
reality_hacker
Расскажи, в каком контексте рулит монго?
Alexey Vasiliev
1. Складирование логов. За счет capped колекций логи будут сами подчищаться и не забьют место на жестком диске.
2. Meteor. В чем смысл заменять MongoDB у этого инструмента (или подобных ему) на другую базу? Тут у монги есть хоть REST интерфейс, а к PostgreSQL придется написать (или включить через веб севрер модули), а так же очень тесная интеграция с фреймворком. Просто используем инструмент из коробки.
3. Преаграгационные и агрегационные репорты. Что бы не билдить дорогостоящие репорты каждый раз — делаем это один раз и ложем в могну. Пусть полежат. На основе репортов за день/неделю можно создавать отчеты за месяц/год.
Ну тут еще можно писать и писать, я только описал свои кейсы :)
1. Складирование логов. За счет capped колекций логи будут сами подчищаться и не забьют место на жестком диске.Ну в постгрес наверное можно скрипт по крону запускать который будет старые записи складировать
2. Meteor. В чем смысл заменять MongoDB у этого инструмента (или подобных ему) на другую базу? Тут у монги есть хоть REST интерфейс, а к PostgreSQL придется написать (или включить через веб севрер модули), а так же очень тесная интеграция с фреймворком. Просто используем инструмент из коробки.Судя по github.com/...isan/meteor-sql это вопрос 20 строчек кода
3. Преаграгационные и агрегационные репорты. Что бы не билдить дорогостоящие репорты каждый раз — делаем это один раз и ложем в могну. Пусть полежат. На основе репортов за день/неделю можно создавать отчеты за месяц/год.Это вообще какая то хрень полная. Что-что а скл для репортов любой сложности намного более пригоден чем убогий язык монго.
Ну в постгрес наверное можно скрипт по крону запускать который будет старые записи складироватьЗачем нагружать основную базу? Тем более бороться с table bloating? Да и не нужно их складировать, их нужно вычищать.
Судя по github.com/...isan/meteor-sql это вопрос 20 строчек кодаТам ничего нет. Если бы указали этот: github.com/...rorm/meteor-sql то тогда было бы понятно — тут руками дописали REST интерфейс с веб сервером.
Это вообще какая то хрень полная. Что-что а скл для репортов любой сложности намного более пригоден чем убогий язык монго.Агрегируются результаты по SQL, которые потом просто забираются из MongoDB при повторном запросе. MongoDB используется как хранилище результатов (думайте об этом, как о кеше без времени жизни).
Зачем нагружать основную базу? Тем более бороться с table bloating? Да и не нужно их складировать, их нужно вычищать.Почему основную? У меня на работе есть отдельный сервер с кучей дисков, мы его называем logdb, и туда пишем все чего душе угодно в структурированом виде, а потом по этим данным очень удобно разную аналитику считать и всякое дебажить, потому что все ходы записаны в доступном виде.
ам ничего нет. Если бы указали этот: github.com/...rorm/meteor-sql то тогда было бы понятно — тут руками дописали REST интерфейс с веб сервером.Ладно, если этот ваш метеор заточен только под монгу, то тут глупо спорить
грегируются результаты по SQL, которые потом просто забираются из MongoDB при повторном запросе. MongoDB используется как хранилище результатов (думайте об этом, как о кеше без времени жизни).А нафига именно нужен этот «кеш»? Чем скл база именно не годится для этой всей роли?
Почему основную? У меня на работе есть отдельный сервер с кучей дисков, мы его называем logdb, и туда пишем все чего душе угодно в структурированом виде, а потом по этим данным очень удобно разную аналитику считать и всякое дебажить, потому что все ходы записаны в доступном виде.
Замените «logdb» это на MongoDB — получите туже самую фразу (разве что писать можно в слабоструктурированном виде, как это часто бывает с логами: тут нужно еще вывести трейс, а тут debug режим, а тут и строчки про запуск хватит). Для логов это хорошая база. Ну и как я уже писал, если данные активно пишутся и стираются, то для PostgreSQL начинается слишком много работы с базой (крон скрипт для чистки, борьба с «table bloating») по сравнению с capped collection.
А нафига именно нужен этот «кеш»? Чем скл база именно не годится для этой всей роли?
У нас была задача не считать каждый раз репорты по архивным данным, раз они не меняются, а просто складировать (зачем вхолостую «ганять» CPU каждый раз?). В основную базу хранить это не нужно. Но и потерять эти данные не страшно — опять можно посчитать результат через SQL запрос.
У нас была задача не считать каждый раз репорты по архивным даннымЧем Materialized view не угодил?
Там все еще 9.0, а миграция базы в ~300 ГБ без даунтайма не легкая задача.
Мне кажется что все же гораздо легче чем добавлять еще одну бд, обучать разработчиков ей пользоваться, встраивать ее в текущую архитектуру.
Мне кажется что все же гораздо легче чем добавлять еще одну бд, обучать разработчиков ей пользоваться, встраивать ее в текущую архитектуру.
Для нас это не составляет труда, как бы громко это не звучало.
А для админа/девопса? Миграция базы делается один раз, а поддерживать всю инфраструктуру, мониторить нужно постоянно.
Так а в чем проблема? У нас DevOps теже люди, что и разрабатывают.
я конечно не эксперт, но идея пришла
а можно ли настроить репликацию в другой постгрес версий 9.3/9.4, а потом просто переключить базы?
в теории даунтайм будет в пределах
Можно. Триггерную (londiste, bucardo, etc.). Но с нагрузкой на эту базу это создает приблизительно 10% оверхед на операции записи (тут достаточно большая нагрузка на запись). Поэтому пока отложили эту идею. Пока как говорится «есть не просит». Вот на 9.5 — хотим переходить — нужно, что бы требуемые патчи (они уже прошли модерацию и осталось, что бы коммитеры их рассмотрели) наконец попали в мастер ветку и в резил.
P.S.
Там все еще 9.0, а миграция базы в ~300 ГБ без даунтайма не легкая задача.Материализированный вью это какой то синтаксический сахар над create table from select, его можно гонять на супердревних версиях постгрес.
Замените «logdb» это на MongoDB — получите туже самую фразуНе получу, потому что выразительность и возможности SQL все еще намного богаче чем то что позволяет делать монго.
Ну и как я уже писал, если данные активно пишутся и стираются, то для PostgreSQL начинается слишком много работы с базой (крон скрипт для чистки, борьба с «table bloating») по сравнению с capped collection.Крон чистки это 3 строки кода, какое-такое «слишком много»?
У нас была задача не считать каждый раз репорты по архивным данным, раз они не меняются, а просто складировать (зачем вхолостую «ганять» CPU каждый раз?). В основную базу хранить это не нужно. Но и потерять эти данные не страшно — опять можно посчитать результат через SQL запрос.Ну так конкретно, что именно здесь не способен сделать скл?
Tim Tretyak
Тут перешло (что и логично) в плоскость ACID против колоночников. И, собственно, в данном сравнении их сильные и слабые стороны стоит маппить на реальные задачи.
Ну в постгрес наверное можно скрипт по крону запускать который будет старые записи складироватьSQL базы традиционно хреново работают с плоскими таблицами на гигантское кол-во записей. Начиная с
Это вообще какая то хрень полная. Что-что а скл для репортов любой сложности намного более пригоден чем убогий язык монго.Тут дело не в языке, а в самой СУБД. На плоской таблице с 100млн записей самый простой select count(*) может выполняться часов 6. Так что зачастую лучше покорячиться с языками колоночников, чем ходить по минному полю оптимизаторов реляционок.
Будущее же, наверняка, за гибридами. Где какие-то таблицы будут реляционными, а другие — колоночными с бесшовным API между ними на уровне СУБД.
Alexey Khripkov
Автору стоит уточнить, в чём идёт сравнение. А то часть комментов можно приложить и к Mysql vs Mongo.
Я так понимаю, тут соль в _9.4_, так как там появилась возможность делать «NoSQL in SQL»
Да, это должно решить часть вопросов производительности, в которые упирается схемная архитектура. Но лишь небольшой. То есть, если вы работали с Постгре, и для пары мелочей держали Монгу, как костыль, то теперь Монгу можно выкинуть — пилите напрямую.
Но ведь прикол Монги не только в том, что в ней _можно_ использовать NoSQL. Главный прикол в том, что в ней _нельзя по-другому_. А такое предсказуемое поведение открывает те самые возможности по репликации, шардированию и остальным плюшкам. Ну и минусы отсюда же.
Там про штыковую и совковую лопату аналогию проводили. Ну, вот представьте, что теперь у штыковой такая же ручка с ручкой, как у снегоуборочной, и в некоторых местах штыковую можно использовать как совковую. Но кучу песка вы всё-равно совковой будете разгребать...
anonymous
Зачем, если есть OrientDB? NoSQL база с поддержкой SQL и ACID транзакций. Работает с графами, документами и обьектами. СУБД будущего просто.
Ну распишите уже поподробнее как OrientDB ведет себя в продакшн условиях. Какой у Вас кластер? Нагрузка? В чем минусы (плюсы мы уже поняли)? А маркетинг материал мы можем к любой базе на официальном сайте почитать :)
Я так же успешно могу написать про ArangoDB, но практической применение и разбор сорцов развеивает все эти маркетинг фразы в «bullshit».
Я как раз собирался статью на доу об этом написать. Через месяц-полтора ждите.
Главная проблема с этими blahblahblahDB , то что они завтра могут перестать быть.
Главная проблема в том что лично программист завтра может перестать «быть». Но это же не повод не пользоваться их услугами?
Программист существо намного более заменяемое, чем экзотическая база обросшая кучей гавнокода.
Valentin Nechayev
Через месяц-полтора ждите.
ну, типа ping.
Тук
Andrii Hrachov
О, я вот тоже про ориент хочу
Andrii Hrachov
Не Bson’ом единым жива СУБД..
Для меня:
Преимущества монги:
1.Скорость! за счёт отсутствия join’ов и внешних ключей.
2.Отсутствие схем(никаких тебе миграций и прочего, что вызывает попаболь при изменении или добавлении полей в «модели» — всё просто! — серьёзный плюс для continous delivery — ускоряет доставку новых фич в продакшн).
3. Возможность хранить «объёмные» данные, ради которых мы в сикуле делаем отдельные таблицы(какой нибудь profile для user).
4.Очень простой «язык запросов» и очень простая аггрегация по сравнению с sql
Недостатки:
1.Блокировки. Раньше при записи лочился весь монго сервер, сейчас — только отдельная база. И вроде бы они собираются довести это до уровня «коллекция», потом «документ». Всё впереди
2. Отсутствие транзакций. Частично лечится кастомными решениями вроде job queue и two-phase commit, но нужно писать всё ручками.
3.Невозможность в один запрос работать с данными из 2х и более коллекций. То есть логические «JOIN» например (там где они нужны) заставляют делать еще 1 запрос к бд.
4. Отсутствие контроля за данными и защиты от дурака. Если sql не даст создать объект Order если его userId не существует, то монго создаст и даже и не спросит. С удалением — та же история. Но есть и плюс — это всё безумно просто и быстро работает.
— И ещё куча недостатков...
А вообще. монгодб и сикуль — как совковая лопата и штыковая. Надо понимать — где какая нужна.
Если Вы пишете сложное B2B Приложение с кучей many-to-many связей, сложной логикой и e-commerce(биллинг, транзакции и тд), у вас релизы раз в месяц и куча программистов начального уровня — Mongodb Вам противопоказана. Использование её вызовет кучу неудобств и нивелирует все премущества.
Если Вы пишете SaaS или B2C (без сложных связей), у вас небольшая команда хороших спецов, И Вам важна скорость работы и доставки фич в продакшн — то Монга может приятно Вас удивить.
Всё вышеописанное — имхо.
Yurii Shulima
у вас небольшая команда хороших спецов, И Вам важна скорость работы и доставки фич в продакшнЗдесь наверное отлично можно примерить отрицание:
«у вас большая команда плохих спецов или вам не важна скорость работы или доствки фич в продакшин»
Это с чего вдруг высокоуровневая субд с мощным языком запросов будет проигрывать в скорости разработки низкоуровневой со слабым языком запросов... На то SQL и сложнее в изучении, чтобы было легче в бою.
Да и не замечал никогда, чтобы у хороших спецов была любовь к искусственно создаваемым трудностям, а чтобы плохие программисты начального уровня любили реляционки и умели нормально схему накидать.
Мир перевернулся. Вы не один с таким мнением.
Вы работали с монгодб в продакшне? Я озвучил своё мнение исходя из своего опыта работы с ней в условиях continuous delivery —
Угу. Сейчас работаю. И сиквелом хорошо и много работал. Есть с чем сравнивать.
С чего вдруг отсутствие схем — минус? Давайте отменим типы в нашем языке программирования и будем сырой памятью пользоваться. Аналогия та же. Схема нужна для того, чтобы жестко фиксировать правила, прямо статически, что сокращает время разработки, потому что далее схема работает сама и не дает сделать гадость. И менять, а также создавать схему — это очень не долго.
А вот с монгой основная проблема — это отсутствие схем. Особенно в процессе разработки. Вроде работало, вроде поменяли, но внезапно один из документов не может десериализироваться.
Да не далее как сегодня потрачено около часа работы двух программистов для выяснения такой проблемы.
А тесты зачем? Я не говорю, что схемы — это минус. Я говорю, что отсутствие их позволяет быстрее вносить изменения. Опять же, nodejs и отсутствие статической типизации способствует, но это другой вопрос и другой холивар
ну, если бы еще тесты всех заставлять писать ))) И все бы велись, мир стал бы чуточку безупречнее.
Вообще, статическая типизация, в том числе и схемы — это нечто, в моем мировоззрении — лучше тестов. Тесты нужны там, куда эта типизация не достает. Т.е. с помощью такой типизации вы пишете декларативные ограничения, утверждения, в каких рамках должна работать система. А тесты дополняют статическую типизацию там, куда она «не достала».
Так вот, тест можно забыть написать, по тесту сходу так не скажешь, какое он ограничение вводит. А схему сразу видно, определенными тулзовинами.
Потом, схема контролирует данные, а не код (в базе данных). Вы допустим пишете код, потом изменяете тесты, изменяете код, код теперь пишет в монгу данные с другой схемой, тесты это контролируют. А кто контролирует те данные, которые уже записали? Это надо теперь еще написать тест, которые поднимет и пробежит по всем данным?
Даже если так, то о какой скорости разработки идет речь.
Мм, с тестами еще один холивар — как по мне, ничто так не документирует код, как тесты, но мы совсем отвлеклись от темы. Все таки разные подходы к разработке.
И тесты — декларация. И статическая типизация — декларация. По крайней мере в том виде, как я ее представляю. Тесты заставляют работать код в определенных ограничениях. И то же делает статическая типизация.
Тесты нужны там, где нельзя кодом и декларативно выразить что-то. Тесты документируют код и штука хорошая и довольно универсальная. Но все же не единственная.
У тестов есть определенные проблемы. Не качественные, а количественные. Тесты в идеальном мире — это такая документация, плюс ускоряют разработку. В реальном мире надо очень уметь написать тест кратко, чтобы одного взгляда на него хватило, чтобы понять что он делает. Но это часто не так. Или надо был бы другой язык программирования. Часто в юнит-тестах занятия практической проктологией — как через открытые члены прокинуть данные так, чтобы они прошли по нужной ветке, которую тестируем.
Схема здесь явно выигрывает в наглядности. Да и менять наверное ее все же легче, чем тест.
Dmytro Krasun
Вообще, статическая типизация, в том числе и схемы — это нечто, в моем мировоззрении — лучше тестов.
Это точка зрения.
1.Скорость! за счёт отсутствия join’ов и внешних ключей.
А если сравнить с одной таблицей вида («key» bytea not null primary key, «value» bytea) в PG?
3. Возможность хранить «объёмные» данные, ради которых мы в сикуле делаем отдельные таблицы(какой нибудь profile для user).
PG сам справляется с тем, где хранить значение, в зависимости от объёма.
4.Очень простой «язык запросов» и очень простая аггрегация по сравнению с sql
Правильно подготовленный SQL запрос работает не медленнее :)
1.Блокировки. Раньше при записи лочился весь монго сервер, сейчас — только отдельная база. И вроде бы они собираются довести это до уровня «коллекция», потом «документ». Всё впереди
Во-во. А с MVCC блокировки совсем незаметны...
2. Отсутствие транзакций. Частично лечится кастомными решениями вроде job queue и two-phase commit, но нужно писать всё ручками.
Ну и зачем? ;)
Я реально вижу только одно преимущество у NoSQL решений — шардинг (в стиле Riak, в крайнем случае Cassandra). И то — свой враппер вокруг нормальной СУБД (типа PG) может решить больше проблем и надёжнее работать, чем такая БД.
Если Вы пишете SaaS или B2C (без сложных связей), у вас небольшая команда хороших спецов, И Вам важна скорость работы и доставки фич в продакшн — то Монга может приятно Вас удивить.
А если сравнить с описанным режимом для PG?
Я из SQL больше всего работал с MSSQL server, постгрес только щупал, но — что мне не нравилось и не нравится в Sql базах — это миграции. чтобы добавить одно поле в «модель» на моем стеке(nodejs + mongodb) — я добавляю поле там где нужно его добавить/обновить/ и пишу малюсенький патч (если он нужен), с sql это было 7 кругов ада — edmx модели, миграции при code first, добавить поле — поправить в модели базы — поправить в DTO, поправить в модели представления, поправить
И километровые stored procedure туда же, которые почему то в 99% случаев писались «другим парнем» и сиди в них ковыряйся.
несправедливое сравнение
с одной стороны — 2 с половиной инструмента:
чтобы добавить одно поле в «модель» на моем стеке(nodejs + mongodb) — я добавляю поле там где нужно его добавить/обновить/ и пишу малюсенький патч (если он нужен)
а с другой — целый зоопарк мощных штук (5 штук, если я правильно сосчитал), в каждой из которых зачем-то нужно станцевать сложный танец:
с sql это было 7 кругов ада — edmx модели, миграции при code first, добавить поле — поправить в модели базы — поправить в DTO, поправить в модели представления, поправитьможет, стоило это как-то автоматизировать?
И километровые stored procedure туда же, которые почему то в 99% случаев писались «другим парнем» и сиди в них ковыряйся.а вот интересно — хранимки это что, не код?
небось в дотнете или джаве и паттерны, и практики, и код ревью, а как доходит до хранимок, так большинство программеров тупо фейлят написать их применяя простые практики из структурного програмирования, родом из
при чем, заметил это даже в больших и серьезных продуктах — хранимки в ms dynamics gp (те, что я видел) — такой же километровый страх и ужас
такой же километровый страх и ужасЭто бывает, да. И как заметил человек выше — писал другой. Потому что до сих пор есть такая специальность как «базовик», потому что до сих пор есть «владение кодом» — я буду эту часть кода поддерживать, сюда не лезь. Программисты обычно слабее в sql и хранимках, поэтому не желают ими заниматься, перетягивают одеяло на себя, стремятся писать на своей стороне всю логику и даже code first.
А базовики, они такие. Обычно у них понятия о программировании крайне плохие. Не всегда и схему нормально проектируют. Они больше по администрированию.
Когда я писал хранимки, а пописал много, никаких в общем проблем не видел и ничто не заставляет делать их километровыми. Так же код можно разбивать и на другие хранимки и добавлять функции.
Ну собственно я примерно о том, что лично мне удобно работать только с кодом приложения, и забыть про субд. Опять же , это проще
ну, я бы поспорил, на счет проще.
В понятие «проще» нельзя включать свою какую-то некомпетентность. Тут у меня спор был, когда программисты утверждают (на шарпе), что код с циклами проще чем linq. Потому что линькю надо еще понимать.
Разница есть между императивным и декларативным подходом. Если грамотно писать хранимки, то там не будет или будет очень мало ифов и прочего, зато будет использоваться вовсю SQL. Как показывает практика, в разы ускоряет разработку. Просто потому, что запросом гораздо быстрее выразить даже сложную логику. А не писать свои велосипеды, контроль за многопоточностью, сайд-эффекты и прочие прелести. Пусть с этим разбирается СУБД, за это им и платят.
Проще то, что несет меньше информации и вам нужно меньше что-то контролировать. Не учитывая, что нужно еще что-то изучить.
Тут у меня спор был, когда программисты утверждают (на шарпе), что код с циклами проще чем linq. Потому что линькю надо еще понимать.Странные шарп программисты. Линькю — няшка
Просто потому, что запросом гораздо быстрее выразить даже сложную логику.
И описывать логику приложения не только в приложении, но и в БД. Что никак не облегчает сопровождение.
Если вы уберете барьеры, то вообще никак не влияет. Т.е. вы сами пишете код для базы, скрипты включаются в систему контроля версий и правильно накатываются, пишете и для них юнит-тесты, то работа с субд — это как с другой сборкой (другим модулем).
Естественно, для этого надо разделить некую ответственность, чтобы то, что считал сервер субд, не пересекалось с логикой на его клиенте. Чтобы не делать тянитолкай.
Пишем логику для приложения, пишем логику для СУБД, пишем тесты для приложения, пишем тесты для СУБД. Изменение чего-либо в приложении влекут за собой изменение этого всего.
У меня вот в связи со всей этой простотой вопрос — зачем стали лепить на sql Model first (А потом счастье пришло в виде Сode first и миграций) подходы(я про C# и entity framework само собой) если «SQL — это просто» ? (И приводит это все равно к тому что никто entity framework не пользуется, потому как работает медленно)
У меня вот в связи со всей этой простотой вопрос — зачем стали лепить на sql Model first (А потом счастье пришло в виде Сode first и миграций) подходы(я про C# и entity framework само собой) если «SQL — это просто» ?
Это потому что у нас еще до сих пор ад и всякие моды. Вот хотят программисты (вследствие вражды с SQL) писать коде фёрст, и даже не понимают, что SQL — это тоже язык программирования. Вот, любят программисты писать велосипеды. Вот, многие уверены, что СУБД должна ничего делать, а просто быть мешочком для данных (т.е. использовать как файловую систему). Тогда вот и выходит на первый план что-то вроде монги. Действительно, если каждый пишет велосипед поверх базы, пытается ослабить транзакции, считать у себя и сливать только состояния объекта — покупать и держать SQL-SERVER — слишком жирно. Это как купить последней модели танк, привязать к нему тачку и возить свои копья на войну.
Вот, многие уверены, что СУБД должна ничего делать, а просто быть мешочком для данныхВот и я так думаю, как раз по причине, чтобы не сидеть на двух стульях одновременно — и сконцентрироваться на разработке новых фич приложения и доставке их в продакшн что === профит.
Но, опять же. Кто что пишет. Когда мне говорят про использование монгодб для энтерпрайз-левел проекта(недавно как раз была дискуссия) — я найду тысячу причин, чтобы попытаться отговорить человека от её использования. Но для SaaS монга подходит очень хорошо
Вот и я так думаю, как раз по причине, чтобы не сидеть на двух стульях одновременноТ.е. вы за то, чтобы обеспечивать транзакционную целостность силами приложения (причем каждый раз)?
Хорошо — пусть это будет бекенд (а где еще?). Мысленно отпараллельте ваш бекенд в 2-3-4 экземплярах и еще раз попробуйте гарантированно обеспечить транзакционную целостность.
Ну и напоследок разнесите экземпляры бекендов на латенси эдак в 1/10 секунды (просто ЦОДы в Штатах и Европе) и еще разок сделайте так, чтобы и транзакционная целостность сохранилась и хоть сколько-либо приемлемая скорость работы.
.
Все это можно сделать, но такое титаническое количество усилий и времени только потому, что «SQL не нравится»?
См. вторую часть комментария.
Наверное.
Никак не привыкну к этим стартаперским вещам — привычка все планировать «на века». )
Справедливости ради, вверху где то лежит ссылка на яндекс презентацию использования монги в качестве хранилища метаданных Яндекс диска.
idOne Арбузный
Хехе.
Я її виклав для того, щоб люди оцінили останні репліки виступаючого — там він розказує яку треба було бд використовувати xD
А с чем нету проблем на хайлоаде? :)
З простими та старими рішеннями, на які вже є сотні записів на SO
Конкретный пример?
И описывать логику приложения не только в приложении, но и в БД. Что никак не облегчает сопровождение.Так никто не заставляет писать ту же логику и в СУБД, и в клиентском коде. СУБД работает со своими обьектами, контролирует целостность данных и обслуживает низкоуровневые данные, на которые приложению фиолетово. А заодно предоставляет АПИ для клиентского приложения.
На самом деле, это не так уже сложно, если взяться и спланировать сначала.
Помню в 2004 один проект, где даже часть html создавалось в хранимках. Потому что их проще было обновлять чем dll перекомпилить — заливать на сервер.
И там присутствовал тег <hr/>
Напомню Oracle Forms — там вообще все в БД хранилось, вплоть до расположения каждой кнопочки и поля на всех формах и грузилось при старте формы.
с sql это было 7 кругов ада — edmx модели, миграции при code first, добавить поле — поправить в модели базы — поправить в DTO, поправить в модели представления, поправитьЭто потому что энтерпрайз головного мозга. Нужно: добавить колонку в класс модели, накатить скрипт который добавит колонку в таблицу БД. Все.
И километровые stored procedure туда же, которые почему то в 99% случаев писались «другим парнем» и сиди в них ковыряйся.А километры странного джаваскрипт кода после «тех парней» не остаются?
Как ни странно, нет.
Типа программиста на джавцаскрипте всегда пишут радужный код?
Типа следят
с sql это было 7 кругов ада — edmx модели, миграции при code first, добавить поле — поправить в модели базы — поправить в DTO, поправить в модели представления, поправить
Я потому и предлагал сравнить не со сложной схемой, а с подходом, где простая key-value таблица с primary key для _id и полями для вторичных индексов. Там таких проблем миграции нет. Посему считаю вопрос по-прежнему открытым.
(Для последнего проекта у нас основное использование было именно таким.)
И километровые stored procedure туда же, которые почему то в 99% случаев писались «другим парнем» и сиди в них ковыряйся.
И без них тоже.
Igor Melnick
Монго далеко не самая быстрая nosql база. Складывается при ~500 параллельных записей, а вместе с собой частенько складывает и сервер/ноду. Независимо от тюнинга, capped/не capped коллекции. Каждая коллекция — это B-tree индекс с блокировкой в момент записи. Последовательные записи — зачастую проглотит, параллельные — смерть.
Вначале начали перед Монгой втыкать Redis, получился эдакий велосипед с квадратными колесами.
Теперь новые проекты делаю сразу на Aerospike:
- оптимизирован под SSD
- скорость записи/чтения сравнима с Redis, в то время как сами данные состоят из кортежей. А из клиентов вообще можно забирать JSON
- красивая репликация/шардинг
- каждый отдельный сервер способен обработать порядка 5к запросов на запись в секунду
- поддерживает как key-value, так и range запросы, и поиск по вторичным индексам (зависит от выбранного коннектора)
если не секрет — можно ли линки на проекты?
Работаем по SAAS, поэтому на сами плюшки линки дать не смогу. Могу только добавить, что это проекты, связанные с рекламой, а именно — с RTB.
P.S. Попутно вспомнил, что Aerospike, как и Redis поддерживает server-side скрипты на Lua
каждый отдельный сервер способен обработать порядка 5к запросов на запись в секундуА редіс на тій же конфігурації скільки видає?
Ну і взагалі, не лячно використовувати на продакшені, рішення, що щойно написане?
У редіса трохи інші вимоги до заліза. На аналогічному залізі, оптимізованому під редіс, він видає той самий порядок, іноді трохи більше — до 6-7к, на найпотужнішому сервері, який я бачив — до 10к.
Разом з тим:
- Вартість такого заліза набагато більше за вартість для того ж обєму данних на SSD.
- Персистентність в Редісі реалізована таким чином, що при зберіганні на диск він клонує себе у памяті, тобто для ефективного зберігання 16 Gb даних буде потрібно 32 Gb або більше оперативної памяті.
Igor Melnick
А что собственно нужно хранить? Какой режим чтения/записи?
Я за PostgreSQL.
Mongodb лише для якихось непотрібних данних для яких лінь писати схему чи які не шкода втратити.
Artyom Krivokrisenko
Andrii Mishkovskyi
Postgres: aphyr.com/...-maybe-postgres
MongoDB: aphyr.com/...e-maybe-mongodb
MongoDB в топку или он еще чем-то круче до сих пор?Монга, вроде как, проще в общем, и в скалировании (шардинге) конкретнее. И в этом ее основное приимущество.
Я так понимаю суть вброса — это JSONB ( wiki.postgresql.org/...ry_JSON_storage ). Из того что читал, выглядит пока слабо, но идея интересная.
Интересно какой процент проектов использующих монгу реально нуждаются в шардинге?
Bogdan Shyiak
Интересно какой процент проектов использующих монгу реально нуждаются в шардинге?Можно перефразировать: Интересно какой проект юзающий любую БД нуждается в чем-то большем чем MySQL? :)
Другими словами: инструмент который вы используете влияет на ваш стиль работы (не всегда в лучшую сторону).
Скорее стоит вопрос насколько Postgre не способен на горизонтальное масштабирование. Реплицирование вроде всех видов есть.
Репликацией можно масштабировать трафик на чтение, но не на запись, так как все слейвы по прежнему будут писать все данные.
Alexander Makeev
Citus DB в помощь. За деньги, правда.
Ну здесь речь идет о конкретном аспекте а не абстрактном стиле. Сколько проектов дорастает до того уровня что им необходимо горизонтально масштабировать трафик на запись? Думаю около 1%. И для 1% можно перенести тяжелые таблицы в более надежное распределенное хранилише, и это не монго.
Сколько проектов дорастает до того уровня что им необходимо горизонтально масштабировать трафик на запись?Та в том то и фишка, что люди начинают масштабироваться со смешных показателей, которые и на 1 MySQL-е можно было бы обработать, просто потому что могут.
Короче ты тоже считаешь что монго не нужно.
мм, а failover? горизонтальное масштабирование — отличная штука для обеспечения 99.9 % аптайма, не только ж в производительности вопрос
мм, а failover?Уговорили, 2 MySQL-я :)
для обеспечения 99.9 % аптаймаРаз 3 девятки, то и одного хватит :)
Владимир Чернышев
>>Можно перефразировать: Интересно какой проект юзающий любую БД нуждается в чем-то большем чем MySQL? :)
Какой проект нуждается в мускуле, а с постгри будет хуже? Для проектов уровня «бложик» они, имхо, равнозначны (даже если без ORM), но у постгри куда больший «запас прочности».
Я б больше перефразировал ))
Кто до сих пор не изучил SQL, боится GROUP BY и ORDER BY и поэтому тешит свое эго, что ему теперь одна дорога в хайлоад
Какой проект нуждается в мускуле, а с постгри будет хуже?Прочитайте еще раз коммент, там не было утверждения что «существуют проекте которые нуждаются в MySQL и PostgreSQL будет хуже».
но у постгри куда больший «запас прочности».Суть моего сообщения была в том что даже у такой простой БД как MySQL достаточный «запас прочности» для очень большого количества разных проектов.
98 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів