Вхід і реєстрація
Розробка · 23 квітня 2013, 14:44 9545
Andrii Serhiienko

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті


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

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

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

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

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

Теми: CouchDb, MongoDB
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Sergii Danilov Consultant в Pencroff Solutions 17.06.2014 23:49

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

Відповісти
Підтримати
Антон Бус 19.11.2013 19:59

Коментар порушує правила спільноти і видалений модераторами.

Антон Бус 19.11.2013 19:57

Коментар порушує правила спільноти і видалений модераторами.

Vitaliy Bondarenko Працює в Amazon 31.07.2013 13:57

Посмотрите на Amazon DynamoDB

Відповісти
Підтримати
anonymous 31.05.2013 13:11

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

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

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

Відповісти
Підтримати
Vyacheslav Software developer with project management experience 31.05.2013 13:30

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

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

Відповісти
Підтримати
anonymous
Yehor Nazarkin Software Engineer в DataRobot 24.05.2013 11:56

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

Відповісти
Підтримати
Ivan Pomidorov 21.05.2013 16:28

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

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 20.05.2013 09:40

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

Відповісти
Підтримати
iddqd 13.05.2013 15:12

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

Відповісти
Підтримати
Igor Petruk Software Engineer в Google 20.05.2013 18:43

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

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

Відповісти
Підтримати
iddqd
iddqd 20.05.2013 20:10

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

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

Відповісти
Підтримати
Igor Petruk
Igor Petruk Software Engineer в Google 20.05.2013 20:12

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

Відповісти
Підтримати
iddqd
iddqd 20.05.2013 20:13

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

Відповісти
Підтримати
Igor Petruk
Andrey Goryachev 17.06.2014 21:13

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

Відповісти
Підтримати
iddqd
Олексій Пєніє 13.05.2013 12:58

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

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

Відповісти
Підтримати
reality_hacker 13.05.2013 19:46
Лично я сторонник SQL + файловая система. SQL удобен для поиска и индексации, файловая система — для хранения и бэкапа.
А как эксперты горизонтально масштабируют свои базы данных?
Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 14.05.2013 18:07

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

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

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

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

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

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

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

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

Відповісти
Підтримати
reality_hacker
reality_hacker 14.05.2013 19:28

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

И да, предпочитаю пожертвовать десятком гектар диска на избыточность
Горизонтальное масштабирование становится актуальным когда у тебя база террабайт 10, и трафик 1000qps, а не десяток гигабайт
Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 15.05.2013 20:51

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

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

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

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

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

Відповісти
Підтримати
reality_hacker
reality_hacker 15.05.2013 20:57

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

Відповісти
Підтримати
Олексій Пєніє
Yehor Nazarkin Software Engineer в DataRobot 15.05.2013 23:04
только тогда следует думать о переходе на MongoDB — при первом и последующих рефакторингах проекта
Проектированием/анализом не занимайся/прототипов не создавай — сразу пиши код.
Переход может быть достаточно плавным, если не сказать вечным. Часть структуры вероятно так и останется на SQL. То самое горизонтальное масштабирование.
Вы только что произнесли новое слово в понятии «горизонтальное масштабирование». Я в восторге.
Відповісти
Підтримати
Олексій Пєніє
Igor Petruk Software Engineer в Google 20.05.2013 18:51

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

Відповісти
Підтримати
reality_hacker
Kostiantyn Kudriavtsev Head of .NET team в Luxoft 01.06.2013 07:57

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

Відповісти
Підтримати
Igor Petruk
reality_hacker 01.06.2013 10:31

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

Відповісти
Підтримати
Kostiantyn Kudriavtsev
Kostiantyn Kudriavtsev Head of .NET team в Luxoft 01.06.2013 13:54

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

А потом потыкаешь палочкой, а оно на 10 залетевших дятлах пользователях падает.
Відповісти
Підтримати
reality_hacker
Kostiantyn Kudriavtsev Head of .NET team в Luxoft 02.06.2013 09:24

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

Відповісти
Підтримати
reality_hacker
Sergey Boroday Team lead 31.07.2013 12:36

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

Відповісти
Підтримати
Igor Petruk
Igor Petruk Software Engineer в Google 31.07.2013 14:42

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

Відповісти
Підтримати
Sergey Boroday
Viacheslav 14.05.2013 19:35
считаю что он устарел
Уже лет 5 так говорят, но все же юзают
Відповісти
Підтримати
Олексій Пєніє
Yehor Nazarkin Software Engineer в DataRobot 15.05.2013 10:34
База данных по сути это что? Именнованные массивы
Как-то про реляционную алгебру ты совсем забыл, наверное её забыли задокументировать и она стала могилой времени для джавадевелопера в забугорье
при общении с ним через многослойные абстракции
Так юзай raw-sql, фигач меткие и лаконичные запросы, где дух молодости и вседозволенности?
Фактически, это и была бы файловая система. Но другая. И насколько я слышал
hdfs, hbase и все что дальше? Ну вообще оно как бе вполне опенсруц.
Я бы хотел базу данных, которая являлась бы продолжением языка программирования
ZODB? Cache? Если погуглить, можно еще несколько примеров вспомнить.

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 15.05.2013 21:12

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

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

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

Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 15.05.2013 22:57
Ещё хуже, когда админ, уже без разработчика. А бывает когда и админа нет, и проект умирает.
Печально наблюдать тенденцию, когда «програмысты» лезут писать код без понимания того, что происходит в системе их поделие исполняющей.
А разработчик не разбирающийся в администрировании целевой платформы — говно, а не специалист,
Многие ли из вас, прежде чем что-то новое ставить, спросили на ДОУ
DOU — не технический ресурс.
уйти потом куда-то, отказаться от подобной абстракции в будущем — будет практически невозможно в короткие сроки
У каждого ухода должна быть обоснованная причина. Пока что это напоминает причитания церковной бабки о необходимости шапочек из фольги и излучении из космоса.
Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 16.05.2013 00:14

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

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

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

Відповісти
Підтримати
Yehor Nazarkin
NewType 20.05.2013 17:17
будет как в анекдоте, когда на Запорожец прицепили дворники от Белаза.

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 21.05.2013 15:56

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

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

Відповісти
Підтримати
NewType
proger 24.05.2013 23:27
имела бы свою файловую систему
нну это можно устроить, что оракл (с версии 3 и или 7) что мускуль (вроде как) может использовать разделы

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 24.05.2013 23:36

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

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

Відповісти
Підтримати
proger
proger 24.05.2013 23:47

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

Відповісти
Підтримати
Олексій Пєніє
reality_hacker 25.05.2013 00:30
но имея опыт под параллельной нагрузкой, я могу сказать что основная проблема баз — локи, ибо если два потока (запроса) хотят поменять одну страницу данных, то один из потоков будет ждать
совершенно эпично это выглядит на ненастроенных базах — загрузка процев 5% а база нереально тормозит
Криворукие программисты?
Відповісти
Підтримати
proger
proger 25.05.2013 00:43
Криворукие программисты?
скорее мало опытных
Відповісти
Підтримати
reality_hacker
idOne Арбузный 13.05.2013 12:39

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

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

I don’t want to do this again. I want to use Postgres.
Відповісти
Підтримати
Andrii Serhiienko
Bohdan Chechyn SSE 29.04.2013 09:24

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

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

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

Відповісти
Підтримати
Vialent Petrovich 27.04.2013 00:45

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

Відповісти
Підтримати
reality_hacker 29.04.2013 08:24

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

Відповісти
Підтримати
Vialent Petrovich
Andrii Serhiienko 29.04.2013 08:38

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

Відповісти
Підтримати
reality_hacker
reality_hacker 29.04.2013 09:10

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

Відповісти
Підтримати
Andrii Serhiienko
idOne Арбузный 26.04.2013 23:52

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

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

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

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

Відповісти
Підтримати
Andrii Serhiienko 27.04.2013 08:34
постгрес/мускул ваш товарищ.

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

Відповісти
Підтримати
idOne Арбузный
idOne Арбузный 27.04.2013 11:26

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

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

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

Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 27.04.2013 13:50

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

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

Відповісти
Підтримати
idOne Арбузный
anonymous 25.04.2013 21:59

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

Відповісти
Підтримати
Alexandr Gavriluk 27.04.2013 17:39

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

Відповісти
Підтримати
anonymous
Andrii Serhiienko 27.04.2013 20:00

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

Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 27.04.2013 20:26

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

Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 27.04.2013 20:33

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

Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 25.04.2013 19:47

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

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

Відповісти
Підтримати
reality_hacker 25.04.2013 19:49

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

Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 25.04.2013 19:56

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

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

Відповісти
Підтримати
reality_hacker
reality_hacker 25.04.2013 19:59
С Ораклом знаю много проблем было при внезапном падении сервера.
/dev/hands device is corrupted видимо
Ну и кластер на ней строится без усилий, но уже не бесплатно (репликатор денег стоит).
А у остальных бесплатно, и даже с автоматическим failover и master to master replication.
Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 25.04.2013 20:04

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

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

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

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

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

Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 25.04.2013 20:34

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

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

Відповісти
Підтримати
reality_hacker
reality_hacker 25.04.2013 20:37
По эффективности и скорости рвет в ошметки все Express версии платных серверов.
Ну я же просил бенчмарки?
Відповісти
Підтримати
Alexandr Gavriluk
reality_hacker 25.04.2013 21:33

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

Відповісти
Підтримати
Alexandr Gavriluk
Alex Batler заговорщик в Mutabor-science 02.06.2013 00:26

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

Відповісти
Підтримати
Alexandr Gavriluk
Andrii Serhiienko 25.04.2013 21:14

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

Відповісти
Підтримати
Alexandr Gavriluk
Bogdan Shyiak SE or Dev 25.04.2013 21:31
Блин, ну и зачем мне информация про Firebird?
Одумайсо заблудшая душа! Ты еще можешш перейти на Делфу и другие «продвинутые» технологии! :)
Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 25.04.2013 21:33

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

Відповісти
Підтримати
Bogdan Shyiak
Alexandr Gavriluk 27.04.2013 17:41

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

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 27.04.2013 17:53
FB очень неплохо используется и для Java проектов
А зачем? Что он может такого чего не могут __мейнстримовые__ БД? Или чем он интересен так же как и модные сейчас НоСКЛ?
идеально сочетается с легким JavaEE типа Томката.
Поясните данной утверждение подробнее.
Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 27.04.2013 18:19

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

Відповісти
Підтримати
Bogdan Shyiak
Alexandr Gavriluk 27.04.2013 18:22
Что он может такого чего не могут __мейнстримовые__ БД?

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

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

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 27.04.2013 18:48
Может не падать 10 лет у тетеньки бухгалтерши, где админом работают обычно школьники 8-10 классов.
MySQL, H2 тоже так умеют.
Кроме того можно провернуть такую штуку, как старт сервера внутри самого процесса Tomcat
H2 (HSQLDB). При том она чисто на джаве.
При том у этих БД есть мега-плюс — они мейнстримовые.
Відповісти
Підтримати
Alexandr Gavriluk
Alexandr Gavriluk 27.04.2013 19:24
H2 (HSQLDB).

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

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 27.04.2013 20:06
Где-то были тесты, что Firebird в 15000% быстрее чем HSQLDB для баз более 2Гб.
Шикарно.
1) Где это так же интересно. Но куда важнее Когда? До где-то 2010 она была полу-мертвой (поэтому и появилась H2)
2) Любые тесты ситуативны, приведите ссылки посмотрим.
3) Допустим таки медленнее. Абсолютные цифры и задачу привести можете. Что за задача была?
------
А теперь самое важное:
При том у этих БД есть мега-плюс — они мейнстримовые.
Банально зайдите на линкедИн и посмотрите скилы и статистику связанные с Firebird, MySQL, PostgreSQL или даже H2. А потом задайтесь целью найти джависта который будет поддерживать код под фаербирд.
Відповісти
Підтримати
Alexandr Gavriluk
Andrii Serhiienko 27.04.2013 20:02
надежность как у советской танковой рации, где можно их сложить в кучу метнуть гранату и все будет продолжать работать

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

Відповісти
Підтримати
Alexandr Gavriluk
Нестор Иванович 24.04.2013 08:09

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

Відповісти
Підтримати
Andrii Serhiienko 24.04.2013 08:21

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

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

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

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

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

Відповісти
Підтримати
Нестор Иванович
reality_hacker 24.04.2013 08:49
в то время как CouchDB дергает HDD
Думается couch тоже имеет какие то буферы из которых тащит данные без дергания диска. К тому же монгодб ничего не стремится, он mmap-ает файлы данных и дальше обо всем заботится ОС
Відповісти
Підтримати
Andrii Serhiienko
Сергей 29.04.2013 01:52
Не хотелось бы просто все сделать, перевязать ленточкой, — а потом через полгода обнаружить что из-за Mongo все умерло однажды и навсегда.
Ну тогда уже брать проверенные временем MySQL/PortgreSQL
сервер в силу каких-то причин был внезапно перезагружен
Я встречал даже жалобы на ext3 fs, которая внезапно теряла старые файлы в таких ситуациях. Это все «детские болезни» проектов.
Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 29.04.2013 08:02
Ну тогда уже брать проверенные временем MySQL/PortgreSQL

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

Відповісти
Підтримати
Сергей
reality_hacker 29.04.2013 08:04

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

Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 29.04.2013 08:21

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

Відповісти
Підтримати
reality_hacker
Oleksandr Kholodov CEO в Yalantis 29.04.2013 09:01

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

Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 29.04.2013 12:02

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

Відповісти
Підтримати
Sergii Voloshyn
Нестор Иванович 29.04.2013 13:56

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

Відповісти
Підтримати
Andrii Serhiienko
reality_hacker 24.04.2013 02:33

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

Відповісти
Підтримати
anonymous
anonymous 24.04.2013 02:50

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

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

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

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

Відповісти
Підтримати
reality_hacker
reality_hacker 24.04.2013 02:59
рекомендую LevelDB
А как может embedded key value база заменить распределенную document oriented базу со всякими плюшками вроде вторичного индекса, full text search, map reduce, aggregation framerworks, etc.
Відповісти
Підтримати
anonymous
anonymous 24.04.2013 03:17

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

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

Відповісти
Підтримати
reality_hacker
Mykola Kharechko developer в SoftServe 23.04.2013 23:01

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

Відповісти
Підтримати
luxeon Senior Software Engineer 23.04.2013 21:13

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

Відповісти
Підтримати
Андрей 23.04.2013 16:49

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

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

Відповісти
Підтримати
Andrii Serhiienko 23.04.2013 19:16
К вам вопрос: нафига вам оно

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

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

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

Відповісти
Підтримати
Андрей
Нестор Иванович 24.04.2013 08:10

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

Відповісти
Підтримати
Andrii Serhiienko
Andrii Serhiienko 24.04.2013 08:17

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

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

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

Відповісти
Підтримати
Нестор Иванович
Yehor Nazarkin Software Engineer в DataRobot 11.05.2013 16:43

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

Відповісти
Підтримати
Andrii Serhiienko
reality_hacker 11.05.2013 20:56

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

Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 11.05.2013 12:40
Из недостатков самый существенный — отсутствие транзакций
В монго никогда и не заявлялась поддержка транзакционности. Она как бы eventual consistent и вообще async write делает. Это не недостаток, это by design.
В нашем проекте используется связка mongodb для хранения сложных структур + postgresql, для данных, требующих транзакционный подход записи/обновления.
Некое подобие транзакций в монго, если так уж хочется стать ближе к этому подходу — использование «вложенных» документов
Відповісти
Підтримати
anonymous
Yehor Nazarkin Software Engineer в DataRobot 11.05.2013 16:41

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

Відповісти
Підтримати
anonymous
Igor Petruk Software Engineer в Google 11.05.2013 17:29
провал производительности будет эпичный

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

Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 12.05.2013 19:15

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

Відповісти
Підтримати
Igor Petruk
reality_hacker 12.05.2013 19:35
многие rdbms делают fsync по умолчанию сильно позже коммита транзакции
Пруфлинк? Или опять откровения школоты?
Відповісти
Підтримати
Yehor Nazarkin
reality_hacker 13.05.2013 07:21

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

Відповісти
Підтримати
Yehor Nazarkin
Alex Batler заговорщик в Mutabor-science 31.05.2013 21:39

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

Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 11.05.2013 16:46

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

Відповісти
Підтримати
anonymous
Yehor Nazarkin Software Engineer в DataRobot 11.05.2013 16:54

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

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

Відповісти
Підтримати
anonymous
Yehor Nazarkin Software Engineer в DataRobot 12.05.2013 19:22

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

Відповісти
Підтримати
anonymous
Ruslan Shevchenko Researcher 23.04.2013 15:02

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

Відповісти
Підтримати
Andrii Serhiienko 23.04.2013 15:27

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

Відповісти
Підтримати
Ruslan Shevchenko
Andrii Serhiienko 23.04.2013 15:56

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

Відповісти
Підтримати
anonymous
Andrii Serhiienko 23.04.2013 16:05

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

Відповісти
Підтримати
anonymous
Norb 23.04.2013 16:36

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

Відповісти
Підтримати
Andrii Serhiienko
Yehor Nazarkin Software Engineer в DataRobot 11.05.2013 12:49
поставить и забыть
1) только на выделенную ноду/инстанс — при mmap с ростом объема данных увеличится потребение памяти.
2) простейшие выборки на малом объеме данных без индексов тормозить не будут, с ростом объема хранимых документов нужно будет об этом заботиться
3) map-reduce в монго — лучше бы его там не было, выполняются в одном потоке, производительность: на шарде из 3-х серверов обработка 10М документов заняла 15 минут

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

Відповісти
Підтримати
Andrii Serhiienko
reality_hacker 23.04.2013 19:51
зато проста в обслуживании
А остальные сложны? Помоему монго не выигрывает в простоте например у кассандры.
так что все используют, ну и так как ее все используют — она развивается быстрее.
Какой то неочевидный вывод, развивают прогаммисты которые ее пишут а не сообщество. Тот же постгрес обгоняет mysql в развитии.
Відповісти
Підтримати
Ruslan Shevchenko
Andrii Serhiienko 23.04.2013 20:00

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

Відповісти
Підтримати
reality_hacker
reality_hacker 23.04.2013 20:04

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

Відповісти
Підтримати
Andrii Serhiienko
Yehor Nazarkin Software Engineer в DataRobot 12.05.2013 20:00
постгрес обгоняет mysql в развитии
Пруфлинк? Или опять откровения школоты?
Відповісти
Підтримати
reality_hacker
reality_hacker 13.05.2013 07:26

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

Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 13.05.2013 11:38

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

Відповісти
Підтримати
reality_hacker
reality_hacker 13.05.2013 19:45
Хоть одну — 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 это вообще колекция сторонних патчей.
Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 13.05.2013 21:06

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

А что плохого в сторонних решениях
абсолютно ничего (: перечитай свои вопросы, школота.
Відповісти
Підтримати
reality_hacker
reality_hacker 13.05.2013 21:09
запроса вместо одного. Второй с двойной вложенностью. Круто чо
Т.е. то что нужны какие то костыльные хранимые процедуры ты согласен что сзвиздел? Ну и что ты думаешь делает под капотом mysql что бы обеспечить такую же семантику для множества движков хранения?
абсолютно ничего (: перечитай свои вопросы, школота.
Слив как он есть
Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 13.05.2013 21:17
Т.е. то что нужны какие то костыльные хранимые процедуры ты согласен что сзвиздел?
Ок, у нас есть 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;
Слив как он есть
Лососни тунца, ты просил примеры, тебе их привели, дальше ты тупо увёл тему. Кто слил?
Відповісти
Підтримати
reality_hacker
reality_hacker 13.05.2013 21:19
Ок, у нас есть 2 косых варианта реализации этой штуки. Одно ты нагуглил, второе выглядит как-то так:
И что ты сказать хотел? В mysql нельзя написать зачем то совсем необязательную процедуру для таких же целей? Тренируй логику, школота?
Лососни тунца, ты просил примеры, тебе их привели, дальше ты тупо увёл тему. Кто слил?
Школота, твои же примеры неправильные оба, я обьяснил почему.
Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 13.05.2013 21:24
твои же примеры неправильные оба, я обьяснил почему.
Конечно, я принял к сведению мнение воинствующего школьника
И что ты сказать хотел?
У вас отличный скилл гугления же

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

Тот же постгрес обгоняет mysql в развитии.
Відповісти
Підтримати
reality_hacker
reality_hacker 13.05.2013 21:51
Конечно, я принял к сведению мнение воинствующего школьника
О, опять слив, я сегодня в ударе.
У вас отличный скилл гугления же
А вообще был запрошен пруф
Тот же постгрес обгоняет mysql в развитии.
Ну я тебе привел список фич, или вы еще в школе какие то аспекты чтения не проходили? Тогда извини.
Відповісти
Підтримати
Yehor Nazarkin
Yehor Nazarkin Software Engineer в DataRobot 13.05.2013 21:56
О, опять слив, я сегодня в ударе.
Ты почему-то решил, что привел контрпримеры реализации несуществующей фичи, по-сути костыли/обходные решения.
Ты конечно мастак оправдывать разработчиков постгри, но пойми же наконец, нету этого функционала там из коробки.
Да, чуваки молодцы, что к 9-й версии пришли к репликации, когда у всех нормальных продуктов она давно уже есть. О чем это говорит? Догоняют, малацца,
но не задают темп. Это как «вечная невеста» линупса.
я тебе привел список фич
Ты как-то резво присвоил себе чужие заслуги? Где и какой список фич ты привел? Ответил костыльным решением с переходом наличности? Да я смотрю ты мастер аргументации. Чему вас только в школе учат
Відповісти
Підтримати
reality_hacker
reality_hacker 13.05.2013 22:02
Ты почему-то решил, что привел контрпримеры реализации несуществующей фичи, по-сути костыли/обходные решения.
Ты конечно мастак оправдывать разработчиков постгри, но пойми же наконец, нету этого функционала там из коробки.
Какую именно функциональность ты имеешь в виду? Конкретнее выражайся.
Да, чуваки молодцы, что к 9-й версии пришли к репликации, когда у всех нормальных продуктов она давно уже есть. О чем это говорит? Догоняют, малацца,
но не задают темп. Это как «вечная невеста» линупса.
Понимаешь, некоторые продукты развиваются модульным путем. Вот линукс это по сути только ядро, который без сторонних дополнений или доработки напильником не запустится вообще, но у тебя же не повернется надеюсь язык набросить что он догоняет винду на серваках? Так и с постгре и репликацией. Хотя для школоты такие мысли могут оказаться сложноватыми согласен.
Ты как-то резво присвоил себе чужие заслуги? Где и какой список фич ты привел? Ответил костыльным решением с переходом наличности? Да я смотрю ты мастер аргументации. Чему вас только в школе учат
Я ответил тебе в первом же ответе на твой вопрос про пруфлинк, но ты похоже не только школота но и жирный троль.
Відповісти
Підтримати
Yehor Nazarkin
Igor Petruk Software Engineer в Google 11.05.2013 17:33
проста в обслуживании

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

Відповісти
Підтримати
Ruslan Shevchenko

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.