BoobenComВ моем эксперименте РСУБД проиграла где-то в 15ть раз.
Если вы видите за счет чего РСУБД может сжать данные и был большой опыт с сжатием данных,
а главное есть понимание за счет какой природы данных их можно ужать - то напишите подробно.

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

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

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



У меня нет проблем с пониманием того, что написано в статье.

Alexey TominМир NoSQL - хорошее дополнение к SQL. Если это понимать- будет счастье. Если нет- Вас ждёт горькое разочарование, когда Вы выйдете из узкой области оптимальности решений NoSQL.

Так если это понимать, то можно и в РСУБД в BLOB хранить XML с дополнительными данными, и/или использовать EAV, и иметь и профит РСУБД, и какоую-то оптимизацию под конкретную предметную область.

BoobenComИтак, я утверждаю что:

А. Дубли это хорошо. Ибо дубли это мать историчности и отец подробный логов. (От чего задыхается современный бизнесс, и это я пишу в своей статье)


"Меня терзают смутные сомнения…!"

"Ты, штоле ?"

авторА. Дубли это хорошо. Ибо дубли это мать историчности и отец подробный логов. (От чего задыхается современный бизнесс, и это я пишу в своей статье)


Тут проблема в чём: "историчность" -- понятие из предметной области. Это -- не техническая проблема.
А РСУБД или NoSQL -- это технические средства.
Нельзя обсуждать технические средства, вменяя им в вину невозможность реализации на них автоматизации каких-то предметных областей. В частности, по следующей немаловажной причине: на обоих средствах можно реализовать оба варианта этих систм,
с и без "историчности".

Т.е. грубо говоря, тебе ставят задачу "реализовать реляционную БД и систему с её использованием, и чтобы была "историчность" данных", но ты говоришь -- "я не знаю, как на РСУБД реализовать такую систему, поэтому я вместо того, чтобы учиться, как это можно сделать, буду брать другую систему (NoSQL в частности), и делать на ней, а потом напишу об этом статью, и мне будет профит"

Кроме того, дубли -- это ПЛОХО .
Если очень интересно, могу подсказать, почему ты тут ошибаешься.


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


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


авторВ. СУБД может иметь свои "аппаратные" возможности для сжатия информации (в 100 и более раз, в этом нет ничего удивительного при правильном подходе к природе данных) и хранить данные даже компактней чем реляционные модели.

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

Alexey TominMasterZivпропущено...


Так если это понимать, то можно и в РСУБД в BLOB хранить XML с дополнительными данными, и/или использовать EAV, и иметь и профит РСУБД, и какоую-то оптимизацию под конкретную предметную область.

Не, не выйдет. Точнее выйдет, но слишком дорого.

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

Ну, это вопрос не технический, а экспертизы сотрудников и финансов.

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




И будто бы я не удивился ...

авторИзучай.
http://blog.pikosec.com/?p=95


Ещё раз, я не хочу ничего изучать. Мне это не интересно, и времени нет. Хотя если будет -- прочитаю.
Арпиори могу сказать сразу, что всё, что там навёрнуто, можно сделать и в РСУБД столь же эффективно.

Ты ж понимаешь, что экспертиза есть и там и там?
Просто реально дешевле купить отдельный кластер из простых серваков, поставить туда хадуп и гонять его расчётами по суткам, чем расширять оракл-сервер. В РАЗЫ дешевле.

И что это доказывает ? Миг-29 -- хороший самолёт, но дорогой, я лучше куплю 20 паропланов, и на них запущу ракету ?
Я не готов обсуждать такие аспекты в данном топике.
Не нужно смешивать технические и нетехнические вопросы в одну кучу.

PS: не надо говорить "NoSQL не нужен"- это такая же ересь, как "SQL устарел".

Я и не говорил, что "NoSQL не нужен". Я бы про NoSQL вообще не говорил, поскольку что это такое -- никто не знает.
В приведённой в теме статье (не автором топика) это очень хорошо разжёвано.

nosql2Предлагается вашему вниманию сравнительный обзор


Кстати, я подёргал этот бубен -- прикольная идея, но всё же там куча проблем...

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

ассоциации слов контекстно-зависимы. Есть омонимы, полисемия. Например, я искал слово "поток".

Ассоциации -- это на самом деле вообще не свойство слов, а свойство понятий. Так, для "потока" я бы сделал три понятия:
поток ввода-вывода, поток управления, и поток(воды,жидкости), а можно ещё и поток (син. "река").

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

Ассоциации для "поток" были такие:


Тут на лицо:
-- что есть словоформы вместо ассоциаций.
-- что слиты два понятия
-- что ассоциации построены неверно (напр. при чём тут try, void ?)

Фееричны ассоциации на простое слово printf :

Наши ассоциацииprintf stdio argv argc stdlib include scanf conio getch cout iostream sizeof struct std main strlen malloc unsigned sprintf stdafx strcpy typedef endl fprintf _tmain


т.е. printf -- это "что-то из С++" -- а дальше уже понеслась...