Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Со вторым что будете делать? C>>>Ничего, всем плевать. G>>Пока это не касается бабла. Как только кто-либо попадет на бабло из-за несохраненности данных сразу станет не плевать. C>Для бабла можно сделать отдельную РБД, с блекджэком и распределёнными транзакциями. Никто же не говорит, что NoSQL нужно прямо для всего использовать.
Вот, первая трезвая мысль.
C>Бабло — вообще неинтересная задача, так как собрать систему, обрататывающую все транзакции даже для крупнейших банков, сейчас можно путём нескольких телефонных звонков и пары-тройки чеков в несколько миллионов долларов. У Microsoft есть классная статья: http://research.microsoft.com/apps/pubs/default.aspx?id=64534
Почитаю.
C>Вот быстрые деньги, то бишь high-speed trading — это уже интереснее. И там как раз никаким SQL'ем и не пахнет. А для durability чаще всего используют многократную репликацию данных в памяти или подобные кастомные решения.
Там вообще записью на диск не пахнет, медленные слишком диски.
Здравствуйте, Ikemefula, Вы писали:
A>>Примитивная, то есть упираемся в диски, а не в CPU. I>Задачи вроде "коммивояжера", это примитивная обработка?
Зависит от параметров.
A>>А значит производительностьц ентрализованной системы может быть меньше. А скорее всего, существенно меньше. I>Дискового пространства надо меньше. Процессорного времени — примерно столько же. Потому надо придумать, куда деть 600-кратную разницу в процессорном времени.
Зачем столько же процессорного времени для обработки меньшего количества данных?
A>>Да нет, это ты рассказывал по 10000 рабочих станций на которых что-то параллельно считается, не я. Если тебе очевидно, то ветку закрываем за очевидностью. I>"что-то параллельно считается" — где ты увидел такое ?
То есть они что, последовательно работают? Ну тогда заменяем одной рабочей станцией.
I>Ты похоже придумал задачу, решил и на этой основе утверждаешь что реальные задачи будут решаться так же легко.
О да, вот ты лично видел 10000 активно что-то считающих компьютеров. Фотки не покажешь? Твой пример реальной задачей и не пахнет.
Здравствуйте, gandjustas, Вы писали:
G>Что ты имеешь ввиду под словом консистентность? Вот меня учили что это свойство выполнимости всех ограничений и проверок по завершению транзакции.
G>Если ты имеешь ввиду консистентность в том виде как о ней говорится в CAP теореме,
Именно. Я в том посте чуть выше это и написал.
G>то её ты с полнотекстовым поиском никак не добьешься, если не променяешь на доступность.
Я об этом и говорю. А вы мне в ответ, что это нормальное поведение для SQL.
G>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
G>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.
M>>Зачем к дереву обращаться полнотекстовым поиском?
G>Ты внимательно прочитал что я написал?
Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»
Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?
G>К каким данным только полнотекстовый поиск позволяет запросы делать?
Здравствуйте, Mamut, Вы писали:
G>>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
G>>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.
M>>>Зачем к дереву обращаться полнотекстовым поиском?
G>>Ты внимательно прочитал что я написал?
M>Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»
M>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?
Здравствуйте, gandjustas, Вы писали:
ANS>>Вся ирония ситуации в том, что Durability в рамках одного хранилища данных обеспечить не возможно. G>ОК. Вот у тебя есть MS SQL Server, покажи подтверждение своим словам.
Но как??!
G>Репликация не поможет если данные не сохранены.
G>Я вообще-тоне знаю какой точно термин используется в случае NoSQL. Суть заключается в том что клиент отправляет команду записи на несколько инстансов, которые потом реплицируются между собой.
???
G>В случае наличия Durability усилия клиента не требуются.
Импосибиль. Если говорить, именно о Durability из ACID, а не о Consistency из CAP (хе-хе).
ANS>>PS. Кстати у упомненных выше 80%
проектов Durability не нужна. G>Отсутствие Durability сразу же лишает как консистентности, так и атомарности. G>При сбое невозможно узнать какая операция не выполнилась, что позволяет иметь несогласованные данные и невозможность откатить транзакцию.
Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?
G>>>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
G>>>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.
M>>>>Зачем к дереву обращаться полнотекстовым поиском?
G>>>Ты внимательно прочитал что я написал?
M>>Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»
M>>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?
К>Дим, дерево не есть структура?
Структура которого неизвестна
А черт, не то процитировал оказывается
2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
3)неструктурированные: текст, blob
Здравствуйте, gandjustas, Вы писали:
G>Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы
Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL?
G>предпочитаете пользоваться всяким г... которое обрабатывает только полуструктурированные данные, и то не лучшим образом.
Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Что ты имеешь ввиду под словом консистентность? Вот меня учили что это свойство выполнимости всех ограничений и проверок по завершению транзакции.
G>>Если ты имеешь ввиду консистентность в том виде как о ней говорится в CAP теореме,
ANS>Именно. Я в том посте чуть выше это и написал.
G>>то её ты с полнотекстовым поиском никак не добьешься, если не променяешь на доступность.
ANS>Я об этом и говорю. А вы мне в ответ, что это нормальное поведение для SQL.
Да. Потому что ACID не говорит о консистентности в таком виде.
.
ANS>>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется. G>>Покажи где он не выполнгяется.
ANS>ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем?
Здравствуйте, Mamut, Вы писали:
G>>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
G>>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.
M>>>Зачем к дереву обращаться полнотекстовым поиском?
G>>Ты внимательно прочитал что я написал?
M>Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»
M>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?
А ввше прочитай. Если их можно представить в виде дерева элементов, то данные становятся полуструктурированными. К ним можно xpath например обращаться.
G>>К каким данным только полнотекстовый поиск позволяет запросы делать? M>Собственно, к тексту
Прочитай еще раз внимательно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Вся ирония ситуации в том, что Durability в рамках одного хранилища данных обеспечить не возможно. G>>ОК. Вот у тебя есть MS SQL Server, покажи подтверждение своим словам.
ANS>Но как??!
G>>Репликация не поможет если данные не сохранены.
G>>Я вообще-тоне знаю какой точно термин используется в случае NoSQL. Суть заключается в том что клиент отправляет команду записи на несколько инстансов, которые потом реплицируются между собой. ANS>???
Именно. Репликация в таком виде как в современных СУБД работает когда есть гарантия Durability транзакций.
G>>В случае наличия Durability усилия клиента не требуются. ANS>Импосибиль. Если говорить, именно о Durability из ACID, а не о Consistency из CAP (хе-хе).
А я именно о нем и говорю.
ANS>>>PS. Кстати у упомненных выше 80%
проектов Durability не нужна. G>>Отсутствие Durability сразу же лишает как консистентности, так и атомарности. G>>При сбое невозможно узнать какая операция не выполнилась, что позволяет иметь несогласованные данные и невозможность откатить транзакцию.
ANS>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?
Ни в чем. Другой случай. Одна машина (!)
MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы
ANS>Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL?
Нет, в терминологический спор вступать не буду.
Есть хранилища, которые позиционируются как NoSQL, есть хранилища, которые позиционируются как SQL. Их и рассматриваем.
G>>предпочитаете пользоваться всяким г... которое обрабатывает только полуструктурированные данные, и то не лучшим образом.
ANS>Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.
Конкретнее.
Здравствуйте, iHateLogins, Вы писали:
HL>Согласен 100%. По моему опыту, наиболее часто приверженностью к NoSQL страдают (наслаждаются? ) люди с очень слабым знанием SQL как языка и реализации его в основных платформах (MySQL, Oracle, MSSQL, DB2).
Совершенно очевидно, что инструмент, который требует углубленных знаний для использования абсолютно непригоден в массовой разработке. Я напомню, что SQL поднялся на том, что запросы мог писать кто угодно, а не только специально обученный человек. Сейчас реалии изменились. БД уже не является продуктом для конечного пользователя. И в БД хранят структуры сложнее чем кортеж из 5-ти элементов.
Здравствуйте, gandjustas, Вы писали:
ANS>>Я об этом и говорю. А вы мне в ответ, что это нормальное поведение для SQL.
G>Да. Потому что ACID не говорит о консистентности в таком виде.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>>Здравствуйте, gandjustas, Вы писали: G>>>Ты вообще о чем? Где теряются гарантии, покажешь? ANS>>Тут
. ANS>>>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется. G>>>Покажи где он не выполнгяется. ANS>>ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем? G>Можем. Select по ключу.
M>>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом? G>А ввше прочитай. Если их можно представить в виде дерева элементов, то данные становятся полуструктурированными. К ним можно xpath например обращаться.
) люди с очень слабым знанием SQL как языка и реализации его в основных платформах (MySQL, Oracle, MSSQL, DB2).
