Здравствуйте, Cyberax, Вы писали:
C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition
Этож простейшая система
Естественно делать такое на Oracle это overkill, а с учетом цены лицензий вообще выглядит плохой идеей. Да и объемы них не космические 80млн записей, даже если каждая по МБ (что очень много), то 80 ГБ всего.
C>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Потому что задача по нынешнем меркам маленькая. А 10 лет назад те же величины были офигенно большими.
C>Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут.
C>Discuss.
Учитывая что РСУБД сейчас начинают применять inmemory технологии, то могут через 5-10 лет отжать рынок небольших и несложных систем у NoSQL. А могут и не отжать, зависит от цены впороса.
При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
Здравствуйте, Cyberax, Вы писали:
G>>Учитывая что РСУБД сейчас начинают применять inmemory технологии, то могут через 5-10 лет отжать рынок небольших и несложных систем у NoSQL. А могут и не отжать, зависит от цены впороса. C>Могут, но при этом станут неотличимы от этих самих NoSQL.
Транзакции и прочие isolation levels со всякими constraints — т.е. всё то, чем в NoSQL и не пахнет — никуда не денутся ж? При этом ЕМНИП ты сам же не так давно рассказывал, что с последними патчами в выборке записи по ключу PostgreSQL догнал по скорости Mongo.
Здравствуйте, Cyberax, Вы писали:
G>>Этож простейшая система C>Ну таки не совсем простейшая.
Тут дело не столько в простоте, сколько в отсутствии жесткой структуры. ПОиск по большей части данных все равно полнотекстовый, так что от непосредственно реляционного движка толку не очень много.
Еще один очень важный момент — вероятность коллизий при записи для медбаз близка к 0, это категорически, просто таки принципиально все упрощает. Большая часть наворотов промышленных РСУБД в таком режиме крутится вхолостую. Из пушки по воробьям.
G>>Естественно делать такое на Oracle это overkill, а с учетом цены лицензий вообще выглядит плохой идеей. Да и объемы них не космические 80млн записей, даже если каждая по МБ (что очень много), то 80 ГБ всего. C>Ну вообще-то, 80Тб всего. Что тоже не сильно чтобы много.
Там большая часть по объему наверняка снимки и томограммы. И от БД требуется исключительно их хранить. Понятно что для такого РСУБД изрядкный оверкилл, а вот в случае nosql задачка просто идеально подходит.
G>>Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут. C>Никто не мешает взять RDS или всякие Data Warehosing решения для оффлайновых запросов для отчётов, а оперативный процессинг перевести на быстрые БД.
У оперативного процесса очень много коллизий + распределенные транзакции. NoSQL не поедут.
Жопа для производителей РСУБД в другом. Объемы данных какие были, такие и остались, сильно не выросли. И если, простой пример, раньше в оперативном учете трахались по черному с онлайновыми кубами, выдумывая всякие хитро выделанные кеши с кучей танцев по их поддержанию, то теперь железо такое, что для типичной средней конторы способно легко и непринужденно перемалывает всю историю в реальном времени, тупо подняв все горячие данные в память.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinclair, Вы писали:
S>Я правильно понимаю, что вы сравниваете oracle 2013 года с MS SQL 2011? S>На всякий случай, поясню, что MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад. В разное время все из большой тройки побывали в лидерах, поэтому с уверенностью судить о том, кто слабее сейчас, я бы не стал.
Ваш вывод — "MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад", поэтому могут быть на уровне или сильнее?
Обратные выводы напрашиваются сами собой
Здравствуйте, a_g_99, Вы писали:
__>1) PostgreSQL не хватает производительности oracle + timesten, а в фин. секторе это многое значит. Там если ты второй, считай ты последний.
С чего бы это? Или ты считаешь что на HFT фин. сектор заканчивается?
__>2) ведение журналов, надежность, professional support. если компания хочет получить это придется купить oracle или ibm db2.
Э, ты ж сказал что если второй, то последний. Так откуда "или" взялось?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Cyberax, Вы писали:
AVK>>Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью. C>Не согласен.
Ради бога.
C>Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.
Ну а в NoSQL тебе придется джоин делать руками. Ну так руками можно джойнить и в РСУБД.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, 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, о чём речь и идёт.
Здравствуйте, a_g_99, Вы писали:
AVK>>С чего бы это? Или ты считаешь что на HFT фин. сектор заканчивается? __>С того что обычно решение о приобретении такого софта принимают люди с тугим кошельками, маленькими мозгами, не имеющие к ИТ почти никакого отношения.
Однако практика подсказывает, что на этом рынке все таки не один единственный продукт присутствует.
__> sql server и postgres/symfoware в тестах tpc-c явно слабее.
Тем не менее sql server имеет свой вполне ощутимый кусок рынка. Опять же, в плане Price/Performance mssql слабее не выглядит.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, 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>На всякий случай, поясню, что MS перестала участвовать в TPC-C соревнованиях три мажорных версии назад. В разное время все из большой тройки побывали в лидерах, поэтому с уверенностью судить о том, кто слабее сейчас, я бы не стал.
TPC-C нынче перестал быть репрезентабельным совсем.
Здравствуйте, 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ТБ.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, novitk, Вы писали:
N>>Например? Нужна популярность, масштабируемость и язык запросов. Hbase не имеет последнего, а к всяким Infobright есть вопросы по первым двум.
M>Если под языком запросов понимать SQL то прикручивать его к колоночным базам данных это на редкость плохая идея.
Что за бред? В MS SQL сделали clustered columnstore индексы, по сути поколоночное хранение данных, с ним нормально SQL работает, да еще и batch execution.
Здравствуйте, Cyberax, Вы писали:
C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition
C>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
C>Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
C>Discuss.
Готов поверить. Обязательно пощупаю этот самый Riak. Oracle вырос (или, скорее, распух) до совершенно неприличных монструозных размеров и держится благодаря в основном хорошему маркетингу и огромному количеству инсталляций.
Банкинг, действительно, прекрасно может работать без чудовищных накладных расходов, которые неизбежны при пользовании Oracle-ом. Все-таки двадцать лет разработки именно для банкинга (в т.ч. для очень крупных структур) дают мне некоторое право так думать. По большому счету, кроме некоторых массовых операций (начисление %% и процессинг) большая часть банковских операций совершенно не требовательны к мощности БД. PostgreSQL или MySQL прекрасно тянут объемы в разы большие, чем банку потребны и при том с нормальной скоростью (да еще остается большой запас).
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, Cyberax, Вы писали:
C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition
Здравствуйте, Cyberax, Вы писали:
C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition
C>Следующий на очереди — это классический банкинг.
такое впечатление что у них весь минздрав\банкинг\другое на одном сервере с одной бд с тремя табличками.
Здравствуйте, Stanislaw K, Вы писали:
C>>Следующий на очереди — это классический банкинг. SK>такое впечатление что у них весь минздрав\банкинг\другое на одном сервере с одной бд с тремя табличками.
Оно примерно так и есть Табличек, конечно, побольше — у них ещё там авторизация и управление доступом есть.
Здравствуйте, Cyberax, Вы писали:
C>Следующий на очереди — это классический банкинг.
Это вряд ли. Между плохо структурированной мединформацией и банковскими данными есть очень существенная разница.
C> Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL
Падажди, ты ж в сабже заявил что RDB fail.
У постгри, при всех его достоинствах, с масштабируемостью пока не очень хорошо.
C>Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
Ага, языком.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Cyberax, Вы писали:
C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition
C>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Хм, если им для хранения данных оказалось достаточно просто свалки key-value, без транзакций, без гарантий надежности, вообще без всего — то даже страшно подумать, а зачем вообще NHS был нужен Oracle, да еще и на десять млн. долларов.
И, главное, а кто будет отвечать за потерю данных и потерю целостности
Здравствуйте, gandjustas, Вы писали:
C>>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition G>Этож простейшая система
Ну таки не совсем простейшая.
G>Естественно делать такое на Oracle это overkill, а с учетом цены лицензий вообще выглядит плохой идеей. Да и объемы них не космические 80млн записей, даже если каждая по МБ (что очень много), то 80 ГБ всего.
Ну вообще-то, 80Тб всего. Что тоже не сильно чтобы много.
C>>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти. G>Потому что задача по нынешнем меркам маленькая. А 10 лет назад те же величины были офигенно большими.
Ну да, только за 10 лет оказалось, что большая часть понтов из Оракла не особо-то и нужна.
G>Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут.
Никто не мешает взять RDS или всякие Data Warehosing решения для оффлайновых запросов для отчётов, а оперативный процессинг перевести на быстрые БД. Собственно, в большинстве банков так всё и устроено.
C>>Discuss. G>Учитывая что РСУБД сейчас начинают применять inmemory технологии, то могут через 5-10 лет отжать рынок небольших и несложных систем у NoSQL. А могут и не отжать, зависит от цены впороса.
Могут, но при этом станут неотличимы от этих самих NoSQL.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition G>>Этож простейшая система C>Ну таки не совсем простейшая.
Судя по описанию там было 5-10 таблиц, не считая справочников. В средней CRM системе гораздо больше.
G>>Естественно делать такое на Oracle это overkill, а с учетом цены лицензий вообще выглядит плохой идеей. Да и объемы них не космические 80млн записей, даже если каждая по МБ (что очень много), то 80 ГБ всего. C>Ну вообще-то, 80Тб всего. Что тоже не сильно чтобы много.
80ТБ это файлы. Они и так отдельно лежат. Структурированных данных от силы на 80ГБ.
C>>>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти. G>>Потому что задача по нынешнем меркам маленькая. А 10 лет назад те же величины были офигенно большими. C>Ну да, только за 10 лет оказалось, что большая часть понтов из Оракла не особо-то и нужна.
Правильно, 10 лет назад они были нужны, сейчас — нет. Объем структурированных данных в подобной системе растет медленно, железо за 10 лет выросло гораздо сильнее.
G>>Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут. C>Никто не мешает взять RDS или всякие Data Warehosing решения для оффлайновых запросов для отчётов, а оперативный процессинг перевести на быстрые БД. Собственно, в большинстве банков так всё и устроено.
Промышленные СУБД обычно предлагают решения все-в-одном и не надо возиться с кучей разных систем и их интеграцией. Именно на таком классе задач дорогие СУБД и выигрывают. А на простых задачах, где все структурированные данные влезают в память одного серевера, нету сложных связей, большой конкурентности доступа и нету требований транзакционности, может как-то вырулить NoSQL, и то только за счет стоимости.
Я думаю, что если бы оракл для был бесплатен, то о переезде на Riak не было бы речи.
C>>>Discuss. G>>Учитывая что РСУБД сейчас начинают применять inmemory технологии, то могут через 5-10 лет отжать рынок небольших и несложных систем у NoSQL. А могут и не отжать, зависит от цены впороса. C>Могут, но при этом станут неотличимы от этих самих NoSQL.
Не станут. РСУБД таки сфокусированы на надежность, а NoSQL пока что сфокусированы на маркетинговые понты.
C>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
C>Следующий на очереди — это классический банкинг.
Я думаю следующая на очереди — опять медицина, и назад на Oracle Во первых это госпроект, а значит попил. Во-вторых всем будет хорошо если мода на всякие умные часы, браслеты и прочие, приведёт к тому что эти устройства начнут сливать в медицинскую БД реал-тайм данные о своих владельцах, предупреждая возникновение многих заболеваний. Внезапно выяснится что с таким потоком медицинских данных всё ложится, и назад на что-то монструозное
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут. C>Никто не мешает взять RDS или всякие Data Warehosing решения для оффлайновых запросов для отчётов, а оперативный процессинг перевести на быстрые БД. Собственно, в большинстве банков так всё и устроено.
Именно так и делается. Небольшие банчки с мизерными объемами транзакций (скажем, до 5-7 тысяч в день) еще могут позволить себе все херячить на одном сервере; но на то они и "небольшие" и тем более "банчки". Правда, периодически (как правило, в конце месяца, когда начисляются проценты, резервы и по 1000 раз на дню рассчитываются фф.101 и 102 с целью накрутить хоть какую-то прибыль) сервер загружен весьма и весьма сильно.
А вот когда объемы транзакций реально большие, то тут уже надо разделять обработку транзакций и расчет аналитики. Но расчет аналитики — это по сути невъ..нные выборки с небольшим количеством арифметики и тут никаких требований к целостности не требуется, т.к. данные на 99% читаются, но не пишутся.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, Cyberax, Вы писали:
C>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition
Я что-то не совсем понял. У них нода в режиме enterprise + саппорт на полгода стоит 12k? Они рекомендуют 5 нод для старта это 60k. Средненькое серверное железо удвоит эту сумму.
За эти деньги можно взять парочку oracle se или один enterpris, который покроет их потребности за счет простого вертикального масштабирования. Где выгода?
C>Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
1) PostgreSQL не хватает производительности oracle + timesten, а в фин. секторе это многое значит. Там если ты второй, считай ты последний.
2) ведение журналов, надежность, professional support. если компания хочет получить это придется купить oracle или ibm db2. либо нанять команду людей которые создадут нечто подобное для postgre (что гораздо дороже)
Здравствуйте, AndrewVK, Вы писали:
AVK>Падажди, ты ж в сабже заявил что RDB fail. AVK>У постгри, при всех его достоинствах, с масштабируемостью пока не очень хорошо.
C HAProxy все хорошо. Я бы сказал PostgreSQL + HAProxy также хорошо масштабируется как и Oracle RAC. Только это не out-of-box feature
Здравствуйте, Cyberax, Вы писали:
C>Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
Конкретизируемся от сферических коней современным примером. Система не моя, но знаю детали так как ей руководит мой приятель.
Дата-склад система в большом инвест-банке. Хранит ежедневные риск-метрики (~100 чисел в среднем) к каждому активному контракту в течении 5 лет. Запросы — выборки с агрегацией по книжкам, портфелям, контрагентам. OLTP не нужен, загрузка данных происходит только в строго определенное время пакетами. В данный момент система покрывает только часть бизнеса и занимает ~100ТБ. Если масштабировать ее на весь банк будет ~х8. Используют оракл на мегабаксе железа (RHat/x86-64, не "золотое" от оракл). Несмотря на это половина команды непрерывно занята оптимизацией.
Здравствуйте, fplab, Вы писали:
C>>Никто не мешает взять RDS или всякие Data Warehosing решения для оффлайновых запросов для отчётов, а оперативный процессинг перевести на быстрые БД. Собственно, в большинстве банков так всё и устроено. F>Именно так и делается. Небольшие банчки с мизерными объемами транзакций (скажем, до 5-7 тысяч в день) еще могут позволить себе все херячить на одном сервере; но на то они и "небольшие" и тем более "банчки". Правда, периодически (как правило, в конце месяца, когда начисляются проценты, резервы и по 1000 раз на дню рассчитываются фф.101 и 102 с целью накрутить хоть какую-то прибыль) сервер загружен весьма и весьма сильно.
Простенький кластер на PostgreSQL держит десяток тысяч транзакций в секунду. Это уже уровень большого банка.
Здравствуйте, a_g_99, Вы писали:
C>>Тут недавно NHS (британский минздрав) переключился с Oracle БД на Riak для хранения медицинских данных пациентов — http://systems.hscic.gov.uk/spine/transition __>Я что-то не совсем понял. У них нода в режиме enterprise + саппорт на полгода стоит 12k? Они рекомендуют 5 нод для старта это 60k. Средненькое серверное железо удвоит эту сумму.
Да, для масштаба страны вполне адекватно.
__>За эти деньги можно взять парочку oracle se или один enterpris, который покроет их потребности за счет простого вертикального масштабирования. Где выгода?
ROTFL. А на чём оно будет "вертикально масштабироваться"? На воздухе, или ему ещё купить кластерочек за мегабакс и пару пучков консультантов по $500 в час?
Вот потому Оракл и сливается в канализацию.
__>1) PostgreSQL не хватает производительности oracle + timesten, а в фин. секторе это многое значит. Там если ты второй, считай ты последний.
Всего хватает. Если речь идёт о финансах, то там важны не in-memory данные, а надёжность.
__>2) ведение журналов, надежность, professional support. если компания хочет получить это придется купить oracle или ibm db2. либо нанять команду людей которые создадут нечто подобное для postgre (что гораздо дороже)
ROTFL. Так что когда эта мега-система упадёт — придётся просить помощи в web'е, так как даже сами консультанты разработчика не знают где искать концы. См.: "Сбербанк".
Здравствуйте, 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>Ага, а то что таки выросло — оказалось обрабатывать РБД-шныеми методами не очень удобно.
Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
C>>Ну вообще-то, NoSQL есть поддерживающие целостность и распределённые транзакции. AVK>Мы это все в свое время обсуждали. Там либо гарантии фиговые, для оперденей в принципе не пригодные, либо перформанс тут же скатывается до уровня плохих РСУБД. Чудес не бывает, за все надо платить.
Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга.
C>> Но именно для OLTP реляционки имеют смысл. AVK>Ну так опердень это и есть классический OLTP.
Да, с него РБД никто не собирается убирать.
C>>Ага, а то что таки выросло — оказалось обрабатывать РБД-шныеми методами не очень удобно. AVK>Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно.
Не совсем. РСУБД предполагает, что данные хранятся в однородных таблицах, которые можно джойнить. Если есть петабайт данных, то это уже не так — нужно делать тот или иной шардинг, а произвольные join'ы становятся неоправданно дорогими.
Здравствуйте, Cyberax, Вы писали:
C>Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга.
Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью.
AVK>>Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно. C>Не совсем.
Совсем.
C> РСУБД предполагает, что данные хранятся в однородных таблицах, которые можно джойнить.
Если данные хорошо структурированы
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
C>>Ну таки у NoSQL есть некоторые удобные фишки, типа лёгкого шардинга. AVK>Все сложности шардинга в РСУБД как раз и связаны с транзакциями, а вовсе не с реляционной моделью.
Не согласен.
AVK>>>Не знаю откуда такой вывод. Если данные хорошо структурированы, с удобством у РСУБД все прекрасно. C>>Не совсем. AVK>Совсем.
Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.
Можно использовать стратегию с разделяемым хранилищем, но тогда проблема с тем, что уже оно станет узким местом.
Здравствуйте, 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.
Здравствуйте, Cyberax, Вы писали: C>Вот у тебя табличка на 10Тб, которая хранится на 4 машинах (шардинг по ID) — пусть это будет табличка AdView с записями просмотра рекламы. Нужно из неё сделать join на другую таблицу, пусть будет Users, которая хранится на других 4 машинах. Это означает, что в кластере будет примерно тонна кросс-траффика между узлами.
А можно пример "реального" запроса c join?
Это что, типа "покажи мне адреса top-100 пользователей по количеству просмотров баннера #12323451"?
Если нет — то приведите "на пальцах" такой запрос. И примерный план его выполнения на NoSQL, который помогает избегать "тонны кросс-траффика между узлами".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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
и сделать вывод, что явно слабее тут Оракл?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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"?
Дал почитать эту тему нашему клиенту — он мне сразу сказал какой запрос они сегодня писали: "найти пользователей, у которых минимальное[или среднее] время между кликами на баннеры меньше среднего для всех пользователей".
Здравствуйте, 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, Вы писали:
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-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Некая организация перещла с неподходящей им системы на бодее подходящую. Ничего из ряда вон выхолящего.
Здравствуйте, AndrewVK, Вы писали:
AVK>Для этого никакой джойн не нужен.
Давай подождём уточняющих ответов.
Если я правильно понимаю, то там хватит distributed partitioned views, и трафик будет вполне себе приемлемым.
Более того — запросто может оказаться, что RDBMS работает с 10ТБ безо всякого шардинга, благодаря использованию индексов. А тупой NoSQL способен хоть как-то прожевать запрос только в том случае, если у него все 10Tb влезают в RAM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>Можно сделать хоть какой-нибудь транслятор, а оптимизировать только то что необходимо путем переписывания запросов с SQL на M/R вручную.
Возникает куча вопросов интеграции SQL и ручного М/R. Скажем смогу ли я сделать вьюху на ручном М/R и использовать ее в SQL?
А вообще есть ли факты что SQL проигрывает ручному M/R на реляционной модели с современными оптимизаторами? Я вполне могу понять, что row backstore или полный ACID для задачи может быть не оптимален, но SQL то за что?
Табличек, конечно, побольше — у них ещё там авторизация и управление доступом есть.
