Какую базу данных использовать для хранения метаданных?

Question

[O_oo]

Разрабатываю приложение, которое должно сохранять координаты разметки и ряд метаданных в локальный файл БД. Метаданные не имеют четкой структуры и могут иметь по-разному заполненные поля. В основе будет использоваться большое количество операций на чтение. Отсюда вопрос - что будет предпочтительнее использовать? Лично мой выбор пал на mongoDB, однако хотел бы услышать стороннее мнение.

Comments

[N]

Да

[Сергей Горностаев]

Лично мой выбор пал на mongoDB

У вас есть три лишних сервера и не жалко оперативной памяти?

[O_oo]

Сергей Горностаев, Не понимаю вашего вопроса и его смысла

[Сергей Горностаев]

O_oo, суть монги в том, что это хорошо масштабируемая горизонтально кластерная СУБД, а чтобы собрать кластер, нужно минимум три узла. Ну и каждый узел памяти будет жрать на порядок больше, чем например PostgreSQL при том же примерно сценарии использования и тех же нагрузках.

[O_oo]

Сергей Горностаев, Я прошу немного вникнуть в суть вопроса. Если его не поняли, то давайте распишу чуть подробнее. Я делаю приложение, которое занимается разметкой изображений, хранящиеся в формате, который не открывает ни один редактор, кроме специализированного ПО и фотошопа. К сожалению из-за того, что производители оборудования для работы с этими данными не соблюдают стандарты заполнения мета-данных, то их структурированность напрочь отсутствует. Они могут содержать как 3, так 300 строк полезной информации. Разрабатываемое ПО нацелено на специалистов, которые занимаются визуальной оценкой снимков. Их задача выделить и указать - есть что-то на изображении или нет. Далее координаты выделенных областей вместе в метаданными следует записать в какой-то один файл, чтобы потом его мне передали и я занимался дальнейшими вопросами с этими координатами и метаданными, поскольку я могу банально использовать названия файлов в качестве идентификатора. Поэтому я посчитал, что наиболее подходящим решением может быть монга.

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

[N]

O_oo, На начальном этапе Вам подойдёт...

[N]

Сергей Горностаев, Вы тоже правы...НО у автора вопрос НЕ в масштабировании...а в NoSQL...
А для этой задачи...Mongo "тупо" подходит...
А далее...уже другая история... :)

[O_oo]

N, не могли вы пояснить - что имеется ввиду под словом "тупо"?
Это отсылка на ранее озвученные темы в отношении многопользовательского доступа и поиска? Или тут что-то иное

[N]

O_oo, Я имел ввиду... что поставленный Вами вопрос - напрямую(тобишь тупо - тобишь в лоб) подходит к Вашей задаче.

P.S.: Если нет никаких скрытых "вводных" или "условий"...

[Сергей Горностаев]

N, монга не единственная документоориентированная СУБД. К тому же, пожелания автора вполне может удовлетворить тип JSONB в постгре.

[O_oo]

Сергей Горностаев, исходя из того, что я читал, работают монга и постгре плюс минус одинаково быстро на относительно небольших объемах данных. А монга мне показалась банально просто удобнее

[Сергей Горностаев]

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

Answer 1

[mayton2019]

Основной use-case при работе с любыми данными это "запрос".

Ты должен задать себе вопрос как я буду эти данные искать? По каким атрибутам?
Например базы данных семейства key-value почти всегда всем подходят и всем нравятся
за высокую скорость и дешевизну. Но это - только при условии что вы делаете поиск по ключевым атрибутам.
Но вы не сможете к ним сделать агрегации (group by).

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

Из личного опыта. Часто выбирают какую-то БД из того что человек (команда) уже раньше
с ней поработали и уже имеет опыт. И такое реально было и с Ораклом и с MS-SQL. Люди их
выбирали не потому что они хороши а чаще всего потому что "так привыкли". И десяток
лицензий были уже давно куплены. Почему-бы не использовать. Заказчик оплатил.
Так жить проще. Так и живут. И так строят архитектуры.

Comments

[N]

Мне кажется с таким вопросом...автору хоть Mongo...Хоть любая почти другая пойдёт...ему же только "для хранения метаданных"...)) Искать и выбирать походу ему ненадо...))

P.S.: Я к тому, чтобы вопросы научились формулировать...пусть возьмёт Mongo - въедет в пня(или не въедет) - придёт с более точным вопросом(или не придёт) :)

[O_oo]

N, верно, искать и выбирать не надо, поэтому вопрос был составлен полностью корректно

[N]

O_oo, Тогда в бой... :)

[mayton2019]

O_oo, go-go.

Answer 2

[rPman]

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

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

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

Comments

[N]

Автор же сказал...что да-да - нет-нет...он в курсе чё спросил...уже в бой пошёл... :)

P.S.: А Вы уже "капнули" в дебри...))
P.S.S.: Но - ответ - годный.

[mayton2019]

Круче только хранение данных в каком-нибудь постом формате в блочном устройстве диска или раздела (например идентификатор записи - ее смещение в файле, а там как то хранить ее размер и сами данные)

Капец ты демон :)

Это уже не разработка приложения а разработка своей DBMS. Ну дай бох хоть Mongo он осилит и внедрит.

[O_oo]

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

[mayton2019]

Пятница брат. Я открыл банку светлого. Я - по доброму. Без токсикоза.

[rPman]

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

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

В награду можно получить что то типа скорости записи на уровне IOPS диска, когда как sql база будет медленнее на порядок.

[O_oo]

rPman, вы предлагаете заниматься бесполезными вещами в контексте четко обозначенной задачи, где есть конкретные инструменты. Какой смысл изобретать велосипед?

[Владислав Лысков]

O_oo, что за время, прыснуть ядом лишний раз нельзя

[rPman]

O_oo, сэкономить на железе, в моем случае я смог решить задачу с дешёвыми десктопными hdd, терабайты.... Типовые инструменты тупо не справились бы, а покупать ssd такого объема в то время было мягко говоря не реал.