Здравствуйте, gandjustas, Вы писали:
G>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
SQL — это язык SQL + данные хотя бы в первой НФ + ACID.
NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ANS>SQL — это язык SQL + данные хотя бы в первой НФ + ACID. ANS>NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
Здравствуйте, gandjustas, Вы писали:
G>>>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ANS>>SQL — это язык SQL + данные хотя бы в первой НФ + ACID. ANS>>NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
G>А чем тогда NoSQL лучше, если это отсутствие?
Т.е. к формулировке претензий нет ? Лучше, очевидно, тем, что имеют более другие свойства. И эти другие свойства более важны, чем комбинация из первых трёх.
Здравствуйте, _d_m_, Вы писали:
___>Врут. И врут еще с 2000 версии. Работаем с индексными представлениями еще с 2000 версии. И работало в т.ч. на MSDE.
А это как? Расскажите чуть подробнее. Очень интересно оказалось.
R>>300мс у тебя чистое процессорное время, все данные в кэше, обращений к диску нет вообще G>Так тем более. На реальном серваке это будет не 300, а 30мс или того меньше и ядер будет задействовано побольше.
не будет никакого параллелизма
а) на дешевых запросах параллельный план не генерируется
б) на олтп системах его генерацию отключают
в) если все-таки энфорсить его то пропускная способность запросов упадет раза в 2, ексчендж операторы знаешь ли не бесплатны
G>У меня ни реального железа, ни реального приложения нет. Одно добавление кеша на такие запросы сделает систему в 100 раз быстрее.
что ты кэшировать собрался? резукльтат запросов?
а)выборка 3х тэгов из 100 дает 1млн комбинаций, пусть по 100 записей по 1к каждая — итого 100ГБ опреативки. Выборка по 4м тэгам так вообще никуда не влезет. Можно конечно поприседать вокруг и уменьшить, но порядок цифр уже говорит сам за себя. При росте объемов требования к оперативке сразу вылетят в стратосферу
б)при пропускной способности 30 запросов\сек ты этот кэш еще и набрать-то не сможешь, этот жалкий миллион будет набираться 10 часов с нагрузкой сервера в 100%.
в)при таком времени набора — он устареет раньше чем туда набьется прилично данных. Вообще сомнительно что ты сможешь при таком подходе набрать достаточный надор данных чтобы от кэша был толк
G>Давай лучше ты покажи класс на NoSQL системе. Те же самые условия, такой же запрос. 300 мс ответа и консистентные результаты.
сделаю позже, сейчас запарка на работе
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ANS>>>SQL — это язык SQL + данные хотя бы в первой НФ + ACID. ANS>>>NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
G>>А чем тогда NoSQL лучше, если это отсутствие?
ANS>Т.е. к формулировке претензий нет ? Лучше, очевидно, тем, что имеют более другие свойства. И эти другие свойства более важны, чем комбинация из первых трёх.
Так вот давай другие свойства, которых в рсубд нету или недостижимы. Описывать NoSQL как отсутствие чего-либо неконструктивно.
Здравствуйте, trophim, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Врут. И врут еще с 2000 версии. Работаем с индексными представлениями еще с 2000 версии. И работало в т.ч. на MSDE.
T>А это как? Расскажите чуть подробнее. Очень интересно оказалось.
Use NOEXPAND if you want to be sure to have SQL Server process a query by reading the view itself instead of reading data from the base tables. If for some reason SQL Server chooses a query plan that processes the query against base tables when you'd prefer that it use the view, consider using NOEXPAND. You must use NOEXPAND in all versions of SQL Server other than Developer and Enterprise editions to have SQL Server process a query against an indexed view directly.
E>>ну скажем MySQL справляется. G>Ох не верится. Я вот на ноуте запись в файл без буферизации прогнал, сильно меньше получилось.
over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит
E>>это уже детали реализации. отправив коммент, мы его можем сразу отобразить, но вот дать гарантию того, что он сохранится, не можем. и дело тут не в типа базы данных. E>>а можем и не отображать до тех пор, пока он не переместится во view базу. E>>собственно, придерживаясь Event Sourcing подхода, мы не можем и писать и читать одновременно. что, имхо, есть правильно. G>не понял о чем ты? Вот мы делаем POST, потом GET. А не изменилось состояние, а потом через несколько GET мы получаем результаты. Это противоречит ожиданиям юзеров.
так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST. а ко времени срабатывания GET, данные синхронизируются и станут актуальными.
E>>это искусственные данные, и они сильно отличаются от того, что может быть на сервере. G>Так слей реальные и прогони, в чем проблема?
у меня нет таких данных. есть другие. но и задача там иные.
E>>такое можно писать в RavenDB. такое можно делать и в других базах, хотя работать будет медленнее. E>>но что это даст? удобство разработки? так рано или поздно тебе в MS SQL придется делать вьюхи. что будет равносильно созданию индекса в NoSQL базе. G>Это даст то что индексированные вьюхи можно написать сильно позже, а в NoSQL ты должен такой дизайн upfront придумать.
не считаю это аргументом. сейчас, или потом, писать всё равно придется.
E>>то есть мы ничего не выигрываем и ничего не теряем. G>Еще как выигрываем
это мнимый выигрыш.
E>>тем более с учетом того, что 80% данных достаются почти всегда по ключу. G>В NoSQL — да, в РСУБД зависит от задачи.
не по ключу мы дергаем данные если
а) мы так организовали структуру данных
б) у нас реляционные данные
но в большенстве случаев все же по ключу.
для всего остального есть view. которые отлично работают и в NoSQL
G>>>Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах. ANS>>Вопрос не ко мне. Но, имхо, ты привратно понимаешь термин NoSql. G>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ну зачем эти глупости? никто никому ничего не противопоставляет. это всего лишь Not Only SQL.
Кстати, SQL всё еще очень плохо умеет xml и FTS. хотя последнее значительно лучше, чем 10 лет назад) но специализированные решения выигрывают.
Здравствуйте, Enomay, Вы писали:
E>>>ну скажем MySQL справляется. G>>Ох не верится. Я вот на ноуте запись в файл без буферизации прогнал, сильно меньше получилось.
E>over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит
Используя Bul Copy в SQL Server можно сильно больше получить, только тут мы теряем ACID. Если в этом цель состоит, то не вижу причин не использовать.
E>так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST.
Почти всегда так и делается.
E>а ко времени срабатывания GET, данные синхронизируются и станут актуальными.
В семантике HTTP заложено что POST изменяет сотояние, а GET — нет. От этого GET можно кешировать. Если момент изменения состояния перемещаешь, то нарушаешь такую логику.
E>>>такое можно писать в RavenDB. такое можно делать и в других базах, хотя работать будет медленнее. E>>>но что это даст? удобство разработки? так рано или поздно тебе в MS SQL придется делать вьюхи. что будет равносильно созданию индекса в NoSQL базе. G>>Это даст то что индексированные вьюхи можно написать сильно позже, а в NoSQL ты должен такой дизайн upfront придумать. E>не считаю это аргументом. сейчас, или потом, писать всё равно придется.
Скорее всего потом не придется. MS SQL на хорошем железе сотни гигабайт держит спокойно, если писать правильно. Даже до таких объемов дорастает малая часть проектов.
E>>>то есть мы ничего не выигрываем и ничего не теряем. G>>Еще как выигрываем E>это мнимый выигрыш.
Это очень реальный выйгрыш в скорости разработки и простоте расширения.
E>>>тем более с учетом того, что 80% данных достаются почти всегда по ключу. G>>В NoSQL — да, в РСУБД зависит от задачи.
E>не по ключу мы дергаем данные если E>а) мы так организовали структуру данных E>б) у нас реляционные данные E>но в большенстве случаев все же по ключу.
В РСУБД у нас реляционные данные
E>для всего остального есть view. которые отлично работают и в NoSQL
View в NoSQL это не View в РСУБД.
Вьюхи в NoSQL базах предварительно вычисляются, это аналогично созданию materialized\indexed view в SQL. Но это уже довольно серьезные оптимизации для SQL, большая часть решается тупо индексами, которые прозрачны для вызывающей стороны. То есть совершенно необязательно создавать индексы заранее.Вполне можно запустить Tuning Adviser, который поработав с реальной нагрузкой расскажет чего надо в базе добавить чтобы быстрее работало.
Здравствуйте, Enomay, Вы писали:
G>>Так вот давай другие свойства, которых в рсубд нету или недостижимы. Описывать NoSQL как отсутствие чего-либо неконструктивно.
E>так ведь везде уже 300 писали E>скорость, масштабируемость, простота и удобство работы, отсутствие четкой схемы документа.
Все это есть в реляционных СУБД.
Кстати проблема определения NoSQL — реальная проблема. Сейчас сложно найти четкое описание, позволяющее классифицировать SQL\NoSQL, а NoSQL решения относят себя к таковым по признакам отсутствия некоторых фич. Как я уже говорил — данная позиция неконструктивна, ибо отсутствие одной фичи не говорит о наличии каких-то других.
Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое.
E>>over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит G>Используя Bul Copy в SQL Server можно сильно больше получить, только тут мы теряем ACID. Если в этом цель состоит, то не вижу причин не использовать.
ACID там нафиг не нужен.
в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач.
E>>так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST. G>Почти всегда так и делается.
где делается? кем делается? тобой? ну ты же не все и не всегда.
E>>а ко времени срабатывания GET, данные синхронизируются и станут актуальными. G>В семантике HTTP заложено что POST изменяет сотояние, а GET — нет. От этого GET можно кешировать. Если момент изменения состояния перемещаешь, то нарушаешь такую логику.
а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема?
E>>не считаю это аргументом. сейчас, или потом, писать всё равно придется. G>Скорее всего потом не придется. MS SQL на хорошем железе сотни гигабайт держит спокойно, если писать правильно. Даже до таких объемов дорастает малая часть проектов.
а у нас не держит. увы.
а если сюда еще добавить огромную посещаемость, то вообще гайки.
E>>это мнимый выигрыш. G>Это очень реальный выйгрыш в скорости разработки и простоте расширения.
ты можешь это для себя утверждать сколько угодно. правдой это не становится.
G>В РСУБД у нас реляционные данные
у вас — да. вы ведь по другому думать не умеете
E>>для всего остального есть view. которые отлично работают и в NoSQL G>View в NoSQL это не View в РСУБД. G>Вьюхи в NoSQL базах предварительно вычисляются, это аналогично созданию materialized\indexed view в SQL. Но это уже довольно серьезные оптимизации для SQL, большая часть решается тупо индексами, которые прозрачны для вызывающей стороны. То есть совершенно необязательно создавать индексы заранее.Вполне можно запустить Tuning Adviser, который поработав с реальной нагрузкой расскажет чего надо в базе добавить чтобы быстрее работало.
то есть, в NoSQL мы создаем VIEW и получаем необходимый результат, тогда как в SQL нам нужно несколько раз к ряду приседать? да ну нафиг такое.
E>>так ведь везде уже 300 писали E>>скорость, масштабируемость, простота и удобство работы, отсутствие четкой схемы документа.
G>Все это есть в реляционных СУБД.
если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL.
да и SQL проигрывает по всем параметрам.
G>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое.
Здравствуйте, Enomay, Вы писали:
E>>>over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит G>>Используя Bul Copy в SQL Server можно сильно больше получить, только тут мы теряем ACID. Если в этом цель состоит, то не вижу причин не использовать.
E>ACID там нафиг не нужен.
Ну так используй BulkCopy
E>в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач.
Это заклинание чтоли? Если ты его не умеешь использовать, то это не значит что не катить. Приведи пример данных и давай забеги проведем MySQL vs SqlServer bulk copy.
E>>>так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST. G>>Почти всегда так и делается.
E>где делается? кем делается? тобой? ну ты же не все и не всегда.
Большинством веб-приложений.
E>>>а ко времени срабатывания GET, данные синхронизируются и станут актуальными. G>>В семантике HTTP заложено что POST изменяет сотояние, а GET — нет. От этого GET можно кешировать. Если момент изменения состояния перемещаешь, то нарушаешь такую логику. E>а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема?
Потому что после post состояние не меняется, оно меняется после.
E>>>не считаю это аргументом. сейчас, или потом, писать всё равно придется. G>>Скорее всего потом не придется. MS SQL на хорошем железе сотни гигабайт держит спокойно, если писать правильно. Даже до таких объемов дорастает малая часть проектов.
E>а у нас не держит. увы.
Значит вы неправильно его используете и все.
E>>>это мнимый выигрыш. G>>Это очень реальный выйгрыш в скорости разработки и простоте расширения. E>ты можешь это для себя утверждать сколько угодно. правдой это не становится.
Ты хочешь сказать что скорость разработки не выйгрыш? Ты в каком мире живешь?
Или может ты покажешь как сделать за 5 минут такой запрос, как я показывал выше? (20 минут вместе с забиванием данных)
G>>В РСУБД у нас реляционные данные E>у вас — да. вы ведь по другому думать не умеете
Не стоит делать таких далекоидущих утверждений Скорее всего это вы не умеете их делать.
E>>>для всего остального есть view. которые отлично работают и в NoSQL G>>View в NoSQL это не View в РСУБД. G>>Вьюхи в NoSQL базах предварительно вычисляются, это аналогично созданию materialized\indexed view в SQL. Но это уже довольно серьезные оптимизации для SQL, большая часть решается тупо индексами, которые прозрачны для вызывающей стороны. То есть совершенно необязательно создавать индексы заранее.Вполне можно запустить Tuning Adviser, который поработав с реальной нагрузкой расскажет чего надо в базе добавить чтобы быстрее работало.
E>то есть, в NoSQL мы создаем VIEW и получаем необходимый результат, тогда как в SQL нам нужно несколько раз к ряду приседать? да ну нафиг такое.
Нет, то что ты называешь View в NoSQL является Materialized\indexed View в SQL. Но производительность в SQL можно поднять вообще не трогая клиентский код, это значит что можно сначала запустить проект, а потом тюнить, а не пытаться оптимальную схему построить с самого начала.
Здравствуйте, Enomay, Вы писали:
E>>>так ведь везде уже 300 писали E>>>скорость, масштабируемость, простота и удобство работы, отсутствие четкой схемы документа.
G>>Все это есть в реляционных СУБД.
E>если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL.
Их используют для кеша.
E>да и SQL проигрывает по всем параметрам.
По каким? Покажешь тест?
G>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>тесты, пруфы. пока это не более чем пустые слова.
Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
E>>ACID там нафиг не нужен. G>Ну так используй BulkCopy E>>в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач. G>Это заклинание чтоли? Если ты его не умеешь использовать, то это не значит что не катить. Приведи пример данных и давай забеги проведем MySQL vs SqlServer bulk copy.
и как это мне bulk copy поможет при запихивании 5к строк в секунду, при том что каждая запись, это http request? давай, расскажи мне, как ты это будешь делать.
E>>где делается? кем делается? тобой? ну ты же не все и не всегда. G>Большинством веб-приложений.
да что ты?
E>>а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема? G>Потому что после post состояние не меняется, оно меняется после.
предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится?
E>>а у нас не держит. увы. G>Значит вы неправильно его используете и все.
ну конечно, ты, не зная всей специфики "авторитетно" заявляешь. пхэ.
E>>>>это мнимый выигрыш. G>>>Это очень реальный выйгрыш в скорости разработки и простоте расширения. E>>ты можешь это для себя утверждать сколько угодно. правдой это не становится. G>Ты хочешь сказать что скорость разработки не выйгрыш? Ты в каком мире живешь? G>Или может ты покажешь как сделать за 5 минут такой запрос, как я показывал выше? (20 минут вместе с забиванием данных)
иногда потеря времени в начале, может обернуться выигрышем в будущем. ты пытаешься делать утверждения без контекста. что глупо.
G>>>В РСУБД у нас реляционные данные E>>у вас — да. вы ведь по другому думать не умеете G>Не стоит делать таких далекоидущих утверждений Скорее всего это вы не умеете их делать.
просто переставил слова местами. ничего интерестного.
E>>то есть, в NoSQL мы создаем VIEW и получаем необходимый результат, тогда как в SQL нам нужно несколько раз к ряду приседать? да ну нафиг такое. G>Нет, то что ты называешь View в NoSQL является Materialized\indexed View в SQL. Но производительность в SQL можно поднять вообще не трогая клиентский код, это значит что можно сначала запустить проект,
а) view в noSQL к производительности не имеет никакого отношения
б) поднять производительность noSQL решений можно так же не трогая клиентский код. только добавив пару тазиков. очень просто.
G>а потом тюнить, а не пытаться оптимальную схему построить с самого начала.
если у тебя схема кривая, то проблемы будут в любой базе. и в MS SQL в том числе. и тюнингом одним ты не отделаешься.
E>>если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL. G>Их используют для кеша.
ложь
E>>да и SQL проигрывает по всем параметрам. G>По каким? Покажешь тест?
в интернете хватает подобного добра.
G>>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>>тесты, пруфы. пока это не более чем пустые слова. G>Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
не вижу ни тестов, ни утверждений. а значит это остается пустыми словами.
Здравствуйте, Enomay, Вы писали:
E>>>ACID там нафиг не нужен. G>>Ну так используй BulkCopy E>>>в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач. G>>Это заклинание чтоли? Если ты его не умеешь использовать, то это не значит что не катить. Приведи пример данных и давай забеги проведем MySQL vs SqlServer bulk copy.
E>и как это мне bulk copy поможет при запихивании 5к строк в секунду, при том что каждая запись, это http request? давай, расскажи мне, как ты это будешь делать.
так складывай в буфер, а потом фигач в базу. У тебя все равно acid нету.
E>>>где делается? кем делается? тобой? ну ты же не все и не всегда. G>>Большинством веб-приложений. E>да что ты?
Да-да, сходу найдешь какойнить проект, где не так? (webforms не в счет)
E>>>а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема? G>>Потому что после post состояние не меняется, оно меняется после. E>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится?
С чего такое предположение? Часто это предположение соотвествует реальности? Скорее всего очень редко. Зачем в этом случае асинхронная обработка?
E>>>а у нас не держит. увы. G>>Значит вы неправильно его используете и все. E>ну конечно, ты, не зная всей специфики "авторитетно" заявляешь. пхэ.
Ну если ты не понимаешь что такое View в SQL.
E>>>>>это мнимый выигрыш. G>>>>Это очень реальный выйгрыш в скорости разработки и простоте расширения. E>>>ты можешь это для себя утверждать сколько угодно. правдой это не становится. G>>Ты хочешь сказать что скорость разработки не выйгрыш? Ты в каком мире живешь? G>>Или может ты покажешь как сделать за 5 минут такой запрос, как я показывал выше? (20 минут вместе с забиванием данных) E>иногда потеря времени в начале, может обернуться выигрышем в будущем. ты пытаешься делать утверждения без контекста. что глупо.
Это скорее ложь чем правда, история полна обратных примеров, когда попытка предусмотреть развите системы оборачивается дальнейшей переделкой архитектуры, тогда как изначально простое решение, потом вполне нормально расширяется:
1)twitter
2)facebook
3)stackoverflow
4)livejournal
именно так и делались, подробности можешь на хайлоде прочитать.
E>если у тебя схема кривая, то проблемы будут в любой базе. и в MS SQL в том числе. и тюнингом одним ты не отделаешься.
В SQL некривая схема обеспечивается нормализацией, а для noSQL есть критерии некривой схемы?
Я вот постил пример: stackoverflow. юзеры, посты, коменты, оценки, теги, юзкейсы можно на сайте посмотреть. Как сделать "некривую" схему на NoSQL?
Здравствуйте, Enomay, Вы писали:
E>>>если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL. G>>Их используют для кеша.
E>ложь
Да ну? Stackoverflow использует redis для кеша, facebook тоже использует для кеширования и оптимизации cassandra кажись. В любом случае за ними стоят нормальные sql-acid-субд.
Единственный только твиттер не использует, потому что у него количество записей в единицу времени просто заоблачное.
E>>>да и SQL проигрывает по всем параметрам. G>>По каким? Покажешь тест? E>в интернете хватает подобного добра.
Ссылку дай, разговоров в интернете полно, а результатов забегов нет. Я тут проводил забеги, SQL вполне нормальные результаты показывает и нету смысла использовать что-то еще пока нагрузка не возросла.
G>>>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>>>тесты, пруфы. пока это не более чем пустые слова. G>>Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
E>не вижу ни тестов, ни утверждений. а значит это остается пустыми словами.
Ты тему читаешь вообще?
Давай ты сначала прочитаешь сначала, а потом будешь писать, ок?
Лучше, очевидно, тем, что имеют более другие свойства. И эти другие свойства более важны, чем комбинация из первых трёх.
