C>>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных. G>Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream?
Э, не. Тут вопрос не в том, "что мешает", а в том, "зачем".
Вся сила реляционок — в ad-hoc запросах, где важны отношения. Для хранения неструктурированных или слабоструктурированных данных никаких преимуществ реляционка не даст. Тем более, если задача не включает в себя OLTP.
Но вот проекты типа stackoverflow практически полностью построены на перекрёстных ссылках, в которых как раз реляционки традиционно сильны. Порвать их на этом поле будет крайне сложно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Miroff, Вы писали:
G>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
M>Сколько стоит этот "хороший сервак"? Что будет, когда он перестянет тянуть? Сколько будет стоить изменение структуры базы в 100Гб под нагрузкой? Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"?
Я тут рядом приводил пример хорошего сервака. 100гб влезет и в плохонький, стоимостью в пределах $3000.
Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ... S>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
А min к примеру мы из чего получим?
S>За остальным можно обратиться к университетскому курсу мат.статистики.
Это ты круто вывернулся с примером-то. Прям может сложиться впечатление, что любой агрегат может быть выражен через то, есть в наличии. А тот, кто усомнился — тот лох и недоучка, пусть читает книжки.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>Не ляжет. Ситуация похожа на ситуацию с индексом по булевскому полю — он бесполезен, так как обычно не уменьшает число рядов, которые надо просканировать. S>>Продолжаю непонимать. Выборка ID тегов делается в один приём. C>Блин, да не в ID дело.
Именно в ID. Выборка по ключу всегда делается максимально эффективно. Основная проблема в получении списка ключей для выборки.
S>>Теперь у нас есть эффективный способ выбрать все статьи, помеченные этими тегами. C>Нету. У тебя есть не особо эффективный способ (так как результатов очень много) выбрать все статьи с данным тэгом. А вот хорошего способа заджойнить результаты выборки по нескольким тэгам уже нет.
Неправда, см мой пост про индексы и FTS.
S>>Ну и, конечно же, главный вопрос — а как вы собрались догонять шустродействие SQL здесь при помощи NoSQL? C>Key-value хранилище + индексный lookup по наименее частовстречающемуся тэгу/тэгам + распределённое сканирование остальных рядов. В теории оно возможно и на реляционной БД, но что-то я пока не слышал, чтобы кто-то кроме Oracle'овского RAC'а умел делать распределённые выборки.
Вот с этого места поподробнее. Какая структура будет у хранимых ключей и значений чтобы эффективно обеспечивались другие кейсы, кроме указанной выборки по совокупности тегов?
Кстати стоит учесть что выборка по совокупности тегов — далеко не самый частый кейс. Более того, на примере stackoverflow, в интерфейсе вообще нет возможности получить такую выборки, только ручками набивать в url.
Ты лучше расскажи как ты будешь реализовывать на Key-value то что я в первом посте написал.
Здравствуйте, Sinclair, Вы писали:
C>>>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных. G>>Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream? S>Э, не. Тут вопрос не в том, "что мешает", а в том, "зачем". S>Вся сила реляционок — в ad-hoc запросах, где важны отношения. Для хранения неструктурированных или слабоструктурированных данных никаких преимуществ реляционка не даст. Тем более, если задача не включает в себя OLTP.
Ну какбы именно это и решается фичами типа filestream и xml, чтобы можно было использовать РБД для работы с нереляционными данными. Когда все в одном месте — управлять проще.
S>Но вот проекты типа stackoverflow практически полностью построены на перекрёстных ссылках, в которых как раз реляционки традиционно сильны. Порвать их на этом поле будет крайне сложно.
Да нету там засилия "перекрестных ссылок", очень типовой веб-два-нольный сайт.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sinclair, Вы писали:
L>>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ... S>>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
L>А min к примеру мы из чего получим?
Для всей таблицы — из индекса по полю. В остальных случаях — ручками в триггерах агрегировать.
S>>Теперь у нас есть эффективный способ выбрать все статьи, помеченные этими тегами. C>Нету. У тебя есть не особо эффективный способ (так как результатов очень много) выбрать все статьи с данным тэгом. А вот хорошего способа заджойнить результаты выборки по нескольким тэгам уже нет.
Да ну? Есть у меня вполне себе прекрасный способ.
Всё зависит от селективности выборок по каждому из тегов.
S>>Ну и, конечно же, главный вопрос — а как вы собрались догонять шустродействие SQL здесь при помощи NoSQL? C>Key-value хранилище + индексный lookup по наименее частовстречающемуся тэгу/тэгам + распределённое сканирование остальных рядов. В теории оно возможно и на реляционной БД, но что-то я пока не слышал, чтобы кто-то кроме Oracle'овского RAC'а умел делать распределённые выборки.
Ага, то есть ключ к успеху — в лукапе по наиболее селективному предикату? Ну так он в RDBMS точно так же побежит.
"Распределённое сканирование" потребуется ой как не скоро — не при масштабах stackoverflow.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
S>>>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
L>>А min к примеру мы из чего получим? G>Для всей таблицы — из индекса по полю.
Для всей таблицы не интересно. Интересно с группировкой.
G>В остальных случаях — ручками в триггерах агрегировать.
Собственно, что и требовалось доказать:
Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
Здравствуйте, Lloyd, Вы писали:
L>Для всей таблицы не интересно. Интересно с группировкой.
G>>В остальных случаях — ручками в триггерах агрегировать.
L>Собственно, что и требовалось доказать: L>
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>
Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
Здравствуйте, gandjustas, Вы писали:
G>>>В остальных случаях — ручками в триггерах агрегировать.
L>>Собственно, что и требовалось доказать: L>>
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>>
G>Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
Давай, прочитай еще раз, что я написал. Уверен, с третей попытки получится. Ключевые слова я выделил.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>>>В остальных случаях — ручками в триггерах агрегировать.
L>>>Собственно, что и требовалось доказать: L>>>
L>>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>>>
G>>Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
L>Давай, прочитай еще раз, что я написал. Уверен, с третей попытки получится. Ключевые слова я выделил.
Интересно увидеть сценарий, где у материализованной вьюхи понадобится и сумма, и минимум\максимум.
Здравствуйте, gandjustas, Вы писали:
G>>>Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
L>>Давай, прочитай еще раз, что я написал. Уверен, с третей попытки получится. Ключевые слова я выделил.
G>Интересно увидеть сценарий, где у материализованной вьюхи понадобится и сумма, и минимум\максимум.
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
вы отстали от жизни
Aggregate functions perform a calculation on a set of values and return a single value. Traditionally, Microsoft SQL Server has supported only built-in aggregate functions, such as SUM or MAX, that operate on a set of input scalar values and generate a single aggregate value from that set. SQL Server integration with the Microsoft .NET Framework common language runtime (CLR) now allows developers to create custom aggregate functions in managed code, and to make these functions accessible to Transact-SQL or other managed code.
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
R>вы отстали от жизни
R>
R>Aggregate functions perform a calculation on a set of values and return a single value. Traditionally, Microsoft SQL Server has supported only built-in aggregate functions, such as SUM or MAX, that operate on a set of input scalar values and generate a single aggregate value from that set. SQL Server integration with the Microsoft .NET Framework common language runtime (CLR) now allows developers to create custom aggregate functions in managed code, and to make these functions accessible to Transact-SQL or other managed code.
Здравствуйте, rm822, Вы писали:
R>вы отстали от жизни
R>
R>Aggregate functions perform a calculation on a set of values and return a single value. Traditionally, Microsoft SQL Server has supported only built-in aggregate functions, such as SUM or MAX, that operate on a set of input scalar values and generate a single aggregate value from that set. SQL Server integration with the Microsoft .NET Framework common language runtime (CLR) now allows developers to create custom aggregate functions in managed code, and to make these functions accessible to Transact-SQL or other managed code.
Напиши в microsoft, скажи им, что они тоже отстали от жизни и не знают фич своего же продукта:
Unfortunately, floating point hardware on different computers (even with the same processor architecture from the same manufacturer) does not always stay 100% the same from version to version of the processor. A firmware upgrade might mean that (a*b) on the new hardware is not equal to (a*b) on the old hardware, for some floating point values a and b. For example, the results might be very close, but differ in the least significant bit. Persisting the imprecise computed values before indexing them solves this detach/attach inconsistency problem since all expressions are evaluated on the same computer during database update and maintenance of indexes and indexed views.
* Common Language Runtime (CLR) types. A major new feature of SQL Server 2005 is support for user-defined types (UDTs) and user-defined functions based on the CLR. Indexed views can be defined on CLR UDT columns, or expressions derived from those columns, provided that the columns or expressions are deterministic, and precise, persisted, or both. CLR user-defined aggregates cannot be used in an indexed view.
Здравствуйте, Sinclair, Вы писали:
S>Я тут рядом приводил пример хорошего сервака. 100гб влезет и в плохонький, стоимостью в пределах $3000. S>Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа.
а почему в обсуждении вообще игнорируется такой параметр как fault tolerant, или если сервак >10k то он "вечный" пока не выйдет новая аппаратная платформа?
Здравствуйте, gandjustas, Вы писали:
M>>Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"? G>Незачем, тупо дешевле выходит один хороший сервак купить.
Учитывая что с увеличением стоимости производительность сервера увеличивается нелинейно, не уверен что это будет даже дешевле. Кроме того, единственный сервер БД это в любом случае потенциальная точка отказа.
Здравствуйте, cadet354, Вы писали:
S>>Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа. C>а почему в обсуждении вообще игнорируется такой параметр как fault tolerant, или если сервак >10k то он "вечный" пока не выйдет новая аппаратная платформа?
Потому что вопросы fault tolerance здесь не поднимались. На всякий случай намекну, что HighAvailability != LoadBalancing. Особенно для stateful компонентов, которыми являются базы данных.
Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, cadet354, Вы писали:
S>>>Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа. C>>а почему в обсуждении вообще игнорируется такой параметр как fault tolerant, или если сервак >10k то он "вечный" пока не выйдет новая аппаратная платформа? S>Потому что вопросы fault tolerance здесь не поднимались. На всякий случай намекну, что HighAvailability != LoadBalancing. Особенно для stateful компонентов, которыми являются базы данных.
т.е. "обычным приложениям" fault tolerance не нужен, понятно что даже 98% простым распределением нагрузки не получишь (это суммарно около недели в год, думаю под обычные приложения вполне попадает), но это один из необходимых методов решения single point of failure S>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть.
только стоят как самолет.
