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

N>Дата-склад система в большом инвест-банке. Хранит ежедневные риск-метрики (~100 чисел в среднем) к каждому активному контракту в течении 5 лет. Запросы — выборки с агрегацией по книжкам, портфелям, контрагентам. OLTP не нужен, загрузка данных происходит только в строго определенное время пакетами. В данный момент система покрывает только часть бизнеса и занимает ~100ТБ. Если масштабировать ее на весь банк будет ~х8. Используют оракл на мегабаксе железа (RHat/x86-64, не "золотое" от оракл). Несмотря на это половина команды непрерывно занята оптимизацией.
N>Что бы ты рекомендовал из OSS?
Я не знаю деталей запросов. Может быть что угодно, от старого недоброго Hadoop до какого-нибудь MongoDB. Могу сказать, что у нас есть клиенты, которые обрабатывают порядка петабайта данных (фиды со всех социальных и рекламных сетей) за ночь на Hadoop.

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

C>>Ну таки не совсем простейшая.
AVK>Тут дело не столько в простоте, сколько в отсутствии жесткой структуры. ПОиск по большей части данных все равно полнотекстовый, так что от непосредственно реляционного движка толку не очень много.
Там скорее важно то, что записи каждого пациента не зависят от остальных.

C>>Ну вообще-то, 80Тб всего. Что тоже не сильно чтобы много.
AVK>Там большая часть по объему наверняка снимки и томограммы. И от БД требуется исключительно их хранить. Понятно что для такого РСУБД изрядкный оверкилл, а вот в случае nosql задачка просто идеально подходит.
Не совсем. Там полуструктурированные HL7-данные, которые прекрасно ложатся на JSON. Ещё от Riak'а у них взята распределённость — данные реплицируются между несколькими центрами.

G>>>Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут.
C>>Никто не мешает взять RDS или всякие Data Warehosing решения для оффлайновых запросов для отчётов, а оперативный процессинг перевести на быстрые БД.
AVK>У оперативного процесса очень много коллизий + распределенные транзакции. NoSQL не поедут.
Ну вообще-то, NoSQL есть поддерживающие целостность и распределённые транзакции. Но именно для OLTP реляционки имеют смысл.

AVK>Жопа для производителей РСУБД в другом. Объемы данных какие были, такие и остались, сильно не выросли. И если, простой пример, раньше в оперативном учете трахались по черному с онлайновыми кубами, выдумывая всякие хитро выделанные кеши с кучей танцев по их поддержанию, то теперь железо такое, что для типичной средней конторы способно легко и непринужденно перемалывает всю историю в реальном времени, тупо подняв все горячие данные в память.
Ага, а то что таки выросло — оказалось обрабатывать РБД-шныеми методами не очень удобно.

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

C>Ну вообще-то, NoSQL есть поддерживающие целостность и распределённые транзакции.

Мы это все в свое время обсуждали. Там либо гарантии фиговые, для оперденей в принципе не пригодные, либо перформанс тут же скатывается до уровня плохих РСУБД. Чудес не бывает, за все надо платить.

C> Но именно для OLTP реляционки имеют смысл.

Ну так опердень это и есть классический OLTP.

C>Ага, а то что таки выросло — оказалось обрабатывать РБД-шныеми методами не очень удобно.

Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно.

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

C>>Ну вообще-то, NoSQL есть поддерживающие целостность и распределённые транзакции.
AVK>Мы это все в свое время обсуждали. Там либо гарантии фиговые, для оперденей в принципе не пригодные, либо перформанс тут же скатывается до уровня плохих РСУБД. Чудес не бывает, за все надо платить.
Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга.

C>> Но именно для OLTP реляционки имеют смысл.
AVK>Ну так опердень это и есть классический OLTP.
Да, с него РБД никто не собирается убирать.

C>>Ага, а то что таки выросло — оказалось обрабатывать РБД-шныеми методами не очень удобно.
AVK>Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно.
Не совсем. РСУБД предполагает, что данные хранятся в однородных таблицах, которые можно джойнить. Если есть петабайт данных, то это уже не так — нужно делать тот или иной шардинг, а произвольные join'ы становятся неоправданно дорогими.

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

C>Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга.

Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью.

AVK>>Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно.
C>Не совсем.

Совсем.

C> РСУБД предполагает, что данные хранятся в однородных таблицах, которые можно джойнить.

Если данные хорошо структурированы

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

C>>Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга.
AVK>Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью.
Не согласен.

AVK>>>Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно.
C>>Не совсем.
AVK>Совсем.
Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.

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

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

AVK>>Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью.
C>Не согласен.

Ради бога.

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

Ну а в NoSQL тебе придется джоин делать руками. Ну так руками можно джойнить и в РСУБД.

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

C>>>Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга.
AVK>>Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью.
C>Не согласен.

Встряну. Сложности шардинга проистекают прежде всего из постановки задачи: какой предикат для разбиения на шарды не возьми, в чём-нибудь да потеряешь. На моё ИМХО, самая халява тут — когда пользователи системы (или группы пользователей — клиенты) друг от дружки изолированы: тогда бьём по пользвателям/клиентам. А синтетические отчёты — да хрен с ними, на худой конец можно в духе map/reduce забабахать. А вот как, например, шардить форум (или соц. сеть какую-нибудь), где все в одном котле варятся — ХЗ. По датам начала веток разве что, больше ничего в голову не приходит. Так вот: все вышеприведённые рассуждения совершенно ортогональны выбору между SQL и NoSQL.

С транзакциями ещё проще, выбор "в чём потерять" сводится к трём альтернативам: берём CAP-теорему и решаем, какую из трёх букв нам менее всего жалко. Мне вот P было не жалко, мне ни разу не попадались задачи, в которых 24/7 было бы настолько критично, чтобы городить дублирующие инфраструктуры, усложняя всю кухню на порядок (что по ощущениям даёт обратный результат: на 10 серверах что-нибудь обязательно будет сбоить чаще, чем на одном). Поэтому я тупо взял и заюзал Atomikos JTA. Не без винтиков на уровне структуры базы, но винтики все достаточно простые и само-напрашивающиеся.

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

C>>Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.
AVK>Ну а в NoSQL тебе придется джоин делать руками. Ну так руками можно джойнить и в РСУБД.
Можно. Только тогда РСУБД становятся аналогами NoSQL, о чём речь и идёт.

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

C>Я не знаю деталей запросов.
Я же описал. Обычные запросы с фильтром (where) и агрегацией(sum/groupby). Модель нормализована, то есть join-ов много, в среднем запросе наверное ~10.

C>Может быть что угодно, от старого недоброго Hadoop до какого-нибудь MongoDB. Могу сказать, что у нас есть клиенты, которые обрабатывают порядка петабайта данных (фиды со всех социальных и рекламных сетей) за ночь на Hadoop.
Дело не только в петабайтах, а в том что модель запросов реляционная. Запихать данные просто, а как их отдать? На NoSql есть два варианта:
а) писать джойнеры/агрегаторы вручную для каждого запроса. Это дорого, запросов разных много.
б) делать свой велосипедный sql. Скорее всего выйдет хуже чем у оракла.

Они кстати попытались сделать б) только на Coherence. В результате вышла жопа. ИМХО для такой задаче стоит все же использовать реляционную базу.
Остается Postgres. В других группах его пытались использовать на похожих задачах. Опыт плохой — "fucking VACCUM" и т.д.

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

C>>Может быть что угодно, от старого недоброго Hadoop до какого-нибудь MongoDB. Могу сказать, что у нас есть клиенты, которые обрабатывают порядка петабайта данных (фиды со всех социальных и рекламных сетей) за ночь на Hadoop.
N>Дело не только в петабайтах, а в том что модель запросов реляционная. Запихать данные просто, а как их отдать? На NoSql есть два варианта:
N>а) писать джойнеры/агрегаторы вручную для каждого запроса. Это дорого, запросов разных много.
Но зато быстрее работает. Кроме того, сложные аггрегации обычно на map-reduce можно проще писать, чем на SQL.

N>б) делать свой велосипедный sql. Скорее всего выйдет хуже чем у оракла.
Это вообще в морг.

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

AVK>С чего бы это? Или ты считаешь что на HFT фин. сектор заканчивается?
С того что обычно решение о приобретении такого софта принимают люди с тугим кошельками, маленькими мозгами, не имеющие к ИТ почти никакого отношения.

AVK>Э, ты ж сказал что если второй, то последний. Так откуда "или" взялось?
Ну если это не спарки (тот самый мегабакс суберакса), то они примерно равны. sql server и postgres/symfoware в тестах tpc-c явно слабее.

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

N>Я же описал. Обычные запросы с фильтром (where) и агрегацией(sum/groupby). Модель нормализована, то есть join-ов много, в среднем запросе наверное ~10.

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

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

AVK>>С чего бы это? Или ты считаешь что на HFT фин. сектор заканчивается?
__>С того что обычно решение о приобретении такого софта принимают люди с тугим кошельками, маленькими мозгами, не имеющие к ИТ почти никакого отношения.

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

__> sql server и postgres/symfoware в тестах tpc-c явно слабее.

Тем не менее sql server имеет свой вполне ощутимый кусок рынка. Опять же, в плане Price/Performance mssql слабее не выглядит.

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

Здравствуйте, a_g_99, Вы писали:
__>Ну если это не спарки (тот самый мегабакс суберакса), то они примерно равны. sql server и postgres/symfoware в тестах tpc-c явно слабее.
Я правильно понимаю, что вы сравниваете oracle 2013 года с MS SQL 2011?
На всякий случай, поясню, что MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад. В разное время все из большой тройки побывали в лидерах, поэтому с уверенностью судить о том, кто слабее сейчас, я бы не стал.

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

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

C>ROTFL. А на чём оно будет "вертикально масштабироваться"? На воздухе, или ему ещё купить кластерочек за мегабакс и пару пучков консультантов по $500 в час?
Насколько я понял эта штука riak масштабируется горизонтально и должна иметь избыточность для надежности. Это говноконторе NHS оно надо чтобы хранить карточки пациентов? Им легче поставить один кластер, где каждый сервер будет работать без избыточности. Ну и зачем им этот riak?
По поводу консультантов — этот riak тоже предоставляет ps. В чем разница, в деньгах? Если они дорастут до уровня оракл, сами из рыцарей на белых конях превратятся в драконов.

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

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

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

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

Ваш вывод — "MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад", поэтому могут быть на уровне или сильнее?
Обратные выводы напрашиваются сами собой

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

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

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

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

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

__>Ваш вывод — "MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад", поэтому могут быть на уровне или сильнее?
Конечно могут. За эти три версии было сделано много оптимизаций, которые влияют на перформанс в OLTP.
__>Обратные выводы напрашиваются сами собой
Делать выводы по тестам — сложная наука.
Вот я смотрю, к примеру, в две вот такие записи:
HP ProLiant DL580G5 639,253 .97 USD NR 01/26/09 Oracle Database 11g Standard Edition Oracle Enterprise Linux TP Microsoft COM+
HP ProLiant DL580G5 634,825 1.10 USD NR 09/15/08 Microsoft SQL Server 2005 Enterprise Edition x64 SP2 Microsoft Windows Server 2003 R2 Enterprise Edition x64
и вижу, что Оракл на аналогичном железе отличается от SQL Server по производительности ажно на 0.7%.
Должен ли я сделать вывод, что "MS SQL явно слабее"?
Или надо посмотреть на
HP ProLiant DL370 G6 631,766 1.08 USD NR 03/30/09 Oracle Database 11g Standard Edition One
HP ProLiant DL370 G6 661,475 1.16 USD NR 02/01/10 Microsoft SQL Server 2005 Enterprise Edition x64 SP2
и сделать вывод, что явно слабее тут Оракл?