LINUX.ORG.RU

Выбор JSON DB

 


2

4

Значится, под задачу хранения метаданных файлов нужно выбрать базу.
Поскольку данные могут быть разные - schema-based хранилища не подходят.
Нужна скорость + гибкость поиска по полям. Аггрегация и mapreduce не нужны.

Варианты:

1) mongodb. плюсы: скорость, простота поисков по вложенным полям. минусы: ненадежность и общее недоверие к проекту. отвратительный коннектор для nginx-lua.

2) couchdb. плюсы: надежность и консистентность, простота апи. минусы: для всего нужны вьюхи через map(reduce). обновляются они не особо шутро. требует переодической ручной чистки.

3) postgres. плюсы: скорость, надежность. минусы: сложность настройки в целом и вакуума в частности. ну и, я с ним никогда особо не работал. плюс по докам не очень понятно, что там с индексацией вложенных полей в json.

4) mysql, лол. плюсы: простота. минусы: индексить вложенные поля можно только через автогенерированные колонки, насколько я понял. ну и, оракаль, ибо в марии с json все плохо пока.

Я пока склоняюсь в сторону постгресса.
Мнения?

★★★★

Ответ на: комментарий от Ja-Ja-Hey-Ho

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

iSage ★★★★ ()

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

anonymous ()

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

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

ya-betmen ★★★★★ ()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

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

iSage ★★★★ ()
Ответ на: комментарий от Deleted

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

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

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

pawnhearts ★★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

xenohunter ()
Ответ на: комментарий от pawnhearts

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от xenohunter

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

iSage ★★★★ ()

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

iSage ★★★★ ()
Ответ на: комментарий от pawnhearts

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

iSage ★★★★ ()
Ответ на: комментарий от iSage

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

xenohunter ()
Ответ на: комментарий от iSage

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

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

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

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

iSage ★★★★ ()
Ответ на: комментарий от iSage

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

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

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

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

iSage ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.