Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.12.10 11:39
Оценка: +1 -3 :))) :))
Здравствуйте, gandjustas, Вы писали:

G>Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.


Вообще-то это фатальное преимущество, а не недостаток.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re: Про NoSQL
От: Курилка Россия http://kirya.narod.ru/
Дата: 07.12.10 18:09
Оценка: 176 (8)
Здравствуйте, Mamut, Вы писали:

M>Странно, что в «Философии» про NoSQL мало говорят, но сегодня в твиттере увидел следующее:


[cut]

Эрик Мейер noSQL называть coSQL (via Mirrorer)
Re[9]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 10:52
Оценка: -2 :))) :))
Здравствуйте, adontz, Вы писали:

A>
A>CREATE TABLE [dbo].[Registry]
A>(
A>    [ID]     hierarchyid] NOT NULL,
A>    [Level]  AS ([ID].[GetLevel]())     PERSISTED,
A>    [Parent] AS ([ID].[GetAncestor](1)) PERSISTED,
A>    [Name]   nvarchar(256) NOT NULL
A>    [Value]  varbinary(MAX) NOT NULL
A>)
A>


Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии. На это же можно возразить тем, что в некоторых NoSql есть и транзакционность и возможность написания макросов для поддержки целостности базы данных...
Re[3]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 09:13
Оценка: -2 :))) :)
Здравствуйте, Sinix, Вы писали:

S>С такими требованиями вам и ОЛАПы подойдут

Большинство хороших ОЛАП движков это NoSQL решения...

S>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения

В NoSql базы вставляются не значения, а объекты.//

NoSQL это не key-value базы, не ORM, не отрицание SQL или реляционной модели, это использование движков к базе не только с колокольни реляционной модели.
Re: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 07:13
Оценка: 7 (2) +3
Здравствуйте, Mamut, Вы писали:

http://zabivator.livejournal.com/412053.html
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: Про NoSQL
От: tlp  
Дата: 05.12.10 10:15
Оценка: 83 (4)
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы


держи,

In-Database MapReduce (Oracle)
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 08:55
Оценка: 2 (1) +1 -2
Здравствуйте, gandjustas, Вы писали:

M>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.

F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>А где его достаточно? Таких задач исчезающе мало.


Такие задачи на каждом десктопе Вспомним реестр Windows.
Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
The God is real, unless declared integer.
Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 07:10
Оценка: 1 (1) +1 :))
Странно, что в «Философии» про NoSQL мало говорят, но сегодня в твиттере увидел следующее:

Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL

Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


© http://twitter.com/kellan/status/10504462699331584

Думаю, это достаточно философское замечание


dmitriid.comGitHubLinkedIn
Re[8]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:53
Оценка: +1 -3
Здравствуйте, netch80, Вы писали:

N>Предложи метод укладки, а я оценю его адекватность для наших задач.

Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
В чем у тебя сложность?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:35
Оценка: +2 -2
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, Mamut, Вы писали:


M>>

M>>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL

M>>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


M>Со словом "медленная" категорически не согласен. По долгу службы сейчас пишу на C++, потому что SQL сильно тормозит. Да и не все запросы на него хорошо ложатся.


Видимо ты просто не знаешь его

Рассказываю тайну. SQL база данных может спокойно порвать любой твой код, потому что СУБД оптимизирует доступ к диску. А это сейчас самая медленная операция.
Re[2]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 08:05
Оценка: -3 :)
Здравствуйте, iHateLogins, Вы писали:

HL>Согласен 100%. По моему опыту, наиболее часто приверженностью к NoSQL страдают (наслаждаются? ) люди с очень слабым знанием SQL как языка и реализации его в основных платформах (MySQL, Oracle, MSSQL, DB2).


Совершенно очевидно, что инструмент, который требует углубленных знаний для использования абсолютно непригоден в массовой разработке. Я напомню, что SQL поднялся на том, что запросы мог писать кто угодно, а не только специально обученный человек. Сейчас реалии изменились. БД уже не является продуктом для конечного пользователя. И в БД хранят структуры сложнее чем кортеж из 5-ти элементов.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:45
Оценка: 45 (1) +2
Здравствуйте, adontz, Вы писали:

A>Всегда в теле таблицы.

Нет, либо всегда отдельно, либо в теле таблицы до определенного размера.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:33
Оценка: 13 (1) +1 -1
Здравствуйте, netch80, Вы писали:

N>И сомнительно, и бессмысленно.

Совершенно верно — NoSQL это сомнительно и в большинстве случаев бессмыслено. =))

N>Как тут уже заметил noetic, ключевое слово — _нужной_ половины.

Нет, ключевое слово — неспецифицированную, глючную и медленную. И если она даже после этого нужная, то тем хуже для noSql.

N> А многим не подходит даже модель реляционной базы.

Только в том случае, если они не умеют реляционкой пользоваться. Все-таки, как совершенно верно замечено, порог вхождения в реляционку, на самом деле, довольно высок и есть иллюзия, что проще взять noSql и не забивать себе голову.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:16
Оценка: 4 (2) +1
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Mamut, Вы писали:


M>>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


N>И сомнительно, и бессмысленно.

N>Сомнительно — потому, что для большинства NoSQL-применений специфика такова, что на SQL их укладывать даже если можно, то совершенно неадекватно.
N>Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано.
К сожалению многие повелись на NoSQL-hype и пихают его во все дыры. Хотя как основное хранилище NoSQL базы почти не пригодны.

N>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит.

Современные СУБД умею гораздо больше, чем описано в стандартах SQL 92.
Применяя те же методы проектирования и развертывания, что в NoSQL, можно добиться результатов не хуже, чем в NoSQL решениях.

N>А многим не подходит даже модель реляционной базы.

Это от того что не умеют правильно её использовать.
Re[26]: Про NoSQL
От: Sinix  
Дата: 06.12.10 18:10
Оценка: 4 (1) +2
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт.


S>>Это стёб, я надеюсь?


ANS>Это правда жизни. Реальность, данная нам в ощущениях А вся веселуха начинается, когда пользователь узнаёт, что у него бек-ап месячной давности и тот не поднимается. Durability это вам не хухры-мухры.


В таком случае, беседовать особо не о чем. Не обижайтесь, но незнание матчасти поправимо. А вот пользователи, которые должны терпеть результаты самодовольного "А нужно нам что попроще" — это уже верх непрофессионализма

Адью
Re[11]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:23
Оценка: -1 :))
Здравствуйте, adontz, Вы писали:

A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.

A>Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?

Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур. Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...
Re[2]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 22:33
Оценка: +3
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Mamut, Вы писали:


К>[cut]


M>>Думаю, это достаточно философское замечание


К>А вот взгляд на NoSQL как на NoJoin и ключевая мысль:


К>

К>Strict normalization makes as much sense as the waterfall model.


Статья — говно

Database engines can physically normalize the data automagically

Агащаз.

It is simply impossible to make sense of the content of any one table. Building new applications on top of this mess is expensive and bug prone.

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

Suppose you want to design a database of research papers.

Потрясающий дизайн без указания того что надо делать.

Strict normalization makes as much sense as the waterfall model.

Чувак нифига не понимает в цикле разработки.

Такое даже читать противно. Дилетантизм, замешаный с откровенным враньем.
Re[12]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 07.12.10 12:33
Оценка: 30 (1) +1
Здравствуйте, Mamut, Вы писали:

M>В MySQL добавляют за неимением «более сложных данных»

В MySql отменили транзитивное замыкание или nested sets?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 18:34
Оценка: 13 (2)
Здравствуйте, gandjustas, Вы писали:

ANS>>Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.

G>Конкретнее.

Самая большая проблема — DDL. Любое применение DDL это даунтайм. Именно отсюда растут ноги у всяких sсhema-less способностей. Т.е. хранение именно неструктурированных данных мало кому нужно, а вот возможность менять схему без трёхдневного даунтайма пригодилось бы многим.

Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.

Из-за этой способности залочить на неопределённое время всю систему и неопределённости поведения при наличии сотен тысяч таблиц с тысячами колонок, людям вместо того, чтобы выполнить "CREATE TABLE/ALTER TABLE" приходится городить огород типа как у FriendFeed. Похожую схему применяет SalesForce. Только они вместо, хранения всего "документа" в одном блобе имеют таблицу на 500 строковых колонок для хранения данных. А для "индексов" создают таблицы как и FriendFeed, только SF пишет в них синхронно, а FF асинхронно. Сумрачный отечественный гений всё пытается породить какую-то ерунду из одной таблицы на каждый тип данных плюс вагон джойнов для построения отношения. Почему я не могу использовать для хранения отношений РБД, особенно если за неё уплочено? Вопрос риторический.

Что интересно, что метапрограммирование хотя и пролезло в майнстрим в последние 10лет, до этого активно использовалось и теоретиками и немайнстримовыми практиками. А создать таблицу в ран-тайм — почему считается зазорным. Если бы не легковесные pure java RBD (a-la "H2") вообще просвета бы не было.

Всё остальное уже обсосано: ACID требует слишком многого. Если c Isolation сразу просекли, что если её обеспечить, то пользователей у такой БД будет не много. И сразу сказали, что изоляция есть хорошо, но есть и уровни изоляции, а об остальном позаботьтесь сами. А с Durability получилось интереснее. Из формулировки "данные должны остаться не зависимо от сбоев нижележащих систем" появилась формулировка "данные должны остаться независимо от сбоев вышележащих систем". В результате если кому нужно то первое — настоящее — durability, у того большие проблемы.

Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу. Я тут намедни термин интересный узнал: "непредвиденная консистентность". Вот такие системы обычно консистентны по недоразумению. Если бы был сверху стандартный слой дающий гарантированные гарантии, то всем бы стало только лучше. Хороший пример — FlockDB с MySql и ACID внизу.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Про NoSQL
От: Sinix  
Дата: 03.12.10 08:33
Оценка: 1 (1) +1
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы

С такими требованиями вам и ОЛАПы подойдут

А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения

NoSQL хорош для примитивных моделей данных с низкой связностью. К сожалению, модели данных с низкой связностью не очень хороши для подавляющего большинства задач.
Re[4]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 08:40
Оценка: +1 -1
Здравствуйте, fddima, Вы писали:

F>Здравствуйте, Mamut, Вы писали:


M>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.

F> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

А где его достаточно? Таких задач исчезающе мало.
Re[6]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:36
Оценка: +2
Здравствуйте, netch80, Вы писали:

N>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.

Да ладно? Что же там в SQL не ложится? )
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[12]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.12.10 11:32
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

G>Конечно, а полнотекстовый индекс это вообще самый NoSQL.


Так и есть. Полнотекстовый индекс никакого отношения к тому что понимают по словом SQL не имеет. С этим нельзя спорить.

G>А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.


При чем тут xml столбцы?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:56
Оценка: -2
Здравствуйте, gandjustas, Вы писали:

G>Такому явлению как NoSQL

Ржуу... Конфигурационные файлы в Unix по сути NoSql...
Re[5]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:05
Оценка: +1 :)
Здравствуйте, gandjustas, Вы писали:

N>>И где тут описанное тобой "основное хранилище"?

G>Ты как-бы привел ваше РЕШЕНИЕ, а не задачу. Расскажи подробнее про задачу тебе решений накидают.
G>Большинство обычных СУБД вытянут базы на 100гб и не поморщатся при нормальной схеме. Никаких распределенных хранилищ не понадобится.

Господи, что за мода приводить абсолютные цифры безо всякого базиса ?

На каком железе будут тянуться эти 100гб ?

За какое время вытянутся эти 100гб?

G>ЗЫ. Единственное во что реально упереться в СУБД, так это в скорость записи.


Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД ?
Re[17]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 17:26
Оценка: -1 :)
Здравствуйте, adontz, Вы писали:

I>>Я не понял, за счет чего ты сэкономил 8.5 млн


A>Вычел стоимость своего варианта из стоимости твоего варианта. Мой на 8.5 миллионов долларов США дешевле. Это только лицензирование только одного наименования ПО.


Не совсем понятно, как можно вычесть 8.9 из 10 млн и получить 8.5 млн в остатке. Это какая то особая арифметика, для распила бабла

A>>>Про ThinClient и Desktop/Application Virtualization рассказывать?

I>>Расскажи на всякий

A>Да нет, ты сперва погугли, а потом я отвечу на конкретные вопросы.


"difficulty in running certain complex applications
increased downtime in the event of network failures
complexity and high costs of VDI deployment and management"

Re[20]: Вдогонку
От: Anton Batenev Россия https://github.com/abbat
Дата: 06.12.10 11:30
Оценка: 15 (1)
Здравствуйте, Mamut, Вы писали:

M> Это камень в огород MongoDB Они вообще гарантируют отсутствие Durability на одной машине


The v1.8 release of MongoDB will have single server durability.


Ну и периодический fsync, который по умолчанию каждые 60 секунд, тоже помогает.
avalon 1.0rc3 rev 372, zlib 1.2.3
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:41
Оценка: 1 (1)
Здравствуйте, gandjustas, Вы писали:

AAV>>Здравствуйте, Sinix, Вы писали:


S>>>С такими требованиями вам и ОЛАПы подойдут

AAV>>Большинство хороших ОЛАП движков это NoSQL решения...
G>Большинство OLAP движков появилось когда про NoSQL еще никто не знал.

А представляешь себе, до великой статьи Дейта уже были базы данных. И они явно были не SQL.
The God is real, unless declared integer.
Re[8]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 09:51
Оценка: 1 (1)
Здравствуйте, netch80, Вы писали:

N>Предложи метод укладки, а я оценю его адекватность для наших задач.


Итак, реестр. Давай начнём с простого, а ты выскажешь свои претензии.

CREATE TABLE [dbo].[Registry]
(
    [ID]     hierarchyid] NOT NULL,
    [Level]  AS ([ID].[GetLevel]())     PERSISTED,
    [Parent] AS ([ID].[GetAncestor](1)) PERSISTED,
    [Name]   nvarchar(256) NOT NULL
    [Value]  varbinary(MAX) NOT NULL
)
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 08:39
Оценка: +1
Здравствуйте, Mamut, Вы писали:

A>>http://zabivator.livejournal.com/412053.html


M>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.


Да что там, даже full-text search в SQL базе данных это тоже NoSQL, по словам некоторых здешних обитателей.
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:04
Оценка: +1
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


M>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.

F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>А где его достаточно? Таких задач исчезающе мало.


N>Такие задачи на каждом десктопе Вспомним реестр Windows.

N>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
Реестр Windows — не универсальное хранилище. В нем жутко неудобно хранить нефиксированное множество.
Каждое приложение пользуется фиксированным конечным множеством ключей, зачастую отказываясь от такого хранилища в пользу конфигурационных файлов.
Re[4]: Про NoSQL
От: Sinix  
Дата: 03.12.10 09:28
Оценка: +1
Здравствуйте, ArhAngelVezel, Вы писали:


S>>С такими требованиями вам и ОЛАПы подойдут

AAV>Большинство хороших ОЛАП движков это NoSQL решения...

Ну, если уважать приоритеты — то большинство NoSQL — это своеобразно переделанные ОЛАПы. Хумор в том, что ОЛАПы плохо подходят для ОЛАПа и к тому что щас понимается под носкулем имеют весьма посредственное отношение.

S>>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения

AAV>В NoSql базы вставляются не значения, а объекты.//
Вай сколько пафоса Хранение Объектов означает неважность всяких там ограничений и согласованности данных?


AAV>NoSQL это не key-value базы, не ORM, не отрицание SQL или реляционной модели, это использование движков к базе не только с колокольни реляционной модели.


Я таки советую пройти по ссылке, что запостил adonz. NoSql — это очень нишевое и очень недешёвое в плане сопровождения и развития решение. И с колокольней, увы, рядом даже не ползало
Re: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.12.10 09:37
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>

M>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL

M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


M>©


M>Думаю, это достаточно философское замечание


Что делает его еще более философским, так это то, что верно и инвертированное утверждение:
Любая достаточно сложная SQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины NoSQL
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[4]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:53
Оценка: -1
Здравствуйте, netch80, Вы писали:

N>С передёрга чужих слов обычно что начинается? Правильно, слив

Сдаешься? )

N>Новое и сырое всегда легко критиковать.

Да я и не утверждаю, что мне сложно ))

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

Ага, такое происходит потому, что свежатинка стала легко доступна. NoSQL обрел популярность ровно по той же причине, что и ORM — есть иллюзия, что можно не думать о хранилище и просто работать с "объектами". Последствия таких заблуждений тоже хорошо известны.

N>Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?

Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 10:42
Оценка: -1
Здравствуйте, adontz, Вы писали:

N>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.


A>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.


Стоит ли обсуждать преимущество архитектурных решений перед инфраструктурными? Конечно, без хаков платформы прожить сложно, но если есть возможность не завязываться, почему бы и нет?
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 10:49
Оценка: :)
Здравствуйте, Mamut, Вы писали:

M>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.

F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>А где его достаточно? Таких задач исчезающе мало.


M>memcached, который некоторые заменяют redis'ом, например

Те NoSQL это не более чем распределенный кеш?

M>вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным

Да, тогда станет вопрос о том как получать список нужных ключей. Собственно язык SQL дает ответ на этот вопрос, а различные NoSQL хранилища — нет.
Полнотекстовым индеском все не заменишь, а вручную создавать индексы под каждый запрос — как то слишком круто.

M>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )

Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:25
Оценка: -1
Здравствуйте, netch80, Вы писали:


G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).

N>>>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.
G>>Ну так расскажи что за задача.

N>Мониторинг распределённой сети, управление функционированием по результатам мониторинга, включая автоматические реакции. Слабосвязанной или сильносвязанной сети — уже пофиг, общие подходы едины, в том смысле, что рваться могут по любому

Ну так SSCM, SCOM на вполне реляционной СУБД работают и ниче.

Поподробнее опиши характер данных.


G>>>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.

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

N>Учётные — да, в общем случае готов согласиться.

N>Веб — это вообще не задача по своей природе, это интерфейс. Его же внутренние задачи не имеют никакой заточки для реляционной модели — наоборот, традиционное хранилище "кука => параметры" это key-value.
Проблема только в том как получить список ключей
Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.

N>Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).

Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.
И NoSQL тут сдается. Ему надо map\reduce индексы писать под каждый такой запрос. Малейшее изменение деталей запроса приведет к изменению индекса.. ну вы поняли.
Re[3]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:39
Оценка: -1
Здравствуйте, IB, Вы писали:

IB>Зачем распределенный map/reduce (еще один модный базворд? )

Почитайте что такое map/reduce и почему такие решения могут обрабатывать миллионы сообщений в секунду, при этом не "пересчитывая" триллионы операций.
Re[15]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:47
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.


Подучите матчасть, как тут советуют фанатики RDBMS:
http://www.mongodb.org/display/DOCS/Indexes
http://www.mongodb.org/display/DOCS/Querying
Re[15]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 12:19
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.

В SmallTalk так и есть ...

G>Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird

G>Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven

G>Классифицировать алгоритмы не буду, они не зависят от хранилища.

А вот и нет:
couchdb, mongodb — это документоорентированные базы
cassandra — это столбцоорентированная база
redis — это key-value орентированная база.

А в первой строчке у вас одни RDBMS...

http://habreffect.ru/files/814/5d37eb18d/visualguide.png
Re[10]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:47
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Ага. Только в заметном числе случаев у нас получается унылое Г.

Ага, в _не_ заметном числе случаев, и если руки под унылое Г. заточены. =)

C> К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.

У строки нет столбцов
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[3]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 03.12.10 14:34
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>Рассказываю тайну. SQL база данных может спокойно порвать любой твой код, потому что СУБД оптимизирует доступ к диску. А это сейчас самая медленная операция.


У меня не используется совсем диск, все данные в памяти
Re[15]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 15:16
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

A>>>С чего вы взяли что у вас что-то там будет тормозить в разы, если вы не умеете работать с RDBMS?

N>>А откуда вывод про "неумение работать с RDBMS"? Незнание того конкретного средства, которое Вы почему-то считаете средством по дефолту, ещё ничего не означает
G>А ты считаешь что умение работать с БД это знание только конструкций стандарта 92 года?

Прикольно наблюдать, как народ домысливает всякую триокись за собеседника.
Ну откуда ты взял, что я так считаю? При чём тут вообще стандарт 92-го года?

G>Маленький чеклист чтобы утверждать что таки знаешь SQL

G>(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД)

Ну посмотрел. ~80% описанного хорошо знакомо. Даже больше, если послать нафиг XML. И что это даёт?

Мы ушли куда-то в сторону. Начали с того, что adontz предложил мне какую-то странную ерунду в виде одной структуры таблицы без объяснения причин и подробностей. И никак не хочет рассказать, что дальше с этим делать.
The God is real, unless declared integer.
Re[15]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 15:52
Оценка: +1
G>Маленький чеклист чтобы утверждать что таки знаешь SQL
G>(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД)
G>
При этом крупные проекты все, как в один голос, говорят, что не надо увлекаться нормализацией


dmitriid.comGitHubLinkedIn
Re[13]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 15:52
Оценка: +1
C>>Ну да. Если понасиловать РБД, то часто можно научить её немного работать как NoSQL.
IB>А если не насиловать, то она работает гораздо лучше, чем noSql.. ))

C>>Ок. "Способ представления кортежей с произвольным числом элементов" тебя устроит?

IB>Абсолютно, тем более, что у реляционки с этим нет никаких проблем =))

А можно пример?


dmitriid.comGitHubLinkedIn
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 22:12
Оценка: +1
Здравствуйте, Mamut, Вы писали:

G>>Маленький чеклист чтобы утверждать что таки знаешь SQL

G>>(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД)
G>>
M>При этом крупные проекты все, как в один голос, говорят, что не надо увлекаться нормализацией

Чтобы об этом говорить надо понимать что такое 3НФ и какие недостатки несет нормализация.
Re[9]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:39
Оценка: :)
Здравствуйте, adontz, Вы писали:

I>>Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов


A>Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред?


Я вообще то не говорил про серверный софт
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.12.10 13:20
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

G>И как выражается это преимущество?


Ну вот смотри. Есть у нас CAP-теорема (она же теорема Брюера). Не смотря на то, что г-н Cyberax педалирует её в контексте высоконагруженных систем
Автор: Cyberax
Дата: 03.12.10
, теорема применима в случае распределённых систем. Существует мнение, что распределённость это удел не многих
Автор: gandjustas
Дата: 03.12.10
, но по факту, нарваться на распределённость (и попасть под действие теоремы) можно даже не заметив этого(как это произошло у gandjustas с полнотекстовым поиском)
Автор: gandjustas
Дата: 03.12.10
. Результатом такого незамечания является то, что из трёх гарантий (C-, A-, P-) теряется не одна, а все гарантии (теорема ведь не обещает, что всегда выполняются две гарантии из трёх, а утверждает, что выполняется не больше двух).

ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется. Гораздо более правильно вывести эти ограничения явно. Программист получает гарантии ACID на уровне отдельных запросов и явный выбор между возможными CAP. Всё прозрачно и понятно. Кстати, обеспечить юзабельную реализацию eventual consistency может сходу и не получиться. Гораздо лучше, когда это уже готовое — реализованное и проверенное.

Итого, преимущество в том, что такие системы не обещают того, что в реальной жизни выполнить не возможно.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 04.12.10 13:32
Оценка: -1
M>>Если специальных иерархических данных нет (тот же MySQL), каждый следующий уровень дерева — это один-два лишних джойна.
IB>Никаких лишних джойнов уровни не добавляют, просто структура данных чуть сложнее. И это именно "чуть", а не так фатально, как тут пытаются описать.

В MySQL добавляют за неимением «более сложных данных»


dmitriid.comGitHubLinkedIn
Re[13]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.12.10 13:34
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


G>Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало


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

G>Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.


шардинг не поможет (учите матчасть, хм). Нужна репликация. Здравствуй CAP теорема.

PS. Кстати у упомненных выше 80%
Автор: gandjustas
Дата: 03.12.10
проектов Durability не нужна.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.12.10 15:27
Оценка: +1
Здравствуйте, IB, Вы писали:

N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.

IB>Да ладно? Что же там в SQL не ложится? )

1. Подо всё свой инструмент нужен. То что доказано, что всё можно запихнуть в реляционную модель не значит, что туда нужно всё пихать. Это настолько очевидно, что я даже не представлял, что его кто-то может оспаривать. К примеру, лет десять назад Oracle создал сервер, который внутри себя держал файлы. Поддерживал кучу протоколов (smb, ftp etc). И естественно обещал ACID. Однако Oracle не сказал, что все должны вместо файловых систем использовать их хранилище. Ибо скорость проседала на порядок по сравнению с обычной ФС. А возможность выполнения запросов к файловой системе и транзакции при таком проседании скорости мало кому нужны.

2. Сам факт появления такой техники как `Nested Sets` и внедрения в SQL cервер встроенного полнотекстового поиска и XML типа данных со своим языком запросов и способом хранения, говорит о том, что разработчики серверов осознают ограниченность своего инструмента и не боятся топать к NoSql когда обстоятельства требуют. Что особенно удивляет, так это то, что приводя такие примеры
Автор: gandjustas
Дата: 03.12.10
одной рукой, другой рукой оппоненты отсылают к нормальным формам
Автор: gandjustas
Дата: 04.12.10
.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.12.10 15:55
Оценка: :)
Здравствуйте, Sinix, Вы писали:

S>Итак, где здесь:


И так, ты действительно не видишь где теряется гарантия ACID при использовании полнотекстового поиска, и считаешь, что можно Durability обеспечить только в рамках одного дискового массива?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Про NoSQL
От: alpha21264 СССР  
Дата: 05.12.10 13:51
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

G>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


FineReader, Promt, Lingvo, Word. Про САПРы вообще молчу.

Течёт вода Кубань-реки куда велят большевики.
Re[20]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.12.10 19:43
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

I>Ты всерьез решил что на 10 тыс пользователей хватит одного 16процессорного комплекта ?

I>Допустим, каждый из проессоров как нынче модно, имеет 4 ядра. Итого — 156 пользователей на одно ядро.

А ядра на декстопе и сервере одинаковые, ага. И производительность SQL сервера в гораздо больше степени зависит от ОЗУ, чем от количества ядер. Я тебе даже больше скажу, на SQL сервер выключение HyperThreading увеличивает производительность. Но чтобы такие вещи знать, надо с этим работать, а у тебя в голове вместо опыта только нелепые домыслы. Прости, общаться с тобой на данную тему совершенно скучно и утомительно.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Про NoSQL
От: Cyberax Марс  
Дата: 05.12.10 22:15
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

A>>Здравствуйте, gandjustas, Вы писали:

G>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
A>>FineReader, Promt, Lingvo, Word. Про САПРы вообще молчу.
G>1)Там не используются БД
G>2)Отсутствие Durability означает что после нажаnия Save документ может быть не сохранен.
И что?

G>Со вторым что будете делать?

Ничего, всем плевать.
Sapienti sat!
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.12.10 22:43
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


A>>>Здравствуйте, gandjustas, Вы писали:

G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
A>>>FineReader, Promt, Lingvo, Word. Про САПРы вообще молчу.
G>>1)Там не используются БД
G>>2)Отсутствие Durability означает что после нажаnия Save документ может быть не сохранен.
C>И что?
И то.

G>>Со вторым что будете делать?

C>Ничего, всем плевать.
Пока это не касается бабла. Как только кто-либо попадет на бабло из-за несохраненности данных сразу станет не плевать.
Хотя адепты NoSQL все равно расскажут что всем плевать.
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 08:18
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

ANS>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?

G>Ни в чем. Другой случай. Одна машина (!)
G>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
G>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?

Я просто намекну, что Durability даёт _абсолютную_ гарантию. Второе, ты утверждал, что сможешь понять, какие именно транзакции пропали за эти 5 сек. Как?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[22]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 10:37
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.


ANS>>>Transaction Log — это не единственная реализация durability, это оптимизация.

G>>Не понимаю что ты хочешь сказать. Чуть менее чем во всех современных СУБД durability обеспечивается логом транзакций.

ANS>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.

Бред. Как ты откатывать транзакцию будешь без лога?

ANS>>>Более того, как я показал
Автор: Andrei N.Sobchuck
Дата: 06.12.10
, durability оно не обеспечивает.

G>>Ты там ничего не показал.

ANS>Либо у тебя один винт и нету никакой D.

Ты неверно понимаешь слово Durability.

ANS>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично.

ACID вообще не коррелирует с CAP.

ANS>Или практика философов не интересует?

Практика это зачастую одна машина с БД, а CAP и мега-распределенные системы это теория.
Re[23]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 11:44
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

ANS>>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.

G>Бред. Как ты откатывать транзакцию будешь без лога?

http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php
Ты путаешь "UNDO log" и лог транзакций.

G>Ты неверно понимаешь слово Durability.


Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно.

ANS>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично.

G>ACID вообще не коррелирует с CAP.

D в ACID == C в CAP. Но не в этом дело. Дело в том, что с практической точки зрения люди всё равно заботятся о доступности.

ANS>>Или практика философов не интересует?

G>Практика это зачастую одна машина с БД, а CAP и мега-распределенные системы это теория.

Угу угу
Автор: Andrei N.Sobchuck
Дата: 04.12.10
. А потом ставят какой-нибудь memcached и работают с ним так: http://www.majordojo.com/2007/03/memcached-howto.php . То что всё иногда ломается — так сделаем круглые глаза, у нас же ACID и всё гарантировано. Почему ты запрещаешь сделать инструмент, который убережёт от таких ошибок?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[22]: Вдогонку
От: Anton Batenev Россия https://github.com/abbat
Дата: 06.12.10 12:09
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M> В общем, NoSQL постепенно приходит к durability Особенно в наиболее известных/распространенных проектах


Угу, лишь бы не в ущерб. Хотя желание поднимать single server instance говорит о том, что распробовали продукт не только большие проекты.
avalon 1.0rc3 rev 372, zlib 1.2.3
Re[13]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 13:23
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

ANS>>Хм. Странно о чем то спорить не дав дефиниции терминам.

G>Я уже давал читай внимательнее.
G>NoSQL — хранилища, которые так себя позиционируют.
G>SQL — современные, как говорится mature, СУБД общего назначения.

Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[26]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 13:45
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>Бред. Как ты откатывать транзакцию будешь без лога?

ANS>>>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php
ANS>>>Ты путаешь "UNDO log" и лог транзакций.
G>>нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?

ANS>В Oracle есть, в MySql есть.

Доказательства?

ANS>Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные.

Снова бред говоришь. Если я поставлю Read Uncommited я увижу незакомиченные данные. Угадай почему я их увижу.

G>>Как раз для postgresql этот undo log является оптимизацией, а transaction log является вполне стандартным средством обеспечения Атомарности и Долговечности транзакций.

ANS>Я не спорю с тем, что это стандартная техника.

Durability обеспечивается не логом транзакций...

Твои слова.

ANS>Просто это не единственная техника.

В СУБД эта техника называется "версионность" или SNAPSHOTS. Жопа в том что она не обеспечивает сериализуемости транзакций.


G>>>>Ты неверно понимаешь слово Durability.


ANS>>>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно.

G>>А если нет пользователя? Если это автоматическия система? Она то думает что все хорошо, а на деле все плохо.

ANS>Автоматическая система на единственном нерабочем компьютере думает, что всё хорошо? Или концепция поменялась и у нас уже не один компьютер?

Причем тут "нерабочий компьютер"? Компьютер вполне рабочий. Но вот возникает ошибка записи на диск по не важно какой причине. Как приложение узнает что ошибка произошла? Ты предложишь перечитывать данные после каждой операции записи? Ты же понимаешь что это бредовая идея?

ANS>>>>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично.

G>>>>ACID вообще не коррелирует с CAP.

ANS>>>D в ACID == C в CAP.

G>>Да ну?

ANS>Истинно глаголю.


G>>C в CAP — одинаковость данных на всех узлах.


ANS>Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable".

Дай ссылку на сие откровение.
Тут говорят что C в CAP это A в ACID.
А википедия говорит что Consistency (all nodes see the same data at the same time).
Причем во втором определении явная дыра. Как только твое приложение (оно ведь тоже "узел") считало данные и не блокирует их то Consitency больше нет, а если блокируешь, то гарантированно Availability нет. Получается CAP-теорема редуцировалась до CA теоремы.

G>>Для начала докажи что:

G>>1)Durability не важен, даже если на одной машине хранилище работает.
ANS>Если никто не его не обеспечивает и все при этом довольны, то оно никому не нужно. Т.е. не важно.
Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.

G>>Практика показывает что надо иметь возможность выбирать между Consistency и Availability,

ANS>Ну наконец-то ты признал, что ACID в пролёте.
Еще раз, ACID не коррелирует с CAP. Свойства ACID по большей части независимы, а CAP — связанные.
Причем реально вырождается это в CA-tradeoff.
И как раз никто не старается выполнять Consistency.

G>>большинтсво NoSQL хранилищ не дают такого выбора,

ANS>Большинство NoSql поддерживают либо ту или иную пару. А некоторые позволяют это поведение сконфигурировать.
Да нихрена они не поддерживают, только делают вид что поддерживают, причем настолько насколько понимают суть проблем (а на практике понимают плохо).

G>>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?

ANS>Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего.
Еще раз, если смотреть комплекс "приложение-субд", то всегда присутствует CA-tradeoff.

Кстати есть сомнение что понимание CAP у тебя правильное. То что понимание ACID у тебя неправильное я уже убедился.
Re[25]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 17:46
Оценка: :)
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>>Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт.


S>Это стёб, я надеюсь?


Это правда жизни. Реальность, данная нам в ощущениях А вся веселуха начинается, когда пользователь узнаёт, что у него бек-ап месячной давности и тот не поднимается. Durability это вам не хухры-мухры.

В добавок, я наблюдал, как консистентное чтение-запись под нагрузкой в друг превращалось в неконсистентное. Ибо понадеялись на ACID, а про то, что приложение правильно готовить нужно — не подумали. А ошибки с консистентностью это такая штука, которая то есть, то нету. Уж лучше нечто с явно прописанными гарантиями и ограничениями, чем этот ваш "ACID".


ЗЫ Или ты думаешь, что 99.9% программистов за что-то несут ответсвенность?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[24]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 07.12.10 12:33
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php

ANS>Ты путаешь "UNDO log" и лог транзакций.
Я вот тут примерно представляю кто чего путает... =)
лог транзакций может быть нескольких типов undo only/redo only/undo redo/... Что не мешает ему в любом случае оставаться логом транзакций.
Да, известны базы без логов (FB, кажется такая), но за это призодится платить долгим коммитом, откатом, временем восстановления.
Как устроен постгри не знаю, но большая часть там передрана с оракла, а у того undo only, если я правильно помню.

ANS>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно.

Это тебе не нужно, а вообще только оно и нужно.

ANS> Пользователь утрётся и введёт данные заново.

Не прокатит. В нагруженных системах, на основе его утерянных данных уже будут другие данные, которые сохранятся — и привет, база в несогласованном состоянии. Кто и когда это ловить будет?
Ты забываешь, что на один пользовательский ввод в реальных системах приходится 3-5 служебных транзакций и что без логов и прочих средств обеспечения durability и consistency нет никакой гарантии, что до диска они доползут ровно в том порядке в котором происходили. То есть никакой гарантии согласованности данных не может быть в принципе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[13]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 07.12.10 12:43
Оценка: +1
M>>В MySQL добавляют за неимением «более сложных данных»
IB>В MySql отменили транзитивное замыкание или nested sets?

Посыпаю голову пеплом

Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets)


dmitriid.comGitHubLinkedIn
Re[26]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 02.02.11 07:39
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Просто с логом быстрее. Пока что.

Ну-ну. =)

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

Шырокие массы за него отслюнявливают только в путь.

ANS>Хе-хе. Так по треду постоянно апеллируют к тому, что нагруженые системы удел не многих, а у многих всё мол попроще. И им durability тоже нужно. Но как раз эти "многие" платить за обеспечение "D" не готовы. Парадокс?

С чего ты взял что не готовы? Где хоть одна бухгалтерская поделка на NoSql без Durability? MySQL и тот скрипя все что надо прикрутил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[28]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.02.11 10:57
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS> Это эти массы то отлюнявливают?

Ага, именно эти. 100% критичных к бизнесу приложений, начиная от бухгалтерии, сидит на RDBMS, которая таки обеспечивает требуемый уровень Durability, что бы ты там по этому поводу не думал.

ANS>В 90 процентов случаев бухгалтер "в случае чего" вколотит данные заново.

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

ANS>fsync перед отсылкой "OK" это не дюрабилити.

Я устал понимать, что ты понимаешь под durability, но задача БД — сделать так, чтобы любой уровень durability при установке БД мог быть обеспечен исключительно средствами администрирования, классические SQL БД это обеспечивают, в том числе и MySQL оборудованный InnoDB, а вот NoSQL — нет.
Более того, как показала практика, если отказаться от durability и consistency в одной конкретно взятой БД, например в том же MySQL-е, то в плане производительности все NoSQL сосут как промышленный пылесос, чего собственно и следовало ожидать: http://l-o-n-g.livejournal.com/153756.html
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[37]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 18:35
Оценка: :)
Здравствуйте, Sinix, Вы писали:

S>Во-первых, durability не даёт 100% гарантии, но, в тоже время, позволяет без существенных затрат обеспечивать сервис в 5-6 девяток за счёт почти моментального восстановления (в большинстве случаев).


Бред.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 21:15
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

ANS>>Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).

S>Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).

Так я с этим полностью согласен. Более того, имхо, в 99% случаев схема известна. Просто в зависимости от пожеланий пользователя она может меняться. Именно из-за эффективности и нужно при любой возможности создавать структуры в БД.
Тот же SalesForce — это крупнейшаая SaaS CRM. Пользователи могут создавать свои структуры (таблицы) и всё такое прочее. Естественно пользователи не хотят ждать пока схема поменяется. Что у SF получилось — я описывал
Автор: Andrei N.Sobchuck
Дата: 30.01.11
. Хотя Oracle вроде много чего умеет. В результате есть, озвученная и тобой, теория, что все изменения могут происходить мгновенно. И есть практика от SF и FF.

S>Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.


На словах, мне нравятся идеи устройства CouchDB.

S>"изменения схемы", которое покажет преимущества NoSQL в полный рост.


Я уж не знаю почему, но в реальной жизни — в обоих примерах с выше — в итоге NoSql получается.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 07:22
Оценка:
A>http://zabivator.livejournal.com/412053.html

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


dmitriid.comGitHubLinkedIn
Re: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 08:09
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы
Re[3]: Про NoSQL
От: fddima  
Дата: 03.12.10 08:11
Оценка:
Здравствуйте, Mamut, Вы писали:

M>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.

По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
Re: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 08:15
Оценка:
Здравствуйте, Mamut, Вы писали:


M> реализацию половины SQL.


я бы добавил — НУЖНОЙ половины
Re: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 08:54
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


И сомнительно, и бессмысленно.

Сомнительно — потому, что для большинства NoSQL-применений специфика такова, что на SQL их укладывать даже если можно, то совершенно неадекватно.

Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано.

Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит. А многим не подходит даже модель реляционной базы.
The God is real, unless declared integer.
Re[7]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 09:23
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>не универсальное хранилище

Кто сказал что NoSQL должно быть универсальным хранилищем? Если бы это было бы так, то они конкурировали бы за место под солнцем. Но нет же. Зачастую в одном проекте используется несколько типов хранилищ, как традиционных реляционных, так и NoSql. Через key-value кешируются обращения к сайту, на реляционке висит авторизация, на документ-ориентированной — профили, на map/reduce — обработка сырых данных, на олапе — аналитика и т.д....
Re[7]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

F>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>А где его достаточно? Таких задач исчезающе мало.
N>>Такие задачи на каждом десктопе Вспомним реестр Windows.
N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
G>Реестр Windows — не универсальное хранилище.

Именно так! И поэтому у него специализированный движок.

G> В нем жутко неудобно хранить нефиксированное множество.

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

А это уже детали выбранной специфики.
The God is real, unless declared integer.
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:30
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>не универсальное хранилище

AAV>Кто сказал что NoSQL должно быть универсальным хранилищем? Если бы это было бы так, то они конкурировали бы за место под солнцем.
Если база не сможет нормально работать с теми данным, которыми захочет пользователь, то нафиг такая база не нужна.

AAV>Но нет же. Зачастую в одном проекте используется несколько типов хранилищ, как традиционных реляционных, так и NoSql. Через key-value кешируются обращения к сайту, на реляционке висит авторизация, на документ-ориентированной — профили, на map/reduce — обработка сырых данных, на олапе — аналитика и т.д....

Только поддержка целостности в таком зоопарке огромный геморрой, неподвластный разработчикам обычных проектов.
Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости.
Угадай какая система становится основным хранилищем?
Re[5]: Про NoSQL
От: Sinix  
Дата: 03.12.10 09:30
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Хумор в том, что ОЛАПы плохо подходят для ОЛАПа и к тому что щас понимается под носкулем имеют весьма посредственное отношение.

Нда. Вообще-то для ОЛТП. Но и так неплохо вышло
Re[2]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:33
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы

Зачем распределенный map/reduce (еще один модный базворд? ) — если банальный MSSQL в tpc-E тесте безо всяких распределений выдает 4К транзакций в секунду, а Oracle в tpc-C 30 миллионов транзакций в минуту. И это честные согласованные транзакции, с ACID и всем остальным антуражем, а не какая-то там одна запись.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[3]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:34
Оценка:
Здравствуйте, gandjustas, Вы писали:

N>>Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано.

G>К сожалению многие повелись на NoSQL-hype и пихают его во все дыры. Хотя как основное хранилище NoSQL базы почти не пригодны.

Ты судишь только с одной колокольни.
Для примера, нам под наши задачи нужны
* key-value хранилище с иерархическими ключами и значениями достаточно произвольной природы — под конфигурацию (в общем, похоже на реестр; если бы был распределённый реестр под Linux, взяли бы его)
* группированное по пулам key-value хранилище в памяти с репликацией пула только между определёнными узлами, и опять-таки природа значений не определена (большинство крошечные, но может быть и BLOB'ы на десятки килобайт)
* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов

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

И где тут описанное тобой "основное хранилище"?

N>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит.

G>Современные СУБД умею гораздо больше, чем описано в стандартах SQL 92.
G>Применяя те же методы проектирования и развертывания, что в NoSQL, можно добиться результатов не хуже, чем в NoSQL решениях.

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

N>>А многим не подходит даже модель реляционной базы.

G>Это от того что не умеют правильно её использовать.

Это общие слова, которые может сказать любой, даже тот, кто ничего не умеет. Покажи, что умеешь.
The God is real, unless declared integer.
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:36
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


F>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>>А где его достаточно? Таких задач исчезающе мало.
N>>>Такие задачи на каждом десктопе Вспомним реестр Windows.
N>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
G>>Реестр Windows — не универсальное хранилище.
N>Именно так! И поэтому у него специализированный движок.
То есть лучше не использовать реестр виндовс, пока не доказано обратное.
С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.
Re[3]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:39
Оценка:
Здравствуйте, IB, Вы писали:

N>>И сомнительно, и бессмысленно.

IB>Совершенно верно — NoSQL это сомнительно и в большинстве случаев бессмыслено. =))

С передёрга чужих слов обычно что начинается? Правильно, слив

N>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины.

IB>Нет, ключевое слово — неспецифицированную, глючную и медленную. И если она даже после этого нужная, то тем хуже для noSql.

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

N>> А многим не подходит даже модель реляционной базы.

IB>Только в том случае, если они не умеют реляционкой пользоваться.

Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?
The God is real, unless declared integer.
Re[4]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:39
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, Sinix, Вы писали:


S>>С такими требованиями вам и ОЛАПы подойдут

AAV>Большинство хороших ОЛАП движков это NoSQL решения...
Большинство OLAP движков появилось когда про NoSQL еще никто не знал.

S>>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения

AAV>В NoSql базы вставляются не значения, а объекты.//

И от этого все сразу стало круто-круто.
Re[7]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:40
Оценка:
Здравствуйте, IB, Вы писали:

N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.

IB>Да ладно? Что же там в SQL не ложится? )

Предложи метод укладки, а я оценю его адекватность для наших задач.
The God is real, unless declared integer.
Re: Про NoSQL
От: Фанатик Ад http://vk.com/id10256428
Дата: 03.12.10 09:41
Оценка:
Учил БД давно, когда слова NoSQL не существовало.
Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели
понимаю как "отсутствие возможности общаться с СУБД посредством языка SQL" — т.е. кастрат-версия СУБД, не вижу в этом смысла.

ЗЫ: параллельно с SQL можно дать другой метод взаимодействия с СУБД, оба интерфейса могут быть опциональными.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[9]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

F>>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>>>А где его достаточно? Таких задач исчезающе мало.
N>>>>Такие задачи на каждом десктопе Вспомним реестр Windows.
N>>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
G>>>Реестр Windows — не универсальное хранилище.
N>>Именно так! И поэтому у него специализированный движок.
G>То есть лучше не использовать реестр виндовс, пока не доказано обратное.

С чего это такой вывод?

G>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.


Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
The God is real, unless declared integer.
Re[2]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:44
Оценка:
Здравствуйте, Фанатик, Вы писали:

Ф>Учил БД давно, когда слова NoSQL не существовало.

Ф>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели

А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).

Ф>понимаю как "отсутствие возможности общаться с СУБД посредством языка SQL" — т.е. кастрат-версия СУБД, не вижу в этом смысла.


Конечно, если заранее задать бессмысленную входную посылку, смысла не будет
The God is real, unless declared integer.
Re[9]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 09:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

G>Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости.
G>Угадай какая система становится основным хранилищем?

Курим Теорму Брюера на тему "проще"
Re[3]: Про NoSQL
От: Фанатик Ад http://vk.com/id10256428
Дата: 03.12.10 09:49
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Фанатик, Вы писали:


Ф>>Учил БД давно, когда слова NoSQL не существовало.

Ф>>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели

N>А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).


Т.е. NoSQL — лишнее слово.

1) "NoSQL" == "Нереляционные СУБД"
2) понятие "Нереляционные СУБД" появилось раньше
Вывод: "NoSQL" — новомодное слово, которое совершенно необязательно понимать.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[9]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 09:57
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, netch80, Вы писали:


N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
IB>В чем у тебя сложность?

А в терминах инструкций к CPU вообще можно все писать куда более эффективно даже, чем на ваших джавах..
netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе
Re[5]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 09:59
Оценка:
Здравствуйте, IB, Вы писали:

IB>Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.


В реляционку ложиться все — тут без проблем. Но иногда вместо кухонного комбайна овощи можно порезать простым ножом
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:08
Оценка:
Здравствуйте, IB, Вы писали:

N>>С передёрга чужих слов обычно что начинается? Правильно, слив

IB>Сдаешься? )

Чего?

N>>Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?

IB>Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.

Откуда ты взял про "не ложится"? Это уже подтасовка моих слов. Я говорил:

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


Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.


его применение будет жуткой натяжкой с громоздким middleware


Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.

А вот ты в своём сообщении уже допустил второе подряд обобщение с подтасовкой фактов. Нехорошо.

Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого. Какой ты метод организации базы предложишь, более эффективный, чем имитация файловой системы?

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, netch80, Вы писали:


N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
IB>В чем у тебя сложность?

В построении _эффективного_ решения, чтобы оно было выгоднее, чем текущее хранилище.
The God is real, unless declared integer.
Re[4]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 10:08
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


N>>>Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано.

G>>К сожалению многие повелись на NoSQL-hype и пихают его во все дыры. Хотя как основное хранилище NoSQL базы почти не пригодны.

N>Ты судишь только с одной колокольни.

N>Для примера, нам под наши задачи нужны
N>* key-value хранилище с иерархическими ключами и значениями достаточно произвольной природы — под конфигурацию (в общем, похоже на реестр; если бы был распределённый реестр под Linux, взяли бы его)
N>* группированное по пулам key-value хранилище в памяти с репликацией пула только между определёнными узлами, и опять-таки природа значений не определена (большинство крошечные, но может быть и BLOB'ы на десятки килобайт)
N>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов
N>SQL хоть как-то подходит только под третий пункт, для остального его применение будет жуткой натяжкой с громоздким middleware, скрывающим отсутствие иерархической структуры данных.

N>И где тут описанное тобой "основное хранилище"?

Ты как-бы привел ваше РЕШЕНИЕ, а не задачу. Расскажи подробнее про задачу тебе решений накидают.
Большинство обычных СУБД вытянут базы на 100гб и не поморщатся при нормальной схеме. Никаких распределенных хранилищ не понадобится.

Как писал Синклер (щас не найду пост) в любых данных есть две части: регулярная (реляционная) и нерегулярная (блобы или XML).
В худшем случае в регулярную часть попадают только ключи, но это редкость.

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

Ну и собственно все.

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

N>>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит.

G>>Современные СУБД умею гораздо больше, чем описано в стандартах SQL 92.
G>>Применяя те же методы проектирования и развертывания, что в NoSQL, можно добиться результатов не хуже, чем в NoSQL решениях.

N>Вот я привёл пример наших требований. Опиши хоть вчерне, на каких доступных сейчас средствах и каким образом ты бы её реализовывал поверх SQL. Ограничения среды — Linux.

См. выше.

Хотя я по линуксовым базам не спец. Для MS SQL напишу решение, аналогичные возможности для того же postgres или oracle под линух найти не сложно будет.

ЗЫ. Единственное во что реально упереться в СУБД, так это в скорость записи. Даже с отключенными блокировками она ниже, чем в специализированном решении. Такое может возникнуть при потоковой обработке, но тут у MS SQL есть решение — Stream Insight.
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 10:09
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


AAV>>>Здравствуйте, Sinix, Вы писали:


S>>>>С такими требованиями вам и ОЛАПы подойдут

AAV>>>Большинство хороших ОЛАП движков это NoSQL решения...
G>>Большинство OLAP движков появилось когда про NoSQL еще никто не знал.

N>А представляешь себе, до великой статьи Дейта уже были базы данных. И они явно были не SQL.

И где они сейчас?
Re[9]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:14
Оценка:
Здравствуйте, adontz, Вы писали:

A>Здравствуйте, netch80, Вы писали:


N>>Предложи метод укладки, а я оценю его адекватность для наших задач.


A>Итак, реестр. Давай начнём с простого, а ты выскажешь свои претензии.


A>
A>CREATE TABLE [dbo].[Registry]
A>(
A>    [ID]     hierarchyid] NOT NULL,
A>    [Level]  AS ([ID].[GetLevel]())     PERSISTED,
A>    [Parent] AS ([ID].[GetAncestor](1)) PERSISTED,
A>    [Name]   nvarchar(256) NOT NULL
A>    [Value]  varbinary(MAX) NOT NULL
A>)
A>


Претензий с ходу несколько:

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

a.p = 1
a.q = 2
zz = 3

2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.

3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.
The God is real, unless declared integer.
Re[10]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 10:18
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


F>>>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>>>>А где его достаточно? Таких задач исчезающе мало.
N>>>>>Такие задачи на каждом десктопе Вспомним реестр Windows.
N>>>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
G>>>>Реестр Windows — не универсальное хранилище.
N>>>Именно так! И поэтому у него специализированный движок.
G>>То есть лучше не использовать реестр виндовс, пока не доказано обратное.

N>С чего это такой вывод?

Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?

G>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).

Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности.


ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.
Re[4]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:18
Оценка:
Здравствуйте, Фанатик, Вы писали:

Ф>>>Учил БД давно, когда слова NoSQL не существовало.

Ф>>>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели
N>>А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).
Ф>Т.е. NoSQL — лишнее слово.
Ф>1) "NoSQL" == "Нереляционные СУБД"

Ну в общем да.

Ф>2) понятие "Нереляционные СУБД" появилось раньше

Ф>Вывод: "NoSQL" — новомодное слово, которое совершенно необязательно понимать.

Кому как. Я просто принял к сведению факт, что сейчас "это" называют именно так.
The God is real, unless declared integer.
Re[10]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 10:20
Оценка:
Здравствуйте, noetic, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


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

G>>Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости.
G>>Угадай какая система становится основным хранилищем?

N>Курим Теорму Брюера на тему "проще"


А причем тут CAP теорема? Для подавляющего большинства проектов не нужна распределенная база. Не каждый день люди пишут фейсбуки.
Re[5]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 10:26
Оценка:
M>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.
F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>А где его достаточно? Таких задач исчезающе мало.


memcached, который некоторые заменяют redis'ом, например

вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным

тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )


dmitriid.comGitHubLinkedIn
Re[11]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 10:29
Оценка:
Здравствуйте, gandjustas, Вы писали:

N>>Курим Теорму Брюера на тему "проще"


G>А причем тут CAP теорема? Для подавляющего большинства проектов не нужна распределенная база. Не каждый день люди пишут фейсбуки.


согласен. но надо же сравнивать два подхода в примерно равных условиях, чтобы четче все +/- отследить.
Re[11]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:32
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>То есть лучше не использовать реестр виндовс, пока не доказано обратное.

N>>С чего это такой вывод?
G>Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?

А с чего это мы должны тут рассматривать интернет-магазин? Это очень специализированная задача, с моей точки зрения и никак не соответствует моим задачам.

G>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
G>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
G>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).

Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.

G>Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности.


Ну, ответил. Говори.)

G>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.


Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования.
The God is real, unless declared integer.
Re[10]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 10:32
Оценка:
Здравствуйте, netch80, Вы писали:

N>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием

N>a.p = 1
N>a.q = 2
N>zz = 3

Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему?

N>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.


Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.

N>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.


Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 10:33
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


Проекты-агрегаторы данных. Скачать с десятка ебэй-магазинов пару десятков тыщ ордеров в виде достаточно развесистых документов и выдать клиенту сервис по постобработке этих данных. База упала? Хрен с ней — перезакачаем, пересчитаем.
Re[11]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:39
Оценка:
Здравствуйте, adontz, Вы писали:

N>>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием

N>>a.p = 1
N>>a.q = 2
N>>zz = 3

A>Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему?


Меня устраивает тут и рассмотрение реестра Windows. А чем этот пример, по-твоему, противоречит реестру?

N>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.

A>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.

Вполне подходит. Ты используешь какие-то специфические средства специфической реализации. Объясни их, достаточно по паре слов на каждое.

N>>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.

A>Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт.

Например, он может храниться в основном теле таблицы, если до K байт, в малом пуле блобов, если >=M, и в большом пуле, если >=N.
The God is real, unless declared integer.
Re[12]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 10:48
Оценка:
Здравствуйте, netch80, Вы писали:

N>>>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием

N>>>a.p = 1
N>>>a.q = 2
N>>>zz = 3
A>>Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему?
N>Меня устраивает тут и рассмотрение реестра Windows. А чем этот пример, по-твоему, противоречит реестру?

Ну в реестре есть разделение на ключи и значения. Описание ветки достаточно стандартно.
[HKEY_LOCAL_MACHINE\Key1\Key2]
"Name"="Value"


N>>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.

A>>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.
N>Вполне подходит. Ты используешь какие-то специфические средства специфической реализации. Объясни их, достаточно по паре слов на каждое.

dbo — Database Owner. Что-то типа пространства имён.
PERSISTED — вычисляемый столбец, но значения физически хранятся в БД.
nvarchar — UNICODE строка переменной длины
hierarchyid — специальный тип для хранения иерархических отношений

N>>>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.

A>>Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт.
N>Например, он может храниться в основном теле таблицы, если до K байт, в малом пуле блобов, если >=M, и в большом пуле, если >=N.

Всегда в теле таблицы.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 10:50
Оценка:
Здравствуйте, noetic, Вы писали:

N>Стоит ли обсуждать преимущество архитектурных решений перед инфраструктурными?


стоил ли делать поспешные выводы?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 10:54
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.


HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 10:56
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


G>>>>То есть лучше не использовать реестр виндовс, пока не доказано обратное.

N>>>С чего это такой вывод?
G>>Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?

N>А с чего это мы должны тут рассматривать интернет-магазин? Это очень специализированная задача, с моей точки зрения и никак не соответствует моим задачам.

Я вот смотрю вакансии: 80% это веб и автоматизация предпирятий (документооборот и учетные системы). Ни одна из этих задач хорошо не ложится на реестр или NoSQL.
Это кореллирует с тем с какими задачами ко мне обращаются заказчики.

G>>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
G>>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
G>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).

N>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.

Ну так расскажи что за задача.

G>>Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности.

N>Ну, ответил. Говори.)
Аргумент "у нас все работает", вообще-то не аргумент. Общая практика как раз говорит об обратном, несмотря на хайп. А если вам повезло, то могу только поздравить.
Опиши свою задачу конкретнее, тогда посмотрим что и как у вас можно сделать средствами SQL баз данных.

G>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.

N>Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования.
Веб, учетные задачи, автоматизация документооборота. Эти задачи традиционно требуют массового хранения данных.
Re[13]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:57
Оценка:
Здравствуйте, adontz, Вы писали:

N>>>>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием

N>>>>a.p = 1
N>>>>a.q = 2
N>>>>zz = 3
A>>>Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему?
N>>Меня устраивает тут и рассмотрение реестра Windows. А чем этот пример, по-твоему, противоречит реестру?

A>Ну в реестре есть разделение на ключи и значения. Описание ветки достаточно стандартно.

A>
[HKEY_LOCAL_MACHINE\Key1\Key2]
A>"Name"="Value"


Хорошо, отщипни HKEY_LOCAL_MACHINE\ в начале и замени бэкслэши на точки — получишь мой пример. И строго наоборот.
Возвращаюсь к исходному вопросу: как будет выглядеть таблица в этом случае?

N>>>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.

A>>>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.
N>>Вполне подходит. Ты используешь какие-то специфические средства специфической реализации. Объясни их, достаточно по паре слов на каждое.
A>dbo — Database Owner. Что-то типа пространства имён.
A>PERSISTED — вычисляемый столбец, но значения физически хранятся в БД.
A>nvarchar — UNICODE строка переменной длины
A>hierarchyid — специальный тип для хранения иерархических отношений

Понятно, ничего специфического, кроме собственно типа hierarchyid. Это целое число или что-то более хитрое?

N>>>>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.

A>>>Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт.
N>>Например, он может храниться в основном теле таблицы, если до K байт, в малом пуле блобов, если >=M, и в большом пуле, если >=N.
A>Всегда в теле таблицы.

В таком случае хранение будет ужасающе неэффективно. В моём случае большинство значений короче 60 байт, но некоторые достигают десятков килобайт. Если таблица на диске будет представляться B-деревом или аналогом, то одна строка может просто не влезть в страницу, а если последовательными чанками с длиной или аналогичным подходом, то проходы по ней будут очень медленны. Подход а-ля FS с каждой строкой в отдельном файле тоже ничего хорошего не даст.
В практически известных мне примерах БД всё-таки стараются такие вещи выселять отдельно по превышению некоторого предельного размера.
The God is real, unless declared integer.
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:08
Оценка:
Здравствуйте, noetic, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


G>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


N>Проекты-агрегаторы данных. Скачать с десятка ебэй-магазинов пару десятков тыщ ордеров в виде достаточно развесистых документов и выдать клиенту сервис по постобработке этих данных. База упала? Хрен с ней — перезакачаем, пересчитаем.


Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало

Фактически операция записи в базу в NoSQL зачастую не оставляет никаких долговременных следов о том что она была выполнена. При падении сервера он после перезагрузки не знает что эта операция была вызвана.

Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.
Re[13]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 11:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>>>То есть лучше не использовать реестр виндовс, пока не доказано обратное.

N>>>>С чего это такой вывод?
G>>>Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?
N>>А с чего это мы должны тут рассматривать интернет-магазин? Это очень специализированная задача, с моей точки зрения и никак не соответствует моим задачам.
G>Я вот смотрю вакансии: 80% это веб и автоматизация предпирятий (документооборот и учетные системы). Ни одна из этих задач хорошо не ложится на реестр или NoSQL.
G>Это кореллирует с тем с какими задачами ко мне обращаются заказчики.

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

G>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).

N>>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.
G>Ну так расскажи что за задача.

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

G>>>Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности.

N>>Ну, ответил. Говори.)
G>Аргумент "у нас все работает", вообще-то не аргумент. Общая практика как раз говорит об обратном, несмотря на хайп. А если вам повезло, то могу только поздравить.
G>Опиши свою задачу конкретнее, тогда посмотрим что и как у вас можно сделать средствами SQL баз данных.

Чего не хватает в предыдущих описаниях?

G>>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.

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

Учётные — да, в общем случае готов согласиться.
Веб — это вообще не задача по своей природе, это интерфейс. Его же внутренние задачи не имеют никакой заточки для реляционной модели — наоборот, традиционное хранилище "кука => параметры" это key-value.
Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).
The God is real, unless declared integer.
Re[11]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:12
Оценка:
Здравствуйте, adontz, Вы писали:

A>Здравствуйте, ArhAngelVezel, Вы писали:


AAV>>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.


A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?


Конечно, а полнотекстовый индекс это вообще самый NoSQL. А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.
Re[4]: Про NoSQL
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.12.10 11:16
Оценка:
Здравствуйте, netch80, Вы писали:

N>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов


А что вы применяете для этой части, если не секрет?
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 11:18
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, netch80, Вы писали:


N>>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов


К>А что вы применяете для этой части, если не секрет?


Сейчас — RRD, но не устраивает. Ищем альтернативы в стиле распределённой разделяемой памяти поверх RDMA.
The God is real, unless declared integer.
Re[14]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 11:25
Оценка:
Здравствуйте, netch80, Вы писали:

N>Хорошо, отщипни HKEY_LOCAL_MACHINE\ в начале и замени бэкслэши на точки — получишь мой пример. И строго наоборот.

N>Возвращаюсь к исходному вопросу: как будет выглядеть таблица в этом случае?

  А тут SQL
DROP PROCEDURE [CreateRegistryKey]
DROP TABLE [RegistryValue];
DROP TABLE [RegistryKey];
GO
CREATE TABLE [RegistryKey]
(
    [HID]     HIERARCHYID   NOT NULL,
    [HLevel]  AS ([HID].[GetLevel]())     PERSISTED,
    [HParent] AS ([HID].[GetAncestor](1)) PERSISTED,
    [Name]    NVARCHAR(256) NOT NULL
)
GO
CREATE TABLE [RegistryValue]
(
    [HID]     HIERARCHYID    NOT NULL,
    [Name]    NVARCHAR(256)  NOT NULL,
    [Value]   VARBINARY(MAX) NOT NULL,
)
GO
ALTER TABLE [RegistryKey]   ADD CONSTRAINT [RegistryKey/PK]   PRIMARY KEY CLUSTERED ([HID], [Name]);
CREATE UNIQUE NONCLUSTERED INDEX [RegistryKey/UK] ON [RegistryKey]([HID])
GO
INSERT INTO [RegistryKey]([HID], [Name]) VALUES (hierarchyid::GetRoot(), '');

GO
ALTER TABLE [RegistryValue] ADD CONSTRAINT [RegistryValue/PK] PRIMARY KEY CLUSTERED ([HID], [Name]);
GO
ALTER TABLE [RegistryValue] ADD CONSTRAINT [RegistryValue/FK] FOREIGN KEY([HID]) REFERENCES [RegistryKey]([HID]);
GO
CREATE PROCEDURE [CreateRegistryKey](
    @ParentID HIERARCHYID,
    @Name     NVARCHAR(256))
AS
BEGIN
    DECLARE @ParentHierarchyID hierarchyid;
    DECLARE @SiblingHierarchyID hierarchyid;
    DECLARE @HierarchyID hierarchyid;
    
    IF @ParentID IS NULL
        SET @ParentID = hierarchyid::GetRoot();

    SELECT
        @ParentHierarchyID = [HID]
    FROM
        [RegistryKey]
    WHERE
        [HID] = @ParentID;

    SELECT
        @SiblingHierarchyID = MAX([HID])
    FROM
        [RegistryKey]
    WHERE
        [HID].GetAncestor(1) = @ParentHierarchyID;

    SET @HierarchyID = @ParentHierarchyID.GetDescendant(@SiblingHierarchyID, NULL);

    INSERT INTO
        [RegistryKey]([HID], [Name])
    VALUES
        (@HierarchyID, @Name);
END
GO
CREATE PROCEDURE [CreateRegistryValue](
    @HID   HIERARCHYID,
    @Name  NVARCHAR(256),
    @Value VARBINARY(MAX))
AS
BEGIN
    INSERT INTO
        [RegistryValue]([HID], [Name], [Value])
    VALUES
        (@HID, @Name, @Value);
END
GO
EXEC [CreateRegistryKey] NULL, 'A';
EXEC [CreateRegistryKey] NULL, 'ZZ';

DECLARE @Hid1 HIERARCHYID;
DECLARE @Hid2 HIERARCHYID;
SELECT @Hid1 = [HID] FROM [RegistryKey] WHERE [Name] = 'A';
SELECT @Hid2 = [HID] FROM [RegistryKey] WHERE [Name] = 'ZZ';

EXEC [CreateRegistryValue] @Hid1, 'P', 0x01;
EXEC [CreateRegistryValue] @Hid1, 'Q', 0x02;
EXEC [CreateRegistryValue] @Hid2, '', 0x03;

SELECT * FROM [RegistryKey];
SELECT * FROM [RegistryValue];


RegistryKey
0x 0 NULL
0x58 1 0x A
0x68 1 0x ZZ
RegistryValue
0x58 P 0x01
0x58 Q 0x02
0x68 0x03

N>Понятно, ничего специфического, кроме собственно типа hierarchyid. Это целое число или что-то более хитрое?


Это массив байт. Считай ещё ещё одним VARBINARY.

N>В таком случае хранение будет ужасающе неэффективно.


Я предпочитаю измерять производительность, а не рассуждать о ней.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 03.12.10 11:32
Оценка:
Здравствуйте, Mamut, Вы писали:

M>

M>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL

M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


Со словом "медленная" категорически не согласен. По долгу службы сейчас пишу на C++, потому что SQL сильно тормозит. Да и не все запросы на него хорошо ложатся.
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:33
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, adontz, Вы писали:


A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

AAV>Что такое объект в ООП? Это данные и методы работы с этими данными.
Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.

AAV>Поэтому, да, HIERARCHYID это объект.

Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?

A>>Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?

AAV>Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур.
Что есть "стандартные процедуры"? MS SQL вполне стандартно имеет возможность писать код на .NET.

AAV>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...

Большего бреда не читал никогда.
Давай рассматривать тупо существующие хранилища, не вешая ярлыки на их возможности.
Re[12]: Про NoSQL
От: Sinix  
Дата: 03.12.10 11:35
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, adontz, Вы писали:


A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

AAV>Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.

Таки почитайте

Вопросы резервного копирования данных, их целостности, работа хранилища в условиях нехватки памяти, параллельные запросы — эти вопросы разработчики НЕ ПОНИМАЮТ ДО КОНЦА, и не в состоянии их эффективно решить.

Будем реалистами — специлисты широкого профиля редко хорошо знают НЕСКОЛЬКО областей одновременно.
Те, что владеют DB-разработкой обычно РУГАЮТ NoSQL.
Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.
Я могу пересчитать по пальцам одной руки своих знакомых, которые ИСПОЛЬЗУЮТ NoSQL, и ПОНИМАЮТ почему они это делают.



AAV>Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур.

[facepalm]
Пожалйста, подучите матчасть.
[/facepalm]
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.


ANS>Вообще-то это фатальное преимущество, а не недостаток.


И как выражается это преимущество?
Re[12]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 11:45
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

AAV>Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.

INT — это данные и методы работы с ними (сложение, вычитание). INT — объект.

AAV>Если View написана с использованием C#


Отсыпьте, я уже готов примкнуть.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:45
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Конечно, а полнотекстовый индекс это вообще самый NoSQL.


ANS>Так и есть. Полнотекстовый индекс никакого отношения к тому что понимают по словом SQL не имеет. С этим нельзя спорить.


Да и к NoSQL не имеет тогда уж. В СУБД полнотекстовый поиск где-то с 2000 поддерживается, а может и раньше. Такому явлению как NoSQL от силы года 3.
Кроме того в самом потоке NoSQL ничего нового в полнотекстовом поиске придумано не было.

К SQL имеет самое прямое отношение ибо можно прямо в SQL запросе указать предикаты CONTAINS и FREETEXT.
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:51
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.


AAV>Подучите матчасть, как тут советуют фанатики RDBMS:

AAV>http://www.mongodb.org/display/DOCS/Indexes
AAV>http://www.mongodb.org/display/DOCS/Querying

Ну и? приведешь как сделать указанный мной запрос на mongodb?
Заодно и схему нарисуй, а потом мы на ней другие юзкесы проверим
Re[13]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.

Wiki: Объект (программирование) — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов).
Тут мы имеем объект и методы работы с ним.

G>Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?

Нет.. Это одна из ранних разновидностей ООП...



AAV>>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...

G>Большего бреда не читал никогда.
А вы почитайте и подумайте. А прежде всего скажите нам, что по вашему RDBMS, а что NoSql...
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:03
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.

AAV>Wiki: Объект (программирование) — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов).
AAV>Тут мы имеем объект и методы работы с ним.
"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.
Нужен критерий отделения объектов от не-объектов. Основной критерий это наличие Identity, которого как раз БД нету и не будет.


G>>Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?

AAV>Нет.. Это одна из ранних разновидностей ООП...
Ну тогда весь SQL это ООП язык.
Бред короче.


AAV>>>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...

G>>Большего бреда не читал никогда.
AAV>А вы почитайте и подумайте. А прежде всего скажите нам, что по вашему RDBMS, а что NoSql...
Берем существующие хранилища и смотрим на них.
Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird
Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven

Классифицировать алгоритмы не буду, они не зависят от хранилища.
Re[17]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 12:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну и? приведешь как сделать указанный мной запрос на mongodb?


db.documents.find({"accepted": "иванов", "date_accepted" : { $gt: date1, $lt: date2 } }).skip((pageNumber-1)*nPerPage).limit(nPerPage)
Re[18]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:11
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>Ну и? приведешь как сделать указанный мной запрос на mongodb?


AAV>db.documents.find({"accepted": "иванов", "date_accepted" : { $gt: date1, $lt: date2 } }).skip((pageNumber-1)*nPerPage).limit(nPerPage)


"Визы" это список, привязанный к документу.
Категории забыл.
Re[13]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 12:11
Оценка:
A>hierarchyid — специальный тип для хранения иерархических отношений

имхо, для иерархических данных пользовать какой-нить graph db + gremlin. но эти базы вообще в зачаточном состоянии


dmitriid.comGitHubLinkedIn
Re[7]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 12:15
Оценка:
M>>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.
F>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>А где его достаточно? Таких задач исчезающе мало.


M>>memcached, который некоторые заменяют redis'ом, например

G>Те NoSQL это не более чем распределенный кеш?

Тек, которые key-value store — по сути, да

M>>вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным

G>Да, тогда станет вопрос о том как получать список нужных ключей. Собственно язык SQL дает ответ на этот вопрос, а различные NoSQL хранилища — нет.

Вообще-то, отвечают. Но кадый — по-разному.

G>Полнотекстовым индеском все не заменишь, а вручную создавать индексы под каждый запрос — как то слишком круто.


Можно и не создавать

NoSQL — это не только kv-store И в этом проблема — так как каждый под NoSQL подразумевает что-то свое.


M>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )

G>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.

Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.


dmitriid.comGitHubLinkedIn
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:20
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )

G>>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.

M>Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.

Да ну?
Не удалось ни тут
Автор: gandjustas
Дата: 29.09.10
, ни там
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:22
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.

AAV>В SmallTalk так и есть ...
А толку?


G>>Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird

G>>Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven

G>>Классифицировать алгоритмы не буду, они не зависят от хранилища.

AAV>А вот и нет:
AAV>couchdb, mongodb — это документоорентированные базы
AAV>cassandra — это столбцоорентированная база
AAV>redis — это key-value орентированная база.
Так это все и есть NoSQL.

AAV>А в первой строчке у вас одни RDBMS...

Именно.
Re[10]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:29
Оценка:
Здравствуйте, noetic, Вы писали:

N>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе

Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.

Переводя на русский — это и есть "не ложится". =)

N>Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого.

В Реляционках для этого давно есть специальные типы данных. А до этих типов данных было несколько разнообразных решений в зависимости от конкретного сценария, так что не вижу тут никакой проблемы =)
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[9]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:42
Оценка:
Здравствуйте, IB, Вы писали:

N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
Ага. Только в заметном числе случаев у нас получается унылое Г. К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.
Sapienti sat!
Re[11]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:45
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
G>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.
Sapienti sat!
Re[11]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:50
Оценка:
Здравствуйте, IB, Вы писали:

C>>Ага. Только в заметном числе случаев у нас получается унылое Г.

IB>Ага, в _не_ заметном числе случаев, и если руки под унылое Г. заточены. =)
Ну да. Если понасиловать РБД, то часто можно научить её немного работать как NoSQL.

C>> К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.

IB>У строки нет столбцов
Ок. "Способ представления кортежей с произвольным числом элементов" тебя устроит?
Sapienti sat!
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


G>>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
G>>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
C>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.
Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.

Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.
Re[13]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.

G>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.
А те которые не столкнутся — нам и неинтересны.

G>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.

Ну так никто и не просит применять NoSQL сразу везде.
Sapienti sat!
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 13:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.

G>>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.
C>А те которые не столкнутся — нам и неинтересны.
Нам как раз интересны насущные проблемы, а не теоретические. странно что тебе ровно наоборот.

G>>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.

C>Ну так никто и не просит применять NoSQL сразу везде.
Ну да, потом распределенный кеш сделать для оптимизации.
Re[9]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 13:24
Оценка:
M>>>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )
G>>>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.

M>>Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.

G>Да ну?
G>Не удалось ни тут
Автор: gandjustas
Дата: 29.09.10
, ни там


И там и там — теоретические изыскания без реальных проектов. Правда, на аналог stackoverflow на ruby+mongodb там промелькнул: http://gitorious.org/shapado

тут не совсем правильный подход «вот вам проект, сделайте аналог». Лучше посмотреть на то, какие проекты уже сделаны и экстраполировать.

на MongоDB валяется http://foursquare.com/ — по сути тот же stackoverflow — рейтинги, комментарии, badges и т.п.
на CouchDB вроде валяется http://www.mydochub.com/answers/ — практически аналог stackoverflow

ну и т.п.

то есть делать можно. только нужно ли?


dmitriid.comGitHubLinkedIn
Re[7]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 13:29
Оценка:
N>>Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.
IB>Переводя на русский — это и есть "не ложится". =)

N>>Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого.

IB>В Реляционках для этого давно есть специальные типы данных.

Далеко не во всех.

IB>А до этих типов данных было несколько разнообразных решений в зависимости от конкретного сценария, так что не вижу тут никакой проблемы =)


что-то мне кажется, что такие решения не заходили дальше FOAF (friend of a friend), а для бОльшей вложенности все равно требовался геморрой.


dmitriid.comGitHubLinkedIn
Re[10]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 13:45
Оценка:
Здравствуйте, Mamut, Вы писали:

M>тут не совсем правильный подход «вот вам проект, сделайте аналог».

ИМХО самый правильный чтобы показать что NoSQLне хуже SQL_ных решений.
Только вот не удается этого показать.

M>Лучше посмотреть на то, какие проекты уже сделаны и экстраполировать.

M>на MongоDB валяется http://foursquare.com/ — по сути тот же stackoverflow — рейтинги, комментарии, badges и т.п.
M>на CouchDB вроде валяется http://www.mydochub.com/answers/ — практически аналог stackoverflow
M>ну и т.п.
В основном это проекты, которые используют сильные стороны соответствующих технологий и не показываются слабых.
Нужен именно real-world проект. Имхо stackoverflow — хороший вариант. Не слишком сложен чтобы охватить одному человеку, и не слишком банален как блог, магазин или "датчики".
Re[11]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 14:03
Оценка:
Здравствуйте, IB, Вы писали:

N>>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе

IB>Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.

Моя? У меня проблемы в этом нет Вот если бы заставили использовать RDBMS — была бы. На торможении в разы.
The God is real, unless declared integer.
Re[12]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 14:05
Оценка:
Здравствуйте, netch80, Вы писали:

N>>>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе

IB>>Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.
N>Моя? У меня проблемы в этом нет Вот если бы заставили использовать RDBMS — была бы. На торможении в разы.

С чего вы взяли что у вас что-то там будет тормозить в разы, если вы не умеете работать с RDBMS?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 14:13
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.

C>>А те которые не столкнутся — нам и неинтересны.
G>Нам как раз интересны насущные проблемы, а не теоретические. странно что тебе ровно наоборот.
А ненасущные проблемы ближе, чем кажутся Вот как раз сегодня абсолютно случайно наткнулся.

G>>>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.

C>>Ну так никто и не просит применять NoSQL сразу везде.
G>Ну да, потом распределенный кеш сделать для оптимизации.
Ага, а потом в этот кэш добавить возможность поиска. И удивиться, что получается какой-то из NoSQL.
Sapienti sat!
Re[13]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 14:15
Оценка:
Здравствуйте, adontz, Вы писали:

A>Здравствуйте, netch80, Вы писали:


N>>>>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе

IB>>>Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.
N>>Моя? У меня проблемы в этом нет Вот если бы заставили использовать RDBMS — была бы. На торможении в разы.

A>С чего вы взяли что у вас что-то там будет тормозить в разы, если вы не умеете работать с RDBMS?


А откуда вывод про "неумение работать с RDBMS"? Незнание того конкретного средства, которое Вы почему-то считаете средством по дефолту, ещё ничего не означает
The God is real, unless declared integer.
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 14:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

G>>>>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.

C>>>Ну так никто и не просит применять NoSQL сразу везде.
G>>Ну да, потом распределенный кеш сделать для оптимизации.
C>Ага, а потом в этот кэш добавить возможность поиска. И удивиться, что получается какой-то из NoSQL.
Я думаю на момент появления распределенного кеша поиск по данным уже будет работать.
Даже на самом простом уровне типа contains\freetext в SQL базе данных.
Re[17]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 14:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Ну да, потом распределенный кеш сделать для оптимизации.

C>>Ага, а потом в этот кэш добавить возможность поиска. И удивиться, что получается какой-то из NoSQL.
G>Я думаю на момент появления распределенного кеша поиск по данным уже будет работать.
G>Даже на самом простом уровне типа contains\freetext в SQL базе данных.
Так захочется поиск запускать в кэше. А потом и запросы на нём делать.
Sapienti sat!
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 14:48
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, adontz, Вы писали:


A>>Здравствуйте, netch80, Вы писали:


N>>>>>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе

IB>>>>Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.
N>>>Моя? У меня проблемы в этом нет Вот если бы заставили использовать RDBMS — была бы. На торможении в разы.

A>>С чего вы взяли что у вас что-то там будет тормозить в разы, если вы не умеете работать с RDBMS?


N>А откуда вывод про "неумение работать с RDBMS"? Незнание того конкретного средства, которое Вы почему-то считаете средством по дефолту, ещё ничего не означает


А ты считаешь что умение работать с БД это знание только конструкций стандарта 92 года?

Маленький чеклист чтобы утверждать что таки знаешь SQL
(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД)
Re[4]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 14:49
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


G>>Рассказываю тайну. SQL база данных может спокойно порвать любой твой код, потому что СУБД оптимизирует доступ к диску. А это сейчас самая медленная операция.


M>У меня не используется совсем диск, все данные в памяти

И что же ты с ними делаешь?
Re[5]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 03.12.10 14:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>У меня не используется совсем диск, все данные в памяти


G>И что же ты с ними делаешь?


Тупой перебор (brutte force), обработка, вывод.
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 14:57
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


M>>>У меня не используется совсем диск, все данные в памяти


G>>И что же ты с ними делаешь?


M>Тупой перебор (brutte force), обработка, вывод.


и что за перебор и обработка?
Re[11]: Про NoSQL
От: messir VolanD Беларусь http://www.google.com/profiles/p.drobushevich
Дата: 03.12.10 15:16
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Mamut, Вы писали:


M>>тут не совсем правильный подход «вот вам проект, сделайте аналог».

G>ИМХО самый правильный чтобы показать что NoSQLне хуже SQL_ных решений.
G>Только вот не удается этого показать.

M>>Лучше посмотреть на то, какие проекты уже сделаны и экстраполировать.

M>>на MongоDB валяется http://foursquare.com/ — по сути тот же stackoverflow — рейтинги, комментарии, badges и т.п.
M>>на CouchDB вроде валяется http://www.mydochub.com/answers/ — практически аналог stackoverflow
M>>ну и т.п.
G>В основном это проекты, которые используют сильные стороны соответствующих технологий и не показываются слабых.
G>Нужен именно real-world проект. Имхо stackoverflow — хороший вариант. Не слишком сложен чтобы охватить одному человеку, и не слишком банален как блог, магазин или "датчики".
Наброшу
Stack Overflow Architecture

What is key about the Stack Overflow story for me is the strong case they make for scale up as a viable solution for a certain potentially large class of problems. The publicity these days is all going scale out using NoSQL databases.

Re[7]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 15:17
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, netch80, Вы писали:


N>>Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.

IB>Переводя на русский — это и есть "не ложится". =)

Твой переводчик явно нуждается в починке.

N>>Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого.

IB>В Реляционках для этого давно есть специальные типы данных. А до этих типов данных было несколько разнообразных решений в зависимости от конкретного сценария, так что не вижу тут никакой проблемы =)

Так всё-таки — будут конкретные предложения, или как обычно?
The God is real, unless declared integer.
Re[7]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 03.12.10 15:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>и что за перебор и обработка?


Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000). Нужно найти количество и заданную страницу данных для items, в которых есть все перечисленные tag (может быть в запросе до 100 штук). При этом некоторые tags могут быть игнорируемые (их наличие необязательно). Некоторые tag-и такие, что встречаются в 60% всех items. Они могут в поиске сочетаться.

В общем, в упрощенном виде нечто такое:

SELECT items.* FROM items
  JOIN item_tags it1 ON items.item_id = it1.item_id
  JOIN item_tags it2 ON items.item_id = it2.item_id
  LEFT JOIN item_tags it3 ON items.item_id = it3.item_id /* игнорируемый */
  ...
WHERE 1=1
  AND it1.tag_id = @tag1
  AND it2.tag_id = @tag2
  AND it3.tag_id = @tag3
  ....
  AND /* Дополнительные условия */
ORDER BY  /* агрегатные функции, иногда с кучей IF, подтаблицами, ... */


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

В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3
Re[12]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 15:21
Оценка:
Здравствуйте, netch80, Вы писали:

N>Вот если бы заставили использовать RDBMS — была бы. На торможении в разы.

Один бы ты в разы не справился, если только с помощником ))
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[12]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 15:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну да. Если понасиловать РБД, то часто можно научить её немного работать как NoSQL.

А если не насиловать, то она работает гораздо лучше, чем noSql.. ))

C>Ок. "Способ представления кортежей с произвольным числом элементов" тебя устроит?

Абсолютно, тем более, что у реляционки с этим нет никаких проблем =))
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 15:21
Оценка:
Здравствуйте, Mamut, Вы писали:

M>что-то мне кажется, что такие решения не заходили дальше FOAF (friend of a friend), а для бОльшей вложенности все равно требовался геморрой.

Никакого геморроя, просто чуть более сложные запросы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[16]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 15:24
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


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


Уже увидел ответ, разберу в спокойной обстановке.
The God is real, unless declared integer.
Re[14]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 15:27
Оценка:
Здравствуйте, netch80, Вы писали:

N>А откуда вывод про "неумение работать с RDBMS"? Незнание того конкретного средства, которое Вы почему-то считаете средством по дефолту, ещё ничего не означает


Назовите средство с которым знакомы, я весь внимание.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 15:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>Твой переводчик явно нуждается в починке.

Пока справляется, лапшу с ушей стряхивает исправно ))

N>Так всё-таки — будут конкретные предложения, или как обычно?

Предложения для чего? ты так и на объяснил в чем проблема положить реестр в реляционку, а по фотографии я не гадаю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 15:40
Оценка:
M>>тут не совсем правильный подход «вот вам проект, сделайте аналог».
G>ИМХО самый правильный чтобы показать что NoSQLне хуже SQL_ных решений.
G>Только вот не удается этого показать.

M>>Лучше посмотреть на то, какие проекты уже сделаны и экстраполировать.

M>>на MongоDB валяется http://foursquare.com/ — по сути тот же stackoverflow — рейтинги, комментарии, badges и т.п.
M>>на CouchDB вроде валяется http://www.mydochub.com/answers/ — практически аналог stackoverflow
M>>ну и т.п.
G>В основном это проекты, которые используют сильные стороны соответствующих технологий и не показываются слабых.
G>Нужен именно real-world проект. Имхо stackoverflow — хороший вариант. Не слишком сложен чтобы охватить одному человеку, и не слишком банален как блог, магазин или "датчики".

А чем foursquare не real world? Аналог stackoverflow на mongodb есть


dmitriid.comGitHubLinkedIn
Re[9]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 15:42
Оценка:
M>>что-то мне кажется, что такие решения не заходили дальше FOAF (friend of a friend), а для бОльшей вложенности все равно требовался геморрой.
IB>Никакого геморроя, просто чуть более сложные запросы.

Ну как бы в том-то и дело

Если специальных иерархических данных нет (тот же MySQL), каждый следующий уровень дерева — это один-два лишних джойна.
Если специальные иерархические данные есть (последние версии MSSQL?), то тут я вообще не копенгаген

Справедливости ради, с деревьями (они же графы) весь NoSQL тоже не дружит, а граф-базы данных мне в NoSQL записывать не хочется


dmitriid.comGitHubLinkedIn
Re[12]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 15:49
Оценка:
MV>Наброшу
MV>Stack Overflow Architecture

MV>

MV>What is key about the Stack Overflow story for me is the strong case they make for scale up as a viable solution for a certain potentially large class of problems. The publicity these days is all going scale out using NoSQL databases.


Там есть другой наброс

The refactorings will be to avoid excessive joins in a lot of key queries. This is the key lesson from giant multi-terabyte table schemas (like Google’s BigTable) which are completely join-free. This is significant because Stack Overflow's database is almost completely in RAM and the joins still exact too high a cost.


Что означает денормализацию и, по сути, key/value запросы То бишь NoSQL


dmitriid.comGitHubLinkedIn
Re[13]: Про NoSQL
От: messir VolanD Беларусь http://www.google.com/profiles/p.drobushevich
Дата: 03.12.10 16:39
Оценка:
Здравствуйте, Mamut, Вы писали:

MV>>Наброшу

MV>>Stack Overflow Architecture

MV>>

MV>>What is key about the Stack Overflow story for me is the strong case they make for scale up as a viable solution for a certain potentially large class of problems. The publicity these days is all going scale out using NoSQL databases.


M>Там есть другой наброс


M>

M>The refactorings will be to avoid excessive joins in a lot of key queries. This is the key lesson from giant multi-terabyte table schemas (like Google’s BigTable) which are completely join-free. This is significant because Stack Overflow's database is almost completely in RAM and the joins still exact too high a cost.


M>Что означает денормализацию и, по сути, key/value запросы То бишь NoSQL


Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 22:06
Оценка:
Здравствуйте, netch80, Вы писали:

G>>Маленький чеклист чтобы утверждать что таки знаешь SQL

G>>(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД)

N>Ну посмотрел. ~80% описанного хорошо знакомо. Даже больше, если послать нафиг XML. И что это даёт?

Ну так надо 100%, а то что написал adontz видимо не попало в 80%, вот непонятно было что за структура.
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 22:20
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


G>>и что за перебор и обработка?


M>Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000).

То есть они таки считываются с диска.

M>Нужно найти количество и заданную страницу данных для items, в которых есть все перечисленные tag (может быть в запросе до 100 штук). При этом некоторые tags могут быть игнорируемые (их наличие необязательно). Некоторые tag-и такие, что встречаются в 60% всех items. Они могут в поиске сочетаться.


M>В общем, в упрощенном виде нечто такое:


M>
M>SELECT items.* FROM items
M>  JOIN item_tags it1 ON items.item_id = it1.item_id
M>  JOIN item_tags it2 ON items.item_id = it2.item_id
M>  LEFT JOIN item_tags it3 ON items.item_id = it3.item_id /* игнорируемый */
M>  ...
M>WHERE 1=1
M>  AND it1.tag_id = @tag1
M>  AND it2.tag_id = @tag2
M>  AND it3.tag_id = @tag3
M>  ....
M>  AND /* Дополнительные условия */
M>ORDER BY  /* агрегатные функции, иногда с кучей IF, подтаблицами, ... */
M>


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

SQL Server отлично такой запрос поборет при правильных индексах.


M>В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3

А считывание всего этого добра в память?
Re[9]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 03.12.10 23:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000).

G>То есть они таки считываются с диска.

M>>В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3

G>А считывание всего этого добра в память?

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

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

G>SQL Server отлично такой запрос поборет при правильных индексах.

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

В моих кривых руках базы работают прекрасно, если есть хотя бы один редкий tag, но вешаются при запросах, например, по двум тагам, когда первый используется в 60% всех item-ов, и второй примерно также. А если сюда добавить еще и третий такой же, то совсем плохо. В этом случае все равно в результате миллион записей, которые надо посчитать, отсортировать, ...

Опять же, написать такое на C++ для меня не проблема. В конце концов там вся на уровне лабораторной работы для нерадивых студентов первого курса. Все в моих руках. Плюс на сегодня большой запас по увеличению производительности в случае необходимости. Добавить те же индексы Но у меня нет никакой уверенности в том, что после долгого ковыряния в мануалах, настройке, подгонки, подкрутки, все это заработает с SQL-сервером. Допускаю, но хотелось бы увидеть. А также запаса на тот случай, что если все это дело в один прекрасный день завалится, то я смогу это быстро поправить. Также я не могу дать гарантию, что если требования изменятся, осилит ли их SQL-сервер. Например, добавится с десяток LEFT JOIN. Ну и прочие неприятности, типа изменился алгоритм, надо менять/перестраивать материализованные вьюхи. А что будет при этом при запросе к ним? И т. д. и т. п.

Гипотетически, в случае Oracle, например, меня смущает тот факт, что запросы строится динамически, не повторяются, а построение плана запроса достаточно дорогая операция.
Re[10]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 06:35
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


M>>>Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000).

G>>То есть они таки считываются с диска.

M>>>В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3

G>>А считывание всего этого добра в память?

M>Считываются с диска раз в сутки при индексации. Потом формируется новый shared memory object, с которым идет дальнейшая работа. Старый уничтожается. Если бы этот гигабайт при каждом запросе считывался с диска, то наступили бы всеобщие грабли. Сейчас, за исключением 15 мин в день, дисковая активность в нулях.


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

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

G>>SQL Server отлично такой запрос поборет при правильных индексах.

M>Но запрос немного упрощенный. Дополнительные условия состоят в том, что у item-ов есть типы. Два item-а одного типа, по возможности, не должны следовать друг за другом. Так что все равно выдачу надо было бы руками обрабатывать. При выдаче данные разбиваются на несколько потоков, которые надо смешать в определенной пропорции. Узнать, куда попадет тот или иной item можно только после выполнения агрегатной функции. Получаем несколько однотипных запросов с разными HAVING-ами.

Сами себе грабли придумываете.

M>В моих кривых руках базы работают прекрасно, если есть хотя бы один редкий tag, но вешаются при запросах, например, по двум тагам, когда первый используется в 60% всех item-ов, и второй примерно также. А если сюда добавить еще и третий такой же, то совсем плохо. В этом случае все равно в результате миллион записей, которые надо посчитать, отсортировать, ...

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

M>Опять же, написать такое на C++ для меня не проблема. В конце концов там вся на уровне лабораторной работы для нерадивых студентов первого курса. Все в моих руках. Плюс на сегодня большой запас по увеличению производительности в случае необходимости. Добавить те же индексы Но у меня нет никакой уверенности в том, что после долгого ковыряния в мануалах, настройке, подгонки, подкрутки, все это заработает с SQL-сервером. Допускаю, но хотелось бы увидеть. А также запаса на тот случай, что если все это дело в один прекрасный день завалится, то я смогу это быстро поправить. Также я не могу дать гарантию, что если требования изменятся, осилит ли их SQL-сервер. Например, добавится с десяток LEFT JOIN. Ну и прочие неприятности, типа изменился алгоритм, надо менять/перестраивать материализованные вьюхи. А что будет при этом при запросе к ним? И т. д. и т. п.

Ну ладно, честно признался что не очень в базе данных рубишь.
Re[10]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 04.12.10 09:02
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Если специальных иерархических данных нет (тот же MySQL), каждый следующий уровень дерева — это один-два лишних джойна.

Никаких лишних джойнов уровни не добавляют, просто структура данных чуть сложнее. И это именно "чуть", а не так фатально, как тут пытаются описать.
Мы уже победили, просто это еще не так заметно...
Re[14]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 04.12.10 09:04
Оценка:
Здравствуйте, Mamut, Вы писали:

M>А можно пример?

пример чего? как это дело через еще одно отношение выразить? У меня и правда складывается впечатление, что адепты noSql на самом деле реляционки не знают. =)
Мы уже победили, просто это еще не так заметно...
Re[11]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 04.12.10 10:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Те обновление раз в день происходит или как?

G>Кстати, что будешь делать если таблица вылезет за пределы доступной памяти на x86?
G>(подсказка: с базой ничего не надо придумывать)

Да, раз в день. Памяти 32G, используется 1G + 1G при индкскации. Как минимум запас в 10 раз есть. Это по самым скромным оценкам, 10 лет развития проекта. А это уже достаточно большой срок. За это время либо я умру, либо ишак.

G>Сами себе грабли придумываете.




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


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



G>Ну ладно, честно признался что не очень в базе данных рубишь.


Зато разбираюсь в алгоритмах. И могу оценить верхнюю границу при условии, что база данных отработает запрос идеально (т. е. выполнит только те вычисления, что необходимы).
Re[9]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:01
Оценка:
Здравствуйте, IB, Вы писали:

N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )

Уложить можно что угодно, куда угодно.

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

И здесь оказывается частенько, что NoSQL решения завязаны на специфику конкретного кастомера или отрасли.

Т.е. они тупо дешевле и оптимизированы исключительно под конкретные сценарии.
Re[6]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 04.12.10 11:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Господи, что за мода приводить абсолютные цифры безо всякого базиса?


+1

I>Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД?


Купить винчестеры быстрее
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:16
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Справедливости ради, с деревьями (они же графы) весь NoSQL тоже не дружит, а граф-базы данных мне в NoSQL записывать не хочется


Это еще почему ? И деревья и графы и гиперграфы со всякими слоями отлично дружиццо с NoSql.
Re[7]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:26
Оценка:
Здравствуйте, adontz, Вы писали:

I>>Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД?


A>Купить винчестеры быстрее


Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов, что повлечет издержки из за переустановки софта минимум 1 рабочий день по всей конторе.

То есть, ты предлагаешь ради ускорения своей софтины затратить сумму примерно равную 10млн долларов только на аппаратное ускорение

Вот тебе и SQL

P.S. это конечно частный случай, но он вполне реальный.
Re[8]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 04.12.10 11:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>Купить винчестеры быстрее

I>Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов

Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Про NoSQL
От: Sinix  
Дата: 04.12.10 11:32
Оценка:
Здравствуйте, Ikemefula, Вы писали:


I>Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов, что повлечет издержки из за переустановки софта минимум 1 рабочий день по всей конторе.


I>Вот тебе и SQL

С интересом понаблюдаю за массовым внедрением ферм на 10k dbms-серверов. Почему сразу не миллион?

И главное, где вы наберёте пару петабайт полезной информации на эту ферму? google@home?
Re[10]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 04.12.10 11:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред?

I>Я вообще то не говорил про серверный софт

А какой тогда вообще смысл говорить о производительности?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:41
Оценка:
Здравствуйте, Sinix, Вы писали:

I>>Вот тебе и SQL

S>С интересом понаблюдаю за массовым внедрением ферм на 10k dbms-серверов. Почему сразу не миллион?

А фермы здесь при чем ?
Re[10]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 04.12.10 11:42
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Вот тебе и SQL

S>>С интересом понаблюдаю за массовым внедрением ферм на 10k dbms-серверов. Почему сразу не миллион?
I>А фермы здесь при чем ?

И то правда, ваша конфигурация на ферму не тянет, максимум на колхоз!
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.12.10 11:43
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред?

I>>Я вообще то не говорил про серверный софт

A>А какой тогда вообще смысл говорить о производительности?


Зачем инженеру ответ за 1 секунду если можно затратить неделю ?

Ты вроде не из России что бы такие вопросы задавать
Re[12]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 04.12.10 11:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>А какой тогда вообще смысл говорить о производительности?

I>Зачем инженеру ответ за 1 секунду если можно затратить неделю ?
I>Ты вроде не из России что бы такие вопросы задавать

Зачем считать на клиенте что-то, что считается больше секунды? Ну ладно, пяти.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.12.10 13:26
Оценка:
Здравствуйте, adontz, Вы писали:

A>http://zabivator.livejournal.com/412053.html


О да. Утверждение, что если человек понимает, что он делает, то он это делает осознанно, а если не понимает, то не осознанно — очень философское. Но очень малополезное. Зачем его по треду в разные посты растыкали — не понятно.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 04.12.10 13:45
Оценка:
M>>А можно пример?
IB>пример чего? как это дело через еще одно отношение выразить? У меня и правда складывается впечатление, что адепты noSql на самом деле реляционки не знают. =)

Стандартный социальный сайт — это, по сути, граф.

Стандартный запрос — это FOAF. Это понятно и примитивно. Интересен запрос любой вложенности/закрученности по графу.


dmitriid.comGitHubLinkedIn
Re[11]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 04.12.10 13:46
Оценка:
M>>Справедливости ради, с деревьями (они же графы) весь NoSQL тоже не дружит, а граф-базы данных мне в NoSQL записывать не хочется

I>Это еще почему ? И деревья и графы и гиперграфы со всякими слоями отлично дружиццо с NoSql.


NoSQL и так перещружен толпой абсолютно разных и непересекающихся баз данных и хрнилищ Не надо в этот термин еще и граф-базы данных втягивать


dmitriid.comGitHubLinkedIn
Re[18]: Про NoSQL
От: Sinix  
Дата: 04.12.10 14:01
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>нарваться на распределённость (и попасть под действие теоремы) можно даже не заметив этого(как это произошло у gandjustas с полнотекстовым поиском)
Автор: gandjustas
Дата: 03.12.10
.


Я обычно терплю даже более крутые ляпсусы, да и с ув gandjustas по ряду тем мы сходимся только в том, что собеседник не прав (с). Тем не менее.

Цитата с контекстом обсуждения (прелессная иллюстрация тезиса "противники SQL даже NoSQL как следует не знают").

gandjustas

AAV>>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.

A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?

Конечно, а полнотекстовый индекс это вообще самый NoSQL. А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.


Итак, где здесь:
1 Распределённость,
2. "из трёх гарантий (C-, A-, P-) теряется не одна, а все гарантии"
3. "ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется".
?

ANS> Программист получает гарантии ACID на уровне отдельных запросов. ... Всё прозрачно и понятно.

Наповал

ANS>Итого, преимущество в том, что такие системы не обещают того, что в реальной жизни выполнить не возможно.



UPD.

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

ANS> Кстати у упомненных выше 80% проектов Durability не нужна.

gandjustas

80% это веб и автоматизация предпирятий (документооборот и учетные системы). Ни одна из этих задач хорошо не ложится на реестр или NoSQL.
Это кореллирует с тем с какими задачами ко мне обращаются заказчики.

И не нужна, и невозможна. Так и запишем.
Сделать хотел козу — палец застрял в носу...
Re: Про NoSQL
От: любой  
Дата: 04.12.10 15:58
Оценка:
Здравствуйте, Mamut, Вы писали:

M>

M>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL

M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.


Ну значит те программы, которые содержат меньше половины реализации SQL — недостаточно сложные

Напрягает, что гиганты индустрии вместо того, чтобы дать разработчикам достойное хранилище данных, всякие виртуальные машины изобретают. А те, кто СУБД делают, просто охамели. Навязывают всем подряд multiple-readers-multiple-writers model со всеми вытекающими, да еще с поддержкой кучи режимов совместного доступа. Понятно дело, что для одного единственного thread'а, который и писатель, и читатель, решение можно бы и попроще и побыстрей на порядок-другой сделать. Да и для multiple-readers-single-write тоже.
художников никогда не обижал
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 20:30
Оценка:
Здравствуйте, Mystic, Вы писали:

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


M>Могут, а толку? Если в результате будет 1 000 000 item-ов, то хочешь-не хочешь придется их все обрабатывать. Как тут выручит селективность?

Еще раз. БД оптимизирует доступ к диску. Фактически она не будет даже поднимать в память те записи, к которым не было обращения.


G>>Ну ладно, честно признался что не очень в базе данных рубишь.

M>Зато разбираюсь в алгоритмах. И могу оценить верхнюю границу при условии, что база данных отработает запрос идеально (т. е. выполнит только те вычисления, что необходимы).
Ты снова забыл про чтение.
Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать?
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 20:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


N>>>И где тут описанное тобой "основное хранилище"?

G>>Ты как-бы привел ваше РЕШЕНИЕ, а не задачу. Расскажи подробнее про задачу тебе решений накидают.
G>>Большинство обычных СУБД вытянут базы на 100гб и не поморщатся при нормальной схеме. Никаких распределенных хранилищ не понадобится.

I>Господи, что за мода приводить абсолютные цифры безо всякого базиса ?

I>На каком железе будут тянуться эти 100гб ?
На хорошем сервере

См конфигурацию сервера БД stackoverflow


G>>ЗЫ. Единственное во что реально упереться в СУБД, так это в скорость записи.

I>Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД ?
У MS SQL есть StreamInsight, у других — ХЗ.

Никто не мешает сварганить свой StreamInsight с потоковой обработкой данных.
Re[18]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 20:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>И как выражается это преимущество?


ANS>Ну вот смотри. Есть у нас CAP-теорема (она же теорема Брюера). Не смотря на то, что г-н Cyberax педалирует её в контексте высоконагруженных систем
Автор: Cyberax
Дата: 03.12.10
, теорема применима в случае распределённых систем. Существует мнение, что распределённость это удел не многих
Автор: gandjustas
Дата: 03.12.10
, но по факту, нарваться на распределённость (и попасть под действие теоремы) можно даже не заметив этого(как это произошло у gandjustas с полнотекстовым поиском)
Автор: gandjustas
Дата: 03.12.10
. Результатом такого незамечания является то, что из трёх гарантий (C-, A-, P-) теряется не одна, а все гарантии (теорема ведь не обещает, что всегда выполняются две гарантии из трёх, а утверждает, что выполняется не больше двух).

Ты вообще о чем? Где теряются гарантии, покажешь?

ANS>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется.

Покажи где он не выполнгяется.
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 21:22
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


G>>Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало


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

ОК. Вот у тебя есть MS SQL Server, покажи подтверждение своим словам.


G>>Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.


ANS>шардинг не поможет (учите матчасть, хм). Нужна репликация.

Репликация не поможет если данные не сохранены.

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


ANS>PS. Кстати у упомненных выше 80%
Автор: gandjustas
Дата: 03.12.10
проектов Durability не нужна.

Отсутствие Durability сразу же лишает как консистентности, так и атомарности.
При сбое невозможно узнать какая операция не выполнилась, что позволяет иметь несогласованные данные и невозможность откатить транзакцию.
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.12.10 22:01
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, IB, Вы писали:


N>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.

IB>>Да ладно? Что же там в SQL не ложится? )

ANS>1. Подо всё свой инструмент нужен. То что доказано, что всё можно запихнуть в реляционную модель не значит, что туда нужно всё пихать. Это настолько очевидно, что я даже не представлял, что его кто-то может оспаривать. К примеру, лет десять назад Oracle создал сервер, который внутри себя держал файлы. Поддерживал кучу протоколов (smb, ftp etc). И естественно обещал ACID. Однако Oracle не сказал, что все должны вместо файловых систем использовать их хранилище. Ибо скорость проседала на порядок по сравнению с обычной ФС. А возможность выполнения запросов к файловой системе и транзакции при таком проседании скорости мало кому нужны.

Скорость простите чего?
Ясное дело что качать блобы через БД, которая обращается к диску, дольше чем читать с самого диска.
Ну и не надо это делать.

ANS>2. Сам факт появления такой техники как `Nested Sets` и внедрения в SQL cервер встроенного полнотекстового поиска и XML типа данных со своим языком запросов и способом хранения, говорит о том, что разработчики серверов осознают ограниченность своего инструмента и не боятся топать к NoSql когда обстоятельства требуют. Что особенно удивляет, так это то, что приводя такие примеры
Автор: gandjustas
Дата: 03.12.10
одной рукой, другой рукой оппоненты отсылают к нормальным формам
Автор: gandjustas
Дата: 04.12.10
.

Теперь специально для тебя рассказываю тайну, которую многие любители NoSQL постигнуть не в состоянии.
Данные делятся на:
1)структурированные, которые можно представить множеством кортежей с элементами одинаковых типов (sql)
2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
3)неструктурированные: текст, blob

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

Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы предпочитаете пользоваться всяким г... которое обрабатывает только полуструктурированные данные, и то не лучшим образом.

ЗЫ. Я намеренно не вешаю тут ярлыков SQL-NoSQL, чтобы путаниицы не возникало.
Впредь рекомендую рассматривать под терминами NoSQL только хранилища, потому что методы обработки зависят в первую очередь от самих данных, а не от того как они хранятся.
Re: Про NoSQL
От: Курилка Россия http://kirya.narod.ru/
Дата: 04.12.10 22:09
Оценка:
Здравствуйте, Mamut, Вы писали:

[cut]

M>Думаю, это достаточно философское замечание


А вот взгляд на NoSQL как на NoJoin и ключевая мысль:

Strict normalization makes as much sense as the waterfall model.

Re[13]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 00:47
Оценка:
Здравствуйте, adontz, Вы писали:

I>>Зачем инженеру ответ за 1 секунду если можно затратить неделю ?

I>>Ты вроде не из России что бы такие вопросы задавать

A>Зачем считать на клиенте что-то, что считается больше секунды? Ну ладно, пяти.


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

Тебя ведь не смущает, что компиляция проекта выполняется больше 5 секунд а выполнение юниттестов еще дольше ?

Представь себе фирму где работает около 10 тыс инженеров. У каждого есть комп.

Задача — заменить тяжелый десктопный софт, скажем нечто похожее на сапр, серверным.

Посчитай бюджет по софту, железу, миграции и тд.
Re[20]: Про NoSQL
От: Sinix  
Дата: 05.12.10 03:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>И так, ты действительно не видишь где теряется гарантия ACID при использовании полнотекстового поиска.

Не вижу. Точнее, ежу понятно, что полнотекстовый индекс как правило обновляется далеко не сразу, и полагаться на результаты поиска для "определяем, какие строчки обновлять/удалять запросом с CONTAINS" будет только последний ССЗБ. Как это нарушает ACID в отношении собсно данных — . Чем FTS отличается от асинхронной очереди Service Broker'а/прочих способов отложенной обработки данных?

Я ещё раз напомню контекст.

gandjustas

AAV>>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.

A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?

Конечно, а полнотекстовый индекс это вообще самый NoSQL. А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.

...

Вы:
Существует мнение, что распределённость это удел не многих, но по факту, нарваться на распределённость (и попасть под действие теоремы) можно даже не заметив этого(как это произошло у gandjustas с полнотекстовым поиском).



ANS>и считаешь, что можно Durability обеспечить только в рамках одного дискового массива?

Можно. Вы ведь про это durability:

Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).

?

Если да — какое глобальное преимущество имеет несколько рейдов перед одним? Чур, настолько глобальное, чтобы подтвердить "один raid — это не durability". Потому что если докапываться до каждой буковки, durability невозможно в уничтожимой вселенной

С практической точки зрения, однако, durability означает минимальное соотношение количества "чорд! Где мои данные!" к количеству сбоев в системе. И да, во взрослых СУБД оно обеспечивается уровнем выше — failower cluster'ами / log shipping'ом.




А вообще, очень показательно отнохение NoSQL-щиков к данным клиента.

To start, there are some very practical reasons why we think single server durability is overvalued.

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

Что ж, смелости, очевидно, хватает, осталось пожелать удачи.
Улыбаемся и машем!
Re[14]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.12.10 06:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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

I>Тебя ведь не смущает, что компиляция проекта выполняется больше 5 секунд а выполнение юниттестов еще дольше ?
I>Представь себе фирму где работает около 10 тыс инженеров. У каждого есть комп.
I>Задача — заменить тяжелый десктопный софт, скажем нечто похожее на сапр, серверным.
I>Посчитай бюджет по софту, железу, миграции и т.д.

SQL Server Standard (+5CAL) — 898 USD
SQL Server Enterprise (per CPU) — 27,495 USD

Итого, 16процессорный сервер — 439,920 USD
Итого, 10000 рабочих станций — 8,980,000 USD, то есть более чем в 20 раз больше. На сэкономленные 8.5 миллионов можно отгрохать весьма неплохой датацентр.

Про ThinClient и Desktop/Application Virtualization рассказывать?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Про NoSQL
От: iHateLogins  
Дата: 05.12.10 06:21
Оценка:
Здравствуйте, Mamut, Вы писали:

M>

M>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL


Согласен 100%. По моему опыту, наиболее часто приверженностью к NoSQL страдают (наслаждаются? ) люди с очень слабым знанием SQL как языка и реализации его в основных платформах (MySQL, Oracle, MSSQL, DB2).

То, что с такими знаниями выходит какашка — вполне закономерный результат.
Re[15]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 10:40
Оценка:
Здравствуйте, adontz, Вы писали:

I>>Посчитай бюджет по софту, железу, миграции и т.д.


A>SQL Server Standard (+5CAL) — 898 USD

A>SQL Server Enterprise (per CPU) — 27,495 USD

A>Итого, 16процессорный сервер — 439,920 USD

A>Итого, 10000 рабочих станций — 8,980,000 USD, то есть более чем в 20 раз больше. На сэкономленные 8.5 миллионов можно отгрохать весьма неплохой датацентр.

Я не понял, за счет чего ты сэкономил 8.5 млн

A>Про ThinClient и Desktop/Application Virtualization рассказывать?


Расскажи на всякий
Re[16]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.12.10 10:42
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>SQL Server Standard (+5CAL) — 898 USD

A>>SQL Server Enterprise (per CPU) — 27,495 USD

A>>Итого, 16процессорный сервер — 439,920 USD

A>>Итого, 10000 рабочих станций — 8,980,000 USD, то есть более чем в 20 раз больше. На сэкономленные 8.5 миллионов можно отгрохать весьма неплохой датацентр.
I>Я не понял, за счет чего ты сэкономил 8.5 млн

Вычел стоимость своего варианта из стоимости твоего варианта. Мой на 8.5 миллионов долларов США дешевле. Это только лицензирование только одного наименования ПО.

A>>Про ThinClient и Desktop/Application Virtualization рассказывать?

I>Расскажи на всякий

Да нет, ты сперва погугли, а потом я отвечу на конкретные вопросы.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Про NoSQL
От: Wolverrum Ниоткуда  
Дата: 05.12.10 12:46
Оценка:
Здравствуйте, Mystic, Вы писали:

M>В общем, в упрощенном виде нечто такое:


M>
M>SELECT items.* FROM items
M>  JOIN item_tags it1 ON items.item_id = it1.item_id
M>  JOIN item_tags it2 ON items.item_id = it2.item_id
M>  LEFT JOIN item_tags it3 ON items.item_id = it3.item_id /* игнорируемый */
M>  ...
M>WHERE 1=1
M>  AND it1.tag_id = @tag1
M>  AND it2.tag_id = @tag2
M>  AND it3.tag_id = @tag3
M>  ....
M>  AND /* Дополнительные условия */
M>ORDER BY  /* агрегатные функции, иногда с кучей IF, подтаблицами, ... */
M>


>3000000... 100000000... 2Gb RAM

(... ~21 байт на запись из них ~10байт на данные)
>Как минимум запас в 10 раз есть. Это по самым скромным оценкам, 10 лет развития проекта
(...т.е. рост примерно до 7000000 items и до 330000000 tags)
>до 100 штук тегов
(...но в среднем — 33)
А мне вот подумалось, если уж данные в транспонированном виде представлять приходится, то почему item_tags
сразу бы не представить как item_tags = {item_id, tag1, tag2 ...}
Например для SQLServer в строку таблицы можно впихнуть не менее 800 Ваших тегов — и все эти теги можно покрыть индексами.
С учетом требований по данным, Вам этих пределов хватит не только на 10 лет вперед, но и промасштабировать систему раз в 10.
Какие жертвы в нашем случае? 2НФ (это почти несущественно — никто не запрещает вести параллельно item_tags2(item_id, tag_id) и синхронно обновлять их), и дисковое пространство — вроде не так уж и много.
Re[9]: Про NoSQL
От: Wolverrum Ниоткуда  
Дата: 05.12.10 12:59
Оценка:
W>(...т.е. рост примерно до 7000000 items и до 330000000 tags)
Прошу щитать это явным арифметическим бредом
Re[12]: Про NoSQL
От: Sinix  
Дата: 05.12.10 14:18
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>FineReader, Promt, Lingvo, Word. Про САПРы вообще молчу.


Как минимум в FR и в ворде есть восстановление документов после сбоя
Но оно, конечно же, не нужно(с).
Всегда ваш, К.О.
Re[21]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 05.12.10 18:11
Оценка:
Здравствуйте, Sinix, Вы писали:

ANS>>И так, ты действительно не видишь где теряется гарантия ACID при использовании полнотекстового поиска.

S>Не вижу. Точнее, ежу понятно, что полнотекстовый индекс как правило обновляется далеко не сразу, и полагаться на результаты поиска для "определяем, какие строчки обновлять/удалять запросом с CONTAINS" будет только последний ССЗБ.

Т.е. менять данные, и при этом ожидать, что твой следующий запрос вернёт их это моветон? Чего только не узнаешь в "Философии".

S>Как это нарушает ACID в отношении собсно данных — .


О. Новый термин — "ACID в отношении собсно данных".
Я же о том и говорю — то, что гдето там далеко внизу заявляется какой-то ACID в современных условиях ничего не значит. Всегда есть какие-то кеши, очереди. А как только появляется две копии одних и тех же данных тут же появляется проблема консистентности (в терминах CAP). В результате, на вход поступают данные, обрабатываются, пишуться в ACID-хранилище, потом приходят новые данные, а старых в хранилище не видно. Но везде один сплошной ACID, да.
И я не вижу ничего плохого в том, что появляются системы, которые дают только те гарантии которые можно обеспечить физически и которые действительно важны. Т.е., я уверен, что CAP важнее ACID. При этом, если внизу нужен движок понимающий SQL запросы, то нужно его использовать. Но разбивать лоб отбивая поклоны перед книгой стандартов на SQL это перебор.

S>Чем FTS отличается от асинхронной очереди Service Broker'а/прочих способов отложенной обработки данных?


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

S>Я ещё раз напомню контекст.

S>

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

А что не так? Из CAP — консистентности нет. Попробуешь обеспечить её потеряешь доступность. Можно ли получить партишенинг вот только не знаю (в случае MSSQL, поскольку вы все о нём, имхо).

ANS>>и считаешь, что можно Durability обеспечить только в рамках одного дискового массива?

S>Можно. Вы ведь про это durability:

Да.

S>Если да — какое глобальное преимущество имеет несколько рейдов перед одним? Чур, настолько глобальное, чтобы подтвердить "один raid — это не durability". Потому что если докапываться до каждой буковки, durability невозможно в уничтожимой вселенной


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

S>С практической точки зрения, однако, durability означает минимальное соотношение количества "чорд! Где мои данные!" к количеству сбоев в системе. И да, во взрослых СУБД оно обеспечивается уровнем выше — failower cluster'ами / log shipping'ом.


См. CAP-теорему. И, тогда, не ясно к чему кивать, что у них даже Durability нету, если всё равно прийдётся строить кластер, со всеми вытекающими.

S>


S>И далее по тексту — пользователи настолько идиоты, что давай им транзакционность, не давай — никакой разницы.


Пользователи точно заметят. А вот программистам сто процентов всё равно.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 05.12.10 18:11
Оценка:
G>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)

G>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.



Зачем к дереву обращаться полнотекстовым поиском?

G>Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы предпочитаете пользоваться всяким г... которое обрабатывает только полуструктурированные данные, и то не лучшим образом.


G>ЗЫ. Я намеренно не вешаю тут ярлыков SQL-NoSQL, чтобы путаниицы не возникало.

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

Только вот какие хранилища мы будем рассматривать? Они в NoSQL разные


dmitriid.comGitHubLinkedIn
Re[18]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.12.10 18:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Не совсем понятно, как можно вычесть 8.9 из 10 млн и получить 8.5 млн в остатке.


Ещё раз, для гениев арфиметики.

Минимальаня версия без ораничений на размер базы дыннх — SQL Server Standard стоит 898 USD
Серверная версия для централизованного хранения SQL Server Enterprise стоит 27,495 USD на процессор.

Итого, лицензии на 16процессорный сервер обходятся 439,920 USD
Итого, лицензии на 10000 рабочих станций с локальными БД 8,980,000 USD, то есть более чем в 20 раз больше.

8,980,000 — 439,920 = 8,540,080

Если вы не в состоянии осилить эти вычисления, говорить нам не о чём.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 05.12.10 18:29
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать?


Сколько раз говорить о том, что нет чтения данных в пямять. Индексация занимает 15 минут. Но при этом данные на диск не пишутся. После чего я работаю с памятью.
Re[9]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 05.12.10 18:44
Оценка:
Здравствуйте, Wolverrum, Вы писали:

W>Какие жертвы в нашем случае? 2НФ (это почти несущественно — никто не запрещает вести параллельно item_tags2(item_id, tag_id) и синхронно обновлять их), и дисковое пространство — вроде не так уж и много.


Как минимум еще надо все это поддерживать. Во-вторых, в самом тяжелом случае, когда надо вернуть миллион/полтора записей, одни только вычисления агрегатных функций, написанные на чистом C, занимают 50% времени. Т. е. если предположить, что поиск данных занимает нуль секунд, а производительность вычислений агрегатных функций совпадает с чистым C, то мы ускоримся в два раза.

И в третьих, как тогда писать SQL-запросы: Если у нас items имеет вид item_id, tag1, tag2, tag3, ..., tag100
то как выбрать все записи, у которых есть в tag встречается и 10 и 25? Писать

WHERE (tag1=10 OR tag2=10 or tag3=10 OR ... ) AND (tag1=25 OR tag2=25 or tag3=25 OR ... )


грустно
Re[19]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 19:15
Оценка:
Здравствуйте, adontz, Вы писали:

A>8,980,000 — 439,920 = 8,540,080


A>Если вы не в состоянии осилить эти вычисления, говорить нам не о чём.


Ты всерьез решил что на 10 тыс пользователей хватит одного 16процессорного комплекта ?

Допустим, каждый из проессоров как нынче модно, имеет 4 ядра. Итого — 156 пользователей на одно ядро.

На десктопе не хватает 4х ядер, а на сервере всем вдруг хватит 1/156й ядра.

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

Вот так чудеса

И да — если ты не в состоянии осилить эти вычисления, говорить нам не о чём.
Re[21]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 19:53
Оценка:
Здравствуйте, adontz, Вы писали:

I>>Ты всерьез решил что на 10 тыс пользователей хватит одного 16процессорного комплекта ?

I>>Допустим, каждый из проессоров как нынче модно, имеет 4 ядра. Итого — 156 пользователей на одно ядро.

A>А ядра на декстопе и сервере одинаковые, ага.


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

>И производительность SQL сервера в гораздо больше степени зависит от ОЗУ, чем от количества ядер. Я тебе даже больше скажу, на SQL сервер выключение HyperThreading увеличивает производительность. Но чтобы такие вещи знать, надо с этим работать, а у тебя в голове вместо опыта только нелепые домыслы. Прости, общаться с тобой на данную тему совершенно скучно и утомительно.


Объясни, за каким хреном ты приплел сюда SQL Server ? Если прога вычисляет чего то больше 5 секунд, как ты говорил, то как SQL сервер здесь поможет в плане ускорения ?

Заметь, ты начал считать деньги даже не обратив внимания на конкретную задачу
Re[22]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.12.10 19:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>А ядра на декстопе и сервере одинаковые, ага.

I>То есть, ты таки хочешь сказать, что серверное ядро будет в 600 раз производительнее десктопного ?

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

I>Объясни, за каким хреном ты приплел сюда SQL Server?


Мы тут SQL vs. NoSQL обсуждаем.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[23]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 20:09
Оценка:
Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Ikemefula, Вы писали:


A>>>А ядра на декстопе и сервере одинаковые, ага.

I>>То есть, ты таки хочешь сказать, что серверное ядро будет в 600 раз производительнее десктопного ?

A>За счёт увеличенного размера кеша при примитивной обработке большого объёма данных? Вполне может.


Чушь. И кто тебе сказал что обработка примитивная ?

Да, наверняка на этих 10000 станциях данные дублировались...

I>>Объясни, за каким хреном ты приплел сюда SQL Server?


A>Мы тут SQL vs. NoSQL обсуждаем.


Это я понимаю. Но вроде очевидно, что на десктоп никто не будет ставить полноценный сервер.
Re[24]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.12.10 20:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>За счёт увеличенного размера кеша при примитивной обработке большого объёма данных? Вполне может.

I>Чушь. И кто тебе сказал что обработка примитивная?

Примитивная, то есть упираемся в диски, а не в CPU.

I>Да, наверняка на этих 10000 станциях данные дублировались...


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

I>>>Объясни, за каким хреном ты приплел сюда SQL Server?

A>>Мы тут SQL vs. NoSQL обсуждаем.
I>Это я понимаю. Но вроде очевидно, что на десктоп никто не будет ставить полноценный сервер.

Да нет, это ты рассказывал по 10000 рабочих станций на которых что-то параллельно считается, не я. Если тебе очевидно, то ветку закрываем за очевидностью.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[25]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.12.10 20:24
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>За счёт увеличенного размера кеша при примитивной обработке большого объёма данных? Вполне может.

I>>Чушь. И кто тебе сказал что обработка примитивная?

A>Примитивная, то есть упираемся в диски, а не в CPU.


Задачи вроде "коммивояжера", это примитивная обработка ?

I>>Да, наверняка на этих 10000 станциях данные дублировались...


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


Дискового пространства надо меньше. Процессорного времени — примерно столько же. Потому надо придумать, куда деть 600-кратную разницу в процессорном времени.

I>>>>Объясни, за каким хреном ты приплел сюда SQL Server?

A>>>Мы тут SQL vs. NoSQL обсуждаем.
I>>Это я понимаю. Но вроде очевидно, что на десктоп никто не будет ставить полноценный сервер.

A>Да нет, это ты рассказывал по 10000 рабочих станций на которых что-то параллельно считается, не я. Если тебе очевидно, то ветку закрываем за очевидностью.


"что-то параллельно считается" — где ты увидел такое ?

Ты похоже придумал задачу, решил и на этой основе утверждаешь что реальные задачи будут решаться так же легко.
Re[13]: Про NoSQL
От: alpha21264 СССР  
Дата: 05.12.10 21:01
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Как минимум в FR и в ворде есть восстановление документов после сбоя


Сначала давай решим, есть ли там SQL.

Течёт вода Кубань-реки куда велят большевики.
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.12.10 22:06
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:


G>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


A>FineReader, Promt, Lingvo, Word. Про САПРы вообще молчу.

1)Там не используются БД
2)Отсутствие Durability означает что после нажаnия Save документ может быть не сохранен.

Со вторым что будете делать?
Re[10]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.12.10 22:24
Оценка:
Здравствуйте, Mamut, Вы писали:

G>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)


G>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.



M>Зачем к дереву обращаться полнотекстовым поиском?


Ты внимательно прочитал что я написал?
К каким данным только полнотекстовый поиск позволяет запросы делать?


G>>Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы предпочитаете пользоваться всяким г... которое обрабатывает только полуструктурированные данные, и то не лучшим образом.


G>>ЗЫ. Я намеренно не вешаю тут ярлыков SQL-NoSQL, чтобы путаниицы не возникало.

G>>Впредь рекомендую рассматривать под терминами NoSQL только хранилища, потому что методы обработки зависят в первую очередь от самих данных, а не от того как они хранятся.
M>Только вот какие хранилища мы будем рассматривать? Они в NoSQL разные
Любые (все), понятно что они все разные, вот и будем конкретные примеры смотреть.
Это у SQLных баз примерно паритет по фичам, NoSQL сильно неоднородны.
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.12.10 22:28
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


G>>Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать?


M>Сколько раз говорить о том, что нет чтения данных в пямять. Индексация занимает 15 минут.

И как часто она выполняется?

M>Но при этом данные на диск не пишутся. После чего я работаю с памятью.

До следующей переиндексации.

Теперь открою еще одну тайну. Работа субд аналогична тому что ты будешь делать переиндексацию на каждое изменение.

Поэтому SQL уже порвал твой код в разы.
Re[15]: Про NoSQL
От: Cyberax Марс  
Дата: 05.12.10 22:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Со вторым что будете делать?

C>>Ничего, всем плевать.
G>Пока это не касается бабла. Как только кто-либо попадет на бабло из-за несохраненности данных сразу станет не плевать.
Для бабла можно сделать отдельную РБД, с блекджэком и распределёнными транзакциями. Никто же не говорит, что NoSQL нужно прямо для всего использовать.

Бабло — вообще неинтересная задача, так как собрать систему, обрататывающую все транзакции даже для крупнейших банков, сейчас можно путём нескольких телефонных звонков и пары-тройки чеков в несколько миллионов долларов. У Microsoft есть классная статья: http://research.microsoft.com/apps/pubs/default.aspx?id=64534

Вот быстрые деньги, то бишь high-speed trading — это уже интереснее. И там как раз никаким SQL'ем и не пахнет. А для durability чаще всего используют многократную репликацию данных в памяти или подобные кастомные решения.

G>Хотя адепты NoSQL все равно расскажут что всем плевать.

Ага.
Sapienti sat!
Re[22]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.12.10 23:27
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Тем, что FTS это не способ отложенной обработки данных, а альтернативный интерфейс к этим самым данным. Вот г-н gandjustas заявил, что FTS, оказывается, sql-ней не бывает. А я говорю, что вот нам FTS подходил подходил, и не подошел. Потому что, не возможно консистентность данных обеспечить даже в пределах одной сессии. А это, имхо, необходимое свойство, при котором можно под систему программировать.


Что ты имеешь ввиду под словом консистентность? Вот меня учили что это свойство выполнимости всех ограничений и проверок по завершению транзакции.

Если ты имеешь ввиду консистентность в том виде как о ней говорится в CAP теореме, то её ты с полнотекстовым поиском никак не добьешься, если не променяешь на доступность.

В SQL Server например можешь запускать вручную построение полнотекстового индекса и до его окончания не пропускать запросы на сервер. Вот тебе будет A-C tradeoff.
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.12.10 23:30
Оценка:
Здравствуйте, 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 чаще всего используют многократную репликацию данных в памяти или подобные кастомные решения.

Там вообще записью на диск не пахнет, медленные слишком диски.
Re[26]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 06.12.10 06:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>Примитивная, то есть упираемся в диски, а не в CPU.

I>Задачи вроде "коммивояжера", это примитивная обработка?

Зависит от параметров.

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

I>Дискового пространства надо меньше. Процессорного времени — примерно столько же. Потому надо придумать, куда деть 600-кратную разницу в процессорном времени.

Зачем столько же процессорного времени для обработки меньшего количества данных?

A>>Да нет, это ты рассказывал по 10000 рабочих станций на которых что-то параллельно считается, не я. Если тебе очевидно, то ветку закрываем за очевидностью.

I>"что-то параллельно считается" — где ты увидел такое ?

То есть они что, последовательно работают? Ну тогда заменяем одной рабочей станцией.

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


О да, вот ты лично видел 10000 активно что-то считающих компьютеров. Фотки не покажешь? Твой пример реальной задачей и не пахнет.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[23]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 07:05
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Что ты имеешь ввиду под словом консистентность? Вот меня учили что это свойство выполнимости всех ограничений и проверок по завершению транзакции.


G>Если ты имеешь ввиду консистентность в том виде как о ней говорится в CAP теореме,


Именно. Я в том посте чуть выше это и написал.

G>то её ты с полнотекстовым поиском никак не добьешься, если не променяешь на доступность.


Я об этом и говорю. А вы мне в ответ, что это нормальное поведение для SQL.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 07:19
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ты вообще о чем? Где теряются гарантии, покажешь?


Тут
Автор: gandjustas
Дата: 06.12.10
.

ANS>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется.

G>Покажи где он не выполнгяется.

ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 07:29
Оценка:
G>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)

G>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.



M>>Зачем к дереву обращаться полнотекстовым поиском?


G>Ты внимательно прочитал что я написал?



Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»

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


G>К каким данным только полнотекстовый поиск позволяет запросы делать?


Собственно, к тексту


dmitriid.comGitHubLinkedIn
Re[12]: Про NoSQL
От: Курилка Россия http://kirya.narod.ru/
Дата: 06.12.10 07:32
Оценка:
Здравствуйте, Mamut, Вы писали:

G>>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)


G>>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.



M>>>Зачем к дереву обращаться полнотекстовым поиском?


G>>Ты внимательно прочитал что я написал?



M>Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»


M>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?



Дим, дерево не есть структура?
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 07:34
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

G>ОК. Вот у тебя есть MS SQL Server, покажи подтверждение своим словам.

Но как??!

G>Репликация не поможет если данные не сохранены.


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


???

G>В случае наличия Durability усилия клиента не требуются.


Импосибиль. Если говорить, именно о Durability из ACID, а не о Consistency из CAP (хе-хе).

ANS>>PS. Кстати у упомненных выше 80%
Автор: gandjustas
Дата: 03.12.10
проектов Durability не нужна.

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

Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 07:44
Оценка:
G>>>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)

G>>>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.



M>>>>Зачем к дереву обращаться полнотекстовым поиском?


G>>>Ты внимательно прочитал что я написал?



M>>Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»


M>>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?



К>Дим, дерево не есть структура?


Структура которого неизвестна

А черт, не то процитировал оказывается

2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
3)неструктурированные: текст, blob


Я имел в виду полуструктурированные


dmitriid.comGitHubLinkedIn
Re[4]: Про NoSQL
От: Michael7 Россия  
Дата: 06.12.10 07:45
Оценка:
Здравствуйте, Фанатик, Вы писали:

Ф>Вывод: "NoSQL" — новомодное слово, которое совершенно необязательно понимать.


NoSQL скорее маркетинговое слово, в противовес SQL, которое стало почти что синонимом СУБД.
Re[9]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 07:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы


Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL?

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


Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 07:54
Оценка:
Здравствуйте, adontz, Вы писали:

A>А ядра на декстопе и сервере одинаковые, ага.


Обычно на сервере медленнее.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[24]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 07:55
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Что ты имеешь ввиду под словом консистентность? Вот меня учили что это свойство выполнимости всех ограничений и проверок по завершению транзакции.


G>>Если ты имеешь ввиду консистентность в том виде как о ней говорится в CAP теореме,


ANS>Именно. Я в том посте чуть выше это и написал.


G>>то её ты с полнотекстовым поиском никак не добьешься, если не променяешь на доступность.


ANS>Я об этом и говорю. А вы мне в ответ, что это нормальное поведение для SQL.


Да. Потому что ACID не говорит о консистентности в таком виде.
Re[20]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 07:56
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Ты вообще о чем? Где теряются гарантии, покажешь?


ANS>Тут
Автор: gandjustas
Дата: 06.12.10
.


ANS>>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется.

G>>Покажи где он не выполнгяется.

ANS>ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем?


Можем. Select по ключу.
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 07:57
Оценка:
Здравствуйте, Mamut, Вы писали:

G>>>>2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)


G>>>>Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.



M>>>Зачем к дереву обращаться полнотекстовым поиском?


G>>Ты внимательно прочитал что я написал?



M>Внимательно: « к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.»


M>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?

А ввше прочитай. Если их можно представить в виде дерева элементов, то данные становятся полуструктурированными. К ним можно xpath например обращаться.


G>>К каким данным только полнотекстовый поиск позволяет запросы делать?

M>Собственно, к тексту
Прочитай еще раз внимательно.
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 08:03
Оценка:
Здравствуйте, 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%
Автор: gandjustas
Дата: 03.12.10
проектов Durability не нужна.

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

ANS>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?

Ни в чем. Другой случай. Одна машина (!)
MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
Re[10]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 08:05
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы


ANS>Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL?

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

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


ANS>Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.

Конкретнее.
Re[25]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 08:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

ANS>>Я об этом и говорю. А вы мне в ответ, что это нормальное поведение для SQL.


G>Да. Потому что ACID не говорит о консистентности в таком виде.


Убил.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 08:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Здравствуйте, gandjustas, Вы писали:
G>>>Ты вообще о чем? Где теряются гарантии, покажешь?
ANS>>Тут
Автор: gandjustas
Дата: 06.12.10
.

ANS>>>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется.
G>>>Покажи где он не выполнгяется.
ANS>>ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем?
G>Можем. Select по ключу.

... и съел мой мозг
Автор: Andrei N.Sobchuck
Дата: 06.12.10
. А мог бы сказать, что не нужно читать то, что ты только записал. Ведь оно и так у тебя есть.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 08:10
Оценка:
M>>Если у нас неструктурированные данные представлены в виде дерева лементов, то почему бы с ними не работать, как с деревом?
G>А ввше прочитай. Если их можно представить в виде дерева элементов, то данные становятся полуструктурированными. К ним можно xpath например обращаться.

Да, я тут исправился: http://rsdn.ru/forum/philosophy/4066615.1.aspx
Автор: Mamut
Дата: 06.12.10


dmitriid.comGitHubLinkedIn
Re[17]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 08:13
Оценка:
ANS>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?
G>Ни в чем. Другой случай. Одна машина (!)
G>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
G>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?

Берем такой NoSQL, который имеет такой же лог

Но вообще-то да. Обычно NoSQL'и теряют как минимум одну из букв в ACID


dmitriid.comGitHubLinkedIn
Re[17]: Вдогонку
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 08:15
Оценка:
ANS>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?
G>Ни в чем. Другой случай. Одна машина (!)
G>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
G>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?

OrientDB иммет ACID
Neo4J позволяет ACID

Всякие ОО-базы тоже позволяют. Тут: http://nosql-database.org/


dmitriid.comGitHubLinkedIn
Re[22]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 08:22
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Ты вообще о чем? Где теряются гарантии, покажешь?
ANS>>>Тут
Автор: gandjustas
Дата: 06.12.10
.

ANS>>>>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется.
G>>>>Покажи где он не выполнгяется.
ANS>>>ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем?
G>>Можем. Select по ключу.

ANS>... и съел мой мозг
Автор: Andrei N.Sobchuck
Дата: 06.12.10
. А мог бы сказать, что не нужно читать то, что ты только записал. Ведь оно и так у тебя есть.


Нужно — читай. Тебе никто не мешает. Ты только полнотекстовым поиском не сможешь сразу ничего найти, если сам не приложишь усилия по его построению.
У тебя тут есть выбор.
Re[18]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 08:23
Оценка:
Здравствуйте, Mamut, Вы писали:

ANS>>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?

G>>Ни в чем. Другой случай. Одна машина (!)
G>>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
G>>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?

M>Берем такой NoSQL, который имеет такой же лог

Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.
Re[18]: Вдогонку
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 08:26
Оценка:
Здравствуйте, Mamut, Вы писали:


ANS>>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?

G>>Ни в чем. Другой случай. Одна машина (!)
G>>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
G>>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?

M>OrientDB иммет ACID

M>Neo4J позволяет ACID

M>Всякие ОО-базы тоже позволяют. Тут: http://nosql-database.org/


Ну значит их и стоит использовать.

Я бы например не решился поднимать решение на NoSQL без Durability на одной машине. А поднимать сразу кластер — как-то накладно.
50% моих решений я без геморроя разворачиваю на shared хостинге, там уж точно NoSQL кластеров не видать.
Re[18]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 08:31
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


ANS>>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql?

G>>Ни в чем. Другой случай. Одна машина (!)
G>>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало.
G>>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?

ANS>Я просто намекну, что Durability даёт _абсолютную_ гарантию.

Что ты имеешь ввиду?

ANS>Второе, ты утверждал, что сможешь понять, какие именно транзакции пропали за эти 5 сек. Как?

Где я такого утверждал? Я вообще catastrophic failure не рассматривал, это ты начал.
А вот незавершение дисковых операций при выключении компа, аппаратные ошибки итп. Особенно в ситуации где ты арендуешь железо — очень вероятны.
Re[19]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 09:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.


Transaction Log — это не единственная реализация durability, это оптимизация. Более того, как я показал
Автор: Andrei N.Sobchuck
Дата: 06.12.10
, durability оно не обеспечивает.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[20]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 09:03
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.


ANS>Transaction Log — это не единственная реализация durability, это оптимизация.

Не понимаю что ты хочешь сказать. Чуть менее чем во всех современных СУБД durability обеспечивается логом транзакций.

ANS>Более того, как я показал
Автор: Andrei N.Sobchuck
Дата: 06.12.10
, durability оно не обеспечивает.

Ты там ничего не показал.
Re[21]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 10:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.


ANS>>Transaction Log — это не единственная реализация durability, это оптимизация.

G>Не понимаю что ты хочешь сказать. Чуть менее чем во всех современных СУБД durability обеспечивается логом транзакций.

Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.

ANS>>Более того, как я показал
Автор: Andrei N.Sobchuck
Дата: 06.12.10
, durability оно не обеспечивает.

G>Ты там ничего не показал.

Либо у тебя один винт и нету никакой D. Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично. Или практика философов не интересует?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: Вдогонку
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 10:02
Оценка:
M>>OrientDB иммет ACID
M>>Neo4J позволяет ACID

M>>Всякие ОО-базы тоже позволяют. Тут: http://nosql-database.org/


G>Ну значит их и стоит использовать.


G>Я бы например не решился поднимать решение на NoSQL без Durability на одной машине. А поднимать сразу кластер — как-то накладно.


Это камень в огород MongoDB Они вообще гарантируют отсутствие Durability на одной машине

G>50% моих решений я без геморроя разворачиваю на shared хостинге, там уж точно NoSQL кластеров не видать.


Это точно.


dmitriid.comGitHubLinkedIn
Re[15]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 06.12.10 10:12
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать?

M>>Сколько раз говорить о том, что нет чтения данных в пямять. Индексация занимает 15 минут.
G>И как часто она выполняется?

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

G>Теперь открою еще одну тайну. Работа субд аналогична тому что ты будешь делать переиндексацию на каждое изменение.

G>Поэтому SQL уже порвал твой код в разы.

Да он порвал мой код в разы, но на другой задаче Ибо требование делать переиндексацию на каждое изменение не критично нисколько. А вот решить именно нашу задачу с использованием SQL никто у нас не смог. Что говорит о том, что писать NoSQL проще. По крайней мере для некоторых.
Re[22]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 10:18
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.


Кстати. redis:

* Fsync() every time a new command is appended to the append log file. Very very slow, very safe.
* Fsync() one time every second. Fast enough, and you can lose 1 second of data if there is a disaster.
* Never fsync(), just put your data in the hands of the Operating System. The faster and unsafer method.

Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 10:51
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


G>>>>Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать?

M>>>Сколько раз говорить о том, что нет чтения данных в пямять. Индексация занимает 15 минут.
G>>И как часто она выполняется?

M>Раз в сутки. К принципе можно запускать каждый час, только это никому не надо и нисколько не критично


G>>Теперь открою еще одну тайну. Работа субд аналогична тому что ты будешь делать переиндексацию на каждое изменение.

G>>Поэтому SQL уже порвал твой код в разы.

M>Да он порвал мой код в разы, но на другой задаче Ибо требование делать переиндексацию на каждое изменение не критично нисколько. А вот решить именно нашу задачу с использованием SQL никто у нас не смог. Что говорит о том, что писать NoSQL проще. По крайней мере для некоторых.

А причем тут NoSQL? Ты просто свел задачу к той, которую БД не умеет решать, и написал решение сам.
Кстати полнотекстовый поиск не пробовал использовать?
Re[21]: Вдогонку
От: Mamut Швеция http://dmitriid.com
Дата: 06.12.10 11:35
Оценка:
M>> Это камень в огород MongoDB Они вообще гарантируют отсутствие Durability на одной машине

AB>

The v1.8 release of MongoDB will have single server durability.


AB>Ну и периодический fsync, который по умолчанию каждые 60 секунд, тоже помогает.


В общем, NoSQL постепенно приходит к durability Особенно в наиболее известных/распространенных проектах


dmitriid.comGitHubLinkedIn
Re[22]: Вдогонку
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 11:51
Оценка:
Здравствуйте, Mamut, Вы писали:

M>В общем, NoSQL постепенно приходит к durability Особенно в наиболее известных/распространенных проектах


Это и понятно. Зародилось оно в условиях когда есть кластер. А там, имхо, синхронная репликация и быстрее и гораздо надёжнее, чем какие-то там винты. А людям хочется эти сервера локально поднимать. Хотя, мне кажется, что будущее тут это БД-как-сервис.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: Про NoSQL
От: Wolverrum Ниоткуда  
Дата: 06.12.10 11:52
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Как минимум еще надо все это поддерживать. Во-вторых, в самом тяжелом случае, когда надо вернуть миллион/полтора записей, одни только вычисления агрегатных функций, написанные на чистом C, занимают 50% времени. Т. е. если предположить, что поиск данных занимает нуль секунд, а производительность вычислений агрегатных функций совпадает с чистым C, то мы ускоримся в два раза.


Ну... А зачем кубы придумали? На худой конец — триггеры.

M>И в третьих, как тогда писать SQL-запросы: Если у нас items имеет вид item_id, tag1, tag2, tag3, ..., tag100

M>то как выбрать все записи, у которых есть в tag встречается и 10 и 25? Писать
M>
M>WHERE (tag1=10 OR tag2=10 or tag3=10 OR ... ) AND (tag1=25 OR tag2=25 or tag3=25 OR ... )
M>

Я же обратил внимание на этот момент:
FROM ...item_tags2 S where S.tag IN (10, 25) ...


M>грустно

Да, грустно.
Re[11]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 11:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

ANS>>Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL?

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

Хм. Странно о чем то спорить не дав дефиниции терминам.

G>Конкретнее.


Обобщу — напишу.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[27]: Про NoSQL
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.12.10 12:12
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>Примитивная, то есть упираемся в диски, а не в CPU.

I>>Задачи вроде "коммивояжера", это примитивная обработка?
A>Зависит от параметров.

На самом деле "коммивояжер" это сильно упрощенный пример. Реально алгоритмы много сложнее.

I>>Дискового пространства надо меньше. Процессорного времени — примерно столько же. Потому надо придумать, куда деть 600-кратную разницу в процессорном времени.


A>Зачем столько же процессорного времени для обработки меньшего количества данных?


Поменял пару параметров в модели, сколько байт изменилось ? Доли процента. А рассчет пойдет совершенно иначе.

A>>>Да нет, это ты рассказывал по 10000 рабочих станций на которых что-то параллельно считается, не я. Если тебе очевидно, то ветку закрываем за очевидностью.

I>>"что-то параллельно считается" — где ты увидел такое ?

A>То есть они что, последовательно работают? Ну тогда заменяем одной рабочей станцией.


Инженеры работают каждый над своей задачей.

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


A>О да, вот ты лично видел 10000 активно что-то считающих компьютеров. Фотки не покажешь? Твой пример реальной задачей и не пахнет.


Я привел ажно два примера, из которых должно быть ясно что к чему.
Re[24]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 12:34
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


ANS>>>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.

G>>Бред. Как ты откатывать транзакцию будешь без лога?

ANS>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php

ANS>Ты путаешь "UNDO log" и лог транзакций.

нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?

Как раз для postgresql этот undo log является оптимизацией, а transaction log является вполне стандартным средством обеспечения Атомарности и Долговечности транзакций.

G>>Ты неверно понимаешь слово Durability.


ANS>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно.

А если нет пользователя? Если это автоматическия система? Она то думает что все хорошо, а на деле все плохо.

ANS>>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично.

G>>ACID вообще не коррелирует с CAP.

ANS>D в ACID == C в CAP.

Да ну? C в CAP — одинаковость данных на всех узлах.
Вообще CAP никоим образом не распространяется на один узел, а acid не говорит о множестве узлов.
Если че, даже сами разработчики СУБД говорят не делать распределенных транзакций.

ANS>Но не в этом дело. Дело в том, что с практической точки зрения люди всё равно заботятся о доступности.

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

ANS>>>Или практика философов не интересует?

G>>Практика это зачастую одна машина с БД, а CAP и мега-распределенные системы это теория.

ANS>Угу угу
Автор: Andrei N.Sobchuck
Дата: 04.12.10
. А потом ставят какой-нибудь memcached и работают с ним так: http://www.majordojo.com/2007/03/memcached-howto.php . То что всё иногда ломается — так сделаем круглые глаза, у нас же ACID и всё гарантировано. Почему ты запрещаешь сделать инструмент, который убережёт от таких ошибок?

Опять ты повторяшь недоказанные утверждения.

Для начала докажи что:
1)Durability не важен, даже если на одной машине хранилище работает.
2)Пользователей больше заботит Consistency между узлами. (хотя тут тебе контрпример
Автор: Mystic
Дата: 06.12.10
уже привести можно)

Практика показывает что надо иметь возможность выбирать между Consistency и Availability, большинтсво NoSQL хранилищ не дают такого выбора, а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 12:36
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


ANS>>>Начнём с простого. Что такое SQL БД и чем она отличается от NoSQL?

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

ANS>Хм. Странно о чем то спорить не дав дефиниции терминам.

Я уже давал читай внимательнее.
NoSQL — хранилища, которые так себя позиционируют.
SQL — современные, как говорится mature, СУБД общего назначения.
Re[17]: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 06.12.10 12:53
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А причем тут NoSQL? Ты просто свел задачу к той, которую БД не умеет решать, и написал решение сам.


Собственно говоря, не я сводил задачу. Я старался изначально удержать все в рамках SQL. Требования поступали от руководства. Так что в итоге мне пришлось сказать: как на SQL это решить я не знаю. Но могу переписать все на C++. Мне сказали: пиши

G>Кстати полнотекстовый поиск не пробовал использовать?


Да, использовался sphinx. Вообще, проблема поиска стояла несколько месяцев. Было несколько попыток найти параллельные решение. В итоге победил C++.
Re[25]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 13:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Бред. Как ты откатывать транзакцию будешь без лога?

ANS>>http://archives.postgresql.org/pgsql-hackers/2007-10/msg01028.php
ANS>>Ты путаешь "UNDO log" и лог транзакций.
G>нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?

В Oracle есть, в MySql есть. Значит они видят какой-то смысл? Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные.

G>Как раз для postgresql этот undo log является оптимизацией, а transaction log является вполне стандартным средством обеспечения Атомарности и Долговечности транзакций.


Я не спорю с тем, что это стандартная техника. Просто это не единственная техника.

G>>>Ты неверно понимаешь слово Durability.


ANS>>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно.

G>А если нет пользователя? Если это автоматическия система? Она то думает что все хорошо, а на деле все плохо.

Автоматическая система на единственном нерабочем компьютере думает, что всё хорошо? Или концепция поменялась и у нас уже не один компьютер?

ANS>>>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично.

G>>>ACID вообще не коррелирует с CAP.

ANS>>D в ACID == C в CAP.

G>Да ну?

Истинно глаголю.

G>C в CAP — одинаковость данных на всех узлах.


Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable".

G>Для начала докажи что:

G>1)Durability не важен, даже если на одной машине хранилище работает.

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

G>Практика показывает что надо иметь возможность выбирать между Consistency и Availability,


Ну наконец-то ты признал, что ACID в пролёте.

G>большинтсво NoSQL хранилищ не дают такого выбора,


Большинство NoSql поддерживают либо ту или иную пару. А некоторые позволяют это поведение сконфигурировать.

G>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?


Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 13:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


ANS>>>Хм. Странно о чем то спорить не дав дефиниции терминам.

G>>Я уже давал читай внимательнее.
G>>NoSQL — хранилища, которые так себя позиционируют.
G>>SQL — современные, как говорится mature, СУБД общего назначения.

ANS>Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально.

Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Re[24]: Про NoSQL
От: Sinix  
Дата: 06.12.10 14:54
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт.


Это стёб, я надеюсь?
Вон из профессии!
Re[27]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 15:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Кстати есть сомнение что понимание CAP у тебя правильное. То что понимание ACID у тебя неправильное я уже убедился.


Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
нашел прекрасное замечание: Consistency означает атомарность операций.
То есть суть теоремы сводится к тому что невозможно одновременно достигнуть:
1)атомарности (выполняется или полностью или не выполняется вообще)
2)доступности (всегда отвечает на запрос)
3)отказоустойчивости (нарушение работоспособности одного узла не приводит к нарушении работы системы и потере данных)

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

Берем такую штуку как SQL Azure. Известно что она Fault Tolerant и Available (это гарантирует Microsoft большим количеством девяток), наружу выставлен SQL интерфейс, который поддерживает ACID, а соотвественно атомарность изменений.

Все три свойства на месте, в чем прикол? Или CAP работает когда к любому узлу системы могут "снаружи" обратиться клиенты?
Re[27]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 16:34
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>нету UNDO log в базе. Да и какой в нем смысл если он дублирует Transactin log?


ANS>>В Oracle есть, в MySql есть.

G>Доказательства?

http://dev.mysql.com/doc/refman/5.0/en/innodb-multi-versioning.html — тут пишут есть.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm — тут пишут как им управлять. Раз можно управлять — значит оно есть.

ANS>>Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные.

G>Снова бред говоришь. Если я поставлю Read Uncommited я увижу незакомиченные данные. Угадай почему я их увижу.

Откуда "Read Uncommited" в версионнике?

ANS>>Я не спорю с тем, что это стандартная техника.

G>

G>Durability обеспечивается не логом транзакций...

G>Твои слова.

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

ANS>>Просто это не единственная техника.

G>В СУБД эта техника называется "версионность" или SNAPSHOTS. Жопа в том что она не обеспечивает сериализуемости транзакций.

"версионность" к наличию или отсутствию лога никакого отношения не имеет.

G>Причем тут "нерабочий компьютер"? Компьютер вполне рабочий. Но вот возникает ошибка записи на диск по не важно какой причине. Как приложение узнает что ошибка произошла? Ты предложишь перечитывать данные после каждой операции записи? Ты же понимаешь что это бредовая идея?


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

ANS>>Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable".

G>Дай ссылку на сие откровение.

Зачем ссылка, это ж логика.

G>Тут говорят что C в CAP это A в ACID.


Хм. Он ссылается на доказательство Gilbert and Lynch, а в этой работе написано:

Atomic or linearizable consistency ... there must exist a total order on all operations such that each operations looks like as if it were completed at a single instant.

Я не уверен, что это соответсвует A в ACID. Мне кажется, что гарантия прочитать записанное это "D". Более того, в ACID, вроде как, не оговаривается наличие линейного порядка между операциями с БД (и ты сказал, требования упорядоченности нет
Автор: gandjustas
Дата: 06.12.10
). Хотя оно может неявно вытекать из какого-то требования. Я пока считаю, что это (неявно) вытекает из D. Но, х.з.

G>А википедия говорит что Consistency (all nodes see the same data at the same time).

G>Причем во втором определении явная дыра. Как только твое приложение (оно ведь тоже "узел") считало данные и не блокирует их то Consitency больше нет, а если блокируешь, то гарантированно Availability нет. Получается CAP-теорема редуцировалась до CA теоремы.

Не получается. Просто ты плавно приходишь к пониманию того, почему ACID-транзакции не реализуют в таких системах.

G>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.

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

G>Причем реально вырождается это в CA-tradeoff.


Нет.

G>И как раз никто не старается выполнять Consistency.


Еще раз. Есть системы и CP и AP. Причем примеры есть даже в презентации Брюера.

G>>>большинтсво NoSQL хранилищ не дают такого выбора,

ANS>>Большинство NoSql поддерживают либо ту или иную пару. А некоторые позволяют это поведение сконфигурировать.
G>Да нихрена они не поддерживают, только делают вид что поддерживают, причем настолько насколько понимают суть проблем (а на практике понимают плохо).

— Дорогой, будь осторожнее. Там какой-то идиот по встречке едет.
— Один идиот? Да их тут тысячи.

G>>>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?

ANS>>Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего.
G>Еще раз, если смотреть комплекс "приложение-субд", то всегда присутствует CA-tradeoff.

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

G>Кстати есть сомнение что понимание CAP у тебя правильное. То что понимание ACID у тебя неправильное я уже убедился.


Это
Автор: Andrei N.Sobchuck
Дата: 06.12.10
я уже понял
Автор: Andrei N.Sobchuck
Дата: 06.12.10
.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Про NoSQL
От: alpha21264 СССР  
Дата: 06.12.10 17:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>1)Там не используются БД


Ыменно. А утверждалось, что половина SQL будет ВЕЗДЕ.

Течёт вода Кубань-реки куда велят большевики.
Re[28]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 17:22
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Ты спросил как откатывать транзакции, я тебе показал — не нужно просто портить старые данные.

G>>Снова бред говоришь. Если я поставлю Read Uncommited я увижу незакомиченные данные. Угадай почему я их увижу.
ANS>Откуда "Read Uncommited" в версионнике?
А причем тут версионники?
Я про все SQL СУБД, а не про конкретные. Механизмы у них всех похожи ибо плоды кучи исследований.

G>>Причем тут "нерабочий компьютер"? Компьютер вполне рабочий. Но вот возникает ошибка записи на диск по не важно какой причине. Как приложение узнает что ошибка произошла? Ты предложишь перечитывать данные после каждой операции записи? Ты же понимаешь что это бредовая идея?


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

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

ANS>>>Нет. "C" значит что ты должен прочитать одни и те же данные после записи. Если ты читаешь данные не смотря на то что часть нодов упала, то очевидно, что эти данные можно назвать "Durable".

G>>Дай ссылку на сие откровение.
ANS>Зачем ссылка, это ж логика.
Логика — она у всех разная.

G>>Тут говорят что C в CAP это A в ACID.


ANS>Хм. Он ссылается на доказательство Gilbert and Lynch, а в этой работе написано:

ANS>

Atomic or linearizable consistency ... there must exist a total order on all operations such that each operations looks like as if it were completed at a single instant.

ANS>Я не уверен, что это соответсвует A в ACID. Мне кажется, что гарантия прочитать записанное это "D". Более того, в ACID, вроде как, не оговаривается наличие линейного порядка между операциями с БД (и ты сказал, требования упорядоченности нет
Автор: gandjustas
Дата: 06.12.10
). Хотя оно может неявно вытекать из какого-то требования. Я пока считаю, что это (неявно) вытекает из D. Но, х.з.

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

G>>А википедия говорит что Consistency (all nodes see the same data at the same time).

G>>Причем во втором определении явная дыра. Как только твое приложение (оно ведь тоже "узел") считало данные и не блокирует их то Consitency больше нет, а если блокируешь, то гарантированно Availability нет. Получается CAP-теорема редуцировалась до CA теоремы.

ANS>Не получается. Просто ты плавно приходишь к пониманию того, почему ACID-транзакции не реализуют в таких системах.

В каких? Если ты не заметил, то это верно для любой системы. Причем Partition Tolerance совершенно не к месту.

G>>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.

ANS>Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал.
Ты путаешь durability и восстановление после критического сбоя.

G>>Причем реально вырождается это в CA-tradeoff.

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

G>>И как раз никто не старается выполнять Consistency.

ANS>Еще раз. Есть системы и CP и AP. Причем примеры есть даже в презентации Брюера.
Еще раз, C в CAP совершенно никак не относится к согласованности данных.
А вот как раз согласованность данных никому не нужна. Я на своей практики не встретился со случаем где мне нужна согласованность данных межу "узлами" приложение — субд между на протяжении нескольких запросов.

G>>>>а SQL СУБД — дают. NoSQL — говно и кроме как для кеша не подходят?

ANS>>>Традиционно считают, что SQL СУБД обеспечивают CA. Ни о каком выборе между "Consistency и Availability" речь не идёт и близко. Если пытаться реализовать этот выбор самому поверх реляционных хранилищ, то легко получить систему, которая не будет поддерживать вообще ничего.
G>>Еще раз, если смотреть комплекс "приложение-субд", то всегда присутствует CA-tradeoff.

ANS>Таки прогрес. Осталось дождаться пока ты признаешь, что гораздо лучше, когда этот трейдоф управляется и гарантируется уже написанным и проверенным фрейворком, а не каждым отдельным программистом по своему разумению.

Он именно каждым программистом по-отдельности по своему разумению делается, потому что задачи разные. Где-то нужна доступность, а где-то согласованность данных. В первом случае будут пессимистичные блокировки, во втором — оптимистичные.
Re[13]: Про NoSQL
От: alpha21264 СССР  
Дата: 06.12.10 17:22
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>2)Отсутствие Durability означает что после нажаnия Save документ может быть не сохранен.

G>что будете делать?

Вероятно то же что сейчас.

Течёт вода Кубань-реки куда велят большевики.
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 17:23
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:


G>>1)Там не используются БД


A>Ыменно. А утверждалось, что половина SQL будет ВЕЗДЕ.


Ты слишком много понимаешь под словом NoSQL. Для очистки мозга предлагаю понимать это только как хранилища, позиционирующие себя таким образом.
Re[28]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 17:37
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem


Это уже "Рабонович" поёт. Первоисточник тут http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&amp;rep=rep1&amp;type=pdf . Там упор на линейный порядок между запросами. Что для меня вполне логично — мне нравится, когда я могу прочитать то, что записал. В отличии от


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


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

G>Берем такую штуку как SQL Azure. Известно что она Fault Tolerant и Available (это гарантирует Microsoft большим количеством девяток),


Большое колличество это: a “Monthly Availability” of 99.9% during a calendar month.

G>наружу выставлен SQL интерфейс, который поддерживает ACID, а соотвественно атомарность изменений.


G>Все три свойства на месте, в чем прикол?


http://social.technet.microsoft.com/wiki/contents/articles/inside-sql-azure.aspx :

each subscriber’s data is actually stored multiple times, replicated across three SQL Server databases that are distributed across three physical servers in a single data center.
/.../
Each database hosted in the SQL Azure data center has three replicas: one primary replica and two secondary replicas. All reads and writes go through the primary replica, and any changes are replicated to the secondary replicas asynchronously.
/.../
the primary replica and at least one of the secondary replicas must confirm that the log records have been written before the transaction is considered to be committed.
/.../
Because it may take up to 30 seconds for the information about the new primary replica to propagate through all the gateway servers, the best practice is to try to reconnect several times with a smaller wait time after each failed attempt.
/.../


Правда у них репликация в пределах одного дата-центра. У Амазона было ряд проблем с дата-центрами в этом году и всё закончилось появлением опции синхронной репликации в другой датацентр. Но что они думают о CAP-теореме я не знаю

G>Или CAP работает когда к любому узлу системы могут "снаружи" обратиться клиенты?


В роли клиента может рассматриваться не конечный пользователь/приложение, а лоад-балансер.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 17:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>NoSQL — хранилища, которые так себя позиционируют.

G>>>SQL — современные, как говорится mature, СУБД общего назначения.
ANS>>Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально.
G>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.

Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[29]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 17:59
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem


ANS>Это уже "Рабонович" поёт. Первоисточник тут http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&amp;rep=rep1&amp;type=pdf . Там упор на линейный порядок между запросами. Что для меня вполне логично — мне нравится, когда я могу прочитать то, что записал. В отличии от

А при нелинейном порядке ты не сможешь прочитать что записал? Как оно вообще связано?
Ты как-то постоянно подменяешь понятия на желаемые.

G>>Берем такую штуку как SQL Azure. Известно что она Fault Tolerant и Available (это гарантирует Microsoft большим количеством девяток),

ANS>Большое колличество это: a “Monthly Availability” of 99.9% during a calendar month.
Где ты такое прочитал?

The goal for Microsoft SQL Azure is to maintain 99.9 percent availability for the subscribers’ databases.


goal и реальный показатель — разные вещи.


G>>наружу выставлен SQL интерфейс, который поддерживает ACID, а соотвественно атомарность изменений.

G>>Все три свойства на месте, в чем прикол?

ANS>http://social.technet.microsoft.com/wiki/contents/articles/inside-sql-azure.aspx :

ANS>

each subscriber’s data is actually stored multiple times, replicated across three SQL Server databases that are distributed across three physical servers in a single data center.
ANS>/.../
ANS>Each database hosted in the SQL Azure data center has three replicas: one primary replica and two secondary replicas. All reads and writes go through the primary replica, and any changes are replicated to the secondary replicas asynchronously.
ANS>/.../
ANS>the primary replica and at least one of the secondary replicas must confirm that the log records have been written before the transaction is considered to be committed.
ANS>/.../
ANS> Because it may take up to 30 seconds for the information about the new primary replica to propagate through all the gateway servers, the best practice is to try to reconnect several times with a smaller wait time after each failed attempt.
ANS>/.../

Нужно очень сильно постараться чтобы нарваться на такую ситуацию: падение primary replica + не успели еще все изменения на другие реплики записаться.
Если такое происходит не чаще раза в месяц и действительно не больше 30 секунд, то это примерно 5 девяток.
Это таки высокий класс доступности. Надо посмотреть сколько оно там реально получается.


G>>Или CAP работает когда к любому узлу системы могут "снаружи" обратиться клиенты?

ANS>В роли клиента может рассматриваться не конечный пользователь/приложение, а лоад-балансер.
Не, меня как раз интересует с точки зрения внешнего клиента, а не внутренних механизмов.
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 18:04
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>NoSQL — хранилища, которые так себя позиционируют.

G>>>>SQL — современные, как говорится mature, СУБД общего назначения.
ANS>>>Т.е. ни SQL ни ACID не являются критериями отнесения к "SQL". Оригинально.
G>>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.

ANS>Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.


Еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Re[29]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 18:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.

ANS>>Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал.
G>Ты путаешь durability и восстановление после критического сбоя.

В определении "durability" нет разделения на критический и не критический сбой. Это делает это определение не практичным. Из-за чего от "durability" осталось "данные запишуться если винда глюконёт".

G>>>Причем реально вырождается это в CA-tradeoff.

ANS>>Нет.
G>Ок, у тебя есть приложение, оно читает из базы на той же машине и дает пользователю редактировать данные. Как ты согласованость данных и доступность для других пользователей обеспечишь одновременно?

Какие сложности?

G>Еще раз, C в CAP совершенно никак не относится к согласованности данных.

G>А вот как раз согласованность данных никому не нужна. Я на своей практики не встретился со случаем где мне нужна согласованность данных межу "узлами" приложение — субд между на протяжении нескольких запросов.

Убил опять. Как писать программу если ты не можешь прочитать то, что записал?
Кстати о "никому не нужна":

Consistent Reads provide the ability to specify the consistency characteristic you require for each read call within your application, with an eventually consistent read optimized for lowest latency and highest throughput and a consistent read that provides “read my last write” capability.


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


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

PS. Целый день в форуме потерял. Всё, больше ничего не пишу, только позже оформлю обещанное
Автор: Andrei N.Sobchuck
Дата: 06.12.10
.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[30]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.10 18:09
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Где ты такое прочитал?

В их SLA.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[30]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.12.10 18:17
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>Кто тебе сказал что никто не обеспечивает? ACID нормально осбеспечивается СУБД, а ты споришь с непонятно чем.

ANS>>>Ну как знаешь. Если ты считаешь, что durability можно обеспечить сложив все яйца в одну корзину, то так и считай. Я вроде всё что мог, то и написал.
G>>Ты путаешь durability и восстановление после критического сбоя.

ANS>В определении "durability" нет разделения на критический и не критический сбой.

Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь.
Критический сбой это как раз такой который повреждает физическое хранилище.
Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.


G>>>>Причем реально вырождается это в CA-tradeoff.

ANS>>>Нет.
G>>Ок, у тебя есть приложение, оно читает из базы на той же машине и дает пользователю редактировать данные. Как ты согласованость данных и доступность для других пользователей обеспечишь одновременно?
ANS>Какие сложности?
Покажи решение.

G>>Еще раз, C в CAP совершенно никак не относится к согласованности данных.

G>>А вот как раз согласованность данных никому не нужна. Я на своей практики не встретился со случаем где мне нужна согласованность данных межу "узлами" приложение — субд между на протяжении нескольких запросов.

ANS>Убил опять. Как писать программу если ты не можешь прочитать то, что записал?

Да спокойно. Очень многие системы имеют время на propagation изменений.
Даже в этой теме пример пробегал.

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

ANS>Задачи разные, а гарантии одни и те же. И обычно получается, что сделанное по своему разумению, это что-то гарантировать в большинстве случаев и иногда ничего не гарантировать вообще. Я предпочитаю гарантированные гарантии негарантированным гарантиям.

Есть всего два способа. Называемые "пессимистичные" и "оптимистичные" блокировки. Первые делаются автоматически при удержании транзакции, вторые оыбчно уже встроены в фреймворк работы с данными. Ты только принимаешь решение что использовать в зависимости от задачи.
Re[30]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 15:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem


ANS>>Это уже "Рабонович" поёт. Первоисточник тут http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&amp;rep=rep1&amp;type=pdf . Там упор на линейный порядок между запросами. Что для меня вполне логично — мне нравится, когда я могу прочитать то, что записал. В отличии от

G>А при нелинейном порядке ты не сможешь прочитать что записал? Как оно вообще связано?

Если у тебя переупорядочились запросы чтения и записи, то очевидно, что можешь прочитать не то что записал. Собственно на примере с FTS я это демонстрировал. Но ты сказал, не читай оттуда и будет счастье
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[31]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 15:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Ты путаешь durability и восстановление после критического сбоя.


ANS>>В определении "durability" нет разделения на критический и не критический сбой.

G>Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь.
G>Критический сбой это как раз такой который повреждает физическое хранилище.
G>Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.

Наконец-то. Я имеено это и имею ввиду. А что на счет:

Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).

?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[25]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 15:39
Оценка:
Здравствуйте, IB, Вы писали:

IB>Да, известны базы без логов (FB, кажется такая), но за это призодится платить долгим коммитом, откатом, временем восстановления.


блин, а я что говорил? Без лога можно жить (это не /единственно возможный/ способ обеспечения durability). Просто с логом быстрее. Пока что.

IB>Как устроен постгри не знаю, но большая часть там передрана с оракла, а у того undo only, если я правильно помню.


Я конечно не большой знаток. Но помню, что изначально postgre был исследовательским проектом и в нём данные не удалялись физически вообще (кроме как явной операцией VACUUM). Это давало возможность вычитывать старые данные (спецсинтаксис у запросов) и не делать никаких журналов. Если мне память не изменяет, то write-ahead-log появился в 6 версии и изначально его не было. В любом случае, сдирание делалось на "внешнем" интерфейсном уровне. Внутреннее устройство, я уверен, там самобытно.

ANS>>Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно.

IB>Это тебе не нужно, а вообще только оно и нужно.

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

ANS>> Пользователь утрётся и введёт данные заново.

IB>Не прокатит. В нагруженных системах, на основе его утерянных данных уже будут другие данные, которые сохранятся — и привет, база в несогласованном состоянии. Кто и когда это ловить будет?

Хе-хе. Так по треду постоянно апеллируют к тому, что нагруженые системы удел не многих, а у многих всё мол попроще. И им durability тоже нужно. Но как раз эти "многие" платить за обеспечение "D" не готовы. Парадокс?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 15:46
Оценка:
Здравствуйте, adontz, Вы писали:

A> вы не умеете работать с RDBMS?


Ох, не удержусь:
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 15:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.


ANS>>Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.


G>Еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.


Странно, я вроде ясно написал, что если у тебя XML — данные, то добраться до них можно только через XPath. Даже если перед XPath ты напишешь слово SELECT это не превратит XPath в SQL. Но дам еще один намёк: реляционная теория рассматривает только отношения находящиеся как минимум в 1-й нормальной форме.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[32]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.01.11 17:36
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>Ты путаешь durability и восстановление после критического сбоя.


ANS>>>В определении "durability" нет разделения на критический и не критический сбой.

G>>Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь.
G>>Критический сбой это как раз такой который повреждает физическое хранилище.
G>>Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.

ANS>Наконец-то. Я имеено это и имею ввиду. А что на счет:

ANS>

Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).

ANS>?

Ссылку на источник
Re[18]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.01.11 17:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.


ANS>>>Ох-ох. Уже сколько раз говорили. Если сделать XML-колонку, то запросы к ней будут на XPath. Если заюзать FTS, то записанные данные нельзя тут-же найти через FTS. Ты утверждал, что это всё только показует мощь SQL, хотя, имхо, это свидетельствует о том, что есть понимание, что всё в реляционные структуры пихать и трудно и нудно.


G>>Еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.


ANS>Странно, я вроде ясно написал, что если у тебя XML — данные, то добраться до них можно только через XPath. Даже если перед XPath ты напишешь слово SELECT это не превратит XPath в SQL. Но дам еще один намёк: реляционная теория рассматривает только отношения находящиеся как минимум в 1-й нормальной форме.


SQL != реляционная алгебра.

И еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.

Если не приведешь — можешь не писать.
Re[31]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.01.11 17:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>>>Кстати, перечитывая, так сказать, первоисточник http://www.julianbrowne.com/article/viewer/brewers-cap-theorem


ANS>>>Это уже "Рабонович" поёт. Первоисточник тут http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&amp;rep=rep1&amp;type=pdf . Там упор на линейный порядок между запросами. Что для меня вполне логично — мне нравится, когда я могу прочитать то, что записал. В отличии от

G>>А при нелинейном порядке ты не сможешь прочитать что записал? Как оно вообще связано?

ANS>Если у тебя переупорядочились запросы чтения и записи, то очевидно, что можешь прочитать не то что записал. Собственно на примере с FTS я это демонстрировал. Но ты сказал, не читай оттуда и будет счастье


Именно. Полнотекстовый поиск — далеко не основной инструмент работы с данными в реляционных СУБД. Можешь статистику посчитать: соотношение поисковых запросов к обычным select. Полученные доли процента умножь на вероятность того что надо будет с помощью FTS найти данные, которые только что были записаны.
Полученное число будет гораздо меньше вероятности аппаратного сбоя.
Re[33]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 18:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

ANS>>>>В определении "durability" нет разделения на критический и не критический сбой.

G>>>Кто тебе такое сказал? Очевидно что уничтожив физическое хранилище БД ты данные потеряешь.
G>>>Критический сбой это как раз такой который повреждает физическое хранилище.
G>>>Если бы рассматривались оба вида сбоев, то смысла в durability вообще бы не было.

ANS>>Наконец-то. Я имеено это и имею ввиду. А что на счет:

ANS>>

Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software).

ANS>>?

G>Ссылку на источник


Такая пойдёт: http://citforum.ru/database/advanced_intro/80.shtml ? Если нет, то это нужно читать бумажные книжки. В инете все определения схожи с этим.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.01.11 18:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>И еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.


Gemstone/S, Objectivity. А вот если ты термин "mature" заменишь на "mainstream", то тут будет сложнее. Но мы же тут не о высокой моде?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 31.01.11 09:13
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


ANS>>>Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности.

G>>Конкретнее.

ANS>Самая большая проблема — DDL. Любое применение DDL это даунтайм.

Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей? Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/

ANS>Именно отсюда растут ноги у всяких sсhema-less способностей.

они совсем из другого места растут.

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

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

ANS>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.

MySQL — база для домашних страниц. Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники.

ANS>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу.

Точно, вот только есть два простых факта:
1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма.
2)Если всетаки понадобятся вагоны "кешей, шардов и реплик", то это решение уже будет приниматься на основе имеющихся данных, профиля их использования итп. NoSQL базы предлагают делать это заранее.
Re[12]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 31.01.11 09:17
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу. Я тут намедни термин интересный узнал: "непредвиденная консистентность". Вот такие системы обычно консистентны по недоразумению.


Ошибся. Автор это назвал "Potential Consistency":

...a pattern I call “Potential Consistency”. Some well known architectures have this property– any system that relies on asynchronous master-slave replication + a cache (think mysql + memcache) has, at best, potential consistency.

Whether you do write-through or read-through caching (do you update the cache or invalidate it?) you can easily have different data in your master, each of your slaves (replication, especially in mysql, isn’t perfect because statement-based replication is non-deterministic) and memcache. And there’s no guarantees that this differences will ever be resolved. Your data might be consistent, but once it becomes inconsistent there no guarantees it will ever become consistent again. Unless you build something to repair that data. If you can do this successfully– congratulations, you’ve built an eventually consistent system.

Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 31.01.11 10:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

ANS>>Самая большая проблема — DDL. Любое применение DDL это даунтайм.

G>Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей?

29'294'914 строк. Estimate — 5 часов.

G>Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/


Да? Что я вижу:

...30 million rows...
ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.

Почти мгновенно

ANS>>Именно отсюда растут ноги у всяких sсhema-less способностей.

G>они совсем из другого места растут.

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

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

G>Можно менять схему и без даунтайма вообще. Если ты так не умеешь, то это не проблема SQL, RDBMS и других аббривеатур.

Не умею. Научи. Решения которые я знаю не универсальны.

И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.

ANS>>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.

G>MySQL — база для домашних страниц.

Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle.

G>Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники.


Никогда не лазил в исходники ни MySql ни Postgres. Что я потерял?

ANS>>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу.

G>Точно, вот только есть два простых факта:
G>1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма.

Но не понятно откуда тогда эти кеши появляются если они никому не нужны.

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


Да, плохо только, что принимаются во внимание "имеющихся данных, профиля их использования" и неберутся во внимание вопросы консистентности. Еще раз вопрос, не лучше ли сразу взять, например, FlockDB (напомню, что внизу в нём MySql)?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 31.01.11 17:42
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


ANS>>>Самая большая проблема — DDL. Любое применение DDL это даунтайм.

G>>Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей?

ANS>29'294'914 строк. Estimate — 5 часов.


G>>Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/


ANS>Да? Что я вижу:

ANS>

...30 million rows...
ANS>ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.

ANS>Почти мгновенно

Ключевое выделил. Не делай так. Просто не делай. Есть другие способы.

ANS>>>Именно отсюда растут ноги у всяких sсhema-less способностей.

G>>они совсем из другого места растут.
ANS>Но, почему-то акцентируется именно возможность гибко менять схему. А не возможность простого хранения абстрактных неструктурированных данных.
"Гибко менять схему" фактически означает забивать на целостность существующих данных при изменениях схемы.

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

G>>Можно менять схему и без даунтайма вообще. Если ты так не умеешь, то это не проблема SQL, RDBMS и других аббривеатур.

ANS>Не умею. Научи.

Дорого тебе это выйдет.

ANS>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.

А это и не нужно.

ANS>>>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.

G>>MySQL — база для домашних страниц.
ANS>Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle.
У них спроси.

G>>Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники.

ANS>Никогда не лазил в исходники ни MySql ни Postgres. Что я потерял?
Ничего, но и не приобрел тоже.

ANS>>>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу.

G>>Точно, вот только есть два простых факта:
G>>1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма.
ANS>Но не понятно откуда тогда эти кеши появляются если они никому не нужны.
Зачастую как раз от того что люди не умеют работать с SQL

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

ANS>Да, плохо только, что принимаются во внимание "имеющихся данных, профиля их использования" и неберутся во внимание вопросы консистентности.
См пункт 1.
Re[27]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.02.11 07:24
Оценка:
Здравствуйте, IB, Вы писали:

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

IB>Шырокие массы за него отслюнявливают только в путь.

Тут в треде было сказано, что 90 процентов пользователей работают на только одном сервере. И два сервера для них равносильно организации экспедиции на марс. Это эти массы то отлюнявливают? Или термин "массы" для тебя имеет особое значение?

ANS>>Хе-хе. Так по треду постоянно апеллируют к тому, что нагруженые системы удел не многих, а у многих всё мол попроще. И им durability тоже нужно. Но как раз эти "многие" платить за обеспечение "D" не готовы. Парадокс?

IB>С чего ты взял что не готовы? Где хоть одна бухгалтерская поделка на NoSql без Durability?

В 90 процентов случаев бухгалтер "в случае чего" вколотит данные заново. Потому, что стоит он дешевле сервера. И работают же как-то.

IB>MySQL и тот скрипя все что надо прикрутил.


fsync перед отсылкой "OK" это не дюрабилити.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.02.11 07:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Дорого тебе это выйдет.


Т.е. — сложно. Об этом я и говорю.

ANS>>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.

G>А это и не нужно.

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

Кстати, если это никому не нужно, то зачем люди изобретали и продолжают(!) изобретать такое чудо.

ANS>>Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle.

G>У них спроси.

Потому что им нужно, что бы схема менялась в произвольные моменты времени гарантировано за время комфортное для человека (это сколько там — меньше 300мс?).
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.11 08:16
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.

G>>А это и не нужно.

ANS>Нужно. И дело не только в убирании даунтайма без плясок с бубном человеком без сотни сертификатов. Возможность изменения схемы из прикладной программы синхронно и за конечное время даёт дополнительные возможности. Это как с кодогенерацией — находятся отдельные ретрограды, которые считают, что можно и без неё, но народ то пользуется.

Ну ты придумал что нужно и для тебя это проблема. Другим не нужно и проблем нет.

ANS>Кстати, если это никому не нужно, то зачем люди изобретали и продолжают(!) изобретать такое чудо.

Идиотизмом страдают и не более того.
Re[29]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.02.11 15:07
Оценка:
Здравствуйте, IB, Вы писали:

ANS>>fsync перед отсылкой "OK" это не дюрабилити.

IB>Я устал понимать, что ты понимаешь под durability,

Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться.

IB>но задача БД — сделать так, чтобы любой уровень durability при установке БД мог быть обеспечен исключительно средствами администрирования, классические SQL БД это обеспечивают, в том числе и MySQL оборудованный InnoDB, а вот NoSQL — нет.


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

Для примера достаточно рассмотреть Google Megastore. И сравнить с тем, что смогли выдать на гора а Амазоне.

IB>Более того, как показала практика, если отказаться от durability и consistency в одной конкретно взятой БД, например в том же MySQL-е, то в плане производительности все NoSQL сосут как промышленный пылесос, чего собственно и следовало ожидать: http://l-o-n-g.livejournal.com/153756.html


Это вообще что, о чем и к чему?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[30]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.02.11 15:37
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться.

Вот и прекрасно. Традиционные SQL базы гарантируют это, а NoSql — нет.

ANS>Дело обстоит ровно наоборот.

Да ты чо? Где у NoSql хоть какое-нибудь durability вместе с consistency.

ANS>Для примера достаточно рассмотреть

Для примера чего? Крутизны гугла и амазона? )

ANS>Это вообще что, о чем и к чему?

Это о том, что NoSQL даже нормально писать не умеют. Если у банального MySql-я отключить блокировки и ряд других заморочек по согласованности, то он рвет чисто in memory NoSQL больше чем в два раза.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[31]: Про NoSQL
От: fddima  
Дата: 03.02.11 16:04
Оценка:
Здравствуйте, IB, Вы писали:

IB>Это о том, что NoSQL даже нормально писать не умеют. Если у банального MySql-я отключить блокировки и ряд других заморочек по согласованности, то он рвет чисто in memory NoSQL больше чем в два раза.

А с включенными блокировками, на вставках, — MySQL не рвёт только очень ленивый.
Re[31]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.02.11 07:12
Оценка:
Здравствуйте, IB, Вы писали:

ANS>>Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться.

IB>Вот и прекрасно. Традиционные SQL базы гарантируют это, а NoSql — нет.

Я уже спрашивал как
Автор: Andrei N.Sobchuck
Дата: 06.12.10
. Расскажи на пальцах, как в рамках одного хранилища данных получить таки "Durability" устойчивое к сбоям этого хранилища.

ANS>>Дело обстоит ровно наоборот.

IB>Да ты чо? Где у NoSql хоть какое-нибудь durability вместе с consistency.

Всё на месте. Кстати, в тройке CAP и просто "Consistency" и более слабое требование "eventual consistency" подразумевает, что данные таки durable.

ANS>>Для примера достаточно рассмотреть

IB>Для примера чего? Крутизны гугла и амазона? )

Не. Это пример того, что для ACID БД, то что сделал Amazon — потолок. А для т.н. NoSql возможно то, что сделал Гугль.

ANS>>Это вообще что, о чем и к чему?

IB>Это о том, что NoSQL даже нормально писать не умеют. Если у банального MySql-я отключить блокировки и ряд других заморочек по согласованности, то он рвет чисто in memory NoSQL больше чем в два раза.
Странное обобщение. Сравнивать производительность key-value с, например, CouchDB некорректно. Впрочем, не смотря на то, что мне нравятся возможности CouchDB, лично для меня более приемлемый подход — FlockDB. А именно, внизу традиционная mature RDBMS, а сверху другой интерфейс предоставляющий определённые гарантии.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[32]: Про NoSQL
От: _ABC_  
Дата: 04.02.11 09:07
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, IB, Вы писали:


ANS>>>Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться.

IB>>Вот и прекрасно. Традиционные SQL базы гарантируют это, а NoSql — нет.

ANS>Я уже спрашивал как
Автор: Andrei N.Sobchuck
Дата: 06.12.10
. Расскажи на пальцах, как в рамках одного хранилища данных получить таки "Durability" устойчивое к сбоям этого хранилища.


А вот интересно, является ли 'durability' полным синонимом 'fault tolerance'? Вроде как нет.

В оригинале у Грея было:

Durability: once a transaction is commited, it cannot be abrogated.


Т.е. подразумевается, что после завершения транзакции она не может быть отменена. Я считаю, что расширенное трактование данного термина как fault-tolerance, т.е. устойчивость к сбоям несколько неправильно. В чем я ошибаюсь?
Re[33]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.02.11 13:55
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>В оригинале у Грея было:

_AB>

_AB>Durability: once a transaction is commited, it cannot be abrogated.


_AB>Т.е. подразумевается, что после завершения транзакции она не может быть отменена. Я считаю, что расширенное трактование данного термина как fault-tolerance, т.е. устойчивость к сбоям несколько неправильно. В чем я ошибаюсь?


В неверно акцентированном переводе слова "abroghated"?

И, вроде как, fault-tolerance не подразумевает под собой обязательную сохранность данных. Где то видел презентацию, где из-за того, что целостность промежуточной системы (очереди) долго восстанавливалась при креше приняли решение пересоздавать очередь, а старые данные просто терять. Если они не важны, то почему нет? И обратное верно — система может сохранять данные и не быть fault-tolerant. Просто это не совсем практично и по факту неработоспособность системы больше некого время может быть равносильна потере данных. Для теории это же не важно.

Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[34]: Про NoSQL
От: Sinix  
Дата: 04.02.11 14:19
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.

А её что, замачивают?

"Потеря ненужных данных" годится для всяких развлекательных ресурсов, где записи (как и их авторы) не несут никакой полезной нагрузки (с точки зрения владельца ресурса). Для софта, который так или иначе имеет дело с реальным миром, подход "работает пока не упадёт" чрезмерно оптимистичен.
Re[14]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.02.11 15:50
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Да? Что я вижу:
ANS>

...30 million rows...
ANS>ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.

ANS>Почти мгновенно
Стесняюсь спросить: а что будет, если мы в NoSQL попробуем запихать 60 миллионов нулей? Неужели есть способ обойти скорость света и получить мгновенный результат?

А если в NoSQL вы не собираетесь запихивать нули, то какого ж рожна вы это делаете с SQL?
Делаете обычные, nullable колонки. Если охота сделать так, чтобы при извлечении были нули там, где нет данных — рисуете view с isnull(column1, 0). Если хотите запретить вставлять null — вешаете instead of триггер.
В целом — выглядит как неудачный пример оправдать применение NoSQL при помощи некомпетентности в SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Про NoSQL
От: _ABC_  
Дата: 04.02.11 18:37
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>В неверно акцентированном переводе слова "abroghated"?


Так вроде далее по тексту тоже не настаивают на восстановлении после сбоя. Надо перечитать, давно это было...

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

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

ANS>Если они не важны, то почему нет? И обратное верно — система может сохранять данные и не быть fault-tolerant. Просто это не совсем практично и по факту неработоспособность системы больше некого время может быть равносильна потере данных. Для теории это же не важно.

Если данные не важны — зачем их хранить постоянно? Это уже нецелевое расходование ресурсов, наверное.

ANS>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.

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

В общем, либо я не так понял Грея (перечитаю на досуге), либо Вы, Андрей, не правы, идя вслед за вики и прочими mySQL-щиками и NoSQL-щиками в утверждении, что Durability — это гарантия сохранности данных после сбоя.
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 07:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А если в NoSQL вы не собираетесь запихивать нули, то какого ж рожна вы это делаете с SQL?

S>Делаете обычные, nullable колонки. Если охота сделать так, чтобы при извлечении были нули там, где нет данных — рисуете view с isnull(column1, 0). Если хотите запретить вставлять null — вешаете instead of триггер.
S>В целом — выглядит как неудачный пример оправдать применение NoSQL при помощи некомпетентности в SQL.

При чем тут NoSql? Негибкость изменения схемы это просто особенность текущей реализации СУБД. Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[35]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 08:08
Оценка:
Здравствуйте, _ABC_, Вы писали:

ANS>>В неверно акцентированном переводе слова "abroghated"?

_AB>Так вроде далее по тексту тоже не настаивают на восстановлении после сбоя. Надо перечитать, давно это было...

Это уже будет не durability, а просто поддержка целостности рабоочих структур. В большинстве случаев именно такие гарантии дают журналируемые ФС, но это никто не называет "durability". Имхо, главное тут неаннулируемость изменений.

_AB> Точнее, на практике предполагает потерю данных не более чем на оговоренный соглашением срок.


Я напомню начало начал треда. Кто-то нашел какую-то конкретную реализацию NoSql БД, которая работает в облаке, и сказал, что если запустить инстанс на одной машине (не в облаке), то сбрасывание данных из volatile памяти в долговременное хранилиже раз в 60 сек делает все NoSql не-durable. Я просто заметил, что между потерей данных за 60 сек, и потерей данных за 1 сек нет принципиальной разницы. Данные стали неконсистентны и их нужно привести в актуальное состояние человеческим вмешательством.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[35]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 08:17
Оценка:
Здравствуйте, Sinix, Вы писали:

ANS>>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.

S>А её что, замачивают?

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

S>"Потеря ненужных данных" годится для всяких развлекательных ресурсов, где записи (как и их авторы) не несут никакой полезной нагрузки (с точки зрения владельца ресурса). Для софта, который так или иначе имеет дело с реальным миром, подход "работает пока не упадёт" чрезмерно оптимистичен.


Да, да. А потом, последует пожимание плечами и фраза о том, что возможность потери данных никто не замалчивает.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[36]: Про NoSQL
От: Sinix  
Дата: 06.02.11 09:05
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.

S>>А её что, замачивают?

ANS>Вот именно по-этому я и сказал, что durability никому не нужна. Инженеры знают что её нет (у подавляющего большинства), но делают вид что она есть, потому что в рекламном проспекте слово такое написано. ...


По-моему, вы играете за обе стороны — сами придумываете доводы за оппонентов, и сами же их опровергаете.

Во-первых, durability не даёт 100% гарантии, но, в тоже время, позволяет без существенных затрат обеспечивать сервис в 5-6 девяток за счёт почти моментального восстановления (в большинстве случаев).
Во-вторых, ваш тезис "не будет durability — нафиг ACI!" слегка расходится с реальностью: вам всё равно надо будет как-то разгребать проблемы параллельной обработки данных и защищаться от непредсказуемых побочных эффектов.
Re[16]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.11 15:06
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>При чем тут NoSql? Негибкость изменения схемы это просто особенность текущей реализации СУБД.
Брр. Поясните мне, что вы называете "негибкостью изменения схемы". Пример, который приведён выше по ветке, некорректен — он не связан с реализацией СУБД. Он связан с тем, что перед СУБД ставят сомнительную задачу — "выкопать окоп для стрельбы с коня".
Если эту же задачу поставить перед NoSQL, она справится ничуть не лучше.

ANS>Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).

Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).
Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.

Скорее всего, у меня просто фантазия ограничена моими привычками мыслить в терминах DDL. В таком случае, можно привести пример такого "изменения схемы", которое покажет преимущества NoSQL в полный рост.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.11 15:22
Оценка:
Здравствуйте, messir VolanD, Вы писали:
MV>Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:
Ну, пока что там всё в порядке.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 21:17
Оценка:
Здравствуйте, gandjustas, Вы писали:

F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?


G>А где его достаточно? Таких задач исчезающе мало.


btw, Amazon S3 Cloud Stores 262 Billion Objects
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.02.11 21:22
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?


G>>А где его достаточно? Таких задач исчезающе мало.


ANS>btw, Amazon S3 Cloud Stores 262 Billion Objects

И что? Это не ответ на вопрос никак.
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 21:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

MV>>Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:

S>Ну, пока что там всё в порядке.

Я так понял это формат экспорта.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.02.11 04:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я так понял это формат экспорта.

Хм. Может быть. Но судя по MS SQL внутрях — там таки SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.02.11 07:02
Оценка:
Здравствуйте, Sinclair, Вы писали:

ANS>>Я так понял это формат экспорта.

S>Хм. Может быть. Но судя по MS SQL внутрях — там таки SQL.

Хе-хе. У FlockDB тоже внизу SQL, а сверху вполне себе графовая NoSql. Это ведь зависит от патерна использования.
Интересно как они теги обрабатывают.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.11 18:37
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets)

Совершенно верно. Поэтому его применение оправдано только при крайне редких изменениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 26.02.11 21:18
Оценка:
M>>Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets)
S>Совершенно верно. Поэтому его применение оправдано только при крайне редких изменениях.

А хоцца-то частые изменения


dmitriid.comGitHubLinkedIn
Re[16]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.11 16:46
Оценка:
Здравствуйте, Mamut, Вы писали:

M>А хоцца-то частые изменения

Берите транзитивные замыкания, кто ж вам мешает-то
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 27.02.11 21:23
Оценка:
M>>А хоцца-то частые изменения
S>Берите транзитивные замыкания, кто ж вам мешает-то

Ой, дяденька, не ругайтесь Я лучше какой-нить Neo4j возьму %)


dmitriid.comGitHubLinkedIn
Re: Про NoSQL
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.02.11 10:58
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Думаю, это достаточно философское замечание


Я думаю, эта мудрость взята отсюда
Re[2]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 28.02.11 11:11
Оценка:
M>>Думаю, это достаточно философское замечание

Pzz>Я думаю, эта мудрость взята отсюда


Ну это-то понятно


dmitriid.comGitHubLinkedIn
Re[17]: andrei.sobchuck
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.03.11 09:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

ANS>>Я так понял это формат экспорта.

S>Хм. Может быть. Но судя по MS SQL внутрях — там таки SQL.

Не только. Еще и Redis.

А мне тут говорят, что любое кеширование &mdash; от неумения SQL пользовать
Автор: gandjustas
Дата: 31.01.11
.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.05.11 15:07
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Mamut, Вы писали:


M>>Странно, что в «Философии» про NoSQL мало говорят, но сегодня в твиттере увидел следующее:


К>[cut]


К>Эрик Мейер noSQL называть coSQL (via Mirrorer)


Я не видел, чтобы это кто-то постил. Так что вот: A Co-Relational Model of Data for Large Shared Data Banks
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 01.08.11 08:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).

S>Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.

btw, http://www.dbms2.com/2011/07/31/dynamic-fixed-schema-databases/.
У него в блоге там еще просто много примеров разных БД-технологий.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.