Здравствуйте, a_g_99, Вы писали:

C>>Да, для масштаба страны вполне адекватно.
__>Напоминает обычный попил бабла. В Британии госконторы такое очень любят, знаю по личному опыту. Только сначала они пилили на оракле, а сейчас на open source.
Не всё является распилом, как ни странно.

C>>ROTFL. А на чём оно будет "вертикально масштабироваться"? На воздухе, или ему ещё купить кластерочек за мегабакс и пару пучков консультантов по $500 в час?
__>Насколько я понял эта штука riak масштабируется горизонтально и должна иметь избыточность для надежности.
У меня для тебя новость — избыточность для надёжности нужна и в случае с Oracle. Так как дата-центры могут отключаться от сети, взрываться террористами или серверы могут просто ломаться.

__>Это говноконторе NHS оно надо чтобы хранить карточки пациентов? Им легче поставить один кластер, где каждый сервер будет работать без избыточности. Ну и зачем им этот riak?
Что значит "кластер, где каждый сервер будет работать без избыточности"?

__>По поводу консультантов — этот riak тоже предоставляет ps. В чем разница, в деньгах? Если они дорастут до уровня оракл, сами из рыцарей на белых конях превратятся в драконов.
У Riak'а суммы на порядок меньше.

C>>Всего хватает. Если речь идёт о финансах, то там важны не in-memory данные, а надёжность.
__>Я вижу тут у каждого Емели свое мнение что должно быть в финансах, хотя 3/4 этих консультантов этих финансов и в глаза не видели. Правда у рынка другое мнение.
Вообще-то, видел вживую. В том числе и не очень стандартные финансы.

C>>ROTFL. Так что когда эта мега-система упадёт — придётся просить помощи в web'е, так как даже сами консультанты разработчика не знают где искать концы. См.: "Сбербанк".
__>Может мне еще ВТБ погуглить и сразу в санкционный список после этого? Этим ребятам дай электронный микроскоп, они им гвозди начнут забивать или ямы копать. Вы еще почту России вспомните.
Я говорю про случай, когда вся банкоматовская сеть Сбербанка день лежала.

Здравствуйте, Sinclair, Вы писали:

S>Это что, типа "покажи мне адреса top-100 пользователей по количеству просмотров баннера #12323451"?
Дал почитать эту тему нашему клиенту — он мне сразу сказал какой запрос они сегодня писали: "найти пользователей, у которых минимальное[или среднее] время между кликами на баннеры меньше среднего для всех пользователей".

Здравствуйте, Sinclair, Вы писали:

S>На всякий случай, поясню, что MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад. В разное время все из большой тройки побывали в лидерах, поэтому с уверенностью судить о том, кто слабее сейчас, я бы не стал.
TPC-C нынче перестал быть репрезентабельным совсем.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:

C>>>Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.
S>>А можно пример "реального" запроса c join?
S>>Это что, типа "покажи мне адреса top-100 пользователей по количеству просмотров баннера #12323451"?
C>Типа: "компания, баннер которой пользователь кликал наиболее часто, для каждого пользователя".
таблички, я так понимаю, user(id, name), banner(id, companyname), click(clickid, bannerid, userid, timestamp)?
И user зашардена на 4 машины по id, и click зашардена на 4 машины по clickid?
И вас беспокоит перформанс операции

with clickStats(userId, bannerId, clicks) as select bannerId, userId, count(clickid) from click group by bannerId, userId
with topClicks(userId, bannerId) as select userId, bannerId from clickStats where (rank() over (partition by userId order by clicks desc)) = 1
select user.name, company.name from topClicks 
  inner join banner on banner.id = topClicks.bannerId 
  inner join user on user.id = topClicks.userId

?

C>Для NoSQL:
C>1) Делаем map на таблицу click, доставая оттуда пользователя.
C>2) Делаем reduce — считаем и группируем по пользователям.
Что именно мы тут "группируем по пользователям"? Просто считаем клики? А как же bannerId? Или я не понимаю смысла операции group by?

C>3) Делаем постобработку — выбираем самую частую компанию (можно тоже через map-reduce).

C>Первые два шага могут выполняться на узлах, на которых лежат данные, так как операция reduce здесь ассоциативна.
Это хорошо. Теперь давайте оценим "объём трафика", который будет передаваться между нодами в вашем решении. Предположим, что характерные количества баннеров — B, пользователей — U, кликов — C.
Понятно, что C >> B*U, U >> B.

Здравствуйте, Cyberax, Вы писали:
S>>Это что, типа "покажи мне адреса top-100 пользователей по количеству просмотров баннера #12323451"?
C>Дал почитать эту тему нашему клиенту — он мне сразу сказал какой запрос они сегодня писали: "найти пользователей, у которых минимальное[или среднее] время между кликами на баннеры меньше среднего для всех пользователей".
Ухты. И по какому принципу вы предполагаете шардить табличку click?
Я не представляю себе, как можно вычислить результат этого запроса, не передавая недостающие 7.5 TБ данных на одну машину.
Если же шардинг делается по диапазону дат, т.е. из четырёх серверов три — архивные, то для таких запросов RDBMS убъют любой NoSQL благодаря индексам.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:

C>>>Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.
S>>А можно пример "реального" запроса c join?
S>>Это что, типа "покажи мне адреса top-100 пользователей по количеству просмотров баннера #12323451"?
C>Типа: "компания, баннер которой пользователь кликал наиболее часто, для каждого пользователя".

S>>Если нет — то приведите "на пальцах" такой запрос. И примерный план его выполнения на NoSQL, который помогает избегать "тонны кросс-траффика между узлами".
C>Для NoSQL:
C>1) Делаем map на таблицу click, доставая оттуда пользователя.
C>2) Делаем reduce — считаем и группируем по пользователям.
C>3) Делаем постобработку — выбираем самую частую компанию (можно тоже через map-reduce).

C>Первые два шага могут выполняться на узлах, на которых лежат данные, так как операция reduce здесь ассоциативна.


Что-то ты фантазируешь. У тебя клики и пользователи лежат на разных узлах, то есть ты не можешь на одном узле сделать шаг 1, тебе придется на два бегать, а это "тонны кросс-траффика между узлами".
Если же в твоей задаче данные о пользователях лежат вместе с кликами, то и в случае SQL проблем не будет никаких, и есть подозрение что РСУБД порвет в какашки решение на map-reduce.

Кстати это OLAP задача, которая в том же SQL Server прекрасно решается. И для 10 ТБ вообще нет смысла ставить несколько машин. Купить один толстый сервер и кучу дисков дешевле, чем купить 4 сервера потоньше, и дисков на те же 10ТБ.

Здравствуйте, Cyberax, Вы писали:

C>У меня для тебя новость — избыточность для надёжности нужна и в случае с Oracle. Так как дата-центры могут отключаться от сети, взрываться террористами или серверы могут просто ломаться.
Опять террористы. Как начинается дискуссия rdbms vs noSQL, Бен Ладен сразу начинает активно откапываться со злыми намерениями. Не надоело?
В конце концов любой норм. rdbms поддерживает резервирование и опции failover cluster.

C>Что значит "кластер, где каждый сервер будет работать без избыточности"?
Напр. oracle rac это много больше чем просто избыточность.

Oracle RAC позволяет нескольким экземплярам (англ. instance) Oracle Database, функционирующим на различных аппаратных узлах, работать с единой базой данных. При этом не требуется вносить модификации в клиентское программное обеспечение, для которого кластеризованная база данных доступна как единый логический экземпляр, как и для инсталляций без RAC.
Каждый дополнительный узел кластера обеспечивает дополнительные вычислительные ресурсы для обработки данных, в том числе поддержаны параллелизация запросов между узлами кластера, конвейерный параллелизм, и тем самым обеспечивается масштабируемость сервера базы данных. В случае сбоя одного из узлов кластера, программное обеспечение RAC переносит все сессии на другой узел. Также RAC обеспечивает программную балансировку нагрузки между узлами кластера.

На самом деле там столько дерьмофич, что ни одна вменяемая контора не использовала и половины.

C>У Riak'а суммы на порядок меньше.
Будет расти компания, вырастут и суммы.

C>Я говорю про случай, когда вся банкоматовская сеть Сбербанка день лежала.
Это плохой пример. Я бы вам объяснил почему, но так и до гулага договориться можно

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>Хм, если им для хранения данных оказалось достаточно просто свалки key-value, без транзакций, без гарантий надежности, вообще без всего — то даже страшно подумать, а зачем вообще NHS был нужен Oracle, да еще и на десять млн. долларов.
Зачем зачем... Вы же не думаете, что откаты это только российское know how

ДФ>И, главное, а кто будет отвечать за потерю данных и потерю целостности

Здравствуйте, Cyberax, Вы писали:

C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition

C>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Некая организация перещла с неподходящей им системы на бодее подходящую. Ничего из ряда вон выхолящего.

Здравствуйте, Cyberax, Вы писали:

C>Типа: "компания, баннер которой пользователь кликал наиболее часто, для каждого пользователя".

Для этого никакой джойн не нужен.

Здравствуйте, Miroff, Вы писали:

M>Любая columnar databse и map/reduce для запросов.

Возможно имеет смысл, конкурирующая группа возится с Vertica. Только это не OSS, оно стоит дороже оракла.

Здравствуйте, AndrewVK, Вы писали:

AVK>Для этого никакой джойн не нужен.
Давай подождём уточняющих ответов.
Если я правильно понимаю, то там хватит distributed partitioned views, и трафик будет вполне себе приемлемым.
Более того — запросто может оказаться, что RDBMS работает с 10ТБ безо всякого шардинга, благодаря использованию индексов. А тупой NoSQL способен хоть как-то прожевать запрос только в том случае, если у него все 10Tb влезают в RAM.

Здравствуйте, novitk, Вы писали:

N>Возможно имеет смысл, конкурирующая группа возится с Vertica. Только это не OSS, оно стоит дороже оракла.

Это всего лишь одно решение, бывает и OSS.

Здравствуйте, Miroff, Вы писали:

M>Это всего лишь одно решение, бывает и OSS.

Например? Нужна популярность, масштабируемость и язык запросов. Hbase не имеет последнего, а к всяким Infobright есть вопросы по первым двум.

Здравствуйте, novitk, Вы писали:

N>Например? Нужна популярность, масштабируемость и язык запросов. Hbase не имеет последнего, а к всяким Infobright есть вопросы по первым двум.

Если под языком запросов понимать SQL то прикручивать его к колоночным базам данных это на редкость плохая идея. Если уж очень хочется, то написать транслятор из ограниченного множества SQL в map/reduce для HBase не особенно трудно.

Здравствуйте, Miroff, Вы писали:

M>Если под языком запросов понимать SQL то прикручивать его к колоночным базам данных это на редкость плохая идея.
Почему? Что именно колоночные данные меняют?

M>Если уж очень хочется, то написать транслятор из ограниченного множества SQL в map/reduce для HBase не особенно трудно.
Простую реализации может и не трудно, а с оптимизатор задача перестает быть тривиальной.

Здравствуйте, novitk, Вы писали:

N>Почему? Что именно колоночные данные меняют?
N>Простую реализации может и не трудно, а с оптимизатор задача перестает быть тривиальной.

Вот именно это и меняют.

Можно сделать хоть какой-нибудь транслятор, а оптимизировать только то что необходимо путем переписывания запросов с SQL на M/R вручную.

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, novitk, Вы писали:

N>>Например? Нужна популярность, масштабируемость и язык запросов. Hbase не имеет последнего, а к всяким Infobright есть вопросы по первым двум.

M>Если под языком запросов понимать SQL то прикручивать его к колоночным базам данных это на редкость плохая идея.

Что за бред? В MS SQL сделали clustered columnstore индексы, по сути поколоночное хранение данных, с ним нормально SQL работает, да еще и batch execution.

Здравствуйте, Miroff, Вы писали:

M>Можно сделать хоть какой-нибудь транслятор, а оптимизировать только то что необходимо путем переписывания запросов с SQL на M/R вручную.

Возникает куча вопросов интеграции SQL и ручного М/R. Скажем смогу ли я сделать вьюху на ручном М/R и использовать ее в SQL?
А вообще есть ли факты что SQL проигрывает ручному M/R на реляционной модели с современными оптимизаторами? Я вполне могу понять, что row backstore или полный ACID для задачи может быть не оптимален, но SQL то за что?