Здравствуйте, Mamut, Вы писали:
M>Справедливости ради, с деревьями (они же графы) весь NoSQL тоже не дружит, а граф-базы данных мне в NoSQL записывать не хочется
Это еще почему ? И деревья и графы и гиперграфы со всякими слоями отлично дружиццо с NoSql.
Здравствуйте, adontz, Вы писали:
I>>Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД?
A>Купить винчестеры быстрее
Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов, что повлечет издержки из за переустановки софта минимум 1 рабочий день по всей конторе.
То есть, ты предлагаешь ради ускорения своей софтины затратить сумму примерно равную 10млн долларов только на аппаратное ускорение
Вот тебе и SQL
P.S. это конечно частный случай, но он вполне реальный.
Здравствуйте, Ikemefula, Вы писали:
A>>Купить винчестеры быстрее I>Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов
Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред?
I>Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов, что повлечет издержки из за переустановки софта минимум 1 рабочий день по всей конторе.
I>Вот тебе и SQL
С интересом понаблюдаю за массовым внедрением ферм на 10k dbms-серверов. Почему сразу не миллион?
И главное, где вы наберёте пару петабайт полезной информации на эту ферму? google@home?
Здравствуйте, adontz, Вы писали:
I>>Вот представь, приходишь ты к кастомеру и говоришь — мы тут написали софтинку, что бы она работала нужно 10000 ваших компов проапргейдить на сумму около 200-500 долларов
A>Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред?
Здравствуйте, Ikemefula, Вы писали:
A>>Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред? I>Я вообще то не говорил про серверный софт
А какой тогда вообще смысл говорить о производительности?
Здравствуйте, Ikemefula, Вы писали:
I>>>Вот тебе и SQL S>>С интересом понаблюдаю за массовым внедрением ферм на 10k dbms-серверов. Почему сразу не миллион? I>А фермы здесь при чем ?
И то правда, ваша конфигурация на ферму не тянет, максимум на колхоз!
Здравствуйте, adontz, Вы писали:
A>>>Кто ставил SQL Server на каждый клиентский компьютер? Что в этом случае реального кроме того что это реальный бред? I>>Я вообще то не говорил про серверный софт
A>А какой тогда вообще смысл говорить о производительности?
Зачем инженеру ответ за 1 секунду если можно затратить неделю ?
Ты вроде не из России что бы такие вопросы задавать
Здравствуйте, Ikemefula, Вы писали:
A>>А какой тогда вообще смысл говорить о производительности? I>Зачем инженеру ответ за 1 секунду если можно затратить неделю ? I>Ты вроде не из России что бы такие вопросы задавать
Зачем считать на клиенте что-то, что считается больше секунды? Ну ладно, пяти.
. Результатом такого незамечания является то, что из трёх гарантий (C-, A-, P-) теряется не одна, а все гарантии (теорема ведь не обещает, что всегда выполняются две гарантии из трёх, а утверждает, что выполняется не больше двух).
ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется. Гораздо более правильно вывести эти ограничения явно. Программист получает гарантии ACID на уровне отдельных запросов и явный выбор между возможными CAP. Всё прозрачно и понятно. Кстати, обеспечить юзабельную реализацию eventual consistency может сходу и не получиться. Гораздо лучше, когда это уже готовое — реализованное и проверенное.
Итого, преимущество в том, что такие системы не обещают того, что в реальной жизни выполнить не возможно.
О да. Утверждение, что если человек понимает, что он делает, то он это делает осознанно, а если не понимает, то не осознанно — очень философское. Но очень малополезное. Зачем его по треду в разные посты растыкали — не понятно.
M>>Если специальных иерархических данных нет (тот же MySQL), каждый следующий уровень дерева — это один-два лишних джойна. IB>Никаких лишних джойнов уровни не добавляют, просто структура данных чуть сложнее. И это именно "чуть", а не так фатально, как тут пытаются описать.
В MySQL добавляют за неимением «более сложных данных»
Здравствуйте, gandjustas, Вы писали:
G>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
G>Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало
Вся ирония ситуации в том, что Durability в рамках одного хранилища данных обеспечить не возможно.
G>Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.
шардинг не поможет (учите матчасть, хм). Нужна репликация. Здравствуй CAP теорема.
M>>А можно пример? IB>пример чего? как это дело через еще одно отношение выразить? У меня и правда складывается впечатление, что адепты noSql на самом деле реляционки не знают. =)
Стандартный социальный сайт — это, по сути, граф.
Стандартный запрос — это FOAF. Это понятно и примитивно. Интересен запрос любой вложенности/закрученности по графу.
M>>Справедливости ради, с деревьями (они же графы) весь NoSQL тоже не дружит, а граф-базы данных мне в NoSQL записывать не хочется
I>Это еще почему ? И деревья и графы и гиперграфы со всякими слоями отлично дружиццо с NoSql.
NoSQL и так перещружен толпой абсолютно разных и непересекающихся баз данных и хрнилищ Не надо в этот термин еще и граф-базы данных втягивать
Я обычно терплю даже более крутые ляпсусы, да и с ув 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.
Это кореллирует с тем с какими задачами ко мне обращаются заказчики.
Здравствуйте, IB, Вы писали:
N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой. IB>Да ладно? Что же там в SQL не ложится? )
1. Подо всё свой инструмент нужен. То что доказано, что всё можно запихнуть в реляционную модель не значит, что туда нужно всё пихать. Это настолько очевидно, что я даже не представлял, что его кто-то может оспаривать. К примеру, лет десять назад Oracle создал сервер, который внутри себя держал файлы. Поддерживал кучу протоколов (smb, ftp etc). И естественно обещал ACID. Однако Oracle не сказал, что все должны вместо файловых систем использовать их хранилище. Ибо скорость проседала на порядок по сравнению с обычной ФС. А возможность выполнения запросов к файловой системе и транзакции при таком проседании скорости мало кому нужны.
2. Сам факт появления такой техники как `Nested Sets` и внедрения в SQL cервер встроенного полнотекстового поиска и XML типа данных со своим языком запросов и способом хранения, говорит о том, что разработчики серверов осознают ограниченность своего инструмента и не боятся топать к NoSql когда обстоятельства требуют. Что особенно удивляет, так это то, что приводя такие примеры
Здравствуйте, Sinix, Вы писали:
S>Итак, где здесь:
И так, ты действительно не видишь где теряется гарантия ACID при использовании полнотекстового поиска, и считаешь, что можно Durability обеспечить только в рамках одного дискового массива?
И деревья и графы и гиперграфы со всякими слоями отлично дружиццо с NoSql.
