MongoDB

[Лекс Айрин]

У Вас как сову на глобус.

Это часто встречается)))

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

мда... бедный стек... если будет переполнение, то программа рухнет.

Короче, тс, напишите пожалуйста, почему для вас так нужен именно mnogodb.

Если честно, то мне оно никуда не уперлось)) Надо будет, я использую какую-нибудь опенсорсную sql-ную базу. Тем более, что необходимо будет как-то решить вопрос с работоспособностью программы (например, приложить dll).

[azsx]

Если честно, то мне оно никуда не уперлось

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

[mirk]

для постгреса на правильно созданных данных - и миллион записей - мелочи

Миллин почти для любой БД мелочи. Вопросы начинаются с миллиардов.

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

С чего бы это, ведь многие (MySQL и PostgreSQL) добавляют подобный функционал к себе.

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

Потому что это уже костыль.
Зачем делать костыль, если можно решить более элегантным решением?
Это давно все поняли и добавляют подобный функционал (опять можно посмотреть на пример MySQL и PostgreSQL).

Короче, тс, напишите пожалуйста, почему для вас так нужен именно mnogodb.

Так писал уже.
Хочу хранить очень много (миллиарды) неструктурированных данных, в которых могу при необходимости поискать.
Если более приближенно к задаче - хочу просто все логи запихнуть в БД для последующего анализа. А их очень много и поля у них разумеется разные. Да и я даже не все возможные поля знаю.

[azsx]

хочу просто все логи запихнуть в БД для последующего анализа. А их очень много и поля у них разумеется разные.

Порасуждаю. Я пишу логи в тхт всегда с тех пор, как делал реальные выборки с grep. Оказалось, что по условию grep делает выборку со скоростью hdd винчестера. То есть 56 гб файл - выборка делалась 9 минут (меньше чуть). Кстати sed - 11 минут. То есть если основной критерий скорость выборки - то строчные файлы самый быстрый по записи и чтению. Хотя БД (из коробки или модулями) могут сжимать поток данных строки zip'ом на лету + реляции сокращают объём данных, всё таки выборки в бд делаются намного медленнее. Для этого в бд используют индексы.
Я уже пытался обрабатывать большие данные, на миллиардах записях индексы помогают слабо (или я в них не шарю). Если миллиард хитов в год, то в среднем это 35 обращений в секунду. Только в реальности если это не с датчиков логи, то будет то 10 тысяч хитов в секунду, то 1. Как я понимаю вам просто необходимо будет юзать стек. Почему бы там в файле и не оставить? То есть я бы получал json, растягивал в строку, писал бы строки в файлы формата "date.txt". Если по какому-то полую нужен индекс, то юзал бы связку (имя файла - номер строки) как id, а хеши данных выводил бы в таблицу sql. Вот я понять не могу.
Это слишком замудренно, mnogodb делает это из коробки?
Мои выборки или индексы слишком просты для ваших задач?
Чо то ещё, чего я даже не понимаю?
зы
лично я мечтаю разобраться в колоночных БД в некоторых задачах они реально ускорят выборки. Некогда.

Так писал уже.

Извините, пожалуйста, пропустил.

Это давно все поняли и добавляют подобный функционал

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

[alexs]

Вопросы начинаются с миллиардов.

И это предлагается запихивать не в неструктурированном виде? Ну... Ну...
И кто тут ССЗБ?

[mirk]

Оказалось, что по условию grep делает выборку со скоростью hdd винчестера.

Вот только если усложнить запрос выборки, да еще свести выборку из несколько логов - будет искаться днями.
На эту тему писали свой опыт вроде mail.ru на habrahabr.ru

Это слишком замудренно, mnogodb делает это из коробки?

Да. По идее такое же умеют и некоторые другие БД.
Но думается мне, что MongoDB быстрее работает. Проверить затруднительно из-за отсутствия драйвера.

И это предлагается запихивать не в неструктурированном виде?

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

[Лекс Айрин]

С чего бы это, ведь многие (MySQL и PostgreSQL) добавляют подобный функционал к себе.

Упрощение формата это всегда шаг назад. Это не Зло... это необходимость.

И это предлагается запихивать не в неструктурированном виде?

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

[mirk]

Упрощение формата это всегда шаг назад. Это не Зло... это необходимость.

Спорный момент про шаг назад. Почему именно назад? Все ведь зависит от точки зрения. Т.е. это больше философский вопрос.
Вот про необходимость - полностью согласен. Если бы задачу можно было решить стандартными методами, не городи ли бы огород с парсингом JSON.

[Лекс Айрин]

Спорный момент про шаг назад. Почему именно назад?

Потому что это отказ от возможностей более навороченного формата.

[Дож]

В принципе, в качестве одного из возможных решений, не сильно сложным кажется написание динамической библиотеки с враппером над mongo-c-driver, которую можно использовать из программы не паскале. (А может, даже, и с самим mongo-c-driver возможно слинковаться.)

[azsx]

По идее такое же умеют и некоторые другие БД.
Но думается мне, что MongoDB быстрее работает.

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

Вот именно этот момент мне и интересен, я его не понимаю. Пожалуйста, покажите Ваш реально сложный запрос.

да еще свести выборку из несколько логов

Не уверен.
1. Я делил текстовые файлы по дискам, то есть 4 диска делали выборку параллельно из 4 файлов. По сути получалось в 4 раза быстрее.
2. БД данные также хранит в файлах. Другой вопрос, что в innodb каждая таблица - это один файл (кажется), в pg файлы принудительно делят по 4 гб. Текстовым файлам вы можете задать свой размер исходя из характера данных и типов выборок.
При чём это именно под данные пула строк, который по сути ничего не связывало и смысла не было пихать в БД.

На эту тему писали свой опыт вроде mail.ru на habrahabr.ru

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

[WAYFARER]

Кстати точно можно даже конвертор написать.

PostgreSQL тоже NoSQL СУБД и поддерживает те же самые форматы хранения что и MongoDB(json,xml, key-value).

[mirk]

Потому что это отказ от возможностей более навороченного формата.

Это не означает шаг назад.
Иначе так и кэширование можно назвать шагом назад от традиционной БД.

В принципе, в качестве одного из возможных решений, не сильно сложным кажется написание динамической библиотеки с враппером над mongo-c-driver, которую можно использовать из программы не паскале. (А может, даже, и с самим mongo-c-driver возможно слинковаться.)

Как? Даже не знаю в какую сторону смотреть.

Вот именно этот момент мне и интересен, я его не понимаю. Пожалуйста, покажите Ваш реально сложный запрос.

Любой сложный запрос, который можно выболнить просто используя SQL в БД, но сложно выполнить грепами на файлах.

Проблема в том, что они могут совершить концептуальные ошибки, но баблом всё равно вытянуть проект.

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

PostgreSQL тоже NoSQL СУБД и поддерживает те же самые форматы хранения что и MongoDB(json,xml, key-value).

Да, писал об этом уже выше.
Именно поэтому и хочется сравнить PostgreSQL и MongoDB.

[Дож]

В принципе, в качестве одного из возможных решений, не сильно сложным кажется написание динамической библиотеки с враппером над mongo-c-driver, которую можно использовать из программы не паскале. (А может, даже, и с самим mongo-c-driver возможно слинковаться.)

Как? Даже не знаю в какую сторону смотреть.

Если вкратце, то также, как и любые другие врапперы.

1. Берём mongo-c-driver и документацию к ней
2. Пишем на языке C динамическую библиотечку, которая экспортирует наружу необходимые (или почти все) функции из mongo-c-dirver (это обычные функции на Си)
3. На языке паскаль пишем заголовок к библиотечке. В нём нужно проимпортировать экспортированные функции, и объявить некоторые константы и типы (может можно обойтись без объявления типов, так как бо'льшую частью mongo-c-driver можно использовать через указатели)
4. Пользуемся в соответствии с документацией на mongo-c-driver