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

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

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

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

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