ой

start foo call func 42 end foo start foo end foo call func start bar 42 end bar call func start bar end bar

ага, я тоже уже скомпилил его)

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

второй вызов foo

print == false поэтому внутри foo обращения к val не происходит

и аргумент val не вычисляется

кто-нибудь юзал mongodb?

не совсем понятно что это за зверь и подходит ли он для решения задач, которые обычно решаются реляционными БД

Нет не подходит, даже не думай брать это убожество

почему?

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

в чём основные различия, какую задачу можно решить обычной базой и не решить с помощью mongo?

https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.z6l6fqs87

В гугле полно аналогичных статей.

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

Это как раз и есть большая боль для реляционных данных. Тебе сложнее следить за структурой, вставляется что угодно куда угодно. Можно вставить дельфинов в таблицу с финансовыми остатками

Транзакционности нету, foreign keys тоже

а вот эти понятия уже мне мало о чём говорят

Монго хорошо подходит если тебе нужно очень много писать/читать однородных данных, вроде всяких метрик и логов

И часть данных не жалко потерять

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

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

конкурентный доступ к записи или к таблице (или вообще к базе)?

Когда сразу несколько клиентов читают и записывают одни и те же данные.

В одной и той же ячейке грубо говоря.

кто-нибудь юзал mongodb?

Работал. Нормально. Главное брать для подходящих задач.

так, хорошо...

на этом всё?)

Ну нет не все, можно бесконечно расписывать преимущества postgres :D

у меня задача достаточно специфичная, пока mongodb вписывается в рамки

ну +/-

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

https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.z6l6fqs87

Ого. Ни разу не сталкивался с такими проблемами.

http://digbigdata.com/wp-content/uploads/2013/05/media_httpfarm5static_mevIk.png

Картинка для помощи в выборе

https://www.quora.com/Which-companies-have-moved-away-from-MongoDB-and-why

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

Что характерно, таких же плохих отзывов про постгрес не получается найти так просто https://www.quora.com/Which-companies-have-moved-away-from-PostgreSQL-and-why )

ничего против postgres не имею, мельком читал, старая и отлаженная реляционная база с некоторыми плюшками

а вот mongo это что-то новое и не до конца доделанное видимо

Ну по сравнению с постгресом новое конечно

просто, как я понимаю, при выборе mongo уже не те подходы должны использоваться для проектирования БД

учитывая наличие встроенных массивов вообще решает

встроенные массивы и json есть и в постгресе уже пару лет :)

а у redis теже проблемы? теряются записи, глючит при высокой нагрузке и тд?

Нет

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

У редиса начинаются проблемы если данные целиком не влазят в оперативку

прихожу к выводу, что оптимальным решением будет использовать все 3

postgres для важных, структурированных данных mongo для записи результатов запросов к api (внешнему) redis для каких-то быстрых мелочей, типа кеша обработки и тд

Я юзал arangodb

@DmitryBubnenkov на D или вообще?

Из минусов очень драйверов для ди не хватает. А юзать по хттп ужос

Для разношерстных данных очень даже удобна. Некоторые вещи в реляционную бд ну никак не вписываются

На ди

У меня онлайн тест на json основан

И я там все хранил

а разница между этим и mongodb?

Там есть удобный язык встроенных запросов на мотив sql

По коллекциям удобно ходить с ним

язык не важен...

Геоданные умеет. К примеру близость объектов и тд. Но это я тока буду юзать

mongo тоже умеет

Пока тока игрался

Графы умеет

По хттп работает

Весит меньше

что весит меньше?

база с теми же данными?

Сама БД. Из минусов под виндой пару раз сама в оффлайн уходила

Дистрибутив

ну это вообще не критерий

если разница на 100 порядков, то это, конечно важно

Мне в идеале нужна субд вообще без установки для ди. Нереляционная

К сожалению ничего внятного пока нет

не могу понять как вообще пал выбор на эту базу, если есть mongo

Мне геоданные нужно хранить. Пока думаю над архитектурой

геоданные умеет (хотя мне кажется совсем лишняя фича для бд)

Просто мне было удобнее тесты проводить прямо с json. Без его перевода в bson

из установки я только архив распаковал

Мне жта фича дико нужна

ещё раз повторю mongo умеет геоданные)))

Без геоданных мне БД не подходят

Ну вот как нить ее изучу тоже

Мне близость между объектами надо считать

И тд

может я не в теме, но это звучит, как "база без возможности брать sin от комплексного числа мне не подходит"

Ну у меня вся работа с пространственными БД

???

пространственные БД это, кажется немного другое

Ну геоданные одни. Geojson

ну и что?)))

А куда их пихать то?

расстояние это 2 числа перемножить и сложить

всмысле куда?)

поле X: float, и Y:float

Ну расстреляние оно на глобусе

да ладно?

Долготы и широты