MongoDB

[mirk]

Есть ли драйвер для работы с MongoDB в FPC?

[Снег Север]

Почему вы никогда не должны использовать MongoDB

[mirk]

У каждого средства есть плюсы и минусы.
Что использовать вместо MongoDB, если нужны ее плюсы (скорость добавения записей, хранение и индексация неструктурированных данных)?

[alexs]

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

Серебряной пули нет!

[mirk]

Так если по кругу, то все-таки что можно использовать вместо MongoDB?

[Deimos]

Серебряной пули нет!

Абсолютно согласен.


С одной стороны - умные дяди "за нас" придумали распределенные базы и стандартизировали SQL и осталось только научиться их правильно использовать... А с другой - эти самые дяди когда-то стали Не довольны теми инструментами, которые есть (были на тот момент) и придумали что-то более-универсальное и удобное... Используя паскль и лазаря я считаю себя ретроградом, поскольку могу реализовать почти-все именно посредством этих инструментов всилу своих знаний и возможностей.... Но я, с удовольствием, слежу за новыми работами и разработками... А без недовольной, нашими решениями, молодежи развития Не будет...

[v-t-l]

все-таки что можно использовать вместо MongoDB?

Postgresql https://habrahabr.ru/post/304026/

[mirk]

Postgresql

Вот цитата из указанной выше статьи:

На моем ноутбуке, PostgreSQL работает около минуты, чтобы получить денормализованные данные для 12000 эпизодов, в то время как извлечение документа по ID в MongoDB занимает доли секунды.

И как после этого можно считать, что PostgreSQL работыет быстрее MongoDB?

[alexs]

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

[mirk]

Вот этой цитате я не очень верю.

Т.к. драйвера нет остается только верить. Проверить нет возможности.

Там что-то не то либо со структурой, либо с запросом.

Так в этом и плюс MongoDB - структура не учитывается, JSON просто индексируется по полям.
Учитывая, что MongoDB по архимтектуре должа быть очень простая, то в ней должно быть сильно меньше накладных расхзодов на добавление новых записей.

[alexs]

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

У меня вообще показатели эффективности:
Сохранение данных в БД <1сек
Открытие первичных документов (это обычно 2-4 рабочих таблицы из нескольких сот млн записей из которых выбирается 1-10 записей для документа для каждой таблицы и несколько 10 справочников не очень больших (порядка 100 строк) <5сек
Простые оперативные отчёты - 1 - 30 сек
Аналитика верхнего звена управления - < 10 сек.

И эти критерии хорошо показывают что и где надо оптимизировать.

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

[Лекс Айрин]

Так в этом и плюс MongoDB

Еще неизвестно плюс это или минус.

А с другой - эти самые дяди когда-то стали Не довольны теми инструментами, которые есть (были на тот момент) и придумали что-то более-универсальное и удобное...

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

две шаги налево, две шаги направо, шаг вперед и две назад (с)

Судя по всему, MongoDB это шаг временный шаг назад. Или два.

[azsx]

Так как всем понятно, что толком ничего в lazarus под mnogodb нет (есть некоторые попытки под делфи), потому спрошу мною непонятое.
Допустим, некоторые данные (особенно если их немеряно) удобно хранить в формате json. Почему эти данные нельзя сохранять в поле text (memo) строя по конкретным объектам (строкам, массивам, числам) отдельные таблички с полями (хешами для строк и обычными для логики и чисел) с простыми индексами и работать в знакомой sql технологии?

[Лекс Айрин]

Почему эти данные нельзя сохранять в поле text (memo) строя по конкретным объектам (строкам, массивам, числам) отдельные таблички с полями (хешами для строк и обычными для логики и чисел) с простыми индексами и работать в знакомой sql технологии?

А кто говорит, что нельзя? В крайнем случае, можно написать конвектор json<-->sql. Другое дело, что пострадает производительность. (базу ведь еще нужно преобразовать)

[azsx]

Кстати точно можно даже конвертор написать. Если данные идут с пиковыми нагрузками, то логично закидывать их в стек, а затем разбирать когда поспокойнее. Но мой метод более nosql'ный, чем ваш. У Вас как сову на глобус.
Короче, тс, напишите пожалуйста, почему для вас так нужен именно mnogodb.