MongoDB

Модератор: Модераторы

Re: MongoDB

Сообщение Лекс Айрин » 24.10.2016 13:08:49

azsx писал(а): У Вас как сову на глобус.


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

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


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

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

Если честно, то мне оно никуда не уперлось)) Надо будет, я использую какую-нибудь опенсорсную sql-ную базу. Тем более, что необходимо будет как-то решить вопрос с работоспособностью программы (например, приложить dll).
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: MongoDB

Сообщение azsx » 24.10.2016 13:38:07

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

Но Вы не топик стартер...
зы
например, я лично просто не понимаю как я могу для себя это использовать, так как весьма слаб в nosql.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: MongoDB

Сообщение mirk » 24.10.2016 21:35:59

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

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

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

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

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

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

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

Так писал уже.
Хочу хранить очень много (миллиарды) неструктурированных данных, в которых могу при необходимости поискать.
Если более приближенно к задаче - хочу просто все логи запихнуть в БД для последующего анализа. А их очень много и поля у них разумеется разные. Да и я даже не все возможные поля знаю.
mirk
постоялец
 
Сообщения: 317
Зарегистрирован: 24.09.2007 10:03:39

Re: MongoDB

Сообщение azsx » 25.10.2016 06:03:32

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

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

Извините, пожалуйста, пропустил.
Это давно все поняли и добавляют подобный функционал

Мода. Чего они только не добавляют, вместо того, чтобы проблемы с автовакумом решать.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: MongoDB

Сообщение alexs » 25.10.2016 09:09:12

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

И это предлагается запихивать не в неструктурированном виде? Ну... Ну...
И кто тут ССЗБ?
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4053
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Re: MongoDB

Сообщение mirk » 25.10.2016 18:57:44

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

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

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

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

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

Предложения?
Судя по статьям найденным в интернете выбор не особенно велик.
Некоторые пихают это в ElasticSearch или Sphinx, но это уже сложнее и логов надо иметь гораздо больше чем у меня.
mirk
постоялец
 
Сообщения: 317
Зарегистрирован: 24.09.2007 10:03:39

Re: MongoDB

Сообщение Лекс Айрин » 25.10.2016 19:07:23

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


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

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



хи-хи.. а я и не заметил)) Видимо, хотят сделать что-то вроде никовского фактографа. Ниторый, фактически, является самоорганизующейся базой знаний (экспертной системой). Кстати, заюзал бы подобное.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: MongoDB

Сообщение mirk » 25.10.2016 19:21:00

Лекс Айрин писал(а):Упрощение формата это всегда шаг назад. Это не Зло... это необходимость.

Спорный момент про шаг назад. Почему именно назад? Все ведь зависит от точки зрения. Т.е. это больше философский вопрос.
Вот про необходимость - полностью согласен. Если бы задачу можно было решить стандартными методами, не городи ли бы огород с парсингом JSON.
mirk
постоялец
 
Сообщения: 317
Зарегистрирован: 24.09.2007 10:03:39

Re: MongoDB

Сообщение Лекс Айрин » 25.10.2016 19:39:36

mirk писал(а):Спорный момент про шаг назад. Почему именно назад?


Потому что это отказ от возможностей более навороченного формата.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: MongoDB

Сообщение Дож » 25.10.2016 19:48:52

В принципе, в качестве одного из возможных решений, не сильно сложным кажется написание динамической библиотеки с враппером над mongo-c-driver, которую можно использовать из программы не паскале. (А может, даже, и с самим mongo-c-driver возможно слинковаться.)
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

Re: MongoDB

Сообщение azsx » 26.10.2016 03:08:46

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

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

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

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

К сожалению опыт огромных компаний не всегда подходит мне. Проблема не в том, что они могут нанять десятки хороших программистов. Проблема в том, что они могут совершить концептуальные ошибки, но баблом всё равно вытянуть проект. Я так не смогу.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: MongoDB

Сообщение WAYFARER » 26.10.2016 19:20:10

azsx писал(а):Кстати точно можно даже конвертор написать.

PostgreSQL тоже NoSQL СУБД и поддерживает те же самые форматы хранения что и MongoDB(json,xml, key-value).
Аватара пользователя
WAYFARER
энтузиаст
 
Сообщения: 517
Зарегистрирован: 09.10.2009 00:00:04
Откуда: г. Курган

Re: MongoDB

Сообщение mirk » 30.10.2016 13:53:26

Лекс Айрин писал(а):Потому что это отказ от возможностей более навороченного формата.

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

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

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

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

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

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

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

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

Да, писал об этом уже выше.
Именно поэтому и хочется сравнить PostgreSQL и MongoDB.
mirk
постоялец
 
Сообщения: 317
Зарегистрирован: 24.09.2007 10:03:39

Re: MongoDB

Сообщение Дож » 31.10.2016 00:19:03

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

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

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

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

Пред.

Вернуться в Базы данных

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Рейтинг@Mail.ru