Выбор JSON DB

Правильный выбор.

требует переодической ручной чистки.

Можно настроить демон для автоматической чистки (https://wiki.apache.org/couchdb/Compaction#Automatic_Compaction).

Да, но там в целом есть проблема с быстротой доступности данных во вьюхах после инсерта/апдейта на большом количестве данных.

Про вакуум в пг слышал только звон?

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

Лучше иметь фичу которую не используешь, чем не иметь фичи которая нужна.

Ну, по тому же принципу можно выбрать монгу. Map-reduce мне понадобится с куда большей вероятностью, нежели реляционная бд.

elasticsearch?

Лол: https://github.com/typicode/json-server.

postgres вызывает больше всего доверия.

по докам не очень понятно, что там с индексацией вложенных полей в json.

http://www.postgresql.org/docs/9.4/static/datatype-json.html это не то?

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

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

Map-reduce мне понадобится

Кстати, последний раз когда я с монгой игрался(несколько лет назад), из-за немного неправильно macreduce запроса монга просто падала. Да и небыстро работало оно.

Плюсую. Каждому инструменту - своё применение.

По производительности MongoDB выросла в последнее время. Мы вот в продакшене для некритичных данных (пользовательские настройки интерфейса web-приложения) используем.

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

Это оно, да. Но вопрос не в этом.
Согласно http://www.postgresql.org/docs/9.4/static/functions-json.html поиска по составным ключам нет. Как и поиска по частичному вхождению значения.

Офигеть какая эффективность. Хранить в текстовом файлике.
Это я и в марии через connect могу, да и вообще без сервера.
А искать по этому говну предлагается, видимо, через греп, да?

Я, на самом деле, пока остановился на монге, если осилю написать человеческий драйвер для нее под nginx-lua.
В конце-концов данные не особо критичные.

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

Это шутка была, вообще-то. Специально же «лол» написал. Что ж так серьёзно?

можно выбрать монгу. Map-reduce мне понадобится с куда большей вероятностью

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

Угу, ведь куда проще заранее знать все нужные индексы и написать простыню аггрегационного непараллелющегося запроса на sql.

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

мап-редьюс это просто метод поиска по неструктурированным хранилищам

Садись, двойка.