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

G>>Этож простейшая система
C>Ну таки не совсем простейшая.

Тут дело не столько в простоте, сколько в отсутствии жесткой структуры. ПОиск по большей части данных все равно полнотекстовый, так что от непосредственно реляционного движка толку не очень много.
Еще один очень важный момент — вероятность коллизий при записи для медбаз близка к 0, это категорически, просто таки принципиально все упрощает. Большая часть наворотов промышленных РСУБД в таком режиме крутится вхолостую. Из пушки по воробьям.

G>>Естественно делать такое на Oracle это overkill, а с учетом цены лицензий вообще выглядит плохой идеей. Да и объемы них не космические 80млн записей, даже если каждая по МБ (что очень много), то 80 ГБ всего.
C>Ну вообще-то, 80Тб всего. Что тоже не сильно чтобы много.

Там большая часть по объему наверняка снимки и томограммы. И от БД требуется исключительно их хранить. Понятно что для такого РСУБД изрядкный оверкилл, а вот в случае nosql задачка просто идеально подходит.

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

У оперативного процесса очень много коллизий + распределенные транзакции. NoSQL не поедут.

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