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 тоже.
Здравствуйте, Mystic, Вы писали:
G>>Базы данных вполне успешно обрабатывают такие ситуации. У них есть статистика использования индекса, они могут оценить селективность предикатов до их выполнения.
M>Могут, а толку? Если в результате будет 1 000 000 item-ов, то хочешь-не хочешь придется их все обрабатывать. Как тут выручит селективность?
Еще раз. БД оптимизирует доступ к диску. Фактически она не будет даже поднимать в память те записи, к которым не было обращения.
G>>Ну ладно, честно признался что не очень в базе данных рубишь. M>Зато разбираюсь в алгоритмах. И могу оценить верхнюю границу при условии, что база данных отработает запрос идеально (т. е. выполнит только те вычисления, что необходимы).
Ты снова забыл про чтение.
Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
N>>>И где тут описанное тобой "основное хранилище"? G>>Ты как-бы привел ваше РЕШЕНИЕ, а не задачу. Расскажи подробнее про задачу тебе решений накидают. G>>Большинство обычных СУБД вытянут базы на 100гб и не поморщатся при нормальной схеме. Никаких распределенных хранилищ не понадобится.
I>Господи, что за мода приводить абсолютные цифры безо всякого базиса ? I>На каком железе будут тянуться эти 100гб ?
На хорошем сервере
См конфигурацию сервера БД stackoverflow
G>>ЗЫ. Единственное во что реально упереться в СУБД, так это в скорость записи. I>Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД ?
У MS SQL есть StreamInsight, у других — ХЗ.
Никто не мешает сварганить свой StreamInsight с потоковой обработкой данных.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>И как выражается это преимущество?
ANS>Ну вот смотри. Есть у нас CAP-теорема (она же теорема Брюера). Не смотря на то, что г-н Cyberax педалирует её в контексте высоконагруженных систем
. Результатом такого незамечания является то, что из трёх гарантий (C-, A-, P-) теряется не одна, а все гарантии (теорема ведь не обещает, что всегда выполняются две гарантии из трёх, а утверждает, что выполняется не больше двух).
Ты вообще о чем? Где теряются гарантии, покажешь?
ANS>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется.
Покажи где он не выполнгяется.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
G>>Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало
ANS>Вся ирония ситуации в том, что Durability в рамках одного хранилища данных обеспечить не возможно.
ОК. Вот у тебя есть MS SQL Server, покажи подтверждение своим словам.
G>>Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.
ANS>шардинг не поможет (учите матчасть, хм). Нужна репликация.
Репликация не поможет если данные не сохранены.
Я вообще-тоне знаю какой точно термин используется в случае NoSQL. Суть заключается в том что клиент отправляет команду записи на несколько инстансов, которые потом реплицируются между собой. В случае наличия Durability усилия клиента не требуются.
проектов Durability не нужна.
Отсутствие Durability сразу же лишает как консистентности, так и атомарности.
При сбое невозможно узнать какая операция не выполнилась, что позволяет иметь несогласованные данные и невозможность откатить транзакцию.
Здравствуйте, 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 когда обстоятельства требуют. Что особенно удивляет, так это то, что приводя такие примеры
.
Теперь специально для тебя рассказываю тайну, которую многие любители NoSQL постигнуть не в состоянии.
Данные делятся на:
1)структурированные, которые можно представить множеством кортежей с элементами одинаковых типов (sql)
2)полуструктурированные: данные можно представить некоторого дерева элементов (xml)
3)неструктурированные: текст, blob
Теперь внимание: к неструктрированным данным единственный вид запросов — "полнотекстовые". В кавычках потому что для блобов несколько хитрее все работает, чем для текста.
Современные движки СУБД (ms sql, postgres, oracle) пытаются покрыть все виды данных, для вашего же удобства. А вы предпочитаете пользоваться всяким г... которое обрабатывает только полуструктурированные данные, и то не лучшим образом.
ЗЫ. Я намеренно не вешаю тут ярлыков SQL-NoSQL, чтобы путаниицы не возникало.
Впредь рекомендую рассматривать под терминами NoSQL только хранилища, потому что методы обработки зависят в первую очередь от самих данных, а не от того как они хранятся.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, 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.
Чувак нифига не понимает в цикле разработки.
Такое даже читать противно. Дилетантизм, замешаный с откровенным враньем.
Здравствуйте, adontz, Вы писали:
I>>Зачем инженеру ответ за 1 секунду если можно затратить неделю ? I>>Ты вроде не из России что бы такие вопросы задавать
A>Зачем считать на клиенте что-то, что считается больше секунды? Ну ладно, пяти.
Теоретически — незачем. Только как правило, не всегда серверные решения будут лучше, дешевле и тд.
Тебя ведь не смущает, что компиляция проекта выполняется больше 5 секунд а выполнение юниттестов еще дольше ?
Представь себе фирму где работает около 10 тыс инженеров. У каждого есть комп.
Задача — заменить тяжелый десктопный софт, скажем нечто похожее на сапр, серверным.
Здравствуйте, 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'ом.
Здравствуйте, 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 рассказывать?
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).
То, что с такими знаниями выходит какашка — вполне закономерный результат.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы
Здравствуйте, 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 рассказывать?
Здравствуйте, 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>Расскажи на всякий
Да нет, ты сперва погугли, а потом я отвечу на конкретные вопросы.
Здравствуйте, 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) и синхронно обновлять их), и дисковое пространство — вроде не так уж и много.
Здравствуйте, 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"
Ну ладно, пяти.
