LINUX.ORG.RU

MongoDB 1.6.0

 , , ,


0

1

MongoDB — документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++.

Шардинг

Шардинг готов для использования в производстве, давая возможность масштабировать MongoDB горизонтально. При необходимости единственный экземпляр mongod может быть преобразован в распределённый кластер с нулевым временем простоя.

Replica Sets

Replica sets — новый метод репликации, который предоставляет возможность автоматически переключаться среди участников кластера.

Replica pairs объявлен устаревшим; использующим данный функционал рекомендуется перейти на использование replica sets.

Другие улучшения

  • Опция w (и wtimeout) форсирует запись на n серверов до успешного завершения операции (особенно хорошо работает с replica sets)
  • $or-запросы
  • Улучшенная многопоточность
  • $slice-оператор для возвращения части массива (подмассива)
  • 64 индекса на каждую коллекцию (в 1.4 было 40)
  • 64-битные целые могут быть представлены в командной оболочке посредством NumberLong
  • Команда findAndModify теперь поддерживает upserts (аналог SQL MERGE). Также теперь позволяется указывать поле, которое должно быть получено
  • $showDiskLoc — опция для отображения местонахождения документа на диске
  • Поддержка IPv6 и доменных сокетов UNIX
  • C++ клиент отделён от бинарного пакета

>>> Подробности

★★

Проверено: catap ()
Последнее исправление: MuZHiK-2 (всего исправлений: 2)
Ответ на: комментарий от crypto5

Ну мы ведь не о таких локах говорили

Такие локи в сложном приложении способны привести к deadlock.
Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно. Транзакций пока нет, разграничения прав доступа тоже нет. Ссылочной целостности нет.
Как элементарно перевести средства с одного счёта на другой без транзакций?

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

> Такие локи в сложном приложении способны привести к deadlock.

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

Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

Смешалось все в кучу, понятие SQL/NoSQL ортогонально транзакциям..

А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно. Транзакций пока нет, разграничения прав доступа тоже нет. Ссылочной целостности нет.

Как элементарно перевести средства с одного счёта на другой без транзакций?

В berkeleydb например есть транзакции.

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

> Такие локи не могут привести к дедлокам, почему я обьяснил выше. В каких СУБД c поддержкой транзакций принципиально отсутствуют дедлоки? Клиентсткие приложения работающие с такими СУБД не будут подвержены дедлокам?

Смешалось все в кучу, понятие SQL/NoSQL ортогонально транзакциям..

Действительно транзакции можно реализовать и в NoSQL СУБД. И таковые реализованы.

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

> лиентсткие приложения работающие с такими СУБД не будут подвержены дедлокам?

Сколько раз мне еще повторить слово «нет»? ;-)

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

Сколько раз мне еще повторить слово «нет»? ;-)

Не верю! Дайте мне примеров! :-) Дайте хотя-бы ссылку.

anonymous
()
Ответ на: комментарий от crypto5

MVCC реализовано в Firebird. Это первая СУБД c MVCC. Дедлок в ней возможен. В каких СУБД с поддержкой транзакций это не так?

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

> MVCC реализовано в Firebird. Это первая СУБД c MVCC. Дедлок в ней возможен. В каких СУБД с поддержкой транзакций это не так?

Те ДБ о которых ты говоришь, они с write lock-ом. А в couchdb write lock-a к примеру нету.

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

В couchdb транзакций нет. Я утверждаю, что если в СУБД есть поддержка транзакций, то возможны дедлоки. Добавьте в couchdb транзакции и получите возможность дедлока.

anonymous
()
Ответ на: комментарий от crypto5

В одиной коллекции документов предметную область не выразишь.
(Как генеалогическое древо в документную СУБД уложить?)
Как только в рамках одной транзакции появляются взаимосвязанные документы возникают дедлоки.

anonymous
()
Ответ на: комментарий от crypto5

Т.е. получаем возможность появления дедлоков.

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

>Поэтому нельзя сказать, что только использование NO-SQL СУБД, решает проблему deadlock, и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

в одном предложении сразу две ветряные мельницы.

Кто сказал, что _только_ использование NO-SQL СУБД, решает проблему deadlock? Да nosql вообще в целях своих не решал именно эту проблему. Просто упростили схему работы, убрали бОльшую часть транзакций (основной источник дедлоков) и подняли производительность базы и поэтому большинство дедлоков ушло. Не более того.

и что это значительное преимущество NO-SQL СУБД по сравнению с SQL СУБД.

А преимущество как раз значительное, вероятность появления дедлоков снижена на порядки.

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

> убрали бОльшую часть транзакций
В Mongodb есть транзакции?
Их там нет. Есть атомарность отдельного объекта коллекции и все.


А преимущество как раз значительное, вероятность появления дедлоков снижена на порядки.

Отсутствие транзакций не тянет на преимущество, скорее наоборот. От дедлоков помогает грамотное проектирование структуры БД и логики обработки данных.

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

> Как только в рамках одной транзакции появляются взаимосвязанные документы возникают дедлоки.

ITT носкулисты не могут понять эту простую истину.

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

>А как использовать NO-SQL СУБД в финансовых БД, мне совсем неясно.

1) Утверждение за весь NO-SQL, а претензии к конкретной реализации. Это неверно.

Транзакций пока нет,

Транзакции на уровне БД не обязательны.

разграничения прав доступа тоже нет.

и как же это большинтво финансовых систем использует для всех один логин к базе?

Ссылочной целостности нет.

которую опять таки обычно отключают в пользу триггеров.

Как элементарно перевести средства с одного счёта на другой без транзакций?

Версиями, метками в объектах, через очередь заданий.

А, теперь понял, трехзвенки до вас так и недошли?

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

>> убрали бОльшую часть транзакций

В Mongodb есть транзакции?

Их там нет. Есть атомарность отдельного объекта коллекции и все.

Читать: «убрали бОльшую часть необходимости в транзакциях»

Отсутствие транзакций не тянет на преимущество, скорее наоборот.

отсутсвие необходимости в транзакциях тянет на преимущество.

От дедлоков помогает грамотное проектирование структуры БД и логики обработки данных.

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

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

и как же это большинтво финансовых систем использует для всех один логин к базе?

Идиоты админы?

Транзакции на уровне БД не обязательны.

Обязательны

которую опять таки обычно отключают в пользу триггеров.

Не понял. Ссылочную целотность надобно отключать? Ccылочная целостность реализуют триггерами? Но как её реализовать, (ссылочную целостность) если атомарна работа только с одним объектом коллекции?

Как элементарно перевести средства с одного счёта на другой без транзакций?

Версиями, метками в объектах, через очередь заданий. т.е. реализуем транзакции самостоятельно? Зачем, если эту возможность можно заложить в СУБД?

Итого: 1. транзакции необходимы в СУБД 2. пока в Mongodb их нет 3. когда они появятся скорость обновлений данных упадет

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

anonymous
()
Ответ на: комментарий от AVL2

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

anonymous
()
Ответ на: комментарий от AVL2

А, теперь понял, трехзвенки до вас так и недошли?

трёхзвенка отменяет удобство использования транзакций без извращений с метками?

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

>> и как же это большинтво финансовых систем использует для всех один логин к базе?

Идиоты админы?

Скорее разработчики.

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

Анонимус доказал, что ему носиквел не нужен. Молодец.

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

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

>трёхзвенка отменяет удобство использования транзакций без извращений с метками?

удобство - нет, а смысла становится много меньше. Хотя трехзвенку я упомянул в первую очередь в связи с логином и уровнями доступа к БД.

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

>Как элементарно перевести средства с одного счёта на другой без транзакций?

Попробую:

{«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

вот, пожалуй, самое очевидное, что приходит в голову.

anonymous
()
Ответ на: комментарий от AVL2

удобство - нет, а смысла становится много меньше.

Смысла намного больше когда функционал транзакций реализован на уровне СУБД

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

У вас в трехзвенке сервер приложений единственным незашифрованным паролем с СУБД коннектится?

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

{«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}


Где первый и второй номер счёта?

anonymous
()
Ответ на: комментарий от AVL2

>Вопрос в том, что новые технологии обычно появляются тогда, когда старые подводят. И носиквел тому не исключение.

Ну, насчет «подводят», это все-таки lor_mode, а вот то, что всякие «ораклы» всовывают туда, где им не место — это да. Любой задристаный сайтик ведь должен быть непременно ЪНтырпрайез-SQL92, хранить картинки в файлах? фи, что за дикость и ниасиляция блобов?!

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

>> {«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

что значит «первый и второй номер счёта»?

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

> что значит «первый и второй номер счёта»?

Номер счета, с которого деньги ушли, и номер счета, на который они пришли.

Еще интересно знать, что в данном случае является «документом» - счет или акт перевода денег?

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

>> {«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Где первый и второй номер счёта?

ок, специально для смущенных латиницей повторяю:

{«тип»:«проводка», «Дата»:«09.08.2010» «Дебет»:«50» «Кредит»:«51» «Сумма»:«100»}

anonymous
()
Ответ на: комментарий от tailgunner

>Номер счета, с которого деньги ушли, и номер счета, на который они пришли.

{«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

Помнится, твой любимый наезд на собеседника — сказать что у него дислексия. Ты, паходу, частенько это слово в детстве слышал, вот оно и въелось тебе в речевой центр.

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

> Помнится, твой любимый наезд на собеседника — сказать что у него дислексия.

В твоем случае это не наезд. Где номера счетов? Что является документом - счет или акт перевода?

Ты, паходу, частенько это слово в детстве слышал, вот оно и въелось тебе в речевой центр.

Еще я люблю наезжать на пафосных придурков, которые пишут безграмотно.

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

>А остатки на счетах менять не надо?

ппц. И эти люди будут говорить мне за избыточность и достоверность?

anonymous
()
Ответ на: комментарий от tailgunner

>Где номера счетов?

Читай, тут вроде почти по-русски написано:

«type»:«posting», «date»:«2010-08-09» «debit»:«50» «credit»:«51» «amount»:«100»}

или вот совсем по-русски:

{«тип»:«проводка», «Дата»:«09.08.2010» «Дебет»:«50» «Кредит»:«51» «Сумма»:«100»}

Что является документом - счет или акт перевода?

Бухгалтерская справка.

Еще я люблю наезжать на пафосных придурков, которые пишут безграмотно.

Наверное, каждую неделю зеркало меняешь?

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

>ппц. И эти люди будут говорить мне за избыточность и достоверность?
т.е. каждый раз заново пересчитываем.
Избыточность это конечно плохо, но иногда, например, в случае больших накладных расходов ею можно чуть чуть пожертвовать. Думаю это тот самый случай.

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

>Смысла намного больше когда функционал транзакций реализован на уровне СУБД

смотря какой ценой. СУБД без транзакций востребованы.

У вас в трехзвенке сервер приложений единственным незашифрованным

паролем с СУБД коннектится?

а у вас все еще логины с паролями по незашифрованным каналам вместо сертификатов с ключами?

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

>т.е. каждый раз заново пересчитываем.

Наоборот.

Избыточность это конечно плохо, но иногда, например, в случае больших накладных расходов ею можно чуть чуть пожертвовать. Думаю это тот самый случай.

Ну да, конечно, посчитать остаток когда это необходимо — это же такие мегатонны накладных расходов! Не то что пересчитывать при каждой поводке, это же повысит производительность на порядки!

anonymous
()
Ответ на: комментарий от tailgunner

>>> Что является документом - счет или акт перевода?

Бухгалтерская справка.

Бумажная?

Предлагаешь гранитные скрижали?

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

>>>> Что является документом - счет или акт перевода?

Бухгалтерская справка.

Бумажная?

Предлагаешь гранитные скрижали?

Мне в данном случае материальные объекты неинтересны... мне нужны абстракции: документы в MongoDB.

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

а у вас все еще логины с паролями по незашифрованным каналам вместо сертификатов с ключами?

У меня то как раз по зашифрованным.
Вы не ответили на вопрос.

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

это же такие мегатонны накладных расходов! А разве нет? N - операция просмотра остатков = 10 (в месяц) PT - количество проводок = 30000 (с начала года) P - добавлено проводок за месяц 10000

S1 = (N*PT)+P S2 = (P*2)+N

Ну и помножим на кол-во бухов.

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

это же такие мегатонны накладных расходов!
А разве нет?
N - операция просмотра остатков = 10 (в месяц)
PT - количество проводок = 30000 (с начала года)
P - добавлено проводок за месяц 10000

S1 = (N*PT)+P
S2 = (P*2)+N

Ну и помножим на кол-во бухов.

anonymous
()
Ответ на: комментарий от tailgunner

>Мне в данном случае материальные объекты неинтересны... мне нужны абстракции: документы в MongoDB.

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

Ответ прежний: бухгалтерская справка. (конечно, в данном случае можно было бы ответить «приходник», но в приведенном документе для этого явно недостаточно атрибутов)

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

> Стрелок, ты, если не в теме, конечно можешь глупости говорить, или вопросы наивные задавать

Я этот наивный вопрос задаю уже не первый раз: что является документом.

Ответ прежний: бухгалтерская справка.

Итак, бухгалтерская справка является документом MongoDB, представляющим перевод денег со счета на счет? Являются ли сами счета документами?

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

Я этот наивный вопрос задаю уже не первый раз: что является документом

Ну дык, кто ж виноват, что ты читать не умеешь?

Являются ли сами счета документами?

Нет, а что? Ты где-то выше увидел такой документ?

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

>> Являются ли сами счета документами?

Нет, а что? Ты где-то выше увидел такой документ?

Я увидел номера счетов: 50 и 51 (если это номера счетов, конечно - ты так и не сказал, что в твоей JSON-строке является номерами счетов). Если счетам не соответствуют документы, то где хранятся текущие суммы? Что вообще соответсвует счету?

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

Конечно расчёты грубые и примерные. Для простоты предположим, что операция выборки данных и добавления стоит одинаково и равна 1.
S1 случай когда мы ведем бухгалтерию сначала года и не храним пересчитанные остатки.
N - сколько раз бух. смотрит в документ в котором есть остатки
N*PT = 10*30000 = 300000
P стоимость добавления проводок за текущий месяц + 10000
Итого 310 000

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

S2
тут вкралась ошибка
должно быть так:
S2 = P + Pfix*2 + N
Pfix - стоимость операции изменения остатков для 2-х счетов
новые проводоки за месяц запись проводок 10000 + 2 + 10 = 10 012

вот вам и разница 310 000 против 10 12


anonymous
()
Ответ на: комментарий от tailgunner

>Я увидел номера счетов: 50 и 51 (если это номера счетов, конечно - ты так и не сказал, что в твоей JSON-строке является номерами счетов)

По-моему, я это ясно написал, даже в двух редакциях.

Если счетам не соответствуют документы, то где хранятся текущие суммы?

А чем, по-твоему, вообще является счет (в терминах предметной области) и за каким забором там надо хранить «текущие суммы» (что это вообще такое? сальдо? И на кой банан тебе сдалось сальдо после каждой проводки?)

Что вообще соответсвует счету?

MapReduce

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

Теперь я посчитаю.

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

N — кол-во проводок; c — кол-во запросов остатка. Всякую хитрую оптимизацию, которую позволяет, например, cjuchdb, мы не учитываем. Получаем:

вставка=O(1) выборка=O(N*c)

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

Ошибка №1. Остатки НУЖНО пересчитывать (иначе, как узнать его значение?)

И — ВНЕЗАПНО — ты предлагаешь пересчитывать эти остатки после каждой(!) проводки. В итоге получаем: вставка=O(N*N) выборка=O(1*c)

Да, просто феерическая экономия! Срочно звони в Стокгольм!

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

>> Что вообще соответсвует счету?

MapReduce

То есть, чтобы узнать сумму на счету (ах да, «сальдо»), нужно запускать жаваскрипт, который проведет MapReduce по всем «бухгалтерским справкам»? Это рекомендованный метод решения таких задач? Кажется, я понимаю, откуда требование к крайней масштабируемости :D

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

Вы неправильно поняли. Я не предлагаю пересчитывать остатки после каждой проводки. Зачем? Пересчет остатков можно сделать в случае крайней необходимости. Просто каждая проводка изменяет значение остатков. Это не лишает возможности произвести пересчёт и для сверки.

Всякую хитрую оптимизацию, которую позволяет, например, cjuchdb, мы не учитываем

Это ту которая точно также будет хранить сальдо?

Ошибка №1. Остатки НУЖНО пересчитывать (иначе, как узнать его значение?)

Их не нужно пересчитывать постоянно, ибо они уже хранятся в базе пересчитанные!

Срочно звони в Стокгольм!

Вы туда уже звонили?

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

И вобще зачем их постоянно пересчитывать (проводки) у меня же транзакции используются и я уверен в своей СУБД

anonymous
()
Ответ на: комментарий от tailgunner

>по всем «бухгалтерским справкам»?

Да, при чем — два раза.

Это рекомендованный метод решения таких задач?

Это единственный надежный метод решения задачи на протяжении последних 500 лет.

Кажется, я понимаю, откуда требование к крайней масштабируемости :D

Кажется, я понимаю, откуда такой пионерский задор у SQL-троллей: от безграмотности. С таким знанием предметной области, как у наших специалистов_по_всему, любые технологии будут повержены. Ну да что там, дело известное: http://www.demotivation.ru/images/20090520/vwe4ydh39rxb.jpg

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

Вы у себя деньги в кошельке после каждой траты пересчитываете заново?
Или по текущему сальдо ориентируетесь?

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

>У меня то как раз по зашифрованным.

ну тогда не совсе понятно, в чем суть вопроса.

Средства шифрации канала есть, средства безопасной аутентификации тоже. Все, что нужно, это желание их использовать.

Вы не ответили на вопрос.

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

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

>То есть, чтобы узнать сумму на счету

Ты же хотел нормализацию данных...

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

>Вы неправильно поняли.

Ну конечно, тут ведь только ты дартаньян

Это ту которая точно также будет хранить сальдо?

Это ту, которая делает инкрементальный MapReduce. В этом случае выборка получается O(logN)

Я не предлагаю пересчитывать остатки после каждой проводки. Зачем?

А значения остатков ты из астралов брать собираешься?

Их не нужно пересчитывать постоянно, ибо они уже хранятся в базе пересчитанные!

Не, ну я ж говорю — гений! Просто гений — и всё тут!

...алсо, че там насчет консистентности было? ась?

Вы туда уже звонили?

не, а я че? это ж ты за нобелевкой поедешь.

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

> Это единственный надежный метод решения задачи на протяжении последних 500 лет.

Абак рулит.

http://www.demotivation.ru/images/20090520/vwe4ydh39rxb.jpg

Ссылка на демотиватор - какое достойное завершение спора (по ссылке не ходил, естественно) %)

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

Что толку от аутентификации, если в СУБД нет нормальных средств разграничения доступа, если ошибка в программе позволит непривелигированному хакеру Васе дропнуть все коллекции? (например все проводки)

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

А я и не просил за всех я у Вас интересовался

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

>Вы у себя деньги в кошельке после каждой траты пересчитываете заново?

да. Мало ли — сдачу не так дали, или, патрег оброни, выронил пока доставал. А ты нет? Может, ты и наличие кошелька проверяешь только непосредственно у кассы?

Или по текущему сальдо ориентируетесь

С вопросами ориентации — это на другой ресурс.

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

А значения остатков ты из астралов брать собираешься?

А если мозг включить и посты перечитать? Все равно непонятно откуда?
Изменить текущее значение сальдо для счета на основе суммы проводки
И пересчитать сальдо на текущую дату по суммам проводок для Вас одно и тоже?


Не, ну я ж говорю — гений! Просто гений — и всё тут!

Я Вас тоже люблю!

...алсо, че там насчет консистентности было? ась?

а она где-то нарушена?

не, а я че? это ж ты за нобелевкой поедешь.

Да не я скромный. Может Вы самии мне нобелевеку пробъёте. Тем более знаете куда звонить. Я с Вами поделюсь потом честно-честно!



anonymous
()
Ответ на: комментарий от tailgunner

>Абак рулит.

Да понятно уж давно, читать ты не умеешь.

Ссылка на демотиватор - какое достойное завершение спора

Сколько пафоса! А по теме есть что сказать?

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

да. Мало ли — сдачу не так дали, или, патрег оброни, выронил пока доставал.


И мелочь тоже?

А ты нет?

Нет я по карте рассчитываюсь.

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


С вопросами ориентации — это на другой ресурс.

А Вы всегда так на слово «ориентация» реагируете?
А цвета Вас не волнуют «розовый» там, «голубой» да и вообще все цвета «радуги»?

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

>А если мозг включить и посты перечитать? Все равно непонятно откуда?

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

...алсо, че там насчет консистентности было? ась?

а она где-то нарушена?

Нет, не нарушена. Её просто нет. Поскольку наш гений хранит отдельно значение остатка и изменяет его при каждой проводке.

Тем более знаете куда звонит

Нет, спасибо, мне тут лулзов хватит.

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

Нет, не нарушена. Её просто нет. Поскольку наш гений хранит отдельно значение остатка и изменяет его при каждой проводке.


Вы мне пример конткретной проблемы обрисуйте в связи с этим.

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

Специально для Вас выдержка из википедии:

Проблема поддержки консистентности данных

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

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

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

В mongodb нет ни триггеров ни ссылочной целостности ни транзакций ни проверки вводимых данных, ни проверки на соответствие структуре вводимых данных. ID объектов могут слететь внезапно.
Какая к черту в этой СУБД может быть консистентность данных!

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

>Там все равно только банковская карта, да пропуск.

Круто! Терять нечего, за то — сколько пафоса! Ведь я прав? Тебя ведь за утерю пропуска не будут в первый отдел тягать все две недели до выдачи «волчьего билета»?

Вы всегда так на слово «ориентация» реагируете?

Нет, что Вы? Только в контексте идиотских вопросов!

А цвета

О, да Вы профи!

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

> Тебя ведь за утерю пропуска не будут в первый отдел тягать все две недели до выдачи «волчьего билета» Конечно не будут. Сотрут ID пропуска в базе и всё.

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

>Вы мне пример конткретной проблемы обрисуйте в связи с этим.

Да какие проблемы? Ну, подумаешь, данные неконсистентны, говно какое! Зато у нас настоящая «взрослая» ынтырпраес РСУБД с транзакциями, а не пионерский носкуль!

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

>Конечно не будут. Сотрут ID пропуска в базе и всё.

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

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

А вы википедию-то почитайте почитайте. В этом пионерском носкуле (mongodb) проблема консистентности стоит горааздо острее.

Примера значит не будет. Обосновать не можете.

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

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

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

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

>В этом пионерском носкуле (mongodb) проблема консистентности стоит горааздо острее. ...которой, мы так и не увидели даже на примере бухгалтерской проводки. Ну да ладно.

Примера значит не будет. Обосновать не можете.

Ну, почитай первые две-три страницы, там фанаты sql чото требовали.

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

>Аргументов больше нет?

Аргументов чего?

Или ты ждешь, что я стану с копипастой беседовать?

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

>Да не, чтоб чужих не пропускать.

Думаешь, тайна кумыса так строго охраняется? Ну-ну, блажен, кто верует.

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

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


Кто читал внимательно, тот увидел. Хотите писать бухгалтерию с БД в Mongodb? Вперёд. Время покажет кто был прав. Загнутся все эти no-sql поделки со временем. А если нет, то только если приобретут возможности развитых РСУБД. Я вам это гарантирую.

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

> Думаешь, тайна кумыса так строго охраняется? Ну-ну, блажен, кто верует.
Не, мы кумыс не производим

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

>> Абак рулит.

Да понятно уж давно, читать ты не умеешь.

Зато у меня воображение нормально развито: я представляю себе бухгалтера 500 лет назад, который, когда какой-нить купец спрашивает о состоянии своего счета, начинает рыть кучу пергаментных томов %)

Ссылка на демотиватор - какое достойное завершение спора

Сколько пафоса! А по теме есть что сказать?

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

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

>Кто читал внимательно, тот увидел.

Ну так можно «на бис», для слепого Базилио, где такое было?

Время покажет кто был прав

да уже показало

А если нет, то только если приобретут возможности развитых РСУБД

чото мускуль не спешит помирать. Или он уже «развитая РСУБД»?

Я вам это гарантирую

инфа 100%?

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

да уже показало

что я прав.

чото мускуль не спешит помирать. Или он уже «развитая РСУБД»?

Почти. Он в процессе развития.

инфа 100%?

Я гарантирую это!

anonymous
()
Ответ на: комментарий от tailgunner

>Зато у меня воображение нормально развито: я представляю себе бухгалтера 500 лет назад, который, когда какой-нить купец спрашивает о состоянии своего счета, начинает рыть кучу пергаментных томов %)

Да уж, развито. И даже слишком.

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

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

Возвращаясь к вопросу выбора технологий: про дверь уже было в этом треде?

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

> Ну так можно «на бис», для слепого Базилио, где такое было? Базилио только притворялся слепым, но он всё видел!

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

Ночь уже. До завтра anonymous

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

> Ну да, бгыкаешь, весело тебе.

Ну веселишь ты меня, что тут поделать.

А все от того, что ты не в теме очень сильно. А понимал бы ты, хоть немного, о чем речь — плакал бы от позора.

«Спердобейся», какая прелесть %)

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

>Ну веселишь ты меня, что тут поделать.

Да, делать нечего, тем более, причину твоего веселья мы уже установили.

«Спердобейся», какая прелесть %

Ты бы завязывал с веществами — видишь, как плохо они влияют? Вот теперь глюки у тебя — прочел то, что не написано.

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

> причину твоего веселья мы уже установили.

Не «мы» %) Или у тебя multiple personalities?

Ты бы завязывал с веществами

Я не могу с ними завязать - я к ним не привязывался :/

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

>я к ним не привязывался :/

сходи к доктору. Новости будут плохие.

Вот представь. Рассказываешь ты человеку про print «HelloWorld», а он тебе в ответ: «Бгг. Ну ты и ламо! Где ты такие принтеры видел? Эта твоя контора HelloWorld небось еще и картриджи одноразовые делает, или мож, принтеры одноразовые? Ты дебил, как принтер может на экране печатать? Хотя, у таких недоумков может и экран бумажный быть»

Видишь, как смешно? И главное, ему ведь тоже смешно, да. Думает, «Эк я его уделал!» А ему не смеяться, ему плакать надо. Слезами позор свой смывать, хоть и бесполезно это.

И вот, ты ему говоришь это, что, мол, радоваться-то ему особо нечему. Но куда там! Он же победил, он же крутой! Вот он и пишет тебе в ответ какой-то невнятный бред, типа «спердобейся штоле? ыы!»

Вот, стрелок, такие дела. Да.

anonymous
()
Ответ на: комментарий от tailgunner

>по ссылке не ходил, естественно

Анон, кстати, тоже. Потому что там что-то говорится о хотлинкинге :)

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

>Анон, кстати, тоже. Потому что там что-то говорится о хотлинкинге :)

обнови своего касперского

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

>> я к ним не привязывался :/

сходи к доктору. Новости будут плохие.

Новостей не будет :)

Рассказываешь ты человеку про print «HelloWorld»

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

А ему не смеяться, ему плакать надо. Слезами позор свой смывать

Какая трогательная забота :)

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

>> Новостей не будет :)

То есть, ты так ничего и не понял?

Анон, что у тебя с памятью?

Ты бы завязывал с веществами

я к ним не привязывался :/

сходи к доктору. Новости будут плохие.

Новостей не будет :)

То есть, ты так ничего и не понял?

Что я понять-то должен был из этого диалога? :)

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

>Что я понять-то должен был из этого диалога? :)

Да не переживай. Кому-то дано, кому-то нет.

anonymous
()
Ответ на: комментарий от tailgunner

>Тебя не поймешь - то «слезами позор смывать», то «не переживай» :)

Если ничего нельзя изменить — остается только не переживать.

Да, жаль, конечно. В некоторых топиках ты производил впечатление человека, который знает, о чем говорит.

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

>>S2 случай когда мы каждый раз меняем значение остатков на счетах и его не нужно пересчитывать заново (да, это немного избыточно).

Ошибка №1. Остатки НУЖНО пересчитывать (иначе, как узнать его значение?)

И — ВНЕЗАПНО — ты предлагаешь пересчитывать эти остатки после каждой(!) проводки. В итоге получаем: вставка=O(N*N) выборка=O(1*c)

Вставка - N*N?! Это как? И что это за 1*c такое? :)

Я вижу три операции при вставке: вставка в список проводок и два обновления или вставки в аггрегированные данные. Как получили N*N?

При выборке - O(1) - просто запрос. Откуда взялся 'c'?

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

В общем позвольте пояснить что имеют ввиду про значения остатков, сальдо и прочее уважаемые анонимусы и защитники NoSQL (сам я свою позицию до конца не выработал).

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

В базе также хранятся map reduce процедуры, много их. Как пример одной такой пары:

- map в качестве аргумента всегда берет документы по одному (у нас это проводка, для примера с суммой 100), результатом работы map есть вызов emit(key,value), в нашем случае map вызовет emit(cred,+100) и emit(debet,-100) (знаки могут быть наоборот, я уж не помню что там и как в этом бухучете).

- reduce собирает в себя все что навыплевывал map,а также то что навыплевывали другие reduce, т.е. reduce(keys, values, rereduce) при этом keys это массив [[key, doc_id1],[key, doc_id2]], а values массив [val1, val2], где val1 это значение value выданное в функции map по ключу key при просмотре документа doc_id1. Самое важное: значение каждого reduce для каждого ключа сохраняется в B-tree (от чего база так сильно пухнет). Соответственно если мы запросим данные по какому то произвольному диапазону ключей, то NoSQL быстренько найдет значения этих ключей у себя в дереве, и вызовет для всех них reduce(null, [val1,val2,val3..], true), т.е. время выборки O(logN), что в общем то неплохо. В нашем простейшем случае reduce должна вернуть просто sum(values).

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

Когда будет написано куча map-reduce то мы поимеем любые варианты информации по счетам, оборотам, остаткам, взаимозачетам и пр имея в базе только одну сущность - документы с движением средств.

Две особенности: - чтобы писать на map reduce надо капитально повернуть мозги, например ключи-массивы и группировки по ним я так интуитивно и не понял, постоянно чиркаю на бумажке. - все эти map reduce вызываются только когда их просят, а не когда добавляются новые документы, при этом вызываются только для необработанных версий документов, результаты reduce записываются B-дерево в нужное место. Соответственно добавление новых документов нисколечки не тормозит.

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

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

> Когда будет написано куча map-reduce то мы поимеем любые варианты информации по счетам, оборотам, остаткам, взаимозачетам и пр имея в базе только одну сущность - документы с движением средств.

Это единственное полезное, что сказал анон. Но на вопрос «а не будет ли это слишком дорого - генерировать эту информацию при запросе?» он предпочел петросянить про 500 лет.

После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом.

Да, интересно. Я подозреваю, что без использования внешних менеджеров блокировок это невозможно.

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

>обнови своего касперского

Какой касперский?

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

> После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

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

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

> Но на вопрос «а не будет ли это слишком дорого - генерировать эту информацию при запросе?» он предпочел петросянить про 500 лет.

Знаешь, я уверен, что ты собирался задать вопрос «а не будет ли это слишком дорого - генерировать эту информацию при запросе?». Я даже уверен, что мой ответ ты воспринимал в контексте этого своего вопроса.

Скажи, как могло получиться так, что вместо этого простого вопроса ты набрал на клавиатуре совсем другое? А именно, является рекомендованной методикой суммирование всех операций по счету? Цитата:

«То есть, чтобы узнать сумму на счету (ах да, „сальдо“), нужно запускать жаваскрипт, который проведет MapReduce по всем „бухгалтерским справкам“? Это рекомендованный метод решения таких задач?»

И вот ссылка, что бы любой желающий мог меня проверить: http://www.linux.org.ru/jump-message.jsp?msgid=5196253&cid=5208385

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

anonymous
()
Ответ на: комментарий от redbaron

>После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

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

Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.

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

А можно на пальцах по шагам объяснить как этого достичь, вместо игры в наводящие вопросы «догадайся сам, а я помогу»? хочется конструктива =)

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

>>После всего вышесказанного для меня остается непонятным одно: как запретить отгружать товар если долг контрагенты выше допустимого? Мы не можем в одной атомарной операции и прогнать все mapreduce и воспользоваться этим результатом. Может более просвященные люди расскажут как, очень интересно.

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

Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.

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

Теперь по пунктам.

1. «ты получил четкую модель данных» - нет, не получил. Она уже была. Причем GognoDB тут не помогло никак.

2. «по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией» - опа... Так значит тупой подсчет позиции и элементарная проверка на выход из допустимого диапазона теперь называется «аналитика с верификацией». Век живи, век учись.

3. «Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.» - ага, конечно. Вот только вопрос был в том, как именно это сделать. На это уважаемый эксперт глубокомысленно промолчал.

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

Мы не можем в одной атомарной операции и прогнать все mapreduce

Зачем нам все mapreduce? За балансы счетов отвечает только один.

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

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

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

<trolling mode=«fat»> Если клиент - один в день, то да. Так что все оправдано. Для псевдобизнеса «на коленке» ваши кушеткаДБ - самое оно. Прибыли нет, но и программисты много не требуют: работают за идею, а на оплачиваемую работу таких «спецов» никто брать не хочет. </trolling>

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

>1. «ты получил четкую модель данных» - нет, не получил. Она уже была. Причем GognoDB тут не помогло никак.

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

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

Это все они не могут обойтись без nosql как раз на этапе сбора данных и получения четкой модели данных, потому что пользователи наваливаются без счета и в пике сношают всю инфраструктуру нафиг, а денег с них даже не взять ибо что интернет-банк, что спайлог - услуги бесплатные, то есть с косвеной оплатой через другие услуги.

А ты молодец, поставил p3-600 с гигом рамы и провел свои три накладные в сутки - на кой ляд тебе все эти носиквелы?

2. «по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией» - опа... Так значит тупой подсчет позиции и элементарная проверка на выход из допустимого диапазона теперь называется «аналитика с верификацией». Век живи, век учись.

Ну, аналитика может быть и такой. У тебя копеечка, а у Абрамовича - рубль, но у вас у обоих - деньги. Важно то, что ты можешь посчитать все, что тебе нужно и если тебе нужна одна сумма - let it be и не парься.

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

3. «Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.» - ага, конечно. Вот только вопрос был в том, как именно это сделать. На это уважаемый эксперт глубокомысленно промолчал.

а тут ничего нового за последние пятьдесят лет не было. Берешь сегмент очереди событий, обсчитываешь его, валидируешь. Если хорошо-сохраняешь. Если нет - повтор. При внесении изменений в очередь в указанном сегменте инициируешь ревалидацию соответствующего результата обработки. Затем ты можешь аместо постоянной переобработки сотен тысяч входящих событий, использовать эти промежуточные итоги. Конроль идет по версиям и признакам валидности.

Что тут еще непонятно?

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

Я тебе про Фому, а ты мне про Ерему.

>1. «ты получил четкую модель данных» - нет, не получил. Она уже была. Причем GognoDB тут не помогло никак.

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

1. Как то, нужен мне nosql или нет, связанно с тем, что я написал выше?

2. не щекочет и не щекотал. Когда такое начиналось, обычно единственно правильный вариант - выгнать чудо-девелопера, что наваял адский ужас, что даже кластер не тянет, и переписать его код.

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

Google и Facebook - другая история. Там, даже если данные просто исчезнут, беды большой не будет. И задачи у них решаются другие.

Это все они не могут обойтись без nosql как раз на этапе сбора данных и получения четкой модели данных, потому что пользователи наваливаются без счета и в пике сношают всю инфраструктуру нафиг, а денег с них даже не взять ибо что интернет-банк, что спайлог - услуги бесплатные, то есть с косвеной оплатой через другие услуги.

Какая оплата - такой и сервис. Какой сервис - такие и технологии.

А ты молодец, поставил p3-600 с гигом рамы и провел свои три накладные в сутки - на кой ляд тебе все эти носиквелы?

Похоже тебе из астрала все хорошо видно.

2. «по которой можешь строить всю аналитику и не просто аналитику, а аналитику с верификацией» - опа... Так значит тупой подсчет позиции и элементарная проверка на выход из допустимого диапазона теперь называется «аналитика с верификацией». Век живи, век учись.

Ну, аналитика может быть и такой. У тебя копеечка, а у Абрамовича - рубль, но у вас у обоих - деньги. Важно то, что ты можешь посчитать все, что тебе нужно и если тебе нужна одна сумма - let it be и не парься.

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

3. «Все, что тебе нужно, это во первых, подсчитывать и валидировать промежуточные результаты, а во вторых, использовать их.» - ага, конечно. Вот только вопрос был в том, как именно это сделать. На это уважаемый эксперт глубокомысленно промолчал.

а тут ничего нового за последние пятьдесят лет не было. Берешь сегмент очереди событий, обсчитываешь его, валидируешь. Если хорошо-сохраняешь. Если нет - повтор. При внесении изменений в очередь в указанном сегменте инициируешь ревалидацию соответствующего результата обработки. Затем ты можешь аместо постоянной переобработки сотен тысяч входящих событий, использовать эти промежуточные итоги. Конроль идет по версиям и признакам валидности.

Что тут еще непонятно?

Все непонятно.

redbaron спросил «как запретить отгружать товар если долг контрагенты выше допустимого?»

Какая очередь? Что, все операции записи стают в очередь, и потом что-то принимается, а что-то отбрасывается?

Что считается событием: сделка или попытка сделки?

Что именно при этом хранится в базе?

Как для программы-клиента выглядит успешность/неуспешность совершения проводки?

redbaron, а тебе понятно? Может объяснишь?

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

Я понял общую концепцию но как это конкретно реализовать на примере не понял :) В простой ситуации у нас есть два типа документов в базе: те что двигают деньги и те что двигают товар.

Решение в лоб: проверяем что у нас по деньгам и если все ок, то создаем документ с движением по товарам. Если подходить по всей строгости, то может возникнуть случай когда документ движения денег создастся после проверки, но до создания документа движения товара и тогда SQL подход так и вопит о необходимости транзакций.

Но вот что подумалось, поскольку документ движения денег будет создан в любом случае независимо от успеха/неудачи движения товара, то с точки зрения бизнеса что мы используем транзакции и с филигранной точностью раздаем разрешения на отгрузку, что мы тупо решаем ее наивным способом выше - нет никакой разницы. Ну прикрутили мы транзакции, ну прибежал клиент за товаром на 2 минуты раньше чем бухгалтерия вбила новый документ увеличивающий долг в базу - SQL со всеми наворотами никак не спас нас от ситуации, что и долг есть и товар уплыл, а раз SQL не спасает то можно и NoSQL поставить, раз результат один и тот же, зато бонусов сильно больше, как ни крути а иметь в базе только фактически существующие документы и мапредьюсить их и в хвост и в гриву сильно проще с точки зрения разработки и поддержки, а также сильно лучше с точки зрения скорости.

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

>1. Как то, нужен мне nosql или нет, связанно с тем, что я написал выше?

nosql решает вполне конкретные задачи. Нет задач - нет nosql.

2. не щекочет и не щекотал. Когда такое начиналось, обычно единственно правильный вариант - выгнать чудо-девелопера, что наваял адский ужас, что даже кластер не тянет, и переписать его код.

Пока это работает - nosql не нужен.

Google и Facebook - другая история. Там, даже если данные просто исчезнут, беды большой не будет. И задачи у них решаются другие.

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

Какая оплата - такой и сервис. Какой сервис - такие и технологии.

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

Похоже тебе из астрала все хорошо видно.

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

redbaron спросил «как запретить отгружать товар если долг контрагенты выше допустимого?»

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

Какая очередь? Что, все операции записи стают в очередь, и потом что-то принимается, а что-то отбрасывается?

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

Что считается событием: сделка или попытка сделки?

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

Что именно при этом хранится в базе?

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

Как для программы-клиента выглядит успешность/неуспешность совершения проводки?

ответ системы с номером проводки и ее статусом. Клиент в такой системе не может работать как локальный. Он должен работать как браузер в общей системе, то есть формировать запросы и показывать ответы. В идеале - асинхронно.

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

>Решение в лоб: проверяем что у нас по деньгам и если все ок, то создаем документ с движением по товарам. Если подходить по всей строгости, то может возникнуть случай когда документ движения денег создастся после проверки, но до создания документа движения товара и тогда SQL подход так и вопит о необходимости транзакций.

Транзакции здесь не при чем. Они только добавят вам дедлоков и только.

Вы должны резервировать суммы на счетах, прежде проводить товар. Решение о проводке зависит от бизнес-модели. Или вы работаете с товарным кредитом и проводите товар (тогда резервирование денежных средств работает в сервисном режиме, позволяя гибко установить ограничения товарного кредита) или без него, тогда товар не проводится.

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

>Методика рекомендованная Екатериной Медичи: Используйте MapReduce!

ой, смищьно-смищьно!

Я смотрю, ты специалист в этом вопросе? Тогда к тебе тот же вопрос, что и к стрелку: какие изменения произошли в методике бухучета со времен Екатерины Медичи?

anonymous
()
Ответ на: комментарий от AVL2

>Решение о проводке зависит от бизнес-модели. Или вы работаете с товарным кредитом и проводите товар (тогда резервирование денежных средств работает в сервисном режиме, позволяя гибко установить ограничения товарного кредита) или без него, тогда товар не проводится.

То есть, модель ИС должна отражать бизнес-модель, и весь вопрос сводится к тому, на сколько точного отражения позволяет достичь тот или иной инструмент?

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

anonymous
()
Ответ на: комментарий от AVL2

2AVL2

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

ZODB Год 98-й если память не изменяет, не старше 95-го точно. Но в 98-м был.

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

В Zope кроме того возможет такой случай: До 2000г. банковские счета были не 20 знаков, а после 20. В SQL бодренько для новых документов завели новые таблицы. Или придумали отображение не 20-и занчных документов на 20 значные и конвертнули их. В Zope поправили схему, теперь в каталоге документов могут лежать как новые документы, так и старые. Есть адаптер для преобразования (для расчетов какихнибудь). Но если я открою для просмтора старый документ, то даже форму я увижу СТАРУЮ.

demmsnt
()
Ответ на: комментарий от anonymous

>Хотите писать бухгалтерию с БД в Mongodb? Вперёд.

Google ERP5. Там правда ZODB не для хранилища. Есть еще Японская банковская система, не помню названия.

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

>> Хотите писать бухгалтерию с БД в Mongodb? Вперёд.

Google ERP5. Там правда ZODB не для хранилища.

А что там для хранилища и причем тут ZODB? Она, IIRC, не документно-ориентированная, а объектно-ориентированная.

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

>Вопрос был «причем здесь ZODB?».

ZODB - Zope Object Database. Объекты и документы это не? Не одно и тоже в контексте скажем форума?

В принципе все тоже самое. Нет map-reduce. Да. Есть словари по которым можно искать, хоть map-reduce делай.

Я к тому, что 10 лет народ использует, а тут столько шума. И да SQL там нет, хотя можно и сделать.

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

> Объекты и документы это не?

По-моему, не. Хотя, конечно, зависит от того, что именно СУБД знает о хранимых объектах.

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

Ну объект это данные + всевозможные манипуляции над ними. Документ это данные (структурированные record или struct).

СУБД знает только 1) Что за поля в рекорде и 2) Какие методы есть.

demmsnt
()
Ответ на: комментарий от tailgunner

Ах да есть некоторые ограничения по типам того что может хранится тут или там:

class IMark(Interface):
«„„This is the book mark object.““»

url = TextLine(
title=u"URL/Link",
description=u"URL of the website",
default=u"http://www.zope.org",
required=True)

description = Text(
title=u"Description",
description=u"Description of the website",
default=u"",
required=False)

class IBookMarker(IContainer):
«„„This is the container for all book marks.““»

name = TextLine(
title=u"Name of BookMarker",
description=u"A name for BookMarker",
default=u"",
required=True)

def __setitem__(name, obj):
pass

__setitem__.precondition = ItemTypePrecondition(IMark)


class IMarkContained(IContained):
«„„A book mark can only contain in a BookMarker““»

__parent__ = Field(
constraint = ContainerTypesConstraint(IBookMarker))

вот вам внешняя ссылка и ограничение на тип.

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

> СУБД знает только 1) Что за поля в рекорде и 2) Какие методы есть.

вот вам внешняя ссылка и ограничение на тип.

Насколько я понял, в NoSQL нет ни того, ни другого. СУБД никак вообще не понимает структуру документа.

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

>Насколько я понял, в NoSQL нет ни того, ни другого. СУБД никак вообще не понимает структуру документа.

Ни фига себе сказку подсократили.

А как искать по конкретному полю в документе, не понимая структуру? Индексы там строить, на уникальность проверять?

в монго специально используют bson, чтобы быстро бегать по структуре документа.

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

В Mongodb это не так. Структура у экземпляров коллекции есть. Правда создаётся она динамически. Документы одной коллекции могут отличаться. Конечно нет практического смысла хранить в одной коллекции документы не имеющие общих атрибутов, но СУБД это не запрещает. Поиск может производится по любым атрибутам. Жаль, что права доступа к атрибутам документа, его субобъектам и массивам раздавать нельзя.

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

В Zope есть права. Через адаптеры можно делать вьюшки. Так, что.....

Я подозреваю это снова Америку открыли. Документные СУБД. Ок, Смотрим FramerD. Марвин Мински это в 70-х еще развивал. Фрейм состоит из слотов (1 и более).

Например фрейм содержащий информацию о человеке:

Фрейм:
Имя: Иван
Фамилия: Иванов
Отчестов: Иванович

Есть так называемые протофреймы. Это схемы собственно говоря. Тоесть фреймы описывающие человека произошли от протофрейма - «схема человека» (всё условно).

Значением слота может быть ссылка на другой фрейм.

Характеристики СУБД FramerD: Размер дистрибутива СУБД меньше 1mb (когда я смотрел было около 800 кб). 64 битная адресация ограничивает размер базы помоему в 4 террабайта. Несколько машин легко объединяются в кластеры. Запросы на Shceme.

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

4TB Это без учета размера самих данных в слотах.

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

В ZODB - тормоза. Судя по отзывам скорость вставки записей 70 зап./сек
В Firebird 12000 зап./сек
В MongoDB 49000 зап./сек

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

И ты учти в ZODB объект это 1500 полей, + логика если надо. А на примере простых кортежей это, да MySQL силен.

demmsnt
()
Ответ на: комментарий от AVL2

>> Насколько я понял, в NoSQL нет ни того, ни другого. СУБД никак вообще не понимает структуру документа.

А как искать по конкретному полю в документе, не понимая структуру? Индексы там строить, на уникальность проверять?

Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?

Повторяю еще раз для анонимного брата - СУБД не знает. То, что структуру документа знает приложение, как бы очевидно.

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

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

anonymous
()
Ответ на: комментарий от tailgunner

>Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?

Возражения есть.

Постороение индекса для сортировки по полям документа:

db.factories.ensureIndex( { «metro.city» : 1, «metro.state» : 1 } );

// these queries can use the above index:

db.factories.find( { «metro.city» : «New York», «metro.state» : «NY» } );

db.factories.find( { «metro.city» : «New York» } );

db.factories.find().sort( { «metro.city» : 1, «metro.state» : 1 } );

db.factories.find().sort( { «metro.city» : 1 } )

Проверка на уникальность.

db.things.ensureIndex({firstname: 1, lastname: 1}, {unique: true});

db.things.ensureIndex({firstname: 1}, {unique: true});

db.things.save({lastname: «Smith»});

// Next operation will fail because of the unique index on firstname.

db.things.save({lastname: «Jones»});

Все это делается на сервере.

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

Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?


Есть. Без знания структуры (атрибутов документа) СУБД не сможет построить индексы. Название коллекций это тоже часть структуры.

anonymous
()
Ответ на: комментарий от demmsnt

Скорость выбоки данных (Выбранные данные пишутся перенаправлением вывода в файл):

Firebird
milliseconds: 7197 records per second: 112171

MongoDB
milliseconds: 4681 records per second: 196299

anonymous
()
Ответ на: комментарий от AVL2

>>Я сказал «СУБД никак не понимает структуру документа». Здесь возражения есть?

Возражения есть.

Постороение индекса для сортировки по полям документа:

db.factories.ensureIndex( { «metro.city» : 1, «metro.state» : 1 } );

То есть единственное, что СУБД знает о документе - это то, что он JSON-коллекция?

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

Нет. Документ не JSON коллекция. Коллекция это набор JSON документов.
Mongodb знает атрибуты документов (экземпляров коллекций) и может их индексировать.

anonymous
()
Ответ на: комментарий от tailgunner

>То есть единственное, что СУБД знает о документе - это то, что он JSON-коллекция?

Нет. Именно поэтому там и не json, а его бинарная версия с , что СУБД не просто хранит пару - ключ <-> json документ с тремя операциями выборка, удаление и сохранение документа по ключу, а смотрит внутрь документа и оперирует его составляющими.

Поиск, сортировка, выбор, обновление полей - все есть.

select ssn from users where last_name=«Smith»;

db.users.find({last_name: 'Smith'}, {'ssn': 1});

http://www.mongodb.org/display/DOCS/Advanced+Queries

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

Ананимус! Ну мы то с тобой знаем, что это все один человек пишет, просто на логин/разлогин тоже время надо.

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

А как он будет гарантировать уникальность элементов если база - распределенная и ограничения по уникальности не связаны?

Пример:

db.things.ensureIndex({foo: 1}, {unique: true});

db.things.ensureIndex({bar: 1}, {unique: true});

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

> http://www.mongodb.org/display/DOCS/Advanced+Queries

Чем больше я читаю доки по этой MongoDB, тем сильнее ощущение безжалостного велосипедостроительства. И призраки IMS, CODASYL и ранних реляционных языков запросов с косами стоят...

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

Вопрос в распределенности базы (в необходимости опрашивать все узлы?) или в том, что ограничения по уникальности не связаны?

не понимаю, в чем тут разница с любой другой СУБД?

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

>Чем больше я читаю доки по этой MongoDB, тем сильнее ощущение безжалостного велосипедостроительства. И призраки IMS, CODASYL и ранних реляционных языков запросов с косами стоят...

Если речь идет об отказе от функционально полного и бесконечного синтаксиса SQL в пользу отрывочных объекто-ориентированных подпорок, то это больше похоже на откат к risc-процессорам.

И причины имхо схожи. Запросы sql, особенно с вложенными подзапросами могут быть сколь угодно сложны, а значит бесконечно трудоемки, а ведь каждый запрос должен быть атомарен, то есть потенциально базу можно легко поставить на колени. В оже время 99% запросов, это простейшие селекты да инсерты, которые гораздо удобней описывать объектом.

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

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

>Map != структура.

Что хотел сказать?

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

> Вопрос в распределенности базы (в необходимости опрашивать все узлы?) или в том, что ограничения по уникальности не связаны?

не понимаю, в чем тут разница с любой другой СУБД?

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

Интересно, как в MongoDB решается вопрос о том, уникальная ли запись или нет. Могу предположить, что узел, на которых пришел запрос, сначала шлет другим узлам уведомление, что есть желание добавить новую запись. И если никто не против - добавляет запись и снова шлет уведомление (теперь уже о том, что объект добавлен).

Так оно работает?

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

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

Интересно, как в MongoDB решается вопрос о том, уникальная ли запись или нет. Могу предположить, что узел, на которых пришел запрос, сначала шлет другим узлам уведомление, что есть желание добавить новую запись. И если никто не против - добавляет запись и снова шлет уведомление (теперь уже о том, что объект добавлен).

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

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

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

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

> Запросы sql, особенно с вложенными подзапросами могут быть сколь угодно сложны, а значит бесконечно трудоемки, а ведь каждый запрос должен быть атомарен, то есть потенциально базу можно легко поставить на колени.

И решить проблему предлагается выполнением JS на стороне сервера... гениально.

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

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

Да так и есть, потому и вопрос.

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

Если только мастер-узел выполняет запрос, то тогда он - узкое место. Куда делось масштабирование? Или оно распространяется только на чтение?

К тому же, что если база действительно большая, и на один узел не помещается? Делать шардинг? ОК, см. ниже..

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

Это все хорошо тогда, когда происходит чтение.

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

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

>Если только мастер-узел выполняет запрос, то тогда он - узкое место. Куда делось масштабирование? Или оно распространяется только на чтение?

Репликация не регает вопросы масштабирования производительности. Она решает вопросы резервирования данных. И доступности.

Это все хорошо тогда, когда происходит чтение.

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

да тоже самое. Индексы на мастере, он и решает.

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