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[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[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[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[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[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[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.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.