При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
Здравствуйте, 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
Этож простейшая система
Естественно делать такое на Oracle это overkill, а с учетом цены лицензий вообще выглядит плохой идеей. Да и объемы них не космические 80млн записей, даже если каждая по МБ (что очень много), то 80 ГБ всего.
C>При этом был существенно улучшен уровень сервиса и сэкономлено около десяти миллионов на лицензиях. ВНЕЗАПНО оказалось, что весь "serious business" из Oracle'а, который в 90-е годы был внушительным, сейчас оказался тривиальным. Вполне можно поддерживать инфраструктуру в масштабах целой страны на обычнейшем OpenSource-стеке без каких-либо экзотических бизнес-консультантов и мэйнфреймов за миллиарды нефти.
Потому что задача по нынешнем меркам маленькая. А 10 лет назад те же величины были офигенно большими.
C>Следующий на очереди — это классический банкинг. Опердени для обычного банка прекрасно могут обрабатываться совершенно скучным кластером серверов на PostgreSQL, даже для самых крупных банков. Коммутация финансовых сообщений в масштабах страны — тривиальная задача для почти любого брокера сообщений. Конечно, остаются требования по ведению журналов и надёжности, но они тоже ну никак не являются чем-то суперсложным.
Бред сивой кобылы. В банкинге очень много аналитических запросов и БД, не влезающие в память сервера. Почти все NoSQL на этом умрут.
C>Discuss.
Учитывая что РСУБД сейчас начинают применять inmemory технологии, то могут через 5-10 лет отжать рынок небольших и несложных систем у NoSQL. А могут и не отжать, зависит от цены впороса.
Здравствуйте, 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, Вы писали:
G>>Учитывая что РСУБД сейчас начинают применять inmemory технологии, то могут через 5-10 лет отжать рынок небольших и несложных систем у NoSQL. А могут и не отжать, зависит от цены впороса. C>Могут, но при этом станут неотличимы от этих самих NoSQL.
Транзакции и прочие isolation levels со всякими constraints — т.е. всё то, чем в NoSQL и не пахнет — никуда не денутся ж? При этом ЕМНИП ты сам же не так давно рассказывал, что с последними патчами в выборке записи по ключу PostgreSQL догнал по скорости Mongo.
Здравствуйте, 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, Вы писали:
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>>
Здравствуйте, 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, Вы писали:
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'е, так как даже сами консультанты разработчика не знают где искать концы. См.: "Сбербанк".
Табличек, конечно, побольше — у них ещё там авторизация и управление доступом есть.
